Re: RFR 8156497: Add jar tool support for Multi-release modular JARs

[Mandy Chung]

> 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 Runtime.version().major() + 1 
instead.

e.g.
 257 "-C", mrjarDir.toString(), 
"META-INF/versions/9/module-info.class”,
 760 Path versionSection = metaInfDir.resolve("versions").resolve("9");

Mandy

Re: RFR: JDK-8155786: Determine modules depending on upgradeable modules directly and indirectly

[Ivan Krylov]

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, look 
for UPGRADEABLE_MODULES. A module is upgradeable can be 
overridden/upgraded by deploying it on the upgrade module path 
(`-upgrademodulepath` to javac or java). If you want to go into more 
details then we should probably move the discussion to jigsaw-dev.


-Alan


I was looking not for the specific list of modules, but rather the 
definition of the concept.
As for the list in that Modules.gmk - those 6 modules are the ones that 
since build 118 are not visible from unnamed modules.
That is not a coincidence but I do not follow the logic either. Perhaps 
it was discussed here earlier - sorry about my ignorance then.


Thanks,
Ivan

Re: 8157598: ModuleReader find returns incorrect URI when modular JAR is a multi-release JAR

[Mandy Chung]

> 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 update to align with 
> the JEP 238 update. The change is simple:
>http://cr.openjdk.java.net/~alanb/8157598/webrev/

+1

Mandy

