Re: RFR(L) : 8176176 : fix @modules in jdk_svc tests

[Igor Ignatyev]

Hi Serguei,

1s of all, thank you for your review. 

since these tests have dependencies on more modules than corresponding 
TEST.properties file declares, we have to specify @modules tag in them, and 
because @modules in a test overrides modules from TEST.properties, jdk.jdi 
module should be mentioned in the tests.

— Igor  
 
> On Mar 15, 2017, at 9:53 PM, serguei.spit...@oracle.com wrote:
> 
> Hi Igor,
> 
> This looks good to me.
> A couple of questions below.
> 
> 
> http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/test/com/sun/jdi/InvokeHangTest.java.udiff.html
> 
> - * @modules jdk.jdi
>  *  @library /test/lib
> + * @modules java.management
> + * jdk.jdiShould the jdk.jdi be removed from this com/sun/jdi test?
> 
> 
> http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/test/com/sun/jdi/RedefineCrossEvent.java.udiff.html
> 
>  *  @modules java.corba
>  *   jdk.jdi
> 
>  Should the jdk.jdi be removed from this com/sun/jdi test?
> 
> 
> Thanks,
> Serguei
> 
> 
> On 3/15/17 11:16, Igor Ignatyev wrote:
>> Shura,
>> 
>> Thank you for your review. I have update 
>> test/java/lang/management/PlatformLoggingMXBean/TEST.properties[1] and 
>> checked that there are no similar things in other TEST.properties files.
>> 
>> Still looking for a review from a Reviewer.
>> 
>> [1]
>>> --- a/test/java/lang/management/PlatformLoggingMXBean/TEST.properties 
>>> Mon Mar 13 18:54:58 2017 -0700
>>> +++ b/test/java/lang/management/PlatformLoggingMXBean/TEST.properties 
>>> Wed Mar 15 11:09:06 2017 -0700
>>> @@ -1,3 +1,2 @@
>>> -modules = java.management \
>>> -  java.logging
>>> +modules = java.logging
>> 
>> Thanks,
>> — Igor
>> 
>>> On Mar 15, 2017, at 9:56 AM, Alexandre (Shura) Iline 
>>>  wrote:
>>> 
>>> Igor,
>>> 
>>> I have looked through a bunch of tests where @modules is changed - that 
>>> looks good.
>>> 
>>> One minor thing I noticed is that, in 
>>> test/java/lang/management/PlatformLoggingMXBean/TEST.properties you are 
>>> explicitly calling out java.management. You do not have to do that because 
>>> “modules” property is concatenated through the hierarchy.  java.management 
>>> is already listed in test/java/lang/management/TEST.properties.
>>> 
>>> Shura
>>> 
 On Mar 13, 2017, at 9:03 PM, Igor Ignatyev  
 wrote:
 
 Shura,
 
 Thank you for review, I agree that having separate bugs is more 
 convenient. [1] is new webrev w/ changes only in the files w/ incorrect 
 module dependency declarations.
 
 [1] http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html
 
 Thanks,
 — Igor
 
