Re: RFR 8152742: jlink --include-locales th fails with ArrayIndexOutOfBoundsException

[Mandy Chung]

> On Apr 1, 2016, at 2:20 PM, Naoto Sato  wrote:
> 
> Hello,
> 
> Please review the fix for the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8152742
> 
> The fix is located at:
> 
> http://cr.openjdk.java.net/~naoto/8152742/webrev.00/

Looks okay to me.  It’d be good to have Masayoshi to review it.

Mandy

Re: modulepath and classpath mixture

[Jonathan Gibbons]

Rémi,

I think all of us working on Jigsaw have equally shared the experience of 
figuring out how to do testing in this modular world.

Currently, the solution to your problem is to use javac's -XaddReads option, 
which is to javac's compilation environment what the launcher's -XaddReads 
option is to the execution environment.

Just as the runtime provides a family of options to configure the modules is 
use at runtime,
-upgrademodulepath -modulepath -addmods -limitmods -XaddReads 
-XaddExports -Xpatch etc
so too does javac have an equivalent set of options to configure the modules in 
use at compile time.

The primary additions/differences at compile time:
-modulesourcepath   (obviously source in not applicable at runtime)
-system (when compiling, you can override the default 
target system)
-Xmodulefor compiling additional classes to patch into 
a module

-- Jon



On 04/01/2016 02:55 PM, fo...@univ-mlv.fr wrote:

Hi Jon,
thanks for taking the time to explain the whole picture, as you know, you are 
probably the one with most experience about testing in the modular world.

This threads starts with this question, how to do unit testing with Maven when 
everything is a module, your case 3, so i will focus on that case.
Here is my question, in case of 3a or 3b, i don't see how to explain to javac 
how to compile if there are some specific dependencies for the test (that are 
also modules).

regards,
Rémi

- Mail original -

De: "Jonathan Gibbons" 
À: "Remi Forax" , "Alan Bateman" 
Cc: "Russell Gold" , "jigsaw-dev" 

Envoyé: Jeudi 31 Mars 2016 03:29:55
Objet: Re: modulepath and classpath mixture

I have been following this thread, and it strongly reminds me of Joe
Darcy's parables of elephants and blind men. [1,2]

In this context, the discussion has been about testing, and the
underlying presumption that one size fits all.

I venture to suggest that one size does /not/ fit all, and that we have
to be able to support a wide range of testing paradigms.

1) Some folk will want to do black box testing, with their tests
contained in their own first class module, to exercise the code the way
that real clients might do

2) Some folk will want to do black box testing, with their test code on
the classpath, in the unnamed module, because they don't want to update
their test code

3) Some folk will want to do white box testing, using code conventions
is widespread use today, where the test code is alongside the code being
tested, in the same package.   This generates two sub-cases:   a) is the
test code compiled into the module itself, in a special test-specific
build, or  b) is the test code dynamically patched into the module

4) Some folk will want to do white box testing, but will be less
concerned about the package used to contain the package.  That has the
same two sub-cases:a) is the test code compiled into the module
itself, in a special test-specific build, or  b) is the test code
dynamically patched into the module

Now you take all those scenarios, and cross-product them with issues
like, is there a test framework involved, such as JUnit or TestNG, and,
where should that framework be placed: can it be an automatic module, or
it is sufficient to put the framework on the classpath, in the unnamed
module?

When you understand all that, then you begin to see the shape of the
elephant in the room that is the testing problem.

But, to stretch the analogy to breaking point,  it's not the only
elephant in the room.  There's another, different, elephant called
"strong encapsulation", and there is a strong conflict between the
desire for easy white box testing and the desire for strong
encapsulation. While the past 20 years of Java have led to easy simple
white box testing, leveraging split packages by adding jars onto the
class path, we've also seen the the problems that such techniques can
lead to ... hence the desire for Project Jigsaw, and the requirement [3]
for strong encapsulation.  We have to accept that the better we succeed
at strong encapsulation, the harder it will be to use the old ways of
white box testing. Conversely, the more we hold to the old ways of
working, the less we will succeed at satisfying the goal of strong
encapsulation.

So, ultimately, the trick is to figure out how to walk the tightrope
between the two elephants in the room.  Previously, as a community,
we've built tools to help manage the task. Now, it is time for the tools
and our practices to evolve, to meet the new demands of testing in a
modular world.

Do we have all the answers today? Almost certainly not. But I will note
one of the unheralded success stories of Jigsaw and OpenJDK. Testing has
always been important, and we have managed to keep running almost all of
the JDK unit and regression tests with little to no 

Re: modulepath and classpath mixture

[forax]

Hi Jon,
thanks for taking the time to explain the whole picture, as you know, you are 
probably the one with most experience about testing in the modular world.

This threads starts with this question, how to do unit testing with Maven when 
everything is a module, your case 3, so i will focus on that case.
Here is my question, in case of 3a or 3b, i don't see how to explain to javac 
how to compile if there are some specific dependencies for the test (that are 
also modules).

regards,
Rémi

- Mail original -
> De: "Jonathan Gibbons" 
> À: "Remi Forax" , "Alan Bateman" 
> Cc: "Russell Gold" , "jigsaw-dev" 
> 
> Envoyé: Jeudi 31 Mars 2016 03:29:55
> Objet: Re: modulepath and classpath mixture
> 
> I have been following this thread, and it strongly reminds me of Joe
> Darcy's parables of elephants and blind men. [1,2]
> 
> In this context, the discussion has been about testing, and the
> underlying presumption that one size fits all.
> 
> I venture to suggest that one size does /not/ fit all, and that we have
> to be able to support a wide range of testing paradigms.
> 
> 1) Some folk will want to do black box testing, with their tests
> contained in their own first class module, to exercise the code the way
> that real clients might do
> 
> 2) Some folk will want to do black box testing, with their test code on
> the classpath, in the unnamed module, because they don't want to update
> their test code
> 
> 3) Some folk will want to do white box testing, using code conventions
> is widespread use today, where the test code is alongside the code being
> tested, in the same package.   This generates two sub-cases:   a) is the
> test code compiled into the module itself, in a special test-specific
> build, or  b) is the test code dynamically patched into the module
> 
> 4) Some folk will want to do white box testing, but will be less
> concerned about the package used to contain the package.  That has the
> same two sub-cases:a) is the test code compiled into the module
> itself, in a special test-specific build, or  b) is the test code
> dynamically patched into the module
> 
> Now you take all those scenarios, and cross-product them with issues
> like, is there a test framework involved, such as JUnit or TestNG, and,
> where should that framework be placed: can it be an automatic module, or
> it is sufficient to put the framework on the classpath, in the unnamed
> module?
> 
> When you understand all that, then you begin to see the shape of the
> elephant in the room that is the testing problem.
> 
> But, to stretch the analogy to breaking point,  it's not the only
> elephant in the room.  There's another, different, elephant called
> "strong encapsulation", and there is a strong conflict between the
> desire for easy white box testing and the desire for strong
> encapsulation. While the past 20 years of Java have led to easy simple
> white box testing, leveraging split packages by adding jars onto the
> class path, we've also seen the the problems that such techniques can
> lead to ... hence the desire for Project Jigsaw, and the requirement [3]
> for strong encapsulation.  We have to accept that the better we succeed
> at strong encapsulation, the harder it will be to use the old ways of
> white box testing. Conversely, the more we hold to the old ways of
> working, the less we will succeed at satisfying the goal of strong
> encapsulation.
> 
> So, ultimately, the trick is to figure out how to walk the tightrope
> between the two elephants in the room.  Previously, as a community,
> we've built tools to help manage the task. Now, it is time for the tools
> and our practices to evolve, to meet the new demands of testing in a
> modular world.
> 
> Do we have all the answers today? Almost certainly not. But I will note
> one of the unheralded success stories of Jigsaw and OpenJDK. Testing has
> always been important, and we have managed to keep running almost all of
> the JDK unit and regression tests with little to no change in
> functionality in almost all of the tests, and we have started supporting
> new testing scenarios as well. Looking back at the list I gave at the
> beginning, support for 1 is coming available, but not yet widely used,
> many JDK tests use case 2,  JDK has a number of tests that use 3b and
> 4b, and we have tests that use JUnit and TestNG.
> 
> So, command line options like -XaddExports, -Xpatch, -Xmodule, etc, may
> not be pretty, but they can be composed to cover a wide range of testing
> scenarios, without giving up too much on the goal of strong
> encapsulation, and that at least is some degree of success.
> 
> -- Jon
> 
> [1]
> https://blogs.oracle.com/darcy/entry/project_coin_elephants_knapsacks_language
> [2] http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant
> [3] http://openjdk.java.net/projects/jigsaw/spec/reqs/
> 

RFR 8152742: jlink --include-locales th fails with ArrayIndexOutOfBoundsException

[Naoto Sato]

Hello,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8152742

The fix is located at:

http://cr.openjdk.java.net/~naoto/8152742/webrev.00/

Naoto

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

[Claes Redestad]

On 2016-04-01 16:57, Mandy Chung wrote:

On Apr 1, 2016, at 5:32 AM, Claes Redestad  wrote:

http://cr.openjdk.java.net/~redestad/8152641/webrev.06/


Looks good except the new test with 2015 copyright start year.


Fixed. Thanks Mandy!

/Claes

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

[Mandy Chung]

> On Apr 1, 2016, at 5:32 AM, Claes Redestad  wrote:
> 
> http://cr.openjdk.java.net/~redestad/8152641/webrev.06/
> 

Looks good except the new test with 2015 copyright start year.

> 
> [1] Mandy filed https://bugs.openjdk.java.net/browse/JDK-8153238 to improve 
> this test.

Yes the test should be revised to validate a well-known list of plugins rather 
than hardcoding the number of plugins.

Mandy

Inner classes are allowed to be specified in 'uses' statement

[Georgiy Rakov]

Hello,

currently inner classes are allowed to be specified in 'uses' statement, 
for instance following code is compiled successfully by JDKb111 javac:


   a/module-info.java:
   module a {
uses pkg.Outer.Inner;
   }

   a/pkg/Outer.java:
   package pkg;
   public class Outer{ public class Inner{} }

Spec doesn't prevent it either. However in 1.1.3 
 it prevents 
implementations specified in 'provides' statement to be inner classes. 
According to my understanding inner class cannot be extended by 
non-inner class, for instance "public class Impl extends Outer.Inner { } 
" would cause:


   error: an enclosing instance
   that contains Outer.Inner is required
   class Implem extends Outer.Inner {}
   ^
   1 error

So could you please tell what is the purpose of allowing inner classes 
to be specified in 'uses' statement, there seem to be no way to create 
its implementation. Should it be prohibited by spec?


The minimized testcase is attached; in order to run it please:
1. unzip attached archive on Windows machine;
2. rename test12\test_bat to test12\test.bat;
3. modify test.bat by changing JDK_HOME variable to point to your JDK 
installation;

4. run test.bat.

Thank you,
Georgiy.

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

[Claes Redestad]

Hi Mandy et al,

On 2016-04-01 01:10, Mandy Chung wrote:

GenerateBMHClassesPlugin::configure
The plugin should validate of the input argument and throw an exception if 
it’s invalid.  The plugin API is still being revised and JDK-8152800 is related 
to the exception case.  The existing plugins throw PluginException.  
GenerateBMHClassesPlugin can do the same.

Perhaps the expanded signatures should be stored after validation.

GenerateBMHClassesPlugin::generateConcreteClass
It issues a warning if any exception thrown.  If the user specifies the 
types in the command line, they should specify the valid values (I would 
expect).  I prefer it to be an error and throw PluginException.

It may be time to rename this plugin to —-generate-jli-classes plugin, as John 
suggests.  A jlink plugin can define its sub options e.g. 
—-generate-jli-classes=bmh[:species=LL,LLL].

Can you add a test to sanity test if the classes are generated (both the 
default species types as well as specified in the input argument)?

Mandy


http://cr.openjdk.java.net/~redestad/8152641/webrev.06/

- Renamed GenerateBMHClassesPlugin to GenerateJLIClassesPlugin, 
--generate-bmh -> --generate-jli-classes
- Implement control of BMH species with sub-parameters 
--generate-jli-classes=bmh:bmh-species=LL,L3,L5 etc. This will be easy 
to extend into something like 
--generate-jli-classes=all:bmh-species=LL,L3,...:invokers=??,...:lambda-forms=??,... 
as we add other things to this plugin

- Expand and validate input in the plugin
- Add a test which tests default, explicit, invalid and disabled cases
- Add a defaultSpecies() method for testing convenience together with a 
comment alluding to how it was generated.

- Bumped the counter in JLinkTest...[1]

To try and answer John's other comments: Yes, I intend to file RFEs and 
work on adding support to generate other j.l.i classes in the near 
future as time allows, and also have some naïve hope that we can add 
support to generate the default input arguments at build-time.


Thanks for all the feedback and reviews!

/Claes

[1] Mandy filed https://bugs.openjdk.java.net/browse/JDK-8153238 to 
improve this test.