(9) RFR: 8157633: Fix module dependencies for /com/* tests

[John Jiang]

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

Re: Ping - Re: RFR 8078812, Test RMI with client and servers as modules

[Jonathan Gibbons]

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 Path.


Sure, either way will work. I had started with String because the data 
originates as strings, either from system properties or from string 
literals.


I switched things around to see what things looked like, starting with 
Path and converting to String as necessary. Basically I declared the 
constants using Paths.get(). This meant fileJoin() could disappear, 
since Paths.get() can concatenate multiple elements.


Paths.get() disappeared from several places inline, and was replaced 
with a chain of calls to resolve() in a couple others. I had to add 
toString() in a few places as well.


The pathJoin() helper had to change a bit though. Formerly it 
concatenated strings with File.pathSeparator; now it has to convert 
Path objects to strings before doing so. The easiest way to do this 
was to use a short stream:


static String pathJoin(Path... paths) {
return Arrays.stream(paths)
 .map(Path::toString)
.collect(Collectors.joining(File.pathSeparator));
}

Overall I'd say six of one, half a dozen of the other.

s'marks



Yes, and the example is small enough that maybe six of one really does 
balance half a dozen of the other.  But as a general matter of style, I 
think it is preferable to use Path when you really want paths.


That being said, it would be nice to have a method on the Paths API to 
create a search path from a series of Path objects. (your pathJoin method)


-- Jon

Re: Ping - Re: RFR 8078812, Test RMI with client and servers as modules

[Stuart Marks]

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 with String because the data 
originates as strings, either from system properties or from string literals.


I switched things around to see what things looked like, starting with Path and 
converting to String as necessary. Basically I declared the constants using 
Paths.get(). This meant fileJoin() could disappear, since Paths.get() can 
concatenate multiple elements.


Paths.get() disappeared from several places inline, and was replaced with a 
chain of calls to resolve() in a couple others. I had to add toString() in a few 
places as well.


The pathJoin() helper had to change a bit though. Formerly it concatenated 
strings with File.pathSeparator; now it has to convert Path objects to strings 
before doing so. The easiest way to do this was to use a short stream:


static String pathJoin(Path... paths) {
return Arrays.stream(paths)
 .map(Path::toString)
 .collect(Collectors.joining(File.pathSeparator));
}

Overall I'd say six of one, half a dozen of the other.

s'marks

Re: Compact profiles broken?

[Uwe Schindler]

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 1.8
>>
>> Uwe
>
>I presume you meant -release, not -target:
>
>warning: [options] bootstrap class path not set in conjunction with
>-source 1.8; consider using -release 1.8

Re: Compact profiles broken?

[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 1.8

Uwe


I presume you meant -release, not -target:

warning: [options] bootstrap class path not set in conjunction with -source 
1.8; consider using -release 1.8

8157598: ModuleReader find returns incorrect URI when modular JAR is a multi-release JAR

[Alan Bateman]

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:

http://cr.openjdk.java.net/~alanb/8157598/webrev/

There is still some remaining work to have modular JARs be multi-release 
JARs, jlink mostly, but it is otherwise aligning nicely.


-Alan

Re: RFR 8156497: Add jar tool support for Multi-release modular JARs

[Alan Bateman]

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

Re: Issue trying to use CORBA classes from javac

[Alan Bateman]

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 UPGRADEABLE_MODULES? I couldn't find anywhere
else where any different treatment might be applied.
The section entitled "Root modules" in JEP 261 is the section to read. 
It's essentially that the java.se rather than java.se.ee is resolved by 
default when compiling code in the unnamed module or running and the 
initial class is loaded from the class path.




:
Hmm, perhaps -XaddExports requires a check to see that it does not add
any exports unless the module has also been added.
javac and java behave slightly differently for this case, it's something 
we need to fix.




:

However, we do interoperate with 2 other orbs and in those cases we 
currently provide the relevant CORBA classes via the classpath using 
-Xbootclasspath:p (which I have explained is no longer going to work). 
I think that this command line option was adopted merely in order to 
pre-empt the SE Corba classes in rt.jar. So, I am hoping that if we 
omit -addmod java.corba and add the alternatrive ORB jar to the system 
classpath then we will actually be safe. If you have reason to believe 
otherwise please let me know. Meanwhile, I'll get back to you if and 
when this turns into a packed lunch problem. Thanks for the help.
If you have complete replacement/upgrade for the java.corba module then 
you can deploy on it on the class path and it should work. Alternatively 
you can deploy it on the upgrade module path to upgrade/override the 
module in the JDK (`-upgrademodulepath mycorba.jar -addmods java.corba`).


On the other hand, if you adding to the JDK java.corba module then 
you'll need to use -Xpatch to augment or override what is in the JDK 
(`-Xpatch:java.corba=mycorbapatch.jar -addmods java.corba`).


-Alan.

Re: RFR 8156497: Add jar tool support for Multi-release modular JARs

[Chris Hegarty]

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 coming for easier creation of MRJARS.



The checks looks right.

In checkModuleInfos then I assume you can use findFirst instead of
collecting the module-infos into a set.


Yes, of course. done


The comment in computeHashes is confusing - too many "as" :-)


Updated.


You might want to re-read the error messages to see if they can be
improved. For example "Invalid versioned module-info.class ..." might be
better as "module-info.class in versioned section ...". Another one is
"Unexpected versioned module-info.class without root module-info.class"
where it might be clearer to say "module-info.class found in versions
section of JAR file, no module-info.class found in root directory" or
something like that.


That is certainly better. done.


Looks like the copyright headers have the Classpath exception so now
might be a good time to fix those.


D'oh. Fixed.

Updated webrev:
  http://cr.openjdk.java.net/~chegar/8156497.01/

-Chris.

Re: Issue trying to use CORBA classes from javac

[Andrew Dinn]

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 arrived at
in the final build? Is it excluded from the standard visible set by
virtue of being listed in UPGRADEABLE_MODULES? I couldn't find anywhere
else where any different treatment might be applied.

> That said, I'm puzzled as to why -XaddExports makes a difference here,
> also by some of the types mentioned in the compilation messages as they
> aren't types in the JDK java.corba module.

Hmm, perhaps -XaddExports requires a check to see that it does not add
any exports unless the module has also been added.

> It would help if you or Michael could summarize what org.omg.** classes
> are in the environment. We've had problems off-list with another app
> server in this area too. In that case, it was augmenting the CORBA
> version in the JDK with additional classes as part of adding support for
> OMG APIs that the JDK version doesn't support. I don't know if we've got
> something similar here. If so, then bring a packed lunch as it will be a
> long day :-)

Mike is currently checking this -- his tweaking of the maven poms during
testing may actually be responsible for some of the problems you
noticed. So, he is checking that before he can be sure that this
resolves the problems using the SE-provided orb. Essentially, for this
build, where we are using the SE ORB, there should be no other
org.omg.** classes in the env.

However, we do interoperate with 2 other orbs and in those cases we
currently provide the relevant CORBA classes via the classpath using
-Xbootclasspath:p (which I have explained is no longer going to work). I
think that this command line option was adopted merely in order to
pre-empt the SE Corba classes in rt.jar. So, I am hoping that if we omit
-addmod java.corba and add the alternatrive ORB jar to the system
classpath then we will actually be safe. If you have reason to believe
otherwise please let me know. Meanwhile, I'll get back to you if and
when this turns into a packed lunch problem. Thanks for the help.

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

Re: Issue trying to use CORBA classes from javac

[Alan Bateman]

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 not visible. These are /not/
classes belonging to concealed packages.

Some of the relevant error messages are shown in the first listing
following my sig.

Indeed, what is more strange is that we found that we could remedy the
first of these errors by adding an explicit addExports for the relevant
package to the javac arguments configured in the maven pom:

   
 -XaddExports:java.corba/org.omg.CORBA=ALL-UNNAMED
   

The second listing shows the difference this makes. Note that package
org.omg.CORBA is now recognised.


No doubt the same sort of fix would apply to remove the other errors but
I don't understand why the use of addExports is necessary. When I run
jmod describe on the java.corba module it tells me that org.omg.CORBA
etc are already exported. So, java.corba does not seem to be a special
sort of package different to all the others in the jmod dir.

Is there some hidden switch which disables exports for this module? If
so then is there a switch (equally as well hidden :-) which allows me to
re-instate them? If not then does anyone have any idea why are we seeing
these missing package errors?

n.b. please keep Mike Musgrove in the cc for any replies as he is not
subscribed to this list.

As Sander said, compiling with `-addmods java.corba` will ensure that 
the java.corba module is resolved.


That said, I'm puzzled as to why -XaddExports makes a difference here, 
also by some of the types mentioned in the compilation messages as they 
aren't types in the JDK java.corba module.


It would help if you or Michael could summarize what org.omg.** classes 
are in the environment. We've had problems off-list with another app 
server in this area too. In that case, it was augmenting the CORBA 
version in the JDK with additional classes as part of adding support for 
OMG APIs that the JDK version doesn't support. I don't know if we've got 
something similar here. If so, then bring a packed lunch as it will be a 
long day :-)


-Alan

Re: Issue trying to use CORBA classes from javac

[Sander Mak]

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 
> 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 not visible. These are /not/
classes belonging to concealed packages.

Some of the relevant error messages are shown in the first listing
following my sig.

Indeed, what is more strange is that we found that we could remedy the
first of these errors by adding an explicit addExports for the relevant
package to the javac arguments configured in the maven pom:

 
   -XaddExports:java.corba/org.omg.CORBA=ALL-UNNAMED
 

The second listing shows the difference this makes. Note that package
org.omg.CORBA is now recognised.


No doubt the same sort of fix would apply to remove the other errors but
I don't understand why the use of addExports is necessary. When I run
jmod describe on the java.corba module it tells me that org.omg.CORBA
etc are already exported. So, java.corba does not seem to be a special
sort of package different to all the others in the jmod dir.

Is there some hidden switch which disables exports for this module? If
so then is there a switch (equally as well hidden :-) which allows me to
re-instate them? If not then does anyone have any idea why are we seeing
these missing package errors?

n.b. please keep Mike Musgrove in the cc for any replies as he is not
subscribed to this list.

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

Errors with no compiler X args:
---

[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[32,21]
package org.omg.CORBA does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[33,21]
package org.omg.CORBA does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[34,30]
package org.omg.PortableServer does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[35,48]
package org.omg.PortableServer.POAManagerPackage does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[36,41]
package org.omg.PortableServer.POAPackage does not exist

. . .


Errors after using -XaddExports:java.corba/org.omg.CORBA=ALL-UNNAMED


[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[34,30]
package org.omg.PortableServer does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[35,48]
package org.omg.PortableServer.POAManagerPackage does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[36,41]
package org.omg.PortableServer.POAPackage does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[37,41]
package org.omg.PortableServer.POAPackage does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/oa/implementations/POABase.java:[39,32]
org.omg.CORBA.ORBPackage.InvalidName is not visible because package
org.omg.CORBA.ORBPackage is not visible
[ERROR]

Issue trying to use CORBA classes from javac

[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 belonging to concealed packages.

Some of the relevant error messages are shown in the first listing
following my sig.

Indeed, what is more strange is that we found that we could remedy the
first of these errors by adding an explicit addExports for the relevant
package to the javac arguments configured in the maven pom:

  
-XaddExports:java.corba/org.omg.CORBA=ALL-UNNAMED
  

The second listing shows the difference this makes. Note that package
org.omg.CORBA is now recognised.


No doubt the same sort of fix would apply to remove the other errors but
I don't understand why the use of addExports is necessary. When I run
jmod describe on the java.corba module it tells me that org.omg.CORBA
etc are already exported. So, java.corba does not seem to be a special
sort of package different to all the others in the jmod dir.

Is there some hidden switch which disables exports for this module? If
so then is there a switch (equally as well hidden :-) which allows me to
re-instate them? If not then does anyone have any idea why are we seeing
these missing package errors?

n.b. please keep Mike Musgrove in the cc for any replies as he is not
subscribed to this list.

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

Errors with no compiler X args:
---

[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[32,21]
package org.omg.CORBA does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[33,21]
package org.omg.CORBA does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[34,30]
package org.omg.PortableServer does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[35,48]
package org.omg.PortableServer.POAManagerPackage does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[36,41]
package org.omg.PortableServer.POAPackage does not exist

. . .


Errors after using -XaddExports:java.corba/org.omg.CORBA=ALL-UNNAMED


[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[34,30]
package org.omg.PortableServer does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[35,48]
package org.omg.PortableServer.POAManagerPackage does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[36,41]
package org.omg.PortableServer.POAPackage does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[37,41]
package org.omg.PortableServer.POAPackage does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/oa/implementations/POABase.java:[39,32]
org.omg.CORBA.ORBPackage.InvalidName is not visible because package
org.omg.CORBA.ORBPackage is not visible
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/oa/implementations/POABase.java:[40,30]
package org.omg.PortableServer does not exist
[ERROR]
/home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/oa/implementations/POABase.java:[41,48]
package org.omg.PortableServer.POAManagerPackage does not exist
[ERROR]