Oh is that what it is? Yeah, 0 of those either.
Malachi de Ælfweald http://www.google.com/profiles/malachid On Thu, Jul 7, 2016 at 8:56 AM, Claes Redestad <claes.redes...@oracle.com> wrote: > Would that be 'jrt:'? > > /Claes > > > On 2016-07-07 17:50, Malachi de Ælfweald wrote: > >> I believe it was mentioned in one of the threads that part of this change >> include moving from jar: to jrl: >> >> Checking the javadoc download, there are 0 mentions of 'jrl:' but 50 >> mentions of 'jar:'. >> >> >> >> >> Malachi de Ælfweald >> http://www.google.com/profiles/malachid >> >> On Wed, Jul 6, 2016 at 11:36 AM, Alan Bateman <alan.bate...@oracle.com> >> wrote: >> >> >>> The jigsaw/jake forest has been updated with an initial implementation of >>> the proposals that Mark brought to the jpms-spec-experts mailing list >>> last >>> week. For those that don't build from source then the EA build/downloads >>> [1] has also been refreshed. >>> >>> The changes in this build are initial/early implementations of: >>> >>> #CompileTimeDependences >>> #ReflectiveAccessToNonExportedTypes >>> #ModuleAnnotations and #ModuleDeprecation >>> #ResourceEncapsulation and #ClassFilesAsResources >>> #ReflectiveAccessByInstrumentationAgents >>> #CustomizableAutomaticModuleNameMapping >>> >>> The updates involve changes to the binary form of a module declaration so >>> if you have been playing with previous builds then you will need to >>> re-compile your modules. >>> >>> One point on #ReflectiveAccessByInstrumentationAgents is that it is just >>> java.lang.instrument for now. The underlying support for the JVM TI >>> equivalent is in place, it's just not exposed as a JVM TI function just >>> yet. >>> >>> The discussion on some of these issues is ongoing so don't treat anything >>> as final yet. We'll refresh the builds as needed over the coming weeks. >>> >>> >>> One other significant change in this build is that it has the new forms >>> for the command line options. As has been mentioned in a number of >>> threads >>> here, we are proposing that the new command line options for modules use >>> the GNU style. Jon Gibbons will be posting an informational JEP on this >>> topic soon. JEP 261 and JEP 282 will be updated soon to reflect the >>> updated >>> proposal. For now, the old => new mapping is: >>> >>> `-modulepath` (or `-mp`) => `--module-path` (or `-p`) >>> `-upgrademodulepath` => `--upgrade-module-path` >>> `-addmods` => `--add-modules` >>> `-limitmods` => `--limit-modules` >>> `-listmods` => `--list-modules` >>> `-XaddReads` => `--add-reads` >>> `-XaddExports` => `--add-exports` >>> `-Xpatch` => `--patch-module` >>> >>> The `java` and `javac` launchers have been updated, as have the >>> `javadoc`, >>> `jlink`, `jar` and `jmod` tools. For now, the old form of the module >>> options (except `-listmods`) still work as before as it will take time to >>> transition. The jtreg test harness will need to be updated too. >>> >>> The JEPs will detail the option syntax but briefly: the format of the >>> values to these options has not changed, the separator between the option >>> and value can be space or `=` in the case of `java` or `javac`, the >>> separator must be `=` when using the JNI invocation API or _JAVA_OPTIONS >>> or >>> a VM options file. >>> >>> Two other things to mention are `--class-path` (`-classpath` and `-cp` >>> work as before of course), and `javac --inherit-runtime-environment` to >>> inherit the module configuration from the runtime environment into the >>> compilation environment. >>> >>> >>> So please try it out. As always, the most valuable feedback is from those >>> trying out the builds to migrate or modularize existing libraries and >>> applications. >>> >>> -Alan >>> >>> [1] https://jdk9.java.net/jigsaw/ >>> >>> >>> >>> >>>
