New EA builds, contains initial implementation of current proposals
Claes Redestad
claes.redestad at oracle.com
Thu Jul 7 16:11:01 UTC 2016
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 <malachid at gmail.com
> <mailto:malachid at 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.redestad at oracle.com <mailto:claes.redestad at 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.Bateman at oracle.com <mailto:Alan.Bateman at 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/
>
>
>
>
>
>
More information about the jigsaw-dev
mailing list