New EA builds, contains initial implementation of current proposals

[Malachi de Ælfweald]

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>
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>
>> 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/
>>>
>>>
>>>
>>>
>>>