> On Mar 9, 2017, at 5:02 PM, Alexandre (Shura) Iline 
>  wrote:
> 
> Igor,
> 
> I have reviewed some number tests which change the @modules - they are 
> fine.
> 
> You, however, fix more things with this than missing module dependency 
> declaration. There is a redesign of line-number-sensitive tests [1] and 
> other multiple improvements such as in [2]. Would it be more convenient 
> to have that as separate bugs?
> 
> Shura
> 
> [1] 
> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArgumentValuesTest.java.sdiff.html
> [2] 
> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArrayLengthDumpTest.sh.sdiff.html
> 
>> On Mar 7, 2017, at 1:07 PM, Igor Ignatyev  
>> wrote:
>> 
>> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html
>>> 2586 lines changed: 669 ins; 484 del; 1433 mod;
>> Hi all,
>> 
>> Could you please review this changeset which fix @modules dependency 
>> declaration in jdk_svc tests?
>> there are a couple issues w/ modules in jdk_svc tests:
>> - some tests do not specify modules which they depend on
>> - modules in TEST.properties is not used in cases there all tests 
>> (should) have the same @modules directive
>> - @modules directive isn't placed according to current convention 
>> (before the 1st run directive)
>> 
>> Since this fix has already touched lots of tests, I have decided to use 
>> this opportunity and reordered some of jtreg tags as well, so there 
>> won’t be two massive updates in the tests.
>> 
>> Some of our tests are line number sensitive, and then I fixed jtreg 
>> declaration, they started to fail. It was really hard to find our all 
>> line number sensitive tests, so I have unified the way we declare that 
>> as a part of this fix. Please let me know if you prefer to have it done 
>> separately.
>> 
>> There are two one-liners which, I hope, can simplify review:
>> [1] shows only the changes which are not in comments. Besides obvious 
>> new added TEST.properties, there are changes in the following line 
>> number sensitive 

Re: RFR(L) : 8176176 : fix @modules in jdk_svc tests

[serguei.spit...@oracle.com]

Hi Igor,

This looks good to me.
A couple of questions below.


http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/test/com/sun/jdi/InvokeHangTest.java.udiff.html

- * @modules jdk.jdi
  *  @library /test/lib
+ * @modules java.management
+ * jdk.jdiShould the jdk.jdi be removed from this com/sun/jdi test?


http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/test/com/sun/jdi/RedefineCrossEvent.java.udiff.html

  *  @modules java.corba
  *   jdk.jdi

  Should the jdk.jdi be removed from this com/sun/jdi test?


Thanks,
Serguei


On 3/15/17 11:16, Igor Ignatyev wrote:

Shura,

Thank you for your review. I have update 
test/java/lang/management/PlatformLoggingMXBean/TEST.properties[1] and checked 
that there are no similar things in other TEST.properties files.

Still looking for a review from a Reviewer.

[1]

--- a/test/java/lang/management/PlatformLoggingMXBean/TEST.properties Mon 
Mar 13 18:54:58 2017 -0700
+++ b/test/java/lang/management/PlatformLoggingMXBean/TEST.properties Wed 
Mar 15 11:09:06 2017 -0700
@@ -1,3 +1,2 @@
-modules = java.management \
-  java.logging
+modules = java.logging


Thanks,
— Igor


On Mar 15, 2017, at 9:56 AM, Alexandre (Shura) Iline 
 wrote:

Igor,

I have looked through a bunch of tests where @modules is changed - that looks 
good.

One minor thing I noticed is that, in 
test/java/lang/management/PlatformLoggingMXBean/TEST.properties you are 
explicitly calling out java.management. You do not have to do that because 
“modules” property is concatenated through the hierarchy.  java.management is 
already listed in test/java/lang/management/TEST.properties.

Shura


On Mar 13, 2017, at 9:03 PM, Igor Ignatyev  wrote:

Shura,

Thank you for review, I agree that having separate bugs is more convenient. [1] 
is new webrev w/ changes only in the files w/ incorrect module dependency 
declarations.

[1] http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html

Thanks,
— Igor


On Mar 9, 2017, at 5:02 PM, Alexandre (Shura) Iline 
 wrote:

Igor,

I have reviewed some number tests which change the @modules - they are fine.

You, however, fix more things with this than missing module dependency 
declaration. There is a redesign of line-number-sensitive tests [1] and other 
multiple improvements such as in [2]. Would it be more convenient to have that 
as separate bugs?

Shura

[1] 
http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArgumentValuesTest.java.sdiff.html
[2] 
http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArrayLengthDumpTest.sh.sdiff.html


On Mar 7, 2017, at 1:07 PM, Igor Ignatyev  wrote:

http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html

2586 lines changed: 669 ins; 484 del; 1433 mod;

