Unexpected ClassnotFoundException on reflective Class#getMethod

[Alan Bateman]

On 31/03/2016 11:20, Sanne Grinovero wrote:
> Thanks Alex,
> that clarifies a lot, I was just about to try with a different dependency.
>
> So this is not a reflection bug, but I'm just realising now that has
> quite significant impact on JavaEE:
> the Synchronization type is defined as public API of the specification [1].
>
> Changing the JavaEE API isn't going to be very popular, so I guess the
> expectation is for
> containers to regularly override the modules?
> This won't affect just the regular EE application servers, as these
> APIs are often used also
> in standalone JavaSE applications, as many components of the JavaEE spec can
> be run in "standalone" or "embedded" modes.
>
> For example Hibernate will now have to require the application launcher to apply
> customizations to the JVM boot parameters, and probably so any other JPA
> implementation.
>
> 1 - http://docs.oracle.com/javaee/7/api/javax/transaction/Synchronization.html
>
Java EE implementations have always upgraded/replaced a number of APIs 
that are "shared" with Java SE. The JSR-250 defined "Common Annotations" 
is another example where Java SE defines a subset of the API and Java EE 
implementations need the deploy with the full API.  So there isn't 
anything forcing anyone to change APIs, this is really just about how to 
compile or run with the Java EE versions of these components.

With JDK 8 and older then the only supported way of upgrading these 
components was the Endorsed Standards Override Mechanism. It turns out 
that this wasn't widely used and instead app servers and others have 
been putting JAR files on the class path with these components. 
Incredibly this worked even though it wasn't actually overriding the 
classes in the Java SE defined subset.

Moving to modules means that EE servers will need to deploy with the EE 
versions of these modules. Adding the class path isn't going to work 
because the module system will prohibit splitting packages between 
modules and the class path. The way to do this is, as Alex mentioned, is 
the upgrade module path.

Patching will work too, at least to get something going. In this case 
you can patch the java.transaction module with:

    -Xpatch:java.transaction=transaction-api_1.2.jar

There aren't any additional packages exported in the EE version so 
-XaddExports isn't neded. The equivalent with the Common Annotations 
would need -XaddExports because the EE version has APIs in packages that 
Java SE does not define.

One final thing to mention is that there is a proposal in the works to 
not resolve the EE modules when compiling code in the unnamed module or 
running code where the initial class is on the class path. For existing 
deployments then it would looking like that the JDK doesn't have the EE 
modules. This isn't fully implemented in the current builds but it is a 
proposal that will make migration to JDK 9 much easier for many. For 
those using the EE components outside the context of an app server then 
it would mean using `-addmods java.se.ee` so that all of the EE modules 
are resolved. I'm sure there will be more on this topic soon.

-Alan