Re: Better tools for adjusting to strong encapsulation
Mark, How do we (Oracle JDeveloper) turn these illegal reflective-access operation warnings off. We don't want or need these warnings when running JDeveloper except during specific developer sessions. BTW, the big kill switch doesn't seem useful, it just hides everything that needs work. Keimpe Bronkhorst On 3/21/2017 11:57 AM, jigsaw-dev-requ...@openjdk.java.net wrote: Warnings of illegal reflective-access operations When an illegal reflective access operation succeeds due to the use of the `--permit-illegal-access` option, or the use of an `--add-opens` or `--add-exports` option, then a warning message of the following form is written to the error stream: WARNING: Illegal access by $PERPETRATOR to $VICTIM (permitted by $OPTION) where: - $PERPETRATOR is the fully-qualified name of the type containing the code that invoked the reflective operation in question plus the code source (i.e., JAR-file path), if available, - $VICTIM is a string that describes the member being accessed, including the fully-qualified name of the enclosing type, and - $OPTION is the name of the command-line option that enabled this access, when that can be determined, or the first one of those options if more than one option had that effect. The run-time system attempts to suppress duplicate warnings for the same $PERPETRATOR and $VICTIM, but it's not always practical to do so. For deeper diagnosis you can request a stack trace on each such warning by setting the system property `sun.reflect.debugModuleAccessChecks` to the value `access`, though this detail might change. (That property can also be helpful to diagnose mysterious failures due to illegal-access exceptions that are caught and suppressed.) In addition to displaying a warning on each illegal access operation, the run-time system also shows new initial warning messages at startup time. If `--permit-illegal-access` is used then a warning reports the imminent demise of that option in the next major release. If either `--add-opens` or `--add-exports` are used then a warning reports a count of each type of option used (i.e., opens vs. exports). Here are some examples of these messages, from running Jython on a very recent Jigsaw build: $ java --permit-illegal-access -jar jython-standalone-2.7.0.jar WARNING: --permit-illegal-access will be removed in the next major release WARNING: Illegal access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD() (permitted by --permit-illegal-access) WARNING: Illegal access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to field sun.nio.ch.FileChannelImpl.fd (permitted by --permit-illegal-access) WARNING: Illegal access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to field java.io.FileDescriptor.fd (permitted by --permit-illegal-access) WARNING: Illegal access by org.python.core.PySystemState (file:/tmp/jython-standalone-2.7.0.jar) to method java.io.Console.encoding() (permitted by --permit-illegal-access) Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11) [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal Type "help", "copyright", "credits" or "license" for more information. >>> ^D $
Re: Better tools for adjusting to strong encapsulation
Thanks, Mark. We're in the middle of collecting necessary --add-opens, --add-exports and other options and only making some progress with removing the need for them. Warnings in JDK10 seems more appropriate. Keimpe Bronkhorst Oracle JDeveloper On 3/23/2017 2:13 AM, jigsaw-dev-requ...@openjdk.java.net wrote: -- Message: 4 Date: Wed, 22 Mar 2017 20:30:00 -0700 From: mark.reinh...@oracle.com To: jigsaw-dev@openjdk.java.net Subject: Re: Better tools for adjusting to strong encapsulation Message-ID: <20170322203000.424722...@eggemoggin.niobe.net> Content-Type: text/plain Thanks to everyone for all the feedback on this topic. It appears that issuing warning messages for illegal-access operations enabled by the precise `--add-opens` and `--add-exports` options is a bit too aggressive, at least for JDK 9. Perhaps we can enable that in JDK 10 after there's been more time for libraries, frameworks, and even the JDK itself to adjust to the realities of strong encapsulation. For now I suggest that we revert to the previous behavior of these two options, so that they do not cause warning messages to be issued. The new `--permit-illegal-access` option will continue to generate warning messages, as proposed. If those messages are a problem in a particular scenario then they can be eliminated by switching to an appropriate set of `--add-opens` options, which can be constructed from the information contained in those messages. Comments? - Mark
-XaddExports: not recognized in JavaVMInitArgs on Windows
I'm using build 9-ea+107-jigsaw-nightly-h4560-20160301 on Windows. I'm executing my program through jvm.dll using JavaVMInitArgs and JNI. I set JavaVMInitArgs.ignoreUnrecognized = JNI_FALSE and add -XaddExports:java.desktop/sun.awt=ALL-UNNAMED as one of the JavaVMInitArgs.options. This results in Unrecognized option: -XaddExports:java.desktop/sun.awt=ALL-UNNAMED If use JavaVMInitArgs.ignoreUnrecognized = JNI_TRUE, I run into the exception: Exception breakpoint: Reflection.java:467, java.lang.IllegalAccessException, class org.openide.util.RequestProcessor$TopLevelThreadGroup cannot access class sun.awt.AppContext (in module java.desktop) because module java.desktop does not export sun.awt to unnamed module @204f30ec Is this a known limitation at this time or should I file a bug? Keimpe Bronkhorst
Warning: Cannot use jsr199 Javac from jrt-fs.jar"
It is possible in JDK8 and before to run JSR199 compilations using a class loader that loads from tools.jar. I can't do something similar in JDK9 using a new jigsaw build, trying to load from jrt-fs.jar. I get this: Warning: Cannot use jsr199 Javac from jrt-fs.jar". Does this mean you can only use the JSR199 as provided by ToolProvider.getSystemJavaCompiler() of the current process in JDK9? Keimpe Bronkhorst JDeveloper
Re: Warning: Cannot use jsr199 Javac from jrt-fs.jar"
The underlying exception I get is: "Class oracle.jdevimpl.javacompiler.JDevJavaCompiler can not access a member of class com.sun.tools.javac.api.JavacTool (module jdk.compiler) with modifiers "public static", module jdk.compiler does not export com.sun.tools.javac.api to " Will there be a "public API" way to run JSR199 of any JDK9 installation? Keimpe Bronkhorst JDeveloper On 10/7/2015 6:54 PM, Keimpe Bronkhorst wrote: It is possible in JDK8 and before to run JSR199 compilations using a class loader that loads from tools.jar. I can't do something similar in JDK9 using a new jigsaw build, trying to load from jrt-fs.jar. I get this: Warning: Cannot use jsr199 Javac from jrt-fs.jar". Does this mean you can only use the JSR199 as provided by ToolProvider.getSystemJavaCompiler() of the current process in JDK9? Keimpe Bronkhorst JDeveloper
RE: Warning: Cannot use jsr199 Javac from jrt-fs.jar"
Jon, Users of JDeveloper want to be able to compile and run their code with any JDK on their filesystem, not just compile and run with the JDK JDeveloper is running on. The compile I could make work in JDK8 and before by getting a javax.tools.JavaCompiler from com.sun.tools.javac.api.JavacTool.create() all loaded through a classloader from tools.jar of the JDK the user wanted to use. I remember you previously mentioned you were considering a way to use JSR199 from any JDK other than the one of the current process. Keimpe Bronkhorst JDeveloper On 10/07/2015 06:01 PM, Keimpe Bronkhorst wrote: /The underlying exception I get is: />/"Class oracle.jdevimpl.javacompiler.JDevJavaCompiler can not access a />/member of class com.sun.tools.javac.api.JavacTool (module />/jdk.compiler) with modifiers "public static", module jdk.compiler does />/not export com.sun.tools.javac.api to " />//>/Will there be a "public API" way to run JSR199 of any JDK9 installation? />//>/Keimpe Bronkhorst />/JDeveloper />//>/On 10/7/2015 6:54 PM, Keimpe Bronkhorst wrote: />>/It is possible in JDK8 and before to run JSR199 compilations using a />>/class loader that loads from tools.jar. I can't do something similar />>/in JDK9 using a new jigsaw build, trying to load from jrt-fs.jar. I />>/get this: Warning: Cannot use jsr199 Javac from jrt-fs.jar". />>//>>/Does this mean you can only use the JSR199 as provided by />>/ToolProvider.getSystemJavaCompiler() of the current process in JDK9? />>//>>/Keimpe Bronkhorst />>/JDeveloper />// Keimpe, While we know that some "friends of javac" have been using its internal API, it would be good to know what specific internal features you have been using, so that we can see if there are alternatives on the public API, and maybe provide additional public API where appropriate. You can run tools like jdeps to find what dependencies you have on any internal API. -- Jon
Re: Warning: Cannot use jsr199 Javac from jrt-fs.jar"
Alan, If the user's project's JDK has a higher version than the JDK of JDeveloper, the compile is done out-of-process. Otherwise an in-process JSR199 is attempted. Yes, -source/-target/-Xbootclasspath (and now -release) for cross-compiling is another way, but it doesn't use the Javac of the user's project's JDK. The user can easily set up a cross-compile in JDeveloper, but some users want to use the actual Javac of their project's JDK. Keimpe Bronkhorst JDeveloper On 10/8/2015 1:36 PM, Alan Bateman wrote: On 08/10/2015 17:47, Keimpe Bronkhorst wrote: Jon, Users of JDeveloper want to be able to compile and run their code with any JDK on their filesystem, not just compile and run with the JDK JDeveloper is running on. I'm curious about this. If JDeveloper is running on JDK 7 for example and someone configures it to use a JDK 8 then would you have attempted to load from the JDK 8 tools.jar in that case? As JDK 7 doesn't know anything about 52.0 class files then I assume not. So maybe the loading from the target tools.jar was when the target JDK is the same or older than the version that the IDE is running? In that case I'm curious as to whether it can be made to use -source/-target/-Xbootclasspath instead of attempt to run the javac from the target JDK in the same VM. On JDK 9 then you have the wonderful new -release option to try too. -Alan.
Re: Warning: Cannot use jsr199 Javac from jrt-fs.jar"
Alan, I'm running JDeveloper with jigsaw build 1.9.0-ea-jigsaw-nightly-h3477-20150929-b83. Compiling in-process using JSR199 with a Javac from JDK8 tools.jar is working fine. Keimpe On 10/8/2015 2:27 PM, Alan Bateman wrote: On 08/10/2015 20:45, Keimpe Bronkhorst wrote: Alan, If the user's project's JDK has a higher version than the JDK of JDeveloper, the compile is done out-of-process. Otherwise an in-process JSR199 is attempted. Yes, -source/-target/-Xbootclasspath (and now -release) for cross-compiling is another way, but it doesn't use the Javac of the user's project's JDK. The user can easily set up a cross-compile in JDeveloper, but some users want to use the actual Javac of their project's JDK. I don't want to comment on trying to mixing different versions of JDK modules in the same VM but I'm curious whether your loading of tools.jar in the target VM continues to work when you run it on jake and when targeting a JDK 8 or older. I would expect it should work as before, assuming of course that your custom class loader that is loading from the targets tools.jar isn't doing parent-first delegation. The latter point is important because a consequence of the JEP 220 work is that types that were previously in tools.jar are always visible when running a class path application on the JDK. -Alan
JavaFileManager UnsupportedOperationException
I'm running with jigsaw build 1.9.0-ea-jigsaw-nightly-h3477-20150929-b83. I'm trying to do a JSR199 compilation using ToolProvider.getSystemJavaCompiler(), but the compile fails immediately with the exception below. I don't have access to the sources of this JDK. Does somebody know what I'm doing wrong? Caused by: java.lang.UnsupportedOperationException at javax.tools.JavaFileManager.listModuleLocations(java.compiler@9.0/JavaFileManager.java:436) at com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager.listModuleLocations(jdk.compiler@9.0/ClientCodeWrapper.java:387) at com.sun.tools.javac.code.ModuleFinder$ModuleLocationIterator.hasNext(jdk.compiler@9.0/ModuleFinder.java:129) at com.sun.tools.javac.code.ModuleFinder.scanModulePath(jdk.compiler@9.0/ModuleFinder.java:242) at com.sun.tools.javac.code.ModuleFinder.findAllModules(jdk.compiler@9.0/ModuleFinder.java:178) at com.sun.tools.javac.comp.Modules.getUnnamedModuleCompleter(jdk.compiler@9.0/Modules.java:617) at com.sun.tools.javac.comp.Modules.setCompilationUnitModules(jdk.compiler@9.0/Modules.java:306) at com.sun.tools.javac.comp.Modules.enter(jdk.compiler@9.0/Modules.java:174) at com.sun.tools.javac.main.JavaCompiler.initModules(jdk.compiler@9.0/JavaCompiler.java:1040) at com.sun.tools.javac.main.JavaCompiler.initModules(jdk.compiler@9.0/JavaCompiler.java:1036) at com.sun.tools.javac.main.JavaCompiler.compile(jdk.compiler@9.0/JavaCompiler.java:924) at com.sun.tools.javac.api.JavacTaskImpl$1.call(jdk.compiler@9.0/JavacTaskImpl.java:97) at com.sun.tools.javac.api.JavacTaskImpl$1.call(jdk.compiler@9.0/JavacTaskImpl.java:93) at com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(jdk.compiler@9.0/JavacTaskImpl.java:128) at com.sun.tools.javac.api.JavacTaskImpl.doCall(jdk.compiler@9.0/JavacTaskImpl.java:93) at com.sun.tools.javac.api.JavacTaskImpl.call(jdk.compiler@9.0/JavacTaskImpl.java:87) Keimpe Bronkhorst JDeveloper
The -release option is not compatible with JavaFileManagers
I have a custom JavaFileManager used for JSR199 compilations, but when I use the -release option I see: Error: -release option specified, but the provided JavaFileManager is not a StandardJavaFileManager.. This basically forces everybody to implement StandardJavaFileManagers, even if they don't want that. Isn't there a way to make this work with JavaFileManagers? Keimpe Bronkhorst JDeveloper