Hi all,

Could you please review this changeset which fix @modules dependency 
declaration in jdk_svc tests?
there are a couple issues w/ modules in jdk_svc tests:
- some tests do not specify modules which they depend on
- modules in TEST.properties is not used in cases there all tests (should) have 
the same @modules directive
- @modules directive isn't placed according to current convention (before the 
1st run directive)

Since this fix has already touched lots of tests, I have decided to use this 
opportunity and reordered some of jtreg tags as well, so there won’t be two 
massive updates in the tests.

Some of our tests are line number sensitive, and then I fixed jtreg 
declaration, they started to fail. It was really hard to find our all line 
number sensitive tests, so I have unified the way we declare that as a part of 
this fix. Please let me know if you prefer to have it done separately.

There are two one-liners which, I hope, can simplify review:
[1] shows only the changes which are not in comments. Besides obvious new added 
TEST.properties, there are changes in the following line number sensitive tests 
(which I mentioned before):
test/com/sun/jdi/ArgumentValuesTest.java
test/com/sun/jdi/BreakpointTest.java
test/com/sun/jdi/FetchLocals.java
test/com/sun/jdi/GetLocalVariables.java
test/com/sun/jdi/GetSetLocalTest.java
test/com/sun/jdi/LambdaBreakpointTest.java
test/com/sun/jdi/LineNumberOnBraceTest.java
test/com/sun/jdi/PopAndStepTest.java

[2] shows changes in jtreg tags, it can help to see that almost all changes in 
jtreg tags are either moving of tags which does not affect execution order or 
@modules changes.

webrev: http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html
bug: https://bugs.openjdk.java.net/browse/JDK-8176176
Testing:
- jdk_svc on linux, windows, mac
- checked that all tests which could be executed with full jdk before still can 
be executed with full jdk

Thanks,
— Igor

[1] $ hg diff -w | grep "^[+-]" | grep -v "^[+-]\s*[*#]"
[2] $ hg diff -w | grep -e "^\(+++ b\)\|\(--- a\)" -e "^[+-]\s*[*#]\s*@"

Re: RFR(L) : 8176176 : fix @modules in jdk_svc tests

[Igor Ignatyev]

Shura,

Thank you for your review. I have update 
test/java/lang/management/PlatformLoggingMXBean/TEST.properties[1] and checked 
that there are no similar things in other TEST.properties files.

Still looking for a review from a Reviewer.

[1]
> --- a/test/java/lang/management/PlatformLoggingMXBean/TEST.properties Mon 
> Mar 13 18:54:58 2017 -0700
> +++ b/test/java/lang/management/PlatformLoggingMXBean/TEST.properties Wed 
> Mar 15 11:09:06 2017 -0700
> @@ -1,3 +1,2 @@
> -modules = java.management \
> -  java.logging
> +modules = java.logging


Thanks,
— Igor

> On Mar 15, 2017, at 9:56 AM, Alexandre (Shura) Iline 
>  wrote:
> 
> Igor,
> 
> I have looked through a bunch of tests where @modules is changed - that looks 
> good.
> 
> One minor thing I noticed is that, in 
> test/java/lang/management/PlatformLoggingMXBean/TEST.properties you are 
> explicitly calling out java.management. You do not have to do that because 
> “modules” property is concatenated through the hierarchy.  java.management is 
> already listed in test/java/lang/management/TEST.properties.
> 
> Shura
> 
>> On Mar 13, 2017, at 9:03 PM, Igor Ignatyev  wrote:
>> 
>> Shura,
>> 
>> Thank you for review, I agree that having separate bugs is more convenient. 
>> [1] is new webrev w/ changes only in the files w/ incorrect module 
>> dependency declarations.  
>> 
>> [1] http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html
>> 
>> Thanks,
>> — Igor
>> 
>>> On Mar 9, 2017, at 5:02 PM, Alexandre (Shura) Iline 
>>>  wrote:
>>> 
>>> Igor,
>>> 
>>> I have reviewed some number tests which change the @modules - they are 
>>> fine. 
>>> 
>>> You, however, fix more things with this than missing module dependency 
>>> declaration. There is a redesign of line-number-sensitive tests [1] and 
>>> other multiple improvements such as in [2]. Would it be more convenient to 
>>> have that as separate bugs?
>>> 
>>> Shura
>>> 
>>> [1] 
>>> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArgumentValuesTest.java.sdiff.html
>>> [2] 
>>> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArrayLengthDumpTest.sh.sdiff.html
>>> 
 On Mar 7, 2017, at 1:07 PM, Igor Ignatyev  wrote:
 
 http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html
> 2586 lines changed: 669 ins; 484 del; 1433 mod;
 
 Hi all,
 
 Could you please review this changeset which fix @modules dependency 
 declaration in jdk_svc tests?
 there are a couple issues w/ modules in jdk_svc tests: 
 - some tests do not specify modules which they depend on 
 - modules in TEST.properties is not used in cases there all tests (should) 
 have the same @modules directive 
 - @modules directive isn't placed according to current convention (before 
 the 1st run directive)
 
 Since this fix has already touched lots of tests, I have decided to use 
 this opportunity and reordered some of jtreg tags as well, so there won’t 
 be two massive updates in the tests.
 
 Some of our tests are line number sensitive, and then I fixed jtreg 
 declaration, they started to fail. It was really hard to find our all line 
 number sensitive tests, so I have unified the way we declare that as a 
 part of this fix. Please let me know if you prefer to have it done 
 separately.
 
 There are two one-liners which, I hope, can simplify review:
 [1] shows only the changes which are not in comments. Besides obvious new 
 added TEST.properties, there are changes in the following line number 
 sensitive tests (which I mentioned before):
 test/com/sun/jdi/ArgumentValuesTest.java
 test/com/sun/jdi/BreakpointTest.java  
 test/com/sun/jdi/FetchLocals.java
 test/com/sun/jdi/GetLocalVariables.java
 test/com/sun/jdi/GetSetLocalTest.java 
 test/com/sun/jdi/LambdaBreakpointTest.java 
 test/com/sun/jdi/LineNumberOnBraceTest.java 
 test/com/sun/jdi/PopAndStepTest.java
 
 [2] shows changes in jtreg tags, it can help to see that almost all 
 changes in jtreg tags are either moving of tags which does not affect 
 execution order or @modules changes.
 
 webrev: http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html
 bug: https://bugs.openjdk.java.net/browse/JDK-8176176
 Testing: 
 - jdk_svc on linux, windows, mac
 - checked that all tests which could be executed with full jdk before 
 still can be executed with full jdk
 
 Thanks,
 — Igor
 
 [1] $ hg diff -w | grep "^[+-]" | grep -v "^[+-]\s*[*#]"
 [2] $ hg diff -w | grep -e "^\(+++ b\)\|\(--- a\)" -e "^[+-]\s*[*#]\s*@"
>>> 
>> 
> 

Re: #VersionsInModuleNames

[Stephen Colebourne]

On 15 March 2017 at 17:47, Alan Bateman  wrote:
> This is the consumer choosing a module name for a library that they don't
> maintain and renaming that library to match (you are writing the `requires
> X` before X exists). All I'm saying is that the library maintainer should be
> the one that chooses the module name. In its absence then deriving the name
> from from the library gives you a stable name in the short term.

I agree that the library maintainer should choose the module name, but
automatic modules will pretty much force consumers to do so, maing a
mess. The proposal above is for the case where person A has randomly
picked a modue name for a module that is not yet modularized, and
person B has to do something to comply. The proposal simply suggests
that the JPMS should not coonvert filename "bar-1.2.jar" to module
name "bar" - the developer should do this instead by renaming the
file.

Anyway, I'll write up more on how to avoid automatic modules in another thread.
Stephen

Re: #VersionsInModuleNames

[Alan Bateman]

On 15/03/2017 17:09, Stephen Colebourne wrote:


:
The proposal above only applies at runtime, not when authoring. Given a module:

module foo {
   requires bar;
}

Then the proposal says the requires clause can be satisfied in one of
three ways.
1) a real module on the module path named "bar"
2) a jar file on the module path of any filename with a "Module-Name:
bar" MANIFEST
3) a jar file on the module path with filename "bar.jar"

A developer or build system that downloads bar-1.2.jar from Maven
Central would have to rename it to put it on the module path.

Reading your response, I can only assume that you are thinknig of a
case where a developer simply moves from the classpath to the module
path for their whole application without writring any module-info
files. That seems like a daft use case to me - just stick with the
classpath. The use case that automatic modules are supposed to handle
is where your application or library is modularized, and depends
directly or indirectly on a jar file that has not yet been
modularized. In this use case, renaming the jar file to match the
module name is perfectly reasonable.
This is the consumer choosing a module name for a library that they 
don't maintain and renaming that library to match (you are writing the 
`requires X` before X exists). All I'm saying is that the library 
maintainer should be the one that chooses the module name. In its 
absence then deriving the name from from the library gives you a stable 
name in the short term.


As regarding someone moving all JAR files from the class path to the 
module path then I wasn't specifically thinking about that but I'm sure 
people will try this. Split package issues is probably the biggest 
concern with doing that.


-Alan

Re: RFR [9] 8176772: jar tool support to report automatic module names

[Mandy Chung]

> On Mar 15, 2017, at 10:12 AM, Chris Hegarty  wrote:
> 
>> 
>> Is there any reason why this option does not print the synthesized 
>> descriptor?  I understand that the issue is specific to show the derived 
>> module name.  But it’d be nice for this option to print the descriptor 
>> consistent with a normal module.
> 
> Unless I am mistaken, the synthesised descriptor does not contain
> any more information. What are you expecting?

provides and main class, if present. 

The modifier of ModuleDescriptor will have AUTOMATIC and so all packages are 
exported and open implicitly and not shown in the output which is okay.

Mandy

Re: RFR [9] 8176772: jar tool support to report automatic module names

[Chris Hegarty]

> On 15 Mar 2017, at 16:54, Mandy Chung  wrote:
> 
>> 
>> On Mar 15, 2017, at 8:31 AM, Chris Hegarty  wrote:
>> 
>> 
>>> On 15 Mar 2017, at 14:42, Alan Bateman  wrote:
>>> 
>>> On 15/03/2017 14:21, Chris Hegarty wrote:
>>> 
 :
 
 Webrev:
 
 http://cr.openjdk.java.net/~chegar/8176772.00/
 https://bugs.openjdk.java.net/browse/JDK-8176772
 
>>> If findAll returns an empty set then the error.unable.derive.automodule 
>>> message might be more appropriate. Otherwise looks good to me.
>> 
>> That would be better. Updated in-place.
>> http://cr.openjdk.java.net/~chegar/8176772.00/
> 
> Is there any reason why this option does not print the synthesized 
> descriptor?  I understand that the issue is specific to show the derived 
> module name.  But it’d be nice for this option to print the descriptor 
> consistent with a normal module.

Unless I am mistaken, the synthesised descriptor does not contain
any more information. What are you expecting?

-Chris.

Re: RFR(L) : 8176176 : fix @modules in jdk_svc tests

[Alexandre (Shura) Iline]

Igor,

I have looked through a bunch of tests where @modules is changed - that looks 
good.

One minor thing I noticed is that, in 
test/java/lang/management/PlatformLoggingMXBean/TEST.properties you are 
explicitly calling out java.management. You do not have to do that because 
“modules” property is concatenated through the hierarchy.  java.management is 
already listed in test/java/lang/management/TEST.properties.

