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/
