• cesarb 6 hours ago

    Part of this complexity comes from what IMO was a mistake on Java's design (which was AFAIK copied by C#): the base Object class does too much. It has equality comparison, string conversion, object hashing, and a per-object re-entrant lock. Other than equality comparison (which is also bad because it contributes to the perennial confusion between identity equality and value equality), these need extra storage for each and every object in the system (string conversion contains the object hash code as part of its default output). Some tricks are used to avoid most of the space overhead for the per-object lock, at the cost of extra complexity.

    • exabrial 7 hours ago

      I always kind of found it interesting that specifying the size of object fitters was part of the JVM specification. This sort of seems like an arbitrary implementation detail, since the programmer will never have to know anything about it.

      • papercrane 6 hours ago

        The JVM specification does not specify anything about how objects should be represented. The only time internal representation of objects is discussed in the JVM spec is section that says "The Java Virtual Machine does not mandate any particular internal structure for objects."

        In this case the JEP is scoped to just the hotspot runtime. Other implementations are free to represent objects however they want.

        https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.h...

        • exabrial 3 hours ago

          Ah! that makes sense, thanks!

      • undefined 7 hours ago
        [deleted]