Shura

> On Mar 13, 2017, at 9:03 PM, Igor Ignatyev  wrote:
> 
> Shura,
> 
> Thank you for review, I agree that having separate bugs is more convenient. 
> [1] is new webrev w/ changes only in the files w/ incorrect module dependency 
> declarations.  
> 
> [1] http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html
> 
> Thanks,
> — Igor
> 
>> On Mar 9, 2017, at 5:02 PM, Alexandre (Shura) Iline 
>>  wrote:
>> 
>> Igor,
>> 
>> I have reviewed some number tests which change the @modules - they are fine. 
>> 
>> You, however, fix more things with this than missing module dependency 
>> declaration. There is a redesign of line-number-sensitive tests [1] and 
>> other multiple improvements such as in [2]. Would it be more convenient to 
>> have that as separate bugs?
>> 
>> Shura
>> 
>> [1] 
>> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArgumentValuesTest.java.sdiff.html
>> [2] 
>> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArrayLengthDumpTest.sh.sdiff.html
>> 
>>> On Mar 7, 2017, at 1:07 PM, Igor Ignatyev  wrote:
>>> 
>>> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html
 2586 lines changed: 669 ins; 484 del; 1433 mod;
>>> 
>>> Hi all,
>>> 
>>> Could you please review this changeset which fix @modules dependency 
>>> declaration in jdk_svc tests?
>>> there are a couple issues w/ modules in jdk_svc tests: 
>>> - some tests do not specify modules which they depend on 
>>> - modules in TEST.properties is not used in cases there all tests (should) 
>>> have the same @modules directive 
>>> - @modules directive isn't placed according to current convention (before 
>>> the 1st run directive)
>>> 
>>> Since this fix has already touched lots of tests, I have decided to use 
>>> this opportunity and reordered some of jtreg tags as well, so there won’t 
>>> be two massive updates in the tests.
>>> 
>>> Some of our tests are line number sensitive, and then I fixed jtreg 
>>> declaration, they started to fail. It was really hard to find our all line 
>>> number sensitive tests, so I have unified the way we declare that as a part 
>>> of this fix. Please let me know if you prefer to have it done separately.
>>> 
>>> There are two one-liners which, I hope, can simplify review:
>>> [1] shows only the changes which are not in comments. Besides obvious new 
>>> added TEST.properties, there are changes in the following line number 
>>> sensitive tests (which I mentioned before):
>>> test/com/sun/jdi/ArgumentValuesTest.java
>>> test/com/sun/jdi/BreakpointTest.java  
>>> test/com/sun/jdi/FetchLocals.java
>>> test/com/sun/jdi/GetLocalVariables.java
>>> test/com/sun/jdi/GetSetLocalTest.java 
>>> test/com/sun/jdi/LambdaBreakpointTest.java 
>>> test/com/sun/jdi/LineNumberOnBraceTest.java 
>>> test/com/sun/jdi/PopAndStepTest.java
>>> 
>>> [2] shows changes in jtreg tags, it can help to see that almost all changes 
>>> in jtreg tags are either moving of tags which does not affect execution 
>>> order or @modules changes.
>>> 
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8176176
>>> Testing: 
>>> - jdk_svc on linux, windows, mac
>>> - checked that all tests which could be executed with full jdk before still 
>>> can be executed with full jdk
>>> 
>>> Thanks,
>>> — Igor
>>> 
>>> [1] $ hg diff -w | grep "^[+-]" | grep -v "^[+-]\s*[*#]"
>>> [2] $ hg diff -w | grep -e "^\(+++ b\)\|\(--- a\)" -e "^[+-]\s*[*#]\s*@"
>> 
> 

Re: RFR [9] 8176772: jar tool support to report automatic module names

[Mandy Chung]

> On Mar 15, 2017, at 8:31 AM, Chris Hegarty  wrote:
> 
> 
>> On 15 Mar 2017, at 14:42, Alan Bateman  wrote:
>> 
>> On 15/03/2017 14:21, Chris Hegarty wrote:
>> 
>>> :
>>> 
>>> Webrev:
>>> 
>>>  http://cr.openjdk.java.net/~chegar/8176772.00/
>>>  https://bugs.openjdk.java.net/browse/JDK-8176772
>>> 
>> If findAll returns an empty set then the error.unable.derive.automodule 
>> message might be more appropriate. Otherwise looks good to me.
> 
> That would be better. Updated in-place.
>  http://cr.openjdk.java.net/~chegar/8176772.00/

Is there any reason why this option does not print the synthesized descriptor?  
I understand that the issue is specific to show the derived module name.  But 
it’d be nice for this option to print the descriptor consistent with a normal 
module.

Mandy

Re: RFR [9] 8176772: jar tool support to report automatic module names

[Chris Hegarty]

> On 15 Mar 2017, at 14:42, Alan Bateman  wrote:
> 
> On 15/03/2017 14:21, Chris Hegarty wrote:
> 
>> :
>> 
>> Webrev:
>> 
>>   http://cr.openjdk.java.net/~chegar/8176772.00/
>>   https://bugs.openjdk.java.net/browse/JDK-8176772
>> 
> If findAll returns an empty set then the error.unable.derive.automodule 
> message might be more appropriate. Otherwise looks good to me.

That would be better. Updated in-place.
  http://cr.openjdk.java.net/~chegar/8176772.00/

-Chris.

Re: RFR [9] 8176772: jar tool support to report automatic module names

[Alan Bateman]

On 15/03/2017 14:21, Chris Hegarty wrote:


:

Webrev:

   http://cr.openjdk.java.net/~chegar/8176772.00/
   https://bugs.openjdk.java.net/browse/JDK-8176772


If findAll returns an empty set then the error.unable.derive.automodule 
message might be more appropriate. Otherwise looks good to me.


-Alan

Re: #VersionsInModuleNames

[Alan Bateman]

On 15/03/2017 10:13, Stephen Colebourne wrote:


Automatic modules must either contain the
Module-Name MANIFEST entry, or have a file name that exactly matches
the desired module name. ie. the standard jar files downloaded from
Maven Central, eg foo-bar-1.2 must be renamed to be used as an
automatic module.
This looks like it would force everyone starting out to rename lots of 
JAR files and essentially choose module names for libraries that they 
don't maintain. The module name is something that the module author 
should choose. Having the consumer or others trying to force a different 
name feels chaotic.


-Alan

Re: #VersionsInModuleNames

[Peter Levart]

+1

I have been planning to write a similar comment. I understand that the 
main desire is to discourage version numbers to creep into module names, 
but no rule can prevent that entirely. We can only advise against it, 
not police it. If one wants to do it otherwise, let him do it. He'll 
soon realize that it doesn't play well...


Regards, Peter

On 03/15/2017 11:13 AM, Stephen Colebourne wrote:

Responding to the discussion on the EG list.

I am now strongly of the opinion that using the language to restrict
module names to not end in a number is a mistake. The two clear cases
show two reasons why it is a mistake.

commons-lang3 is the third version of commons-lang. It was named  this
way because the API changed, and there was a strong desire to allow
both commons-lang and commons-lang3 to be on the classpath. Note that
the package for commons-lang is org.apache.commons.lang and the
package for commons-lang3 is org.apache.commons.lang3.

