Re: Compilation feedback and version question

[Chris Hegarty]

On 29 Oct 2015, at 11:25, Stephen Colebourne  wrote:

>> ...
> 
> Bear in mind that the help/usage text of the jar.exe tool has not been
> updated. As such, jmod.exe looks like its the only thing capable of
> working with modules.

Just on this specific point. Can you please try ‘jar —help’ from a 
jigsaw build, it should contain additional options and notes relating
to modular jars.

-Chris.

Re: Avoiding same-package conflicts

[David M. Lloyd]

On 10/29/2015 05:59 AM, Martin Lehmann wrote:

Hi all,

I stumbled across the same "issue".


that having multiple versions of the same library isn't a best practice to say 
the least.

Full ACK. Bad practice.


I disagree, actually.  I think that this is a completely needless and 
artificial restriction that arose from implementation decisions, not 
from a valid requirement.


We have used our ability to ship multiple modules with the same package 
names to good effect on more than one occasion.  As long as a given 
module doesn't link the conflicting packages, there is no real problem. 
 Even hypothetical issues involving indirect linkage or passing objects 
back and forth have never really been a problem for us.



I might have an (artifical?) use case where this might lead to some extra 
effort in migration, though:
Let's assume that two libraries D1 and D2 implement the same common API. For 
some historical reason, both libraries *ship* the interfaces classes of that 
common API.
This won't work (easily) without repackaging jar files (even if the common API 
classes would not even differ).

Example:
A --requires --> B, C
B --requires --> D1
C --requires --> D2
D1 and D2 both contain the same interfaces. Even if neither B nor C would *not* 
"requires public" D1 / D2, this would not work.

Too artifical? I actually thought of two logging implementations using & 
shipping the common slf4j interface classes.

So we really need disjunct classes in *all* libraries now? Not even, if the redundant 
packages are not even exported (right?). Would it work in the "old" classpath?


I think that judging by whether something would work in an old classpath 
is a false test.  The whole point of modules is to throw off the 
restrictions and problems of the classpath, after all.  I think a better 
test is, "does this make sense?", and to use your slf4j example - it 
definitely makes sense, because:


* Modules generally use slf4j as a private API to perform their own 
logging functions

* Thus slf4j generally never leaks to a module's exported package set
* Thus there's no actual harm in allowing this, and much benefit - 
especially if B and C (in your example) are not completely under your 
control (which is inevitable in any nontrivial system)


--
- DML

Re: Compilation feedback and version question

[Stephen Colebourne]

On 28 October 2015 at 23:59, Alan Bateman  wrote:
> On 28/10/2015 20:50, Stephen Colebourne wrote:
>> Just to note that my experiments of the last 2 hours suggest that
>> "java -listmods" does not show user modules in its output, only JDK
>> modules:
>>java -mp jmods -listmods
>
> -listmods will list the names of the modules in the application's module
> graph. In this case, there isn't any initial module (application) specified
> so it defaults to the system modules. I expect this will do what you want:
>
> java -mp jmods -addmods org.joda.convert -listmods

So, after about an hour yesterday, I did try that and it still didn't
work. That must have been because jmod doesn't work fully. I've tried
it now, and with -addmods it does find the modular jar file.

However, my feedback is that the -listmods option is confusing. An
option called "list" is something I expect to list all things, not to
be clever and only show some subset. At the very least, I consider it
vital for there to be a tool (preferably java.exe) that can list *all*
available modules given a module path. Maybe the current -listmods
should be renamed to -applicationmods or -initialmods, or split to
-listmods:app and -listmods:all ?  (Being able to list everything
available feels like module 101).

Note to Alex Buckley's response, I haven't used the link or image
levels yet. The feedback above applies without using those tools.

>> My experiments also only worked with modular jar files. The jmod
>> generated files were not recognized as modules at all.
>
> There are a few open issues around the JMOD format. At this time (and stated
> in JEP 261), JMOD files can only be used at compile-time or link-time. So
> for now at least, they are ignored at run-time.

Bear in mind that the help/usage text of the jar.exe tool has not been
updated. As such, jmod.exe looks like its the only thing capable of
working with modules.

Stephen

Re: Compilation feedback and version question

[Alan Bateman]

On 29/10/2015 11:25, Stephen Colebourne wrote:

