Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] Which JVMs support eager class loading?

Hi, Scott,

It's very rare that a JVM uses eager classloading. I don't know much about eager classloading from my own experience, but my research shows that, 11 years ago, IBM's JVM supported a JVM option to turn eager classloading on. I also think that it's possible to create a classloader that loads classes eagerly as soon as it finds them in the import. But I'm not sure if there are some classloaders out there which would do that. I can't think of any scenario where such a behavior would make sense.

Although it's technically possible that classes are loaded eagerly by some JVM or a classloader, I think that most of the world expects lazy classloading, for example in this stackoverflow answer:

All the best,

On Fri, Oct 7, 2022 at 3:10 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:

On 10/7/22 6:33 AM, Scott Marlow wrote:
Does anyone know which JVMs support eager class loading?

I like to see what happens when the Java Security Manager classes are removed from the JVM and the impact on EE 10 applications.  

I am pretty sure we will see ClassNotFoundException on Security Manager classes but I would like to see a test prove it.

For background on eager/lazy class loading look at the JVM SPEC, I think section 5.4 `Linking` is worth reading:



5.4. Linking

Linking a class or interface involves verifying and preparing that class or interface, its direct superclass, its direct superinterfaces, and its element type (if it is an array type), if necessary. Resolution of symbolic references in the class or interface is an optional part of linking.

This specification allows an implementation flexibility as to when linking activities (and, because of recursion, loading) take place, provided that all of the following properties are maintained:

  • A class or interface is completely loaded before it is linked.

  • A class or interface is completely verified and prepared before it is initialized.

  • Errors detected during linkage are thrown at a point in the program where some action is taken by the program that might, directly or indirectly, require linkage to the class or interface involved in the error.

For example, a Java Virtual Machine implementation may choose to resolve each symbolic reference in a class or interface individually when it is used ("lazy" or "late" resolution), or to resolve them all at once when the class is being verified ("eager" or "static" resolution). This means that the resolution process may continue, in some implementations, after a class or interface has been initialized. Whichever strategy is followed, any error detected during resolution must be thrown at a point in the program that (directly or indirectly) uses a symbolic reference to the class or interface.

Because linking involves the allocation of new data structures, it may fail with an OutOfMemoryError.



jakartaee-tck-dev mailing list
To unsubscribe from this list, visit

Back to the top