(Again, if we were to name modules after the highest package, it would
be obvious what the relationship is, and why restricting numbers
doesn't make sense, because they are allowed in package names)

fabric8 is a brand name, and an example of the future of naming
projects. Over time, more and more good project names are being used
up (just like good user names). Roll forward 10 years, and the chances
of finding a good project name will decrease. Using a number as part
of the name is one way to sidestep the problem and expand the number
of available names.

If the current #VersionsInModuleNames plan is not changed, the key
question is What Should These Projects Name Themselves?

commons-lang-three?
Maybe, but yuck.

fabricate?
Maybe, but really that is a completely different name, and the whole
point of using the 8 was to avoid using the -ate project name (maybe
someone else owns "fabricate").

I'm sure there are plenty of other examples on Maven Central. But it
doesn't really matter. Both of these are valid reasons to name a
project with a number at the end. As such, the #VersionsInModuleNames
proposal cannot stand.


Since part of the reason for this proposal was automatic modules,
which have caused problems in other ways, I'll suggest the following
change to automatic modules. Automatic modules must either contain the
Module-Name MANIFEST entry, or have a file name that exactly matches
the desired module name. ie. the standard jar files downloaded from
Maven Central, eg foo-bar-1.2 must be renamed to be used as an
automatic module. This means that the proposed rules for removing the
trailing version and converting dashes to dots would be removed from
the spec. Build systems and developers are perfactly capable of
renaming a file - baking specific naming conversion rules into the
JPMS is inadvisble.

(Note that the above is not an endorsement of automatic modules in
general, I believe that there are better solutions to the migration
problem. But the above is an imporvement to the current state of the
JPMS.)

thanks
Stephen

#VersionsInModuleNames

[Stephen Colebourne]

Responding to the discussion on the EG list.

I am now strongly of the opinion that using the language to restrict
module names to not end in a number is a mistake. The two clear cases
show two reasons why it is a mistake.

commons-lang3 is the third version of commons-lang. It was named  this
way because the API changed, and there was a strong desire to allow
both commons-lang and commons-lang3 to be on the classpath. Note that
the package for commons-lang is org.apache.commons.lang and the
package for commons-lang3 is org.apache.commons.lang3.

(Again, if we were to name modules after the highest package, it would
be obvious what the relationship is, and why restricting numbers
doesn't make sense, because they are allowed in package names)

fabric8 is a brand name, and an example of the future of naming
projects. Over time, more and more good project names are being used
up (just like good user names). Roll forward 10 years, and the chances
of finding a good project name will decrease. Using a number as part
of the name is one way to sidestep the problem and expand the number
of available names.

If the current #VersionsInModuleNames plan is not changed, the key
question is What Should These Projects Name Themselves?

commons-lang-three?
Maybe, but yuck.

fabricate?
Maybe, but really that is a completely different name, and the whole
point of using the 8 was to avoid using the -ate project name (maybe
someone else owns "fabricate").

I'm sure there are plenty of other examples on Maven Central. But it
doesn't really matter. Both of these are valid reasons to name a
project with a number at the end. As such, the #VersionsInModuleNames
proposal cannot stand.


Since part of the reason for this proposal was automatic modules,
which have caused problems in other ways, I'll suggest the following
change to automatic modules. Automatic modules must either contain the
Module-Name MANIFEST entry, or have a file name that exactly matches
the desired module name. ie. the standard jar files downloaded from
Maven Central, eg foo-bar-1.2 must be renamed to be used as an
automatic module. This means that the proposed rules for removing the
trailing version and converting dashes to dots would be removed from
the spec. Build systems and developers are perfactly capable of
renaming a file - baking specific naming conversion rules into the
JPMS is inadvisble.

(Note that the above is not an endorsement of automatic modules in
general, I believe that there are better solutions to the migration
problem. But the above is an imporvement to the current state of the
JPMS.)

thanks
Stephen

hg: jigsaw/jake/langtools: Tempoarily exclude tools/javac/platform/PlatformProviderTest.java

[alan . bateman]

Changeset: fb9bb5851e88
Author:alanb
Date:  2017-03-15 10:00 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fb9bb5851e88

Tempoarily exclude tools/javac/platform/PlatformProviderTest.java

! test/ProblemList.txt