| Re: [jakartaee-tck-dev] [External] : Re: Which JVMs support eager class loading? |
IMO, it will be good to consult JDK forums to know on current JVM support for eager class loading. We can try on JDK documentation, but not much martial with specifics on JVM configuration on support for eager class loading is available as per my knowledge.
Even if we find that there are no JVM implementations using eager
class loading, there still could be a future JVM that uses eager
class loading as it is allowed by the latest JVM
Spec.
Also IMO, would be great if SPEC's highlight their dependency on JDK security manager if any.
https://docs.google.com/document/d/1m-dkvbL0iFFzitO4vt1SVq6GGSJyFdCDM2NU_FzGS10/edit?pli=1# mentions the Security SPEC but agreed other will need to do the same for EE 11.
regards,Guru
From: jakartaee-tck-dev <jakartaee-tck-dev-bounces@xxxxxxxxxxx> on behalf of Scott Marlow <smarlow@xxxxxxxxxx>
Sent: 09 October 2022 18:11
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Subject: [External] : Re: [jakartaee-tck-dev] Which JVMs support eager class loading?
On Fri, Oct 7, 2022, 4:21 PM Ondro Mihályi <mihalyi@xxxxxxxxxxx> wrote:
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.
So the only solution for eager JVM class loaders is updating the SPECs to not use the security manager which is likely to be in the next major release.
If the various TCKs do a service release to remove the security manager or make it possible to run with our it, that will be only for the lazy JVM class loaders.
Thanks for the feedback. If anyone knows of any current JVMs that support eager class loading, please speak up.
Scott
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: https://stackoverflow.com/questions/16771373singleton-via-enum-way-is-lazy-initialized
All the best,Ondro
_______________________________________________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:
From https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html
"
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."
Scott
Scott
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________ jakartaee-tck-dev mailing list jakartaee-tck-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev