> From: Ed Merks <ed.me...@gmail.com> > 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
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