:
So, after about an hour yesterday, I did try that and it still didn't
work. That must have been because jmod doesn't work fully. I've tried
it now, and with -addmods it does find the modular jar file.

However, my feedback is that the -listmods option is confusing. An
option called "list" is something I expect to list all things, not to
be clever and only show some subset. At the very least, I consider it
vital for there to be a tool (preferably java.exe) that can list *all*
available modules given a module path. Maybe the current -listmods
should be renamed to -applicationmods or -initialmods, or split to
-listmods:app and -listmods:all ?  (Being able to list everything
available feels like module 101).
The sub-option on -listmods is used to look at specific modules but fair 
point, the expectation may be that it scans the application module path 
and lists all modules that are found when what it actually does is list 
the modules in the boot layer. One other usage that that should work for 
you is to add it to your launch command that uses -m.




:
Bear in mind that the help/usage text of the jar.exe tool has not been
updated. As such, jmod.exe looks like its the only thing capable of
working with modules.


The jar tool is significantly enhancement to support modules so check 
out jar --help as Chris suggests.


-Alan.

Re: RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV

[Mandy Chung]

Resource file of zero-length module name and package name should not be allowed 
to be written to jimage.  The moduleName > 0 and packageName > 0 should be an 
assertion; exception if fails.

Mandy

> On Oct 29, 2015, at 1:09 PM, Dmitry Samersoff  
> wrote:
> 
> Roger,
> 
> ImageNativeSubstrate.cpp:565
> 
>two extra bytes is accounted if moduleLen == 0
> 
> Please, add examples of valid resource name when moduleLen == 0 and/or
> packageLen == 0 to comments.
> 
> 
> -Dmitry
> 
> On 2015-10-28 09:40, Roger Riggs wrote:
>> Please review an update to the jimage reader implementation to correct the
>> case where a class name is very long causing a SEGV due to buffer overruns.
>> 
>> The fix will be pushed to the hs-comp repo; the bug was first spotted
>> there.
>> 
>> Webrev:
>>   http://cr.openjdk.java.net/~rriggs//webrev-jimage-segv-8139390
>> 
>> Issue:
>>   https://bugs.openjdk.java.net/browse/JDK-8139390
>> 
>> Thanks, Roger
>> 
> 
> 
> -- 
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

Re: RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV

[Mandy Chung]

> On Oct 27, 2015, at 11:40 PM, Roger Riggs  wrote:
> 
> Please review an update to the jimage reader implementation to correct the
> case where a class name is very long causing a SEGV due to buffer overruns.
> 
> The fix will be pushed to the hs-comp repo; the bug was first spotted there.

I suggest to push it to jdk9/dev and that will be pulled into hs-comp when it’s 
sync’ed up. 

> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs//webrev-jimage-segv-8139390

Looks okay in general.  

ImageNativeSubstrate.cpp
Is this native JIMAGE_FindResource method intended for tests to use?  I 
don’t find any reference to it besides tests.  The other option is to have a 
java method checking null parameters and call this native method (and make this 
native method private).

test/jdk/internal/jimage/JImageReadTest.java
169 Assert.assertTrue(max > 16000,
170 "missing entries, should be more than 31000, reported: " + 
count);

Is the change from 31000 to 16000 accidental?

This is unrelated to your change and just to mention it.  The test hardcodes 
9.0 as the version and the hardcoded value should be replaced for future 
release.   Probably best to file a JBS issue for that.

Mandy

Re: RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV

[Mandy Chung]

> On Oct 29, 2015, at 4:22 PM, Roger Riggs  wrote:
> 
> Hi Mandy,
> 
> Collapsing the emails.
> 
> As for asserting that module name is never null;
> it appears that the module name is not being supplied by the VM. (in hs-comp 
> or jdk9).
> 
> On 10/29/15 12:59 PM, Mandy Chung wrote:
>>> On Oct 27, 2015, at 11:40 PM, Roger Riggs  wrote:
>>> 
>>> Please review an update to the jimage reader implementation to correct the
>>> case where a class name is very long causing a SEGV due to buffer overruns.
>>> 
>>> The fix will be pushed to the hs-comp repo; the bug was first spotted there.
>> I suggest to push it to jdk9/dev and that will be pulled into hs-comp when 
>> it’s sync’ed up.
> ok, the issue was with HS tests failing and pushing to hs-comp more rapidly 
> addresses that.
> But I'm fine with pushing to jdk9.
> 
> (BTW, there is a different fix for this issue expected to be reimplemented 
> for Jake).
>> 
>>> Webrev:
>>>   http://cr.openjdk.java.net/~rriggs//webrev-jimage-segv-8139390
>> Looks okay in general.
>> 
>> ImageNativeSubstrate.cpp
>> Is this native JIMAGE_FindResource method intended for tests to use?  I 
>> don’t find any reference to it besides tests.  The other option is to have a 
>> java method checking null parameters and call this native method (and make 
>> this native method private).
> yes, it is only being used to specifically test the native JIMAGE_xxx native 
> functions.

