Sharing experiences with the latest EA build // #ReflectiveAccessToNonExportedTypes #ResourceEncapsulation

[Alan Bateman]

On 30/09/2016 16:16, Rafael Winterhalter wrote:

>
>         With the newest EA build, out of 7000 unit tests, only
>         42 tests still fail and those are all because of using
>         non-exported API of
>         the JCL.
>
>     Just curious, what is "JCL" here?
>
>
> I mean "Java class library", the classes that are part of the JVM.
Are there many JDK internal APIs bring used? Are all these usages using 
core reflection (and so not found by jdeps).


>
> :
>
> I was using reflection for this functionality and offered a fallback 
> or offered a proper failure message. I did however manage to fix most 
> of these problems in the last hours by revisiting them. I am currently 
> down to a single failing unit test which relates to 
> Class.forName(typeName, false, classLoader) not returning its loaded 
> classes if the class loader is an instance of "DelegatingClassLoader". 
> I worked around this by reading the class containing vector for 
> instances of this class loader and wrote a unit tests that is no 
> longer executable. As it only affects the test, this does however not 
> really matter.
Is the DelegatingClassLoader that is used in the internal reflection 
implementation or is it something else?



> :
>
> I hope this is clear now from my above clarification. I was trying out 
> explicit, "proper" modules and added dependent jars as automatic modules.
Just on this, I'm interested to know if the modules names that were 
chosen for the automatic modules work out okay? When you migrated 
automatic modules to explicit modules then did you keep the module name?

-Alan