Re: [cross-project-issues-dev] Will Your Project Work When Running on Ja

["Thomas Watson" <tjwatson@xxxxxxxxxx>]

> From: Ed Merks <ed.merks@xxxxxxxxx>
> During testing I also see this stack trace in
my Error log:
> 
> java.lang.reflect.InaccessibleObjectException: Unable to make field
> private static volatile java.net.Authenticator 
> java.net.Authenticator.theAuthenticator accessible: module java.base
> does not "opens java.net" to unnamed module @26749efe
>     at java.base/
> java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:
> 335)
>     at java.base/
> java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:
> 278)
>     at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:175)
>     at java.base/java.lang.reflect.Field.setAccessible(Field.java:169)
>     at 
> org.eclipse.epp.internal.mpc.core.util.ProxyHelper.getDefaultAuthenticator(ProxyHelper.java:
> 116)

> I'm not sure what to make of that, but it suggests that MPC might
> well not function when running on Java 9. 
> So in the end, I think there isn't so much to
worry about, but 
> nevertheless, I strongly encourage each team to test their project's
> readiness so we can all avoid hassles and embarrassment when Java
9 
> is finally released.  I've tried to help make that as easy as
possible...

> Regards,
> Ed

This is an indication that ProxyHelper is using reflection
on some internal types of java.net.Authenticator.  Looks like it is
to unset itself from the private static field java.net.Authenticator.theAuthenticator.
 This likely is happening on shutdown and the ProxyHelper is just
trying to clean up the VMs static field.  In the Eclipse Platform
case this is not a big deal that it failed because the VM is going to terminate
anyway so there is no concern that ProxyHelper could not clean up from
the awful static instance in the VM.

I had to work around a similar issue in the Equinox
Framework in order to clean up our URLStreamHandlerFactory implementation
[1].  I did horrendous things by using the Unsafe class to get around
this.  There is a temporary option in Java 9 (--force-open-all-module-packages)
that should force all packages from modules in the boot layer to be open
for deep reflection on private types.  You can try this option out
to see if it works around the issue.  They say this option will be
removed in a future release so I don't think it is a viable long term solution.
 You could also try using the more specific option --add-opens:

--add-opens java.base/java.net=ALL-UNNAMED

The commandline help for --add-options does not state
that ALL-UNNAMED is a valid target so it may not work, but the similar
options --add-reads and --add-exports do state ALL-UNNAMED is a valid target
so it may work.  Even this is not a great option because in the future
we may try to get the bundles to be loaded as real named modules [2] (note
this article is out of date and some of the details have changed significantly).
 In that case you would have to be more specific and list the symbolic
names of the bundles that need to do deep reflection.

Tom

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=502209
[2] https://www.eclipse.org/community/eclipse_newsletter/2016/october/article3.php