[9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible.
daniel.fuchs at oracle.com
Thu Dec 4 11:38:43 UTC 2014
In fact I could use 'null' on JDK 9 as well.
My first version of the JDK 9 test was parsing over all the .jimage
files under <jdk>/lib/modules - which explain why I needed to
use the System class loader.
Then I switched to only parsing the bootmodules.jimage - because
I noticed that the results where more coherent with what I had
observed on 8 & 7 - but I kept using the System class loader.
I am not sure whether we want the test for 9 should iterate over
the three .jimage - or continue to test only the boot .jimage.
I have updated the JDK 9 test (refreshed the webrev in place)
and added support for possibly running the test in the two modes
(I added a 'test.boot.only' system property, true by default)
as well as additional traces to print the loaded classes by
defining loader at the end (test.list.classes, false by default).
Thanks for your question, it triggered me into looking deeper
into what was happening :-)
On 04/12/14 10:05, Daniel Fuchs wrote:
>>> The differences between 8 & 9 are limited to:
>>> - ClassLoader:
>>> - on 8 we use 'null' (BCL)
>>> - on 9 we use the system class loader.
>> I haven't seen anything in JEP 220, regarding modules, that indicates
>> that classes currently loaded by the boot-loader will now be loaded
>> by the system classloader ???
> In  towards the end:
>  http://openjdk.java.net/jeps/220
> "The defining class loader of the types in some existing packages
> will change. Existing code that makes assumptions about the class
> loaders of these types might not work correctly."
> (then there is a list of specific changes).
> This test looks up all class names in the image files and attempt
> to load the corresponding class. But as indicated in 
> some of these classes are now in the Boot CL, some in the
> Extension CL, and some in the Application CL.
> So the test uses the System CL to load each class - which ensures
> that the loading will be delegated to the appropriate ClassLoader.
> best regards,
> -- daniel
More information about the core-libs-dev