Re: javac accepts enums, annotations and final classes being referenced by 'uses' statement

[Georgiy Rakov]

Hello,

the issue is filed: https://bugs.openjdk.java.net/browse/JDK-8153268

Thanks,
Georgiy.

On 31.03.2016 18:10, Jonathan Gibbons wrote:

Georgiy,

Please file this as an issue against javac, and we'll take it from 
there.   The case of the final class has previously been considered 
and considered "silly but not wrong", but the other two have not been 
explicitly considered.


Alex has previously said in this forum that 'uses' and 'provides' are 
just a convenient front-end for the ServiceLoader API, so I would 
expect that to be taken into account when considering what should be 
accepted as legal here.


-- Jon

On 03/30/2016 04:18 AM, Georgiy Rakov wrote:

Hello,

currently JDK9b111 javac successfully compiles following code:

   a/module-info.java:
   module a {
uses pkg.FinalClassST;
uses pkg.EnumST;
uses pkg.AnnotationST;
   }

   a/pkg/AnnotationST.java:
   package pkg;
   public @interface AnnotationST{}

   a/pkg/EnumST.java:
   package pkg;
   public enum EnumST {A,B}

   a/pkg/FinalClassST.java:
   package pkg;
   public final class FinalClassST{}


Could you please tell if this is javac, spec or both issue that type 
being referenced by 'uses' statement is not checked at compile-time 
for ability to be a service interface.


The minimized testcase is attached; in order to run it please:
1. unzip attached archive on Windows machine;
2. rename test9\test_bat to test9\test.bat;
3. modify test.bat by changing JDK_HOME variable to point to your JDK 
installation;

4. run test.bat.

BTW: provided the type name references non existing type javac does 
produce compile error.


Thanks,
Georgiy.

hg: jigsaw/jake/jdk: 8136645: jlink tool should create windows os compatible launcher

[sundararajan . athijegannathan]

Changeset: 1525539374b6
Author:sundar
Date:  2016-04-01 17:42 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1525539374b6

8136645: jlink tool should create windows os compatible launcher
Reviewed-by: dsamersoff, mchung, alanb

! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java

Re: RFR 8136645: jlink tool should create windows os compatible launcher

[Alan Bateman]

On 01/04/2016 09:38, Sundararajan Athijegannathan wrote:

Thanks for your comments.

* Removed !Files.exists
* Added isWindows check for .bat files

Updated webrev: http://cr.openjdk.java.net/~sundar/8136645/webrev.03/


This looks okay.

At some point then we need to change this so that it generates based on 
the target OS but it is a bit of a corner case to be generating a 
Windows runtime image when not on Windows. On the other hand, one might 
be creating a runtime image for an embedded system, say linux-arm, when 
on Windows, so that should work. We probably need other issues to track 
some of the residual issues to make that work.


-Alan

Re: RFR 8136645: jlink tool should create windows os compatible launcher

[Sundararajan Athijegannathan]

Thanks for your comments.

* Removed !Files.exists
* Added isWindows check for .bat files

Updated webrev: http://cr.openjdk.java.net/~sundar/8136645/webrev.03/

Thanks,
-Sundar

On 4/1/2016 12:07 PM, Alan Bateman wrote:
>
>
> On 01/04/2016 06:27, Sundararajan Athijegannathan wrote:
>> That is true of shell scripts too. i.e., existing code generates shell
>> scripts on Windows too  (although those shell scripts seem to run fine
>> under Cygwin).
>>
>> Do you think we should filter out? Cross-platform image generation
>> scenario?
>>
> As I recall, the .sh is generated on Windows for those that might run
> it from Cygwin so I think okay to leave that. The main thing is only
> generate the .bat on Windows.
>
> I think we can rid of the !Files.exists test for both the shell and
> .bat case.
>
> -Alan.

Re: RFR 8136645: jlink tool should create windows os compatible launcher

[Alan Bateman]

On 01/04/2016 06:27, Sundararajan Athijegannathan wrote:

That is true of shell scripts too. i.e., existing code generates shell
scripts on Windows too  (although those shell scripts seem to run fine
under Cygwin).

Do you think we should filter out? Cross-platform image generation scenario?

As I recall, the .sh is generated on Windows for those that might run it 
from Cygwin so I think okay to leave that. The main thing is only 
generate the .bat on Windows.


I think we can rid of the !Files.exists test for both the shell and .bat 
case.


-Alan.