> On May 23, 2016, at 8:05 AM, Chris Hegarty wrote:
>
> Updated webrev:
> http://cr.openjdk.java.net/~chegar/8156497.01/
Looks fine to me.
Minor comment on the test, “9” is hardcoded in a few places. It might be good
to prepare for the future release e.g. use
On 23/05/2016 16:12, Alan Bateman wrote:
On 23/05/2016 13:27, Ivan Krylov wrote:
(perhaps this question belongs to the jigsaw-dev list..)
How upgradable modules are defined.
JEP-261 uses this term but does not define it AFAICS.
make/commons/Modules.gmk defines the list of upgradeable modules,
> On May 23, 2016, at 9:49 AM, Alan Bateman wrote:
>
>
> JDK-8151542 changed the URL scheme for resources in the versioned section of
> a multi-release JAR. The ModuleReader API can be used to get a URI to a
> resource in a modular JAR and it needs a corresponding
Hi,
Please review this small patch on fixing module dependencies for /com/*
tests.
Issue: https://bugs.openjdk.java.net/browse/JDK-8157633
Webrev: http://cr.openjdk.java.net/~jjiang/8157633/webrev.00/
Best regards,
John Jiang
On 05/23/2016 02:31 PM, Stuart Marks wrote:
On 5/20/16 4:59 PM, Jonathan Gibbons wrote:
While I would agree on the use of one type, not two, for file paths,
I would
question the choice to use String instead of Path. If something is a
file path,
use the type system to say so, and use a
On 5/20/16 4:59 PM, Jonathan Gibbons wrote:
While I would agree on the use of one type, not two, for file paths, I would
question the choice to use String instead of Path. If something is a file path,
use the type system to say so, and use a Path.
Sure, either way will work. I had started
Sorry, yes!
Am 23. Mai 2016 19:54:55 MESZ, schrieb Jonathan Gibbons
:
>
>
>On 05/23/2016 10:33 AM, Uwe Schindler wrote:
>> Maybe change to something like:
>>
>> warning: [options] bootstrap class path not set in conjunction with
>-source 1.8; consider using -target
On 05/23/2016 10:33 AM, Uwe Schindler wrote:
Maybe change to something like:
warning: [options] bootstrap class path not set in conjunction with -source
1.8; consider using -target 1.8
Uwe
I presume you meant -release, not -target:
warning: [options] bootstrap class path not set in
JDK-8151542 changed the URL scheme for resources in the versioned
section of a multi-release JAR. The ModuleReader API can be used to get
a URI to a resource in a modular JAR and it needs a corresponding update
to align with the JEP 238 update. The change is simple:
On 23/05/2016 16:05, Chris Hegarty wrote:
D'oh. Fixed.
Updated webrev:
http://cr.openjdk.java.net/~chegar/8156497.01/
This version looks good.
-Alan
On 23/05/2016 15:52, Andrew Dinn wrote:
:
Thanks to you and Sanders for the advice. The relevant packages now appear.
Could you explain how the disabled status of this module is arrived at
in the final build? Is it excluded from the standard visible set by
virtue of being listed in
On 20/05/16 22:24, Alan Bateman wrote:
On 20/05/2016 16:55, Chris Hegarty wrote:
:
http://cr.openjdk.java.net/~chegar/8156497.00/
Note: while there are some new test scenarios added, which give
reasonable coverage, further tests will be added later. Steve has some
additional jar tools support
Hi Alan,
On 23/05/16 14:27, Alan Bateman wrote:
> As Sander said, compiling with `-addmods java.corba` will ensure that
> the java.corba module is resolved.
Thanks to you and Sanders for the advice. The relevant packages now appear.
Could you explain how the disabled status of this module is
On 23/05/2016 13:51, Andrew Dinn wrote:
Hi All,
Red Hat's Transactions developers are having problems compiling their
Corba-based code using the latest early access release of JDK9
(9-ea-b119). When the maven compiler plugin executes javac the compile
fails because various corba packages are
Hi Andrew, Michael,
It's come up several times recently on this list, but this should clear up the
issue: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html
In short: use `-addmods java.corba` when compiling as of 9-ea-b119.
Sander
On 23 May 2016, at 14:51, Andrew Dinn
Hi All,
Red Hat's Transactions developers are having problems compiling their
Corba-based code using the latest early access release of JDK9
(9-ea-b119). When the maven compiler plugin executes javac the compile
fails because various corba packages are not visible. These are /not/
classes
16 matches
Mail list logo