Since the fix will be reimplemented in jake, it would be better to hide this 
native method and do the null check in java.  This would require existing tests 
to change.

It’s okay with your version as an interim fix.

>> 
>> test/jdk/internal/jimage/JImageReadTest.java
>> 169 Assert.assertTrue(max > 16000,
>> 170 "missing entries, should be more than 31000, reported: " 
>> + count);
>> 
>> Is the change from 31000 to 16000 accidental?
> When I added a test for a long classname, I discovered that the test was not 
> properly marked with @test
> and was not being run.  When I re-enabled it, I observed that the number of 
> entries
> was quite a bit smaller than previously and so updated the test.

I see.  line 170 should be updated for the new number.
>> 
>> This is unrelated to your change and just to mention it.  The test hardcodes 
>> 9.0 as the version and the hardcoded value should be replaced for future 
>> release.   Probably best to file a JBS issue for that.
> I thought I had seen a change to allow a default version to be used.  But at 
> the moment the
> argument is ignored and until it is not ignored this value is immaterial.

I filed https://bugs.openjdk.java.net/browse/JDK-8140803 to track this.

Mandy

RFR: 8139067: Re-examine if a consumer module should load bundles from unnamed module

[Masayoshi Okutsu]

Hello,

Please review the change for JDK-8139067. A consumer module 
(ResourceBundle.getBundle caller) will no longer load resource bundles 
from the class-path if the consumer module is a named module. Test 
programs, basic and modlocal, have been changed to confirm .properties 
bundles are not loaded from a jar file on the class-path.The webrev also 
include some cleanup of @bug and @summary for the test programs.


Issue: https://bugs.openjdk.java.net/browse/JDK-8139067

Webrev: http://cr.openjdk.java.net/~okutsu/9/8139067/webrev.00

Thanks,
Masayoshi

Re: Jigsaw @ JavaOne 2015

[Sundararajan Athijegannathan]

I watched all the 4 talks - audio is fine.

-Sundar

On 10/29/2015 12:08 PM, Jochen Theodorou wrote:
since it seems nobody mentioned it yet... is there sound on the 
youtube video? Because I seem not to have that.


bye blackdrag

On 27.10.2015 21:15, mark.reinh...@oracle.com wrote:

2015/10/23 7:39 -0700, mark.reinh...@oracle.com:

FYI, Alan, Alex, Mandy, and I will present five sessions related to
Jigsaw at JavaOne next week, three of which will be repeated:

...


Slides and videos of the sessions are available here:

   http://openjdk.java.net/projects/jigsaw/j1/

- Mark

Re: Avoiding same-package conflicts

[Karl Sanders]

Hi Alex,

indeed I'm on JDK 8 but at the moment I don't have different versions
of the same library in the classpath.
However sooner or later I will have to satisfy this requirement.
I can wait the year or so that separates us from the GA release of JDK
9 but I'm afraid that Jigsaw won't be able to help me.
Hence my questions.

Also, just for the record, I understand that having multiple versions
of the same library isn't a best practice to say the least.
But I'm afraid that this is one of the cases where the library vendor
can't modify the current code to fit my requirements and extracting
the part that I need from an older version and refactoring it into a
separate library would be quite an undertaking.

Thanks for your time.

Cheers,
Karl

