0

When asking When are enums first created?

The answer is: When the enum class is first loaded.

Then when asking: When are enums first loaded?

the answer seems to be: When they are.

The JVM helps us instantiate enumeration types when they are loaded

enum values are constants created once at runtime, during the initialization phase of the enum class loading.

When looking deep into the concept of "loading" we come across "Loading, Linking, and Initializing", and so the clear implication seems to be that loading happens "when it is first needed".

The reason why I am asking this is because I came across a post in which someone wrongfully thought that enums were loaded on to Metaspace before the first line of a program was executed.

And I never even noticed it, but I realized that I had the same thought process, and some of the answers in that post seem to imply that whenever an enum or private static constant are present as a field inside a class, then that class is bound to a synchronization performance hit for each and every instance concurrently created of said class, if and only if multiple instances are being created for the first time (in a concurrent manner), so that each object gets the same instance of the enum and/or static constant.

So the question: If the compiler has all the code information before executing the program, why does it chooses to load constants and enums whenever they are first needed?

Is this done out of uncertainty that maybe the code will not execute, saving memory space if it doesn't?

Delark
  • 1,141
  • 2
  • 9
  • 15
  • 4
    I mean, the most obvious reason is "because there are rules in the Java language spec about initialization order, in case you do weird side-effecting things in class initialization, and you have to stay consistent with those rules." – Louis Wasserman Jul 11 '22 at 18:39
  • 1
    I don’t know where get the idea about the “synchronization performance hit” from, as none of the linked answers says anything about it. Since this performance hit doesn’t exist, there is no need to optimize anything about it. Besides that, it’s not clear what “the compiler” is in your reasoning. The source code compiler? It knows which enum types you’re compiling, but how is it supposed to tell the JVM to load something before starting the program? The JIT compiler? How is it supposed to know beforehand, which enum types exist in your program? – Holger Jul 12 '22 at 10:11
  • I admit my knowledge of the compiler and/or interpreters are very limited to try to justify my reasoning, having said this I am aware that the source code crosses multiple translations until it becomes something that the processor can understand. I thought it was in one of these steps (maybe from source to bytecode since the compiler scans the entirety of the source code for errors) that the loading process of constants was defined. I don't think it is a good idea to link the comment about sync here, but if you @Holger tell me there is none, I definitely trust your voice on this. – Delark Jul 12 '22 at 19:44
  • 1
    But you should know that with Java, the source files get compiled to a bunch of `.class` files and that the common deployment form, `.jar` files, is just a zip file containing the `.class` files, additional resources, and some meta information. Then, you launch an application by specifying a classpath and/or module path containing one or more `.jar` files or directories containing `.class` files. The next launch, you could omit a path element or add one. This standard setup has no global registry of enum types and searching the entire path on startup would be very expensive, for little benefit – Holger Jul 13 '22 at 09:22
  • 2
    Maybe confusion about synchronization overhead came from the fact that the specification’s guarantees wrt initialization thread safety are described formally in terms of lock acquisition but eliminating such overhead once completed is so ubiquitous that it is even [mentioned in the specification](https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-5.html#jvms-5.5-300): “*A Java Virtual Machine implementation may optimize this procedure by eliding the lock acquisition in step 1 (and release in step 4/5) when it can determine that the initialization of the class has already completed, …*” – Holger Jul 13 '22 at 09:40

0 Answers0