Right - I was trying to find documentation on the new url format. Using the newly downloaded documentation, what I found was things like this instead:
./api/javax/tools/StandardJavaFileManager.html: <code>jar:lib/vendorA.jar!/com/vendora/LibraryClass.class</code> I assumed that they just weren't updated yet; but since I couldn't find any reference to the new format, I thought I would mention it. Malachi de Ælfweald http://www.google.com/profiles/malachid On Thu, Jul 7, 2016 at 9:11 AM, Claes Redestad <claes.redes...@oracle.com> wrote: > Not sure how you meant 'jar:' is being replaced, so I might've just added > to the confusion here. > > 'jrt' is the new scheme used to reference resources in the runtime image, > e.g., "jrt:/java.base/java/net/URL.class", and in some places where you > previously got a jar-based URL you might now get a jrt-based one, e.g., > when calling class.getResource. > > 'jar' is by no means going away, though, and will still be valid in a lot > of places. I wouldn't be surprised if there are places in the docs which > are in need of an update, though. :-) > > /Claes > > > On 2016-07-07 18:01, Malachi de Ælfweald wrote: > >> Here's the subset that appear to be out of date: >> >> ./technotes/guides/javadoc/whatsnew-1.4.2.html >> ./technotes/guides/io/fsp/zipfilesystemprovider.html >> ./technotes/guides/jmx/tutorial/lookup.html >> ./technotes/guides/jmx/examples/Lookup/jini/README >> ./technotes/guides/security/jaas/tutorials/GeneralAcnAndAzn.html >> ./technotes/guides/security/jaas/tutorials/GeneralAcnOnly.html >> ./technotes/guides/security/crypto/MyJCE.java >> ./technotes/guides/security/crypto/HowToImplAProvider.html >> ./technotes/guides/security/jgss/tutorials/LoginSample.html >> ./technotes/guides/security/jgss/tutorials/AcnAndAzn.html >> ./technotes/guides/security/jgss/tutorials/MoreToDo.html >> ./technotes/guides/security/jgss/tutorials/ClientServer.html >> ./technotes/guides/management/jconsole.html >> ./technotes/guides/troubleshoot/tooldescr.html >> ./technotes/guides/rmi-iiop/interop.html >> ./technotes/tools/windows/javah.html >> ./technotes/tools/windows/javadoc.html >> ./technotes/tools/windows/classpath.html >> ./technotes/tools/unix/javah.html >> ./technotes/tools/unix/javadoc.html >> ./technotes/tools/unix/classpath.html >> ./api/java/net/JarURLConnection.html >> ./api/java/net/URLClassLoader.html >> ./api/javax/xml/XMLConstants.html >> ./api/javax/tools/StandardJavaFileManager.html >> >> >> >> Malachi de Ælfweald >> http://www.google.com/profiles/malachid >> >> On Thu, Jul 7, 2016 at 8:59 AM, Malachi de Ælfweald <malac...@gmail.com >> <mailto:malac...@gmail.com>> wrote: >> >> 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 <mailto: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 <mailto: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/ >> >> >> >> >> >> >>
