A class is accessable from another?

Remi Forax forax at univ-mlv.fr
Sun Jan 3 13:37:17 UTC 2016


Hi Yuting,
the way IBM VM (J9) and OpenJDK VM (Hotspot) verify classes is different.
J9 is more lazy, by example, it only verifies a method the first time you execute it and not upfront when you load the class containing the method, as Hotspot does.

Note that both semantics are valid because the Java spec only requires something to be verified before being executed.

cheers,
Rémi

----- Mail original -----
> De: "陈雨亭" <chenyt at cs.sjtu.edu.cn>
> À: hotspot-runtime-dev at openjdk.java.net, "ioi lam" <ioi.lam at oracle.com>
> Envoyé: Dimanche 3 Janvier 2016 13:41:36
> Objet: Re: A class is accessable from another?
> 
> Hi, Ioi,
> 
> In fact I raised the similar question two months ago:
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-October/016082.html
> 
> But at that time a private inner class
> sun/java2d/pisces/PiscesRenderingEngine$2 (corresponding to
> private static enum NormMode {OFF, ON_NO_AA, ON_WITH_AA}) is put in
> the "main" method. Still, JDK complains, but IBM's SDK
> does not. It seems that some JVMs may omit these
> inaccessable classes even if they are in the main method.
> 
> Regards,
> Yuting
> 
> -----Original Message-----
> From: 陈雨亭
> Sent: Sunday, January 03, 2016 8:21 PM
> To: hotspot-runtime-dev at openjdk.java.net ; ioi.lam at oracle.com
> Subject: Re: A class is accessable from another?
> 
> Thank you, Ioi.
> 
> (1) I rechecked the code. HotSpot complains when I put
> java.lang.AbstractStringBuilder to any method (e.g., run()), while
> J9 complains only when I put java.lang.AbstractStringBuilder to
> the "main" method. Indeed, they take different strategies, although
> they should be some compatible to each other.
> 
> So, should HotSpot complain if the class AbstractStringBuilder is not
> accessable at runtime? I guess AbstractStringBuilder is still usable
> (and it also has no effects to the main method) because in JVM
> specification,
> "5.4.3.1 Class and Interface Resolution",
> 
> To resolve an unresolved symbolic reference from D to a class or interface C
> denoted
> by N, the following steps are performed:
> 1. The defining class loader of D is used to create a class or interface
> denoted by
> N. This class or interface is C. The details of the process are given in
> §5.3.
> Any exception that can be thrown as a result of failure of class or
> interface
> creation can thus be thrown as a result of failure of class and interface
> resolution.
> 2. If C is an array class and its element type is a reference type, ...
> 3. Finally, access permissions to C are checked.
> • If C is not accessible (§5.4.4) to D, class or interface resolution
> throws an
> IllegalAccessError.
> ...
> If steps 1 and 2 succeed but step 3 fails, C is still valid and usable.
> 
> (2) Thank you for your answer. GraphicsPrimitive$TraceReporter
> has been changed to "implement Runnable".
> 
> Yuting
> 
> 


More information about the hotspot-runtime-dev mailing list