On Thu, Oct 29, 2015 at 1:03 AM, Alex Buckley  wrote:
> Hi Karl,
>
> Serious question: does your Java SE application expect that different
> versions of the same library are placed on the classpath in JDK 8?
>
> Alex
>
>
> On 10/28/2015 1:34 PM, Karl Sanders wrote:
>>
>> Hi,
>>
>> I'm trying out the JDK 9 EA with Jigsaw.
>>
>> I created two modules, A and B, which are required by module C.
>>
>> Modules A and B contain a non-exported package with the same name.
>>
>> After compiling each module separately I start module C and get a
>> java.lang.reflect.LayerInstantiationException saying that modules A
>> and B contain a package with the same name.
>>
>> In light of this behaviour I have two questions.
>>
>> - Is it correct to say that for a simple Java SE application to work
>> with this configuration the only solution, in the realm of what will
>> be provided with the GA version of JDK 9, is through the concept of
>> layers of modules?
>>
>> - In that case will there be some sort of out-of-the box functionality
>> to have this scenario work or will I have to write some non-trivial
>> code to manage these layers?
>>
>> In other words, I have to use different versions of the same library
>> in a Java SE application.
>> Since Jigsaw is approaching I thought I could wait for it instead of
>> learning and having to deal with OSGi.
>> But from what I see by using only Jigsaw I won't be able to satisfy
>> this requirement.
>> At least not without writing some non-trivial code that I'm afraid is
>> above my skill level.
>>
>> Cheers,
>> Karl
>>
>

Re: Jigsaw @ JavaOne 2015

[Jochen Theodorou]

since it seems nobody mentioned it yet... is there sound on the youtube 
video? Because I seem not to have that.


bye blackdrag

On 27.10.2015 21:15, mark.reinh...@oracle.com wrote:

2015/10/23 7:39 -0700, mark.reinh...@oracle.com:

FYI, Alan, Alex, Mandy, and I will present five sessions related to
Jigsaw at JavaOne next week, three of which will be repeated:

...


Slides and videos of the sessions are available here:

   http://openjdk.java.net/projects/jigsaw/j1/

- Mark

hg: jigsaw/jake/jdk: 8139067: Re-examine if a consumer module should load bundles from unnamed module

[mandy . chung]

Changeset: 1ac78e4a10d5
Author:okutsu
Date:  2015-10-29 19:55 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1ac78e4a10d5

8139067: Re-examine if a consumer module should load bundles from unnamed module
Reviewed-by: alanb, mchung, naoto

! 
src/java.base/share/classes/sun/util/locale/provider/ResourceBundleProviderSupport.java
! test/java/util/ResourceBundle/modules/appbasic2/appbasic2.sh
! test/java/util/ResourceBundle/modules/basic/basic.sh
! test/java/util/ResourceBundle/modules/modlocal/modlocal.sh
! test/java/util/ResourceBundle/modules/simple/simple.sh

Re: RFR: 8139067: Re-examine if a consumer module should load bundles from unnamed module

[Alan Bateman]

On 29/10/2015 23:55, Masayoshi Okutsu wrote:

Hello,

Please review the change for JDK-8139067. A consumer module 
(ResourceBundle.getBundle caller) will no longer load resource bundles 
from the class-path if the consumer module is a named module. Test 
programs, basic and modlocal, have been changed to confirm .properties 
bundles are not loaded from a jar file on the class-path.The webrev 
also include some cleanup of @bug and @summary for the test programs.


Issue: https://bugs.openjdk.java.net/browse/JDK-8139067

Webrev: http://cr.openjdk.java.net/~okutsu/9/8139067/webrev.00
This looks okay to me and I agree with Mandy's comment that they are 
likely to migrate together.


-Alan.

Re: RFR: 8139067: Re-examine if a consumer module should load bundles from unnamed module

[Mandy Chung]

> On Oct 29, 2015, at 4:55 PM, Masayoshi Okutsu  
> wrote:
> 
> Hello,
> 
> Please review the change for JDK-8139067. A consumer module 
> (ResourceBundle.getBundle caller) will no longer load resource bundles from 
> the class-path if the consumer module is a named module. Test programs, basic 
> and modlocal, have been changed to confirm .properties bundles are not loaded 
> from a jar file on the class-path.The webrev also include some cleanup of 
> @bug and @summary for the test programs.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8139067
> 
> Webrev: http://cr.openjdk.java.net/~okutsu/9/8139067/webrev.00

The ResourceBundleProviderSupport change looks good to me.  It is reasonable to 
expect that the consumer of the resource bundles and the bundle modules should 
migrate to named module at the same time.  Resource bundles are generally 
application-specific. 

Mandy