From stephan.herrmann at berlin.de  Tue Nov  7 18:56:04 2017
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Tue, 7 Nov 2017 19:56:04 +0100
Subject: Combining -classpath and module-info?
Message-ID: <01aa6a5b-db88-adf4-c3a6-2767a8f34261@berlin.de>

I recently noticed that compilers start to ignore -classpath as soon
as module-info (.java or .class) is found during the compile.
(Incidentally, javac and Eclipse compiler agree in this).

Using a trivial test class this works:
$ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java

This doesn't (cannot resolve any types from junit4.jar):
$ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java src/module-info.java

Similarly if -sourcepath is used or module-info.class exists in bin/ .

In my reading, JEP 261 explicitly allows this situation, but before I fix this
on our side, I'd like to know whether this *is* a bug or intended behavior.

thanks,
Stephan

From Alan.Bateman at oracle.com  Tue Nov  7 20:43:06 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 Nov 2017 20:43:06 +0000
Subject: Combining -classpath and module-info?
In-Reply-To: <01aa6a5b-db88-adf4-c3a6-2767a8f34261@berlin.de>
References: <01aa6a5b-db88-adf4-c3a6-2767a8f34261@berlin.de>
Message-ID: <bb19c4c0-aa7e-ca4a-2f34-62a786d85863@oracle.com>

On 07/11/2017 18:56, Stephan Herrmann wrote:
> I recently noticed that compilers start to ignore -classpath as soon
> as module-info (.java or .class) is found during the compile.
> (Incidentally, javac and Eclipse compiler agree in this).
>
> Using a trivial test class this works:
> $ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java
>
> This doesn't (cannot resolve any types from junit4.jar):
> $ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java 
> src/module-info.java
The module you are compiling doesn't read the unnamed module. You can't 
write "requires $CLASSPATH" for example.

If you add `--add-reads <module>=ALL-UNNAMED` to the command line then 
it should compile.

-Alan

From stephan.herrmann at berlin.de  Tue Nov  7 20:56:25 2017
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Tue, 7 Nov 2017 21:56:25 +0100
Subject: Combining -classpath and module-info?
In-Reply-To: <bb19c4c0-aa7e-ca4a-2f34-62a786d85863@oracle.com>
References: <01aa6a5b-db88-adf4-c3a6-2767a8f34261@berlin.de>
 <bb19c4c0-aa7e-ca4a-2f34-62a786d85863@oracle.com>
Message-ID: <e324c15a-fc27-ff94-5f1d-8f696f96bb74@berlin.de>

On 07.11.2017 21:43, Alan Bateman wrote:
> On 07/11/2017 18:56, Stephan Herrmann wrote:
>> I recently noticed that compilers start to ignore -classpath as soon
>> as module-info (.java or .class) is found during the compile.
>> (Incidentally, javac and Eclipse compiler agree in this).
>>
>> Using a trivial test class this works:
>> $ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java
>>
>> This doesn't (cannot resolve any types from junit4.jar):
>> $ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java src/module-info.java
> The module you are compiling doesn't read the unnamed module. You can't write "requires $CLASSPATH" for example.
> 
> If you add `--add-reads <module>=ALL-UNNAMED` to the command line then it should compile.
> 
> -Alan

Thanks, Alan, that would work.

But that is not what I meant when referring to JEP 261.

In JEP 261 I see (under "Single-module mode"):
"It is possible to put arbitrary classes and JAR files on the class path in this mode,
  but that is not recommended since it amounts to treating those classes and JAR files as
  part of the module being compiled."

Doesn't this say, my above command line treats junit4.jar as part of the current module,
*not* as an unnamed module?

Is everything referenced via -classpath definitely treated as an unnamed module?
Independent of single-/multi-module modes?

Stephan

From jonathan.gibbons at oracle.com  Tue Nov  7 22:03:15 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 07 Nov 2017 14:03:15 -0800
Subject: Combining -classpath and module-info?
In-Reply-To: <e324c15a-fc27-ff94-5f1d-8f696f96bb74@berlin.de>
References: <01aa6a5b-db88-adf4-c3a6-2767a8f34261@berlin.de>
 <bb19c4c0-aa7e-ca4a-2f34-62a786d85863@oracle.com>
 <e324c15a-fc27-ff94-5f1d-8f696f96bb74@berlin.de>
Message-ID: <5A022DA3.3050308@oracle.com>



On 11/07/2017 12:56 PM, Stephan Herrmann wrote:
> On 07.11.2017 21:43, Alan Bateman wrote:
>> On 07/11/2017 18:56, Stephan Herrmann wrote:
>>> I recently noticed that compilers start to ignore -classpath as soon
>>> as module-info (.java or .class) is found during the compile.
>>> (Incidentally, javac and Eclipse compiler agree in this).
>>>
>>> Using a trivial test class this works:
>>> $ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java
>>>
>>> This doesn't (cannot resolve any types from junit4.jar):
>>> $ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java 
>>> src/module-info.java
>> The module you are compiling doesn't read the unnamed module. You 
>> can't write "requires $CLASSPATH" for example.
>>
>> If you add `--add-reads <module>=ALL-UNNAMED` to the command line 
>> then it should compile.
>>
>> -Alan
>
> Thanks, Alan, that would work.
>
> But that is not what I meant when referring to JEP 261.
>
> In JEP 261 I see (under "Single-module mode"):
> "It is possible to put arbitrary classes and JAR files on the class 
> path in this mode,
>  but that is not recommended since it amounts to treating those 
> classes and JAR files as
>  part of the module being compiled."
>
> Doesn't this say, my above command line treats junit4.jar as part of 
> the current module,
> *not* as an unnamed module?
>
> Is everything referenced via -classpath definitely treated as an 
> unnamed module?
> Independent of single-/multi-module modes?
>
> Stephan

Stephan,

I think you have identified some outdated text that needs to be fixed.

The text was correct at one point, when the distinction between "single 
module mode"
and "multi-module mode" was a bigger deal.

These days, the primary distinction is between "classpath (legacy) mode" 
(no modules being compiled)
and "module mode" (one or more modules being compiled.)

Here's how javac treats these modes:

In classpath (legacy) mode ...

* the sourcepath, classpath and output directory behave as previously, 
such as in JDK 8.

In module mode ...

* all classes on the classpath (-classpath) are treated as part of the 
unnamed module.

* if you are just compiling a single module, you may either put the 
source for that module
on the source path (-sourcepath) or in a directory on the module source 
path (--module-source-path).

* if you are compiling multiple modules, they must be in separate 
directories on the
module source path (--module-source-path).

* javac will implicitly look for previously compiled classes in the 
output directory (-d).
(This is in contrast to the usage in classpath/legacy mode, where it has 
always been common practice
to explicitly put the output directory on the classpath as well.)

-- Jon



From stephan.herrmann at berlin.de  Tue Nov  7 22:25:58 2017
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Tue, 7 Nov 2017 23:25:58 +0100
Subject: Combining -classpath and module-info?
In-Reply-To: <5A022DA3.3050308@oracle.com>
References: <01aa6a5b-db88-adf4-c3a6-2767a8f34261@berlin.de>
 <bb19c4c0-aa7e-ca4a-2f34-62a786d85863@oracle.com>
 <e324c15a-fc27-ff94-5f1d-8f696f96bb74@berlin.de>
 <5A022DA3.3050308@oracle.com>
Message-ID: <ea7dc86a-4941-3b0a-69fa-a0d4f6212132@berlin.de>

Thanks a lot, Jon,

This is very helpful.

As you mention legacy mode as "no modules being compiled", this mode
is still tied to the -source, -target, and --release options, right?

IOW, the fact that the command line without module-info.java succeeds
is not owed to using a different compilation mode, but to compiling
everything in the same unnamed module, right?


Does JEP 261 have a process for correcting the text after it has been delivered?

Which space should I watch for updates?
- http://openjdk.java.net/jeps/261
- https://bugs.openjdk.java.net/browse/JDK-8061972
- any other?

regards,
Stephan

On 07.11.2017 23:03, Jonathan Gibbons wrote:
> 
> 
> On 11/07/2017 12:56 PM, Stephan Herrmann wrote:
>> On 07.11.2017 21:43, Alan Bateman wrote:
>>> On 07/11/2017 18:56, Stephan Herrmann wrote:
>>>> I recently noticed that compilers start to ignore -classpath as soon
>>>> as module-info (.java or .class) is found during the compile.
>>>> (Incidentally, javac and Eclipse compiler agree in this).
>>>>
>>>> Using a trivial test class this works:
>>>> $ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java
>>>>
>>>> This doesn't (cannot resolve any types from junit4.jar):
>>>> $ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java src/module-info.java
>>> The module you are compiling doesn't read the unnamed module. You can't write "requires $CLASSPATH" for example.
>>>
>>> If you add `--add-reads <module>=ALL-UNNAMED` to the command line then it should compile.
>>>
>>> -Alan
>>
>> Thanks, Alan, that would work.
>>
>> But that is not what I meant when referring to JEP 261.
>>
>> In JEP 261 I see (under "Single-module mode"):
>> "It is possible to put arbitrary classes and JAR files on the class path in this mode,
>> ?but that is not recommended since it amounts to treating those classes and JAR files as
>> ?part of the module being compiled."
>>
>> Doesn't this say, my above command line treats junit4.jar as part of the current module,
>> *not* as an unnamed module?
>>
>> Is everything referenced via -classpath definitely treated as an unnamed module?
>> Independent of single-/multi-module modes?
>>
>> Stephan
> 
> Stephan,
> 
> I think you have identified some outdated text that needs to be fixed.
> 
> The text was correct at one point, when the distinction between "single module mode"
> and "multi-module mode" was a bigger deal.
> 
> These days, the primary distinction is between "classpath (legacy) mode" (no modules being compiled)
> and "module mode" (one or more modules being compiled.)
> 
> Here's how javac treats these modes:
> 
> In classpath (legacy) mode ...
> 
> * the sourcepath, classpath and output directory behave as previously, such as in JDK 8.
> 
> In module mode ...
> 
> * all classes on the classpath (-classpath) are treated as part of the unnamed module.
> 
> * if you are just compiling a single module, you may either put the source for that module
> on the source path (-sourcepath) or in a directory on the module source path (--module-source-path).
> 
> * if you are compiling multiple modules, they must be in separate directories on the
> module source path (--module-source-path).
> 
> * javac will implicitly look for previously compiled classes in the output directory (-d).
> (This is in contrast to the usage in classpath/legacy mode, where it has always been common practice
> to explicitly put the output directory on the classpath as well.)
> 
> -- Jon
> 
> 


From jonathan.gibbons at oracle.com  Wed Nov  8 00:08:55 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 07 Nov 2017 16:08:55 -0800
Subject: Combining -classpath and module-info?
In-Reply-To: <ea7dc86a-4941-3b0a-69fa-a0d4f6212132@berlin.de>
References: <01aa6a5b-db88-adf4-c3a6-2767a8f34261@berlin.de>
 <bb19c4c0-aa7e-ca4a-2f34-62a786d85863@oracle.com>
 <e324c15a-fc27-ff94-5f1d-8f696f96bb74@berlin.de>
 <5A022DA3.3050308@oracle.com>
 <ea7dc86a-4941-3b0a-69fa-a0d4f6212132@berlin.de>
Message-ID: <5A024B17.9070004@oracle.com>



On 11/07/2017 02:25 PM, Stephan Herrmann wrote:
> Thanks a lot, Jon,
>
> This is very helpful.
>
> As you mention legacy mode as "no modules being compiled", this mode
> is still tied to the -source, -target, and --release options, right?

Strongly related, yes, but not directly tied together.

Set aside the use of the "legacy" word for a bit.

When -source, -target and/or --release imply compiling for versions of 
the platform
preceding JDK 9, there is no concept of modules, and so there is no 
concept of
"module mode". Thus, there is only "classpath mode" when compiling for 
these
older versions of the platform (JDK 8 and before).

But you can also have "classpath mode" when compiling for JDK 9 (and 
later).
For the most part, the same  commands that can be used to compile code 
in JDK 8
should also work in JDK 9.(Obviously, there are some differences, 
related to the use
of advanced options like -bootclasspath, or to access internal API.)  
But conceptually,
a javac invocation just using -classpath, -sourcepath and -d, and not 
using any
module declarations (in either module-info.java or module-info.class) 
should work
the same on JDK 9 as on JDK 8. Put another way, an average-Joe developer 
wanting
to compile a  simple jar file can use JDK 9 just like he/she previously 
used JDK 8.

That is the sense in which I use the term "legacy mode" as an alias for
"classpath mode". Although I don't particularly like the term "legacy mode",
it does carry strong connotations of "the same as before".

Now, when the developer starts working with modules, and introducing
their own module declarations, that's when javac switches to "module mode"
and the rules that I described previously will apply.


>
> IOW, the fact that the command line without module-info.java succeeds
> is not owed to using a different compilation mode, but to compiling
> everything in the same unnamed module, right?

That would be another way of looking at it, and a reasonable way for anyone
already knowledgeable about the terminology of the module system.
Compiling code with --release 8, or compiling code without a module 
declaration
with --release 9 should be effectively equivalent.  It's just that you 
can't talk about
the unnamed module in the context of --release 8 and earlier.

>
>
> Does JEP 261 have a process for correcting the text after it has been 
> delivered?
>
> Which space should I watch for updates?
> - http://openjdk.java.net/jeps/261
> - https://bugs.openjdk.java.net/browse/JDK-8061972
> - any other?

I'll leave it to others to respond on this point, but yes, it does seem 
we need an update.

-- Jon

>
> regards,
> Stephan
>
> On 07.11.2017 23:03, Jonathan Gibbons wrote:
>>
>>
>> On 11/07/2017 12:56 PM, Stephan Herrmann wrote:
>>> On 07.11.2017 21:43, Alan Bateman wrote:
>>>> On 07/11/2017 18:56, Stephan Herrmann wrote:
>>>>> I recently noticed that compilers start to ignore -classpath as soon
>>>>> as module-info (.java or .class) is found during the compile.
>>>>> (Incidentally, javac and Eclipse compiler agree in this).
>>>>>
>>>>> Using a trivial test class this works:
>>>>> $ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java
>>>>>
>>>>> This doesn't (cannot resolve any types from junit4.jar):
>>>>> $ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java 
>>>>> src/module-info.java
>>>> The module you are compiling doesn't read the unnamed module. You 
>>>> can't write "requires $CLASSPATH" for example.
>>>>
>>>> If you add `--add-reads <module>=ALL-UNNAMED` to the command line 
>>>> then it should compile.
>>>>
>>>> -Alan
>>>
>>> Thanks, Alan, that would work.
>>>
>>> But that is not what I meant when referring to JEP 261.
>>>
>>> In JEP 261 I see (under "Single-module mode"):
>>> "It is possible to put arbitrary classes and JAR files on the class 
>>> path in this mode,
>>>  but that is not recommended since it amounts to treating those 
>>> classes and JAR files as
>>>  part of the module being compiled."
>>>
>>> Doesn't this say, my above command line treats junit4.jar as part of 
>>> the current module,
>>> *not* as an unnamed module?
>>>
>>> Is everything referenced via -classpath definitely treated as an 
>>> unnamed module?
>>> Independent of single-/multi-module modes?
>>>
>>> Stephan
>>
>> Stephan,
>>
>> I think you have identified some outdated text that needs to be fixed.
>>
>> The text was correct at one point, when the distinction between 
>> "single module mode"
>> and "multi-module mode" was a bigger deal.
>>
>> These days, the primary distinction is between "classpath (legacy) 
>> mode" (no modules being compiled)
>> and "module mode" (one or more modules being compiled.)
>>
>> Here's how javac treats these modes:
>>
>> In classpath (legacy) mode ...
>>
>> * the sourcepath, classpath and output directory behave as 
>> previously, such as in JDK 8.
>>
>> In module mode ...
>>
>> * all classes on the classpath (-classpath) are treated as part of 
>> the unnamed module.
>>
>> * if you are just compiling a single module, you may either put the 
>> source for that module
>> on the source path (-sourcepath) or in a directory on the module 
>> source path (--module-source-path).
>>
>> * if you are compiling multiple modules, they must be in separate 
>> directories on the
>> module source path (--module-source-path).
>>
>> * javac will implicitly look for previously compiled classes in the 
>> output directory (-d).
>> (This is in contrast to the usage in classpath/legacy mode, where it 
>> has always been common practice
>> to explicitly put the output directory on the classpath as well.)
>>
>> -- Jon
>>
>>
>


From register.jigsaw at brychcy.de  Wed Nov  8 20:03:16 2017
From: register.jigsaw at brychcy.de (Till Brychcy)
Date: Wed, 8 Nov 2017 21:03:16 +0100
Subject: How to compile test code in a modular project?
Message-ID: <59E9A53C-8B2B-4336-94FE-3644855AAE3A@brychcy.de>


A common source structure (e.g. used by maven and gradle) is that tests are in separate source directory with separate output directory
and are in the same packages as the code that is being tested, so the tests can access code elements that have package visibility.

Also, test dependencies like junit should not be referenced in the module-info.java, so ?main" code cannot accidentally access them.

The question is, how to compile the tests with javac (version 9.0.1)?

The following example is more detailed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=520713  but I think my question should
be clear without the details.

Compiling the main code is no problem (module-info.java defines module m):
    javac -d target/classes src/main/java/module-info.java src/main/java/p1/*.java

I think the following would be correct according to http://openjdk.java.net/jeps/261
   javac -d target/test-classes -cp target/classes --module-path junit-4.8.2.jar --add-reads m=junit src/test/java/p1/P1Test.java
but there is a warning: "warning: module name in --add-reads option not found: m" and then there are errors because junit is not found.

The following versions don't work:
   javac --module=m -d target/test-classes -cp target/classes --module-path junit-4.8.2.jar --add-reads m=junit src/test/java/p1/P1Test.java
   javac --module=m -d target/test-classes --module-path target/classes:junit-4.8.2.jar --add-reads m=junit src/test/java/p1/P1Test.java
Both give: "error: module source path must be specified if -m option is used"

I tried to use --module-source-path, just to have one:
 javac --module=m -d target/test-classes --module-path target/classes:junit-4.8.2.jar --module-source-path src/main/java --add-reads m=junit src/test/java/p1/P1Test.java
But this gives "error: module m not found in module source path" (I guess the problem is that there  is no "m" subdirectory in src/main/java)

I *can* compile the test code as follows:
   javac -d target/test-classes -cp target/classes --module-path junit-4.8.2.jar --add-modules junit src/test/java/p1/P1Test.java
As I understand it, javac compiles this as part of the unnamed module, so I can e.g. use "import java.rmi.*;" in P1Test.java and no error is reported.
So this is not a "correct" solution.

Is compiling code test code (or any code to be used with --patch-module) as part of the module actually possible with javac?


From sormuras at gmail.com  Wed Nov  8 20:40:16 2017
From: sormuras at gmail.com (Christian Stein)
Date: Wed, 8 Nov 2017 21:40:16 +0100
Subject: How to compile test code in a modular project?
In-Reply-To: <59E9A53C-8B2B-4336-94FE-3644855AAE3A@brychcy.de>
References: <59E9A53C-8B2B-4336-94FE-3644855AAE3A@brychcy.de>
Message-ID: <CAJi8+g4FSsGKwUciiLXu_X5mDTLqS54RWZk3Fg73pCcDza3zFg@mail.gmail.com>

On Wed, Nov 8, 2017 at 9:03 PM, Till Brychcy <register.jigsaw at brychcy.de>
 wrote:

>
> [...]

Is compiling code test code (or any code to be used with --patch-module) as
> part of the module actually possible with javac?
>
>
Hi Till,

I compiled an example called "sawdust" that show-cases how you
can compile and run projects that organize main and test sources
in modules. It's available at https://github.com/micromata/sawdust
It is based on Java 9 and JUnit 5, but you may adopt the process
to JUnit 4 or older.

Basically "black box"[2] testing is the easy part. Your test sources can
be considered as application modules that happen to use your
modules along with JUnit/AssertJ/... modules. Here you can test
the module API or the exported types. No need to "--patch-module".

"White box" testing needs some more setup. I like the approach
pro[1] is taking here: first you (manually) merge the module
descriptors and then you patch the types declared in the "main"
source set into the source path of your "test" source set.

Hope that helps -- and only because it works for me, doesn't mean
it's the intended or recommended way compile and run tests
on the module path.

Cheers,
Christian

[1] pro https://github.com/forax/pro
[2] black box https://github.com/micromata/sawdust/tree/master/
modules/user.view/src/test/java/user.view
[3] white box https://github.com/micromata/sawdust/tree/master/
modules/sawdust.alpha/src

On Wed, Nov 8, 2017 at 9:03 PM, Till Brychcy <register.jigsaw at brychcy.de>
wrote:

>
> A common source structure (e.g. used by maven and gradle) is that tests
> are in separate source directory with separate output directory
> and are in the same packages as the code that is being tested, so the
> tests can access code elements that have package visibility.
>
> Also, test dependencies like junit should not be referenced in the
> module-info.java, so ?main" code cannot accidentally access them.
>
> The question is, how to compile the tests with javac (version 9.0.1)?
>
> The following example is more detailed in https://bugs.eclipse.org/bugs/
> show_bug.cgi?id=520713  but I think my question should
> be clear without the details.
>
> Compiling the main code is no problem (module-info.java defines module m):
>     javac -d target/classes src/main/java/module-info.java
> src/main/java/p1/*.java
>
> I think the following would be correct according to
> http://openjdk.java.net/jeps/261
>    javac -d target/test-classes -cp target/classes --module-path
> junit-4.8.2.jar --add-reads m=junit src/test/java/p1/P1Test.java
> but there is a warning: "warning: module name in --add-reads option not
> found: m" and then there are errors because junit is not found.
>
> The following versions don't work:
>    javac --module=m -d target/test-classes -cp target/classes
> --module-path junit-4.8.2.jar --add-reads m=junit
> src/test/java/p1/P1Test.java
>    javac --module=m -d target/test-classes --module-path
> target/classes:junit-4.8.2.jar --add-reads m=junit
> src/test/java/p1/P1Test.java
> Both give: "error: module source path must be specified if -m option is
> used"
>
> I tried to use --module-source-path, just to have one:
>  javac --module=m -d target/test-classes --module-path
> target/classes:junit-4.8.2.jar --module-source-path src/main/java
> --add-reads m=junit src/test/java/p1/P1Test.java
> But this gives "error: module m not found in module source path" (I guess
> the problem is that there  is no "m" subdirectory in src/main/java)
>
> I *can* compile the test code as follows:
>    javac -d target/test-classes -cp target/classes --module-path
> junit-4.8.2.jar --add-modules junit src/test/java/p1/P1Test.java
> As I understand it, javac compiles this as part of the unnamed module, so
> I can e.g. use "import java.rmi.*;" in P1Test.java and no error is reported.
> So this is not a "correct" solution.
>
> Is compiling code test code (or any code to be used with --patch-module)
> as part of the module actually possible with javac?
>
>

From me at md-5.net  Thu Nov  9 01:07:20 2017
From: me at md-5.net (Michael D)
Date: Thu, 9 Nov 2017 01:07:20 +0000
Subject: Regression in getImplementationVersion from Jigsaw
Message-ID: <0100015f9e512c37-24ed5417-2eeb-48e2-97f6-a0831c1a9a53-000000@email.amazonses.com>

Hi All,

Hope I'm in the right place.
The implementation of Jigsaw caused a regression in that
Package.getImplementationVersion is unusable if no other version
things are defined in the manifest.
This appears to be an unintentional regression caused by a missing null check.
I have prepared a patch and unit test for review here:
https://patch-diff.githubusercontent.com/raw/md-5/OpenJDK/pull/3.patch
Note that only testImplVersion fails, but I have included tests for
all the version elements for completeness.

NB: Not an OpenJDK dev so can't create webrev or bug report.

Thanks
Michael

From mandy.chung at oracle.com  Thu Nov  9 02:22:11 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 8 Nov 2017 18:22:11 -0800
Subject: Regression in getImplementationVersion from Jigsaw
In-Reply-To: <0100015f9e512c37-24ed5417-2eeb-48e2-97f6-a0831c1a9a53-000000@email.amazonses.com>
References: <0100015f9e512c37-24ed5417-2eeb-48e2-97f6-a0831c1a9a53-000000@email.amazonses.com>
Message-ID: <8b17fd83-ac7e-8e4b-aa4d-6b7d6ccb08ed@oracle.com>

Hi Michael,

It is indeed a bug and I file:
 ?? https://bugs.openjdk.java.net/browse/JDK-8190987

The patch looks good and I will sponsor this patch for you.

Thanks for the regression test.? It'd be good to wrap the long lines and 
I will clean that up before I push.

thanks
Mandy

On 11/8/17 5:07 PM, Michael D wrote:
> Hi All,
>
> Hope I'm in the right place.
> The implementation of Jigsaw caused a regression in that
> Package.getImplementationVersion is unusable if no other version
> things are defined in the manifest.
> This appears to be an unintentional regression caused by a missing null check.
> I have prepared a patch and unit test for review here:
> https://patch-diff.githubusercontent.com/raw/md-5/OpenJDK/pull/3.patch
> Note that only testImplVersion fails, but I have included tests for
> all the version elements for completeness.
>
> NB: Not an OpenJDK dev so can't create webrev or bug report.
>
> Thanks
> Michael


From me at md-5.net  Thu Nov  9 02:25:47 2017
From: me at md-5.net (Michael D)
Date: Thu, 9 Nov 2017 02:25:47 +0000
Subject: Regression in getImplementationVersion from Jigsaw
In-Reply-To: <8b17fd83-ac7e-8e4b-aa4d-6b7d6ccb08ed@oracle.com>
References: <0100015f9e512c37-24ed5417-2eeb-48e2-97f6-a0831c1a9a53-000000@email.amazonses.com>
 <8b17fd83-ac7e-8e4b-aa4d-6b7d6ccb08ed@oracle.com>
Message-ID: <0100015f9e98fe1f-e72c0d9a-d6e0-480d-9991-0fc5c6077343-000000@email.amazonses.com>

Hi Mandy,

No problem. Wasn't sure where the limit was on line lengths, so I will
watch and learn :)

Thanks
Michael

On 9 November 2017 at 13:22, mandy chung <mandy.chung at oracle.com> wrote:
> Hi Michael,
>
> It is indeed a bug and I file:
>    https://bugs.openjdk.java.net/browse/JDK-8190987
>
> The patch looks good and I will sponsor this patch for you.
>
> Thanks for the regression test.  It'd be good to wrap the long lines and I
> will clean that up before I push.
>
> thanks
> Mandy
>
> On 11/8/17 5:07 PM, Michael D wrote:
>>
>> Hi All,
>>
>> Hope I'm in the right place.
>> The implementation of Jigsaw caused a regression in that
>> Package.getImplementationVersion is unusable if no other version
>> things are defined in the manifest.
>> This appears to be an unintentional regression caused by a missing null
>> check.
>> I have prepared a patch and unit test for review here:
>> https://patch-diff.githubusercontent.com/raw/md-5/OpenJDK/pull/3.patch
>> Note that only testImplVersion fails, but I have included tests for
>> all the version elements for completeness.
>>
>> NB: Not an OpenJDK dev so can't create webrev or bug report.
>>
>> Thanks
>> Michael
>
>

From mandy.chung at oracle.com  Thu Nov  9 03:07:57 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 8 Nov 2017 19:07:57 -0800
Subject: Regression in getImplementationVersion from Jigsaw
In-Reply-To: <0100015f9e98fe26-773424a3-518c-46dc-be2d-174fca819550-000000@email.amazonses.com>
References: <0100015f9e512c37-24ed5417-2eeb-48e2-97f6-a0831c1a9a53-000000@email.amazonses.com>
 <8b17fd83-ac7e-8e4b-aa4d-6b7d6ccb08ed@oracle.com>
 <0100015f9e98fe26-773424a3-518c-46dc-be2d-174fca819550-000000@email.amazonses.com>
Message-ID: <42c76bec-6591-0a07-c339-ee39d696753a@oracle.com>

FYI. 
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8190987/webrev.00/index.html

While the line width is not consistent across all source files, we try 
to keep 80-column width as the coding convention.

Mandy

On 11/8/17 6:25 PM, Michael D wrote:
> Hi Mandy,
>
> No problem. Wasn't sure where the limit was on line lengths, so I will
> watch and learn :)
>
> Thanks
> Michael
>
> On 9 November 2017 at 13:22, mandy chung <mandy.chung at oracle.com> wrote:
>> Hi Michael,
>>
>> It is indeed a bug and I file:
>>     https://bugs.openjdk.java.net/browse/JDK-8190987
>>
>> The patch looks good and I will sponsor this patch for you.
>>
>> Thanks for the regression test.  It'd be good to wrap the long lines and I
>> will clean that up before I push.
>>
>> thanks
>> Mandy
>>
>> On 11/8/17 5:07 PM, Michael D wrote:
>>> Hi All,
>>>
>>> Hope I'm in the right place.
>>> The implementation of Jigsaw caused a regression in that
>>> Package.getImplementationVersion is unusable if no other version
>>> things are defined in the manifest.
>>> This appears to be an unintentional regression caused by a missing null
>>> check.
>>> I have prepared a patch and unit test for review here:
>>> https://patch-diff.githubusercontent.com/raw/md-5/OpenJDK/pull/3.patch
>>> Note that only testImplVersion fails, but I have included tests for
>>> all the version elements for completeness.
>>>
>>> NB: Not an OpenJDK dev so can't create webrev or bug report.
>>>
>>> Thanks
>>> Michael
>>


From me at md-5.net  Thu Nov  9 03:19:07 2017
From: me at md-5.net (Michael D)
Date: Thu, 9 Nov 2017 03:19:07 +0000
Subject: Regression in getImplementationVersion from Jigsaw
In-Reply-To: <42c76bec-6591-0a07-c339-ee39d696753a@oracle.com>
References: <0100015f9e512c37-24ed5417-2eeb-48e2-97f6-a0831c1a9a53-000000@email.amazonses.com>
 <8b17fd83-ac7e-8e4b-aa4d-6b7d6ccb08ed@oracle.com>
 <0100015f9e98fe26-773424a3-518c-46dc-be2d-174fca819550-000000@email.amazonses.com>
 <42c76bec-6591-0a07-c339-ee39d696753a@oracle.com>
Message-ID: <0100015f9ec9cf5e-729c6c58-78c2-4d79-bbae-d18bb238b566-000000@email.amazonses.com>

Noted,

Thanks again
Michael

On Thu, 9 Nov 2017 at 14:08, mandy chung <mandy.chung at oracle.com> wrote:

> FYI.
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8190987/webrev.00/index.html
>
> While the line width is not consistent across all source files, we try to
> keep 80-column width as the coding convention.
>
>
> Mandy
>
>
> On 11/8/17 6:25 PM, Michael D wrote:
>
> Hi Mandy,
>
> No problem. Wasn't sure where the limit was on line lengths, so I will
> watch and learn :)
>
> Thanks
> Michael
>
> On 9 November 2017 at 13:22, mandy chung <mandy.chung at oracle.com> <mandy.chung at oracle.com> wrote:
>
> Hi Michael,
>
> It is indeed a bug and I file:
>    https://bugs.openjdk.java.net/browse/JDK-8190987
>
> The patch looks good and I will sponsor this patch for you.
>
> Thanks for the regression test.  It'd be good to wrap the long lines and I
> will clean that up before I push.
>
> thanks
> Mandy
>
> On 11/8/17 5:07 PM, Michael D wrote:
>
> Hi All,
>
> Hope I'm in the right place.
> The implementation of Jigsaw caused a regression in that
> Package.getImplementationVersion is unusable if no other version
> things are defined in the manifest.
> This appears to be an unintentional regression caused by a missing null
> check.
> I have prepared a patch and unit test for review here:https://patch-diff.githubusercontent.com/raw/md-5/OpenJDK/pull/3.patch
> Note that only testImplVersion fails, but I have included tests for
> all the version elements for completeness.
>
> NB: Not an OpenJDK dev so can't create webrev or bug report.
>
> Thanks
> Michael
>
>

From Alan.Bateman at oracle.com  Thu Nov  9 08:29:41 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 Nov 2017 09:29:41 +0100
Subject: How to compile test code in a modular project?
In-Reply-To: <59E9A53C-8B2B-4336-94FE-3644855AAE3A@brychcy.de>
References: <59E9A53C-8B2B-4336-94FE-3644855AAE3A@brychcy.de>
Message-ID: <57908cb7-2509-b890-b4aa-e23444d5a307@oracle.com>

On 08/11/2017 21:03, Till Brychcy wrote:
> A common source structure (e.g. used by maven and gradle) is that tests are in separate source directory with separate output directory
> and are in the same packages as the code that is being tested, so the tests can access code elements that have package visibility.
>
> Also, test dependencies like junit should not be referenced in the module-info.java, so ?main" code cannot accidentally access them.
>
> The question is, how to compile the tests with javac (version 9.0.1)?
> :
>
> Is compiling code test code (or any code to be used with --patch-module) as part of the module actually possible with javac?
>
Yes, --patch-module is needed to compile the tests "as if" they are part 
of the module, e.g.

 ?? javac --module-path classes:junit.jar --patch-module m=src/test/java 
--add-reads m=junit -d test-classes \
 ?????? src/test/java/p1/P1Test.java

Are you using Maven? If so then the maven-compiler-plugin already does 
this for you when the project is a module.

-Alan


From register.jigsaw at brychcy.de  Thu Nov  9 21:05:03 2017
From: register.jigsaw at brychcy.de (Till Brychcy)
Date: Thu, 9 Nov 2017 22:05:03 +0100
Subject: How to compile test code in a modular project?
In-Reply-To: <57908cb7-2509-b890-b4aa-e23444d5a307@oracle.com>
References: <59E9A53C-8B2B-4336-94FE-3644855AAE3A@brychcy.de>
 <57908cb7-2509-b890-b4aa-e23444d5a307@oracle.com>
Message-ID: <2D95FA44-525A-449E-A573-176A26FB32E1@brychcy.de>

> Am 09.11.2017 um 09:29 schrieb Alan Bateman <Alan.Bateman at oracle.com>:
> 
> Yes, --patch-module is needed to compile the tests "as if" they are part of the module, e.g.
> 
>   javac --module-path classes:junit.jar --patch-module m=src/test/java --add-reads m=junit -d test-classes \
>       src/test/java/p1/P1Test.java
> 

Thanks a lot, Alan! 

The surprise for me was that --patch-module is used for source folders, too. I thought it was only for binaries.

But I noted I also have to add "--add-modules=junit" or the "--add-reads m=junit" will give an error that module junit cannot be found. 
So the command has to be:
   javac -d target/test-classes --patch-module m=src/test/java --module-path target/classes:junit-4.8.2.jar --add-modules=junit --add-reads m=junit src/test/java/p1/P1Test.java

I?m not sure if that is a bug or a feature.  BTW, I noted that "javac -help" doesn?t mention --patch-module and --add-reads at all (only --add-modules)


From jonathan.gibbons at oracle.com  Thu Nov  9 21:09:02 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 09 Nov 2017 13:09:02 -0800
Subject: How to compile test code in a modular project?
In-Reply-To: <2D95FA44-525A-449E-A573-176A26FB32E1@brychcy.de>
References: <59E9A53C-8B2B-4336-94FE-3644855AAE3A@brychcy.de>
 <57908cb7-2509-b890-b4aa-e23444d5a307@oracle.com>
 <2D95FA44-525A-449E-A573-176A26FB32E1@brychcy.de>
Message-ID: <5A04C3EE.3050006@oracle.com>



On 11/09/2017 01:05 PM, Till Brychcy wrote:
>> Am 09.11.2017 um 09:29 schrieb Alan Bateman <Alan.Bateman at oracle.com>:
>>
>> Yes, --patch-module is needed to compile the tests "as if" they are part of the module, e.g.
>>
>>    javac --module-path classes:junit.jar --patch-module m=src/test/java --add-reads m=junit -d test-classes \
>>        src/test/java/p1/P1Test.java
>>
> Thanks a lot, Alan!
>
> The surprise for me was that --patch-module is used for source folders, too. I thought it was only for binaries.
>
> But I noted I also have to add "--add-modules=junit" or the "--add-reads m=junit" will give an error that module junit cannot be found.
> So the command has to be:
>     javac -d target/test-classes --patch-module m=src/test/java --module-path target/classes:junit-4.8.2.jar --add-modules=junit --add-reads m=junit src/test/java/p1/P1Test.java
>
> I?m not sure if that is a bug or a feature.  BTW, I noted that "javac -help" doesn?t mention --patch-module and --add-reads at all (only --add-modules)
>

Use "javac -X" or "javac --help-extra" to see help on additional 
options, such as less common or more advanced options.

-- Jon

From sundararajan.athijegannathan at oracle.com  Mon Nov 13 08:02:05 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 13 Nov 2017 13:32:05 +0530
Subject: RFR 8177471: jlink should use the version from java.base.jmod to
 find modules
Message-ID: <5A09517D.6030900@oracle.com>

Please review.

Bug: https://bugs.openjdk.java.net/browse/JDK-8177471

Webrev: http://cr.openjdk.java.net/~sundar/8177471/webrev.00/index.html

Thanks to Mandy for initial (internal) round of review and suggesting me 
simplifications on my initial version of test.

Thanks,
-Sundar

From Alan.Bateman at oracle.com  Mon Nov 13 15:09:44 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 13 Nov 2017 15:09:44 +0000
Subject: RFR 8177471: jlink should use the version from java.base.jmod to
 find modules
In-Reply-To: <5A09517D.6030900@oracle.com>
References: <5A09517D.6030900@oracle.com>
Message-ID: <4e304577-d1a0-c59d-4630-a7443bed0722@oracle.com>

On 13/11/2017 08:02, Sundararajan Athijegannathan wrote:
> Please review.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177471
>
> Webrev: http://cr.openjdk.java.net/~sundar/8177471/webrev.00/index.html
>
> Thanks to Mandy for initial (internal) round of review and suggesting 
> me simplifications on my initial version of test.
The update to newModuleFinder looks okay although at L450 then checking 
the major version is probably enough (re-creating the module finder when 
the versions aren't equal is okay too).

The changes to ImageHelper bring several questions on whether 
NoSuchElementException is possible. I think this is closer to what you 
want there:

 ??????? Runtime.Version v = cf.findModule("java.base")
 ??????????????? .map(ResolvedModule::reference)
 ??????????????? .map(ModuleReference::descriptor)
 ??????????????? .flatMap(ModuleDescriptor::version)
 ??????????????? .map(ModuleDescriptor.Version::toString)
 ??????????????? .map(Runtime.Version::parse)
 ??????????????? .orElse(Runtime.version());

-Alan.

From gunnar at hibernate.org  Mon Nov 13 16:03:22 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 13 Nov 2017 17:03:22 +0100
Subject: Patterns for libraries to access private state of user modules
Message-ID: <CADGJaX_js2YLBEyb7Bg+MwjF1p_kQZgUFp-9+mVT=BnwOfH-=w@mail.gmail.com>

Hi,

Libraries such as Hibernate often need to access private state of classes
from other modules (e.g. when using field access for JPA entities).

Assuming that such library and the user's JAR are both provided as JPMS
(named) modules, it had been my understanding so far [1], that the library
should allow to pass in a MethodHandles.Lookup instance which has private
access to the user's classes. This could be passed via a parameter during
the library bootstrap, retrieved via a callback or similar.

But discussing this with Alex Buckley at Devoxx Belgium last week, he
suggested that this may not be the best level of abstraction. User code
should never have to deal with low-level APIs such as Lookup, instead some
sort of utility method should be provided by the library. It's not quite
clear to me how this would look like, though. I can't see how a utility
method in my library could obtain the Lookup, as MethodHandles#lookup() is
caller-sensitive and must be invoked from within the module that wishes to
grant private access to the library.

So I'm curious whether there are any recommendations around this. Having
some kind of documented API best practices for library authors in the same
situation as me would be very helpful.

I could also help to write that up, provided there's an agreed on pattern
to do this.

Thanks,

--Gunnar

[1]
http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/#can-you-handle-the-var

From sundararajan.athijegannathan at oracle.com  Mon Nov 13 16:36:31 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 13 Nov 2017 22:06:31 +0530
Subject: RFR 8177471: jlink should use the version from java.base.jmod
 to find modules
In-Reply-To: <4e304577-d1a0-c59d-4630-a7443bed0722@oracle.com>
References: <5A09517D.6030900@oracle.com>
 <4e304577-d1a0-c59d-4630-a7443bed0722@oracle.com>
Message-ID: <5A09CA0F.2010502@oracle.com>

Thanks for the review. Updated as per suggestions:

http://cr.openjdk.java.net/~sundar/8177471/webrev.01/index.html

-Sundar

On 13/11/17, 8:39 PM, Alan Bateman wrote:
> On 13/11/2017 08:02, Sundararajan Athijegannathan wrote:
>> Please review.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177471
>>
>> Webrev: http://cr.openjdk.java.net/~sundar/8177471/webrev.00/index.html
>>
>> Thanks to Mandy for initial (internal) round of review and suggesting 
>> me simplifications on my initial version of test.
> The update to newModuleFinder looks okay although at L450 then 
> checking the major version is probably enough (re-creating the module 
> finder when the versions aren't equal is okay too).
>
> The changes to ImageHelper bring several questions on whether 
> NoSuchElementException is possible. I think this is closer to what you 
> want there:
>
>         Runtime.Version v = cf.findModule("java.base")
>                 .map(ResolvedModule::reference)
>                 .map(ModuleReference::descriptor)
>                 .flatMap(ModuleDescriptor::version)
>                 .map(ModuleDescriptor.Version::toString)
>                 .map(Runtime.Version::parse)
>                 .orElse(Runtime.version());
>
> -Alan.

From david.lloyd at redhat.com  Mon Nov 13 16:54:06 2017
From: david.lloyd at redhat.com (David Lloyd)
Date: Mon, 13 Nov 2017 10:54:06 -0600
Subject: Patterns for libraries to access private state of user modules
In-Reply-To: <CADGJaX_js2YLBEyb7Bg+MwjF1p_kQZgUFp-9+mVT=BnwOfH-=w@mail.gmail.com>
References: <CADGJaX_js2YLBEyb7Bg+MwjF1p_kQZgUFp-9+mVT=BnwOfH-=w@mail.gmail.com>
Message-ID: <CANghgrSDxjcMJ_T=5sLisFAELu7B-Y_+AKoFwsBTHywXr5zgGw@mail.gmail.com>

On Mon, Nov 13, 2017 at 10:03 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> Libraries such as Hibernate often need to access private state of classes
> from other modules (e.g. when using field access for JPA entities).
>
> [...] I can't see how a utility
> method in my library could obtain the Lookup, as MethodHandles#lookup() is
> caller-sensitive and must be invoked from within the module that wishes to
> grant private access to the library.

My understanding is that you should be using
MethodHandlers.privateLookupIn(userClazz, lookup()); and that the user
module should be "open" to you (i.e. they have to opt in to granting
reflection access).  Part of this was tied up in the discussion around
the need for standardized module names for spec modules, so a user can
choose the right module name:

  opens com.mycompany.dao to java.spec.jpa;

Then you only need a Lookup from the "java.spec.jpa" module to create
the private lookup in the user class.

-- 
- DML

From Alan.Bateman at oracle.com  Mon Nov 13 18:37:57 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 13 Nov 2017 18:37:57 +0000
Subject: RFR 8177471: jlink should use the version from java.base.jmod to
 find modules
In-Reply-To: <5A09CA0F.2010502@oracle.com>
References: <5A09517D.6030900@oracle.com>
 <4e304577-d1a0-c59d-4630-a7443bed0722@oracle.com>
 <5A09CA0F.2010502@oracle.com>
Message-ID: <28d60640-81c7-c487-d041-aecd58faf183@oracle.com>

On 13/11/2017 16:36, Sundararajan Athijegannathan wrote:
> Thanks for the review. Updated as per suggestions:
>
> http://cr.openjdk.java.net/~sundar/8177471/webrev.01/index.html
I think this looks fine.

-Alan

From Alan.Bateman at oracle.com  Mon Nov 13 19:18:00 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 13 Nov 2017 19:18:00 +0000
Subject: Patterns for libraries to access private state of user modules
In-Reply-To: <CANghgrSDxjcMJ_T=5sLisFAELu7B-Y_+AKoFwsBTHywXr5zgGw@mail.gmail.com>
References: <CADGJaX_js2YLBEyb7Bg+MwjF1p_kQZgUFp-9+mVT=BnwOfH-=w@mail.gmail.com>
 <CANghgrSDxjcMJ_T=5sLisFAELu7B-Y_+AKoFwsBTHywXr5zgGw@mail.gmail.com>
Message-ID: <e5b4fb17-054f-4430-ecb6-25ab447ee0c7@oracle.com>

On 13/11/2017 16:54, David Lloyd wrote:
> :
> My understanding is that you should be using
> MethodHandlers.privateLookupIn(userClazz, lookup()); and that the user
> module should be "open" to you (i.e. they have to opt in to granting
> reflection access).  Part of this was tied up in the discussion around
> the need for standardized module names for spec modules, so a user can
> choose the right module name:
>
>    opens com.mycompany.dao to java.spec.jpa;
>
> Then you only need a Lookup from the "java.spec.jpa" module to create
> the private lookup in the user class.
>
Yes, this is one approach. The application module will require the JPA 
module and at the same time open the packages with classes that have 
annotations on private members to the JPA module. If JPA is pluggable 
(which I think it is) then the code doing the deep reflection may be in 
an JPA implementation module, in which case the JPA API module may have 
to open the packages to the JPA implementation module. JAXB is one 
example doing this already and it would be good to exercise it with 
other libraries to ensure that it is feasible.

The other approach is to have the application module provide the Lookup 
as a capability. For some libraries, Guice for example, there is 
explicit initialization which could be the place to provide the Lookup 
object. If you there is no explicit initialization then coercion may be 
an option, maybe at build time or run-time. Coercion is of course much 
easier if there is an app server or container using module layers as it 
can open any package in any module in the layer to other modules.

-Alan

From mandy.chung at oracle.com  Tue Nov 14 03:00:22 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 13 Nov 2017 21:00:22 -0600
Subject: RFR 8177471: jlink should use the version from java.base.jmod to
 find modules
In-Reply-To: <5A09517D.6030900@oracle.com>
References: <5A09517D.6030900@oracle.com>
Message-ID: <eb27cfb4-5ef1-b6bf-5015-72124d2f6d29@oracle.com>

Looks good.? Thanks for fixing this.

Mandy

On 11/13/17 2:02 AM, Sundararajan Athijegannathan wrote:
> Please review.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177471
>
> Webrev: http://cr.openjdk.java.net/~sundar/8177471/webrev.00/index.html
>
> Thanks to Mandy for initial (internal) round of review and suggesting 
> me simplifications on my initial version of test.
>
> Thanks,
> -Sundar


From jan.lahoda at oracle.com  Tue Nov 14 13:17:44 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 14 Nov 2017 14:17:44 +0100
Subject: JDK-8191112: javac OutOfMemoryError caused by "-Xlint:exports" option
Message-ID: <5A0AECF8.2010603@oracle.com>

Hi,

Consider an automatic module "dep" with class "dep.Dep", and additional 
automatic modules ext1 and ext2.

When javac has these on the modulepath, and compiles a module like this:
---
module mod {
     requires dep;
     exports api;
}

package api;

public class Api extends dep.Dep {}
---

-Xlint:exports can be used to report exported APIs that refer to types 
potentially inaccessible to the clients. In this case, the supertype of 
api.Api may be inaccessible unless the client has a dependency on "dep", 
so the lint will warn about that. But since the dep, ext1 and ext2 are 
automatic modules, each of the modules "requires transitive" the other 
automatic modules, and the check may go into an infinite loop.

Moreover, for code like this:
---
module mod {
requires transitive ext1;
exports api;
}
---

"dep.Dep" is accessible using requires transitive edges of the automatic 
modules, hence the warning/lint is not printed.

That does not seem quite right, an explicit "requires transitive dep" 
dependency would be better, otherwise the changes in the module path can 
lead to surprising behavior.

The suggested patch is to simply ignore the dependencies of automatic 
modules in the check - that should avoid the infinite loop and print the 
warning in the "requires transitive ext1" case.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191112
Webrev: http://cr.openjdk.java.net/~jlahoda/8191112/webrev.00/

What do you think?

Thanks,
     Jan


From gunnar at hibernate.org  Tue Nov 14 17:07:37 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 14 Nov 2017 18:07:37 +0100
Subject: Patterns for libraries to access private state of user modules
In-Reply-To: <e5b4fb17-054f-4430-ecb6-25ab447ee0c7@oracle.com>
References: <CADGJaX_js2YLBEyb7Bg+MwjF1p_kQZgUFp-9+mVT=BnwOfH-=w@mail.gmail.com>
 <CANghgrSDxjcMJ_T=5sLisFAELu7B-Y_+AKoFwsBTHywXr5zgGw@mail.gmail.com>
 <e5b4fb17-054f-4430-ecb6-25ab447ee0c7@oracle.com>
Message-ID: <CADGJaX_U_HGO=ON1hc4YX=qedi6MeA4qsMWqhYuZZK4jyAHc_w@mail.gmail.com>

2017-11-13 20:18 GMT+01:00 Alan Bateman <Alan.Bateman at oracle.com>:

> On 13/11/2017 16:54, David Lloyd wrote:
>
>> :
>> My understanding is that you should be using
>> MethodHandlers.privateLookupIn(userClazz, lookup()); and that the user
>> module should be "open" to you (i.e. they have to opt in to granting
>> reflection access).  Part of this was tied up in the discussion around
>> the need for standardized module names for spec modules, so a user can
>> choose the right module name:
>>
>>    opens com.mycompany.dao to java.spec.jpa;
>>
>> Then you only need a Lookup from the "java.spec.jpa" module to create
>> the private lookup in the user class.
>>
>> Yes, this is one approach. The application module will require the JPA
> module and at the same time open the packages with classes that have
> annotations on private members to the JPA module. If JPA is pluggable
> (which I think it is) then the code doing the deep reflection may be in an
> JPA implementation module, in which case the JPA API module may have to
> open the packages to the JPA implementation module.


How would that look like like exactly? I.e. how could the JPA API module
"pass on" the open packages of the user's module to the JPA implementation
module?

I can see how it'd work if the user's module would be an entirely open
module. But it seems desirable to limit it to open up only specific
packages to specific modules (the JPA provider). The user could open to a
specific implementation module of course, but that'd come at the cost of
reduced portability.

JAXB is one example doing this already and it would be good to exercise it
> with other libraries to ensure that it is feasible.
>

Is this happening in the JAXB reference implementation? Would you perhaps
have any pointers to specifics so I could take a look?

>
> The other approach is to have the application module provide the Lookup as
> a capability. For some libraries, Guice for example, there is explicit
> initialization which could be the place to provide the Lookup object.


Yes, what I like about it is that it makes the need for private access more
apparent to the user, if e.g. the library bootstrap is designed in a way
that a Lookup object is mandatory (as opposed to the requirement for
opening up the user's module/packages, which essentially can only be
documented or things will fail at runtime). Although in reality it'd likely
have to be multiple Lookup objects, one for each module of the user
containing entities or similar. It'll be interesting how to collect those
Lookups so they can be passed to the library without making them available
to other modules, too.

But in respect to my initial question you seem to suggest indeed that the
user would have to pass a literal Lookup object which they'd have obtained
themselves. So indeed the user code would have to deal with the specifics
of Lookup objects.


> If you there is no explicit initialization then coercion may be an option,
> maybe at build time or run-time. Coercion is of course much easier if there
> is an app server or container using module layers as it can open any
> package in any module in the layer to other modules.


Right, I think containers have different ways for making this work, be it
via modification of module descriptors, injection of some helper code into
the user's module etc. My original question here was primarily focused on
usage under plain SE and envisioned patterns there.

-Alan
>

From Alan.Bateman at oracle.com  Tue Nov 14 18:29:57 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Nov 2017 18:29:57 +0000
Subject: Patterns for libraries to access private state of user modules
In-Reply-To: <CADGJaX_U_HGO=ON1hc4YX=qedi6MeA4qsMWqhYuZZK4jyAHc_w@mail.gmail.com>
References: <CADGJaX_js2YLBEyb7Bg+MwjF1p_kQZgUFp-9+mVT=BnwOfH-=w@mail.gmail.com>
 <CANghgrSDxjcMJ_T=5sLisFAELu7B-Y_+AKoFwsBTHywXr5zgGw@mail.gmail.com>
 <e5b4fb17-054f-4430-ecb6-25ab447ee0c7@oracle.com>
 <CADGJaX_U_HGO=ON1hc4YX=qedi6MeA4qsMWqhYuZZK4jyAHc_w@mail.gmail.com>
Message-ID: <023ae270-7fc3-6835-5e00-ae7d477e12c6@oracle.com>

On 14/11/2017 17:07, Gunnar Morling wrote:
>
>
> :
>
>     JAXB is one example doing this already and it would be good to
>     exercise it with other libraries to ensure that it is feasible.
>
>
> Is this happening in the JAXB reference implementation? Would you 
> perhaps have any pointers to specifics so I could take a look?
Yes, in javax.xml.bind.ContextFinder where it uses its 
delegateAddOpensToImplModule method to open the packages to the 
implementation module.


>
> Yes, what I like about it is that it makes the need for private access 
> more apparent to the user, if e.g. the library bootstrap is designed 
> in a way that a Lookup object is mandatory (as opposed to the 
> requirement for opening up the user's module/packages, which 
> essentially can only be documented or things will fail at runtime). 
> Although in reality it'd likely have to be multiple Lookup objects, 
> one for each module of the user containing entities or similar. It'll 
> be interesting how to collect those Lookups so they can be passed to 
> the library without making them available to other modules, too.
If the library needs to reflect into several non-open modules then it 
would minimally need a Lookup with MODULE access for each one.

>
> But in respect to my initial question you seem to suggest indeed that 
> the user would have to pass a literal Lookup object which they'd have 
> obtained themselves. So indeed the user code would have to deal with 
> the specifics of Lookup objects.
Right, either explicitly or oerced by some means.

-Alan

From alex.buckley at oracle.com  Tue Nov 14 19:03:31 2017
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 14 Nov 2017 11:03:31 -0800
Subject: JDK-8191112: javac OutOfMemoryError caused by "-Xlint:exports"
 option
In-Reply-To: <5A0AECF8.2010603@oracle.com>
References: <5A0AECF8.2010603@oracle.com>
Message-ID: <5A0B3E03.1020006@oracle.com>

On 11/14/2017 5:17 AM, Jan Lahoda wrote:
> ---
> module mod {
> requires transitive ext1;
> exports api;
> }
> ---
>
> "dep.Dep" is accessible using requires transitive edges of the automatic
> modules, hence the warning/lint is not printed.
>
> That does not seem quite right, an explicit "requires transitive dep"
> dependency would be better, otherwise the changes in the module path can
> lead to surprising behavior.
>
> The suggested patch is to simply ignore the dependencies of automatic
> modules in the check - that should avoid the infinite loop and print the
> warning in the "requires transitive ext1" case.

Good idea to make -Xlint:exports be more sophisticated w.r.t. automatic 
modules ... but for the very last point, are you saying that a warning 
is given for "requires transitive ext1" because of "transitive" or 
because of "ext1"? That is, would a warning be printed for just 
"requires ext1" ? I think it should be; the "transitive" in "requires 
transitive ext1" is for the benefit of consumers of mod, which is not 
germane to mod's barely-visible consumption of dep via ext1's implicit 
"requires transitive dep1".

Alex

From jan.lahoda at oracle.com  Tue Nov 14 19:16:04 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 14 Nov 2017 20:16:04 +0100
Subject: JDK-8191112: javac OutOfMemoryError caused by "-Xlint:exports"
 option
In-Reply-To: <5A0B3E03.1020006@oracle.com>
References: <5A0AECF8.2010603@oracle.com> <5A0B3E03.1020006@oracle.com>
Message-ID: <5A0B40F4.9020602@oracle.com>

Hi Alex,

On 14.11.2017 20:03, Alex Buckley wrote:
> On 11/14/2017 5:17 AM, Jan Lahoda wrote:
>> ---
>> module mod {
>> requires transitive ext1;
>> exports api;
>> }
>> ---
>>
>> "dep.Dep" is accessible using requires transitive edges of the automatic
>> modules, hence the warning/lint is not printed.
>>
>> That does not seem quite right, an explicit "requires transitive dep"
>> dependency would be better, otherwise the changes in the module path can
>> lead to surprising behavior.
>>
>> The suggested patch is to simply ignore the dependencies of automatic
>> modules in the check - that should avoid the infinite loop and print the
>> warning in the "requires transitive ext1" case.
>
> Good idea to make -Xlint:exports be more sophisticated w.r.t. automatic
> modules ... but for the very last point, are you saying that a warning
> is given for "requires transitive ext1" because of "transitive" or
> because of "ext1"? That is, would a warning be printed for just
> "requires ext1" ? I think it should be; the "transitive" in "requires
> transitive ext1" is for the benefit of consumers of mod, which is not
> germane to mod's barely-visible consumption of dep via ext1's implicit
> "requires transitive dep1".

(For completeness, there are other checks that inspect dependencies on 
automatic modules, but this one is not specific to automatic modules, it 
warns about using possibly inaccessible types in exported API.)

With the proposed patch, the warning would be printed for all "requires 
transitive ext1", "requires ext1" and "requires dep", but not for 
"requires transitive dep", as in the last case depending on "mod" will 
make exported types from dep available to the client (which may be also 
true for "requires transitive ext1", but that depends on how the module 
path is constructed). If "ext1" would be an explicit module, which would 
have "requires transitive dep", then the warning would not be printed 
for "requires transitive ext1". If ext1 would contain only "requires 
dep", then the warning would be printed.

Jan

>
> Alex

From alex.buckley at oracle.com  Tue Nov 14 19:36:52 2017
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 14 Nov 2017 11:36:52 -0800
Subject: JDK-8191112: javac OutOfMemoryError caused by "-Xlint:exports"
 option
In-Reply-To: <5A0B40F4.9020602@oracle.com>
References: <5A0AECF8.2010603@oracle.com> <5A0B3E03.1020006@oracle.com>
 <5A0B40F4.9020602@oracle.com>
Message-ID: <5A0B45D4.5060602@oracle.com>

On 11/14/2017 11:16 AM, Jan Lahoda wrote:
> With the proposed patch, the warning would be printed for all "requires
> transitive ext1", "requires ext1" and "requires dep", but not for
> "requires transitive dep", as in the last case depending on "mod" will
> make exported types from dep available to the client ...

 > If "ext1" would be an explicit module, which would
> have "requires transitive dep", then the warning would not be printed
> for "requires transitive ext1".

 > If ext1 would contain only "requires
> dep", then the warning would be printed.

All sounds good!

Alex

From tom at trellis.ch  Thu Nov 16 23:03:37 2017
From: tom at trellis.ch (Thomas Brand)
Date: Fri, 17 Nov 2017 00:03:37 +0100
Subject: Using legacy jar files with jlink
Message-ID: <d631d0aafc54db061b82dfe5bd143048.squirrel@ips73.ips.ch>

Hi List,

this is my first post here, I hope this is the right place to ask a
question about how to use jlink.

For a given scenario with modules a and b, a using methods of b, following
instructions I managed to create a runnable image that can be called (from
inside exploded image) like

$ ./bin/java a.A
A.main() called
B() called
string from B:test()

this works nicely, also both modules are shown with
$ ./bin/java --list-modules
a
b
java.base at 10-internal

My question is if it's possible to create that image if module b would be
a legacy jar with just the .class files in it. I understand it's possible
to auto-generate the module-info.java for this legacy b.jar.

I was thinking to be smart and just compile the generated module-info.java
for b.jar and then put it to the legacy b.jar or put the module-info.class
to the classpath in order to make it modular and then use for the jlink
step.
However that doesn't work:

$JAVAC -d compile_out src/modb/module-info.java
src/modb/module-info.java:2: error: package is empty or does not exist: b
    exports b;
            ^
1 error

How can a legacy jar file without access to source files be used as a
module, is it possible at all? The idea is to use legacy jar files in
conjunction with jlink to be used in self-contained runtime images.

Thanks for suggestions,
best regards
Thomas Brand




From mark.reinhold at oracle.com  Thu Nov 16 23:35:45 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 16 Nov 2017 15:35:45 -0800
Subject: Using legacy jar files with jlink
In-Reply-To: <d631d0aafc54db061b82dfe5bd143048.squirrel@ips73.ips.ch>
References: <d631d0aafc54db061b82dfe5bd143048.squirrel@ips73.ips.ch>
Message-ID: <20171116153545.863462361@eggemoggin.niobe.net>

2017/11/16 15:03:37 -0800, Thomas Brand <tom at trellis.ch>:
> this is my first post here, I hope this is the right place to ask a
> question about how to use jlink.

Yes, it is!

> For a given scenario with modules a and b, a using methods of b, following
> instructions I managed to create a runnable image that can be called (from
> inside exploded image) like
> 
> $ ./bin/java a.A
> A.main() called
> B() called
> string from B:test()
> 
> this works nicely, also both modules are shown with
> $ ./bin/java --list-modules
> a
> b
> java.base at 10-internal
> 
> My question is if it's possible to create that image if module b would be
> a legacy jar with just the .class files in it.

No.  There's no place in the image to store arbitrary JAR files, and
even if there were there'd be no way to guarantee that all the other
JAR files required by those JAR files are present, since they're just
JAR files rather than modules.  An image built by jlink is intended to
be complete, consistent, and runnable as-is rather than something that
might need additional JAR files just in order to launch.

>                                                I understand it's possible
> to auto-generate the module-info.java for this legacy b.jar.
> 
> I was thinking to be smart and just compile the generated module-info.java
> for b.jar and then put it to the legacy b.jar or put the module-info.class
> to the classpath in order to make it modular and then use for the jlink
> step.
> However that doesn't work:
> 
> $JAVAC -d compile_out src/modb/module-info.java
> src/modb/module-info.java:2: error: package is empty or does not exist: b
>     exports b;
>             ^
> 1 error

To make this work, copy the content of b.jar into compile_out before you
run javac so that the compiler can detect that the package is not empty.

> How can a legacy jar file without access to source files be used as a
> module, is it possible at all? The idea is to use legacy jar files in
> conjunction with jlink to be used in self-contained runtime images.

It's possible, as above, but it can fail in many ways.  If the legacy
JAR files contain conflicting packages then the module system won't be
able to load them.  Your generated module-info.java files could have
missing dependences, especially if any of the legacy code uses
reflection.

It's really best to modularize an existing component properly, at the
source.  If you can't do that, for whatever reason, then it's generally
safer to leave legacy JAR files on the class path.  You can still use
jlink to generate a custom image containing just the modules that you
need; you'll just have to run that image with a non-empty class path.

- Mark

From tom at trellis.ch  Fri Nov 17 00:21:59 2017
From: tom at trellis.ch (Thomas Brand)
Date: Fri, 17 Nov 2017 01:21:59 +0100
Subject: Using legacy jar files with jlink
In-Reply-To: <20171116153545.863462361@eggemoggin.niobe.net>
References: <d631d0aafc54db061b82dfe5bd143048.squirrel@ips73.ips.ch>
 <20171116153545.863462361@eggemoggin.niobe.net>
Message-ID: <aaeebdd9c4afaa29fba59283def42da0.squirrel@ips73.ips.ch>


Thanks for the quick answer!

On Fri, November 17, 2017 00:35, mark.reinhold at oracle.com wrote:
> 2017/11/16 15:03:37 -0800, Thomas Brand <tom at trellis.ch>:
>
>> this is my first post here, I hope this is the right place to ask a
>> question about how to use jlink.
>
> Yes, it is!
>
>
>> For a given scenario with modules a and b, a using methods of b,
>> following instructions I managed to create a runnable image that can be
>> called (from inside exploded image) like
>>
>> $ ./bin/java a.A
>> A.main() called
>> B() called
>> string from B:test()
>>
>> this works nicely, also both modules are shown with $ ./bin/java
>> --list-modules
>> abjava.base at 10-internal
>>
>> My question is if it's possible to create that image if module b would
>> be a legacy jar with just the .class files in it.
>
> No.  There's no place in the image to store arbitrary JAR files, and
> even if there were there'd be no way to guarantee that all the other JAR
> files required by those JAR files are present, since they're just JAR
> files rather than modules.  An image built by jlink is intended to be
> complete, consistent, and runnable as-is rather than something that might
> need additional JAR files just in order to launch.
>
>> I understand it's possible
>> to auto-generate the module-info.java for this legacy b.jar.
>>
>> I was thinking to be smart and just compile the generated
>> module-info.java for b.jar and then put it to the legacy b.jar or put
>> the module-info.class to the classpath in order to make it modular and
>> then use for the jlink step. However that doesn't work:
>>
>>
>> $JAVAC -d compile_out src/modb/module-info.java
>> src/modb/module-info.java:2: error: package is empty or does not exist:
>> b exports b; ^
>> 1 error
>>
>
> To make this work, copy the content of b.jar into compile_out before you
> run javac so that the compiler can detect that the package is not empty.
>

That was the issue, it works now. I also tried using -cp to point to the
legacy jar but obviously it's different when putting the contents to
compile_out.

>> How can a legacy jar file without access to source files be used as a
>> module, is it possible at all? The idea is to use legacy jar files in
>> conjunction with jlink to be used in self-contained runtime images.
>
> It's possible, as above, but it can fail in many ways.  If the legacy
> JAR files contain conflicting packages then the module system won't be
> able to load them.  Your generated module-info.java files could have
> missing dependences, especially if any of the legacy code uses reflection.
>

Good to know to keep an eye on that.

>
> It's really best to modularize an existing component properly, at the
> source.  If you can't do that, for whatever reason, then it's generally
> safer to leave legacy JAR files on the class path.  You can still use
> jlink to generate a custom image containing just the modules that you
> need; you'll just have to run that image with a non-empty class path.
>

That's another welcome hint to explore. It could well be interesting to
set a system library path for .so files that are packed to the image and
loaded at runtime by modules IIUC.

I read on https://jnbridge.com/blog/legacy-developers-guide-java-9:

-----%<-----
It?s also possible that you might not want to modularize a JAR file, or
that the JAR file belongs to someone else, so you can?t modularize it
yourself. In that case, you can still put the JAR file into the module
path; it becomes an automatic module. An automatic module is considered a
module even though it doesn?t have a module-info.class file.
...
This means that it?s possible to make an unmodularized classpath JAR file
into a module with no work at all: Legacy JAR files become modules
automatically, albeit without some of the information needed to determine
whether all required modules are really there, and to determine what is
missing.
----->%-----

So I tried
$ $JLINK --module-path jar:legacy_jar:$JAVA_HOME/jmods --add-modules a
--output distimage
Error: module-info.class not found for b module

When compiling module-info.java with the extracted b.jar as suggested
above, repacking b.jar with included module-info.class doesn't show an
error:

$ $JLINK --module-path jar:legacy_pimped_jar/:$JAVA_HOME/jmods
--add-modules a --output distimage

And the image works.

Thanks again for your valuable hints. I might come back again later.
Best regards
Thomas


> - Mark
>
>



From gunnar at hibernate.org  Sun Nov 19 13:44:13 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sun, 19 Nov 2017 14:44:13 +0100
Subject: Incorrect casing in output of jar --describe-module
Message-ID: <CADGJaX__1J2VZjk4XFLuVS5Kzk9JZzXjOVDT+YiH2W0OiZYAFg@mail.gmail.com>

Hi,

In a module-info.java descriptor I have this service definition:

    provides com.example.MyService with com.example.internal.MyServiceImpl

If I run jar --describe-module for the JAR containing this descriptor, the
service implementation name is printed all lower case:

com.example.MyModule
jar:file:///.../com.example.mymodule.jar/!module-info.class
...
provides com.example.MyService with com.example.internal.myserviceimpl

Note how the name of the service interface is given correctly.

I reckon this is an issue within the "jar" tool, as the entries in the
constant pool of the compiled module-info.class file look alright. I see
this with JDK 9.0.1 as well as 10 b32.

Is this a known issue?

Thanks,

--Gunnar

From Alan.Bateman at oracle.com  Sun Nov 19 15:17:38 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 19 Nov 2017 15:17:38 +0000
Subject: Incorrect casing in output of jar --describe-module
In-Reply-To: <CADGJaX__1J2VZjk4XFLuVS5Kzk9JZzXjOVDT+YiH2W0OiZYAFg@mail.gmail.com>
References: <CADGJaX__1J2VZjk4XFLuVS5Kzk9JZzXjOVDT+YiH2W0OiZYAFg@mail.gmail.com>
Message-ID: <e3673c47-20f3-3648-3cfd-7f486fcd4c7a@oracle.com>

On 19/11/2017 13:44, Gunnar Morling wrote:
> :
>
> I reckon this is an issue within the "jar" tool, as the entries in the
> constant pool of the compiled module-info.class file look alright. I see
> this with JDK 9.0.1 as well as 10 b32.
>
> Is this a known issue?
>
Yes, this in a bug in both the `jar` and `jmod` tools. I don't think it 
has been reported already so I'll create a bug for this now.

-Alan

From gunnar at hibernate.org  Mon Nov 20 21:04:46 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 20 Nov 2017 22:04:46 +0100
Subject: Resolution exception when service interface gets exposed via
 --add-exports
Message-ID: <CADGJaX9+TZZ36WBkGKgYAvmnh33nVprgj6HO-vitOwtaBwhvEA@mail.gmail.com>

Hi,

I'm having one module which defines a service interface but does not export
that interface's package. In another module I wish to create an
implementation of that service, which should be possible via --add-exports.

I can successfully compile that second module, but running it fails:

    Error occurred during initialization of boot layer
    j.l.m.ResolutionException: Module com.example.b does not read a module
that exports com.example.a

It seems as if the service binding happens before the --add-exports of the
java invocation is processed. Please see below for the steps to reproduce.

Is it a bug or am I trying to do something unsupported here?

Thanks,

--Gunnar

=====
mkdir -p sources/com.example.a/src/main/java/a/
mkdir -p sources/com.example.b/src/main/java/b/

cat > sources/com.example.a/src/main/java/a/Hello.java << EOF
package a;

public interface Hello {
    void world();
}
EOF

cat > sources/com.example.a/src/main/java/module-info.java << EOF
module com.example.a {}
EOF

cat > sources/com.example.b/src/main/java/b/HelloImpl.java << EOF
package b;

public class HelloImpl implements a.Hello {

    public void world() { System.out.println( "Hello"); }

    public static void main(String... args) {
        java.util.ServiceLoader.load( a.Hello.class ).findFirst().get()
            .world();
    }
}
EOF

cat > sources/com.example.b/src/main/java/module-info.java << EOF
module com.example.b {
    requires com.example.a;
    provides a.Hello with b.HelloImpl;
    uses a.Hello;
}
EOF

cd sources/com.example.a && javac -g -d ../../modules/com.example.a $(find
src/main/java -name "*.java") && cd ../..

cd sources/com.example.b && javac -g --add-exports
com.example.a/a=com.example.b --module-path ../../modules -d
../../modules/com.example.b $(find src/main/java -name "*.java") && cd ../..

java --add-exports com.example.a/a=com.example.b --module-path modules -m
com.example.b/b.HelloImpl

From Alan.Bateman at oracle.com  Mon Nov 20 21:24:16 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 20 Nov 2017 21:24:16 +0000
Subject: Resolution exception when service interface gets exposed via
 --add-exports
In-Reply-To: <CADGJaX9+TZZ36WBkGKgYAvmnh33nVprgj6HO-vitOwtaBwhvEA@mail.gmail.com>
References: <CADGJaX9+TZZ36WBkGKgYAvmnh33nVprgj6HO-vitOwtaBwhvEA@mail.gmail.com>
Message-ID: <5d0433e7-524a-9a66-bd8b-865a113b1098@oracle.com>

On 20/11/2017 21:04, Gunnar Morling wrote:
> Hi,
>
> I'm having one module which defines a service interface but does not export
> that interface's package. In another module I wish to create an
> implementation of that service, which should be possible via --add-exports.
>
> I can successfully compile that second module, but running it fails:
>
>      Error occurred during initialization of boot layer
>      j.l.m.ResolutionException: Module com.example.b does not read a module
> that exports com.example.a
>
> It seems as if the service binding happens before the --add-exports of the
> java invocation is processed. Please see below for the steps to reproduce.
>
> Is it a bug or am I trying to do something unsupported here?
>
At run-time, the --add-reads/--add-exports options are the equivalent of 
the module invoking addReads or addExports. So yes, they come into 
effect after resolution and service binding (and so after the resolution 
consistency check that detects that a module uses a service type in a 
package that isn't exported by anyone to the module).

-Alan

From gunnar at hibernate.org  Mon Nov 20 21:56:35 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 20 Nov 2017 22:56:35 +0100
Subject: Resolution exception when service interface gets exposed via
 --add-exports
In-Reply-To: <5d0433e7-524a-9a66-bd8b-865a113b1098@oracle.com>
References: <CADGJaX9+TZZ36WBkGKgYAvmnh33nVprgj6HO-vitOwtaBwhvEA@mail.gmail.com>
 <5d0433e7-524a-9a66-bd8b-865a113b1098@oracle.com>
Message-ID: <CADGJaX89_wo_fd1_m6T9-beWYE-FM-ufJGSfL-pnxHOQmKkY+A@mail.gmail.com>

I see, thanks for the clarification.

It's a pity, though, I hoped to employ that approach for providing a custom
jlink plug-in (implementation of jdk.tools.jlink.plugin.Plugin). So it
seems that's not possible until jdk.jlink exports j.t.j.plugin? Are there
any plans to do so some time soon?

Even if it was marked as experimental/incubating, being able to provide
custom jlink plug-ins would enable interesting use cases.

2017-11-20 22:24 GMT+01:00 Alan Bateman <Alan.Bateman at oracle.com>:

> On 20/11/2017 21:04, Gunnar Morling wrote:
>
>> Hi,
>>
>> I'm having one module which defines a service interface but does not
>> export
>> that interface's package. In another module I wish to create an
>> implementation of that service, which should be possible via
>> --add-exports.
>>
>> I can successfully compile that second module, but running it fails:
>>
>>      Error occurred during initialization of boot layer
>>      j.l.m.ResolutionException: Module com.example.b does not read a
>> module
>> that exports com.example.a
>>
>> It seems as if the service binding happens before the --add-exports of the
>> java invocation is processed. Please see below for the steps to reproduce.
>>
>> Is it a bug or am I trying to do something unsupported here?
>>
>> At run-time, the --add-reads/--add-exports options are the equivalent of
> the module invoking addReads or addExports. So yes, they come into effect
> after resolution and service binding (and so after the resolution
> consistency check that detects that a module uses a service type in a
> package that isn't exported by anyone to the module).
>
> -Alan
>

From forax at univ-mlv.fr  Mon Nov 20 23:33:43 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 21 Nov 2017 00:33:43 +0100 (CET)
Subject: Resolution exception when service interface gets exposed via
 --add-exports
In-Reply-To: <CADGJaX89_wo_fd1_m6T9-beWYE-FM-ufJGSfL-pnxHOQmKkY+A@mail.gmail.com>
References: <CADGJaX9+TZZ36WBkGKgYAvmnh33nVprgj6HO-vitOwtaBwhvEA@mail.gmail.com>
 <5d0433e7-524a-9a66-bd8b-865a113b1098@oracle.com>
 <CADGJaX89_wo_fd1_m6T9-beWYE-FM-ufJGSfL-pnxHOQmKkY+A@mail.gmail.com>
Message-ID: <222001594.519189.1511220823415.JavaMail.zimbra@u-pem.fr>

Hi Gunnar,
you can use --patch-module to add your plugin inside jdk.jlink if you want to experiment.

R?mi

----- Mail original -----
> De: "Gunnar Morling" <gunnar at hibernate.org>
> ?: "Alan Bateman" <Alan.Bateman at oracle.com>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoy?: Lundi 20 Novembre 2017 22:56:35
> Objet: Re: Resolution exception when service interface gets exposed via --add-exports

> I see, thanks for the clarification.
> 
> It's a pity, though, I hoped to employ that approach for providing a custom
> jlink plug-in (implementation of jdk.tools.jlink.plugin.Plugin). So it
> seems that's not possible until jdk.jlink exports j.t.j.plugin? Are there
> any plans to do so some time soon?
> 
> Even if it was marked as experimental/incubating, being able to provide
> custom jlink plug-ins would enable interesting use cases.
> 
> 2017-11-20 22:24 GMT+01:00 Alan Bateman <Alan.Bateman at oracle.com>:
> 
>> On 20/11/2017 21:04, Gunnar Morling wrote:
>>
>>> Hi,
>>>
>>> I'm having one module which defines a service interface but does not
>>> export
>>> that interface's package. In another module I wish to create an
>>> implementation of that service, which should be possible via
>>> --add-exports.
>>>
>>> I can successfully compile that second module, but running it fails:
>>>
>>>      Error occurred during initialization of boot layer
>>>      j.l.m.ResolutionException: Module com.example.b does not read a
>>> module
>>> that exports com.example.a
>>>
>>> It seems as if the service binding happens before the --add-exports of the
>>> java invocation is processed. Please see below for the steps to reproduce.
>>>
>>> Is it a bug or am I trying to do something unsupported here?
>>>
>>> At run-time, the --add-reads/--add-exports options are the equivalent of
>> the module invoking addReads or addExports. So yes, they come into effect
>> after resolution and service binding (and so after the resolution
>> consistency check that detects that a module uses a service type in a
>> package that isn't exported by anyone to the module).
>>
>> -Alan

From Alan.Bateman at oracle.com  Tue Nov 21 08:33:33 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Nov 2017 08:33:33 +0000
Subject: Resolution exception when service interface gets exposed via
 --add-exports
In-Reply-To: <CADGJaX89_wo_fd1_m6T9-beWYE-FM-ufJGSfL-pnxHOQmKkY+A@mail.gmail.com>
References: <CADGJaX9+TZZ36WBkGKgYAvmnh33nVprgj6HO-vitOwtaBwhvEA@mail.gmail.com>
 <5d0433e7-524a-9a66-bd8b-865a113b1098@oracle.com>
 <CADGJaX89_wo_fd1_m6T9-beWYE-FM-ufJGSfL-pnxHOQmKkY+A@mail.gmail.com>
Message-ID: <5d87c9c4-2b02-adc4-2bfd-1129df37565f@oracle.com>

On 20/11/2017 21:56, Gunnar Morling wrote:
> I see, thanks for the clarification.
>
> It's a pity, though, I hoped to employ that approach for providing a 
> custom jlink plug-in (implementation of 
> jdk.tools.jlink.plugin.Plugin). So it seems that's not possible until 
> jdk.jlink exports j.t.j.plugin? Are there any plans to do so some time 
> soon?
>
> Even if it was marked as experimental/incubating, being able to 
> provide custom jlink plug-ins would enable interesting use cases.
>
There was interest in creating an incubating module in JDK 9 but it was 
put aside due to the issues of tool modules depending on an incubating 
module. The other issue is that most of the interesting plugins to date 
do code generation at link time and are deeply tied to specific areas of 
java.base and other core modules (they can't really live outside of the 
jdk repo). So while it might be desirable to expose the interface for 
plugins, I think it will need further exploration to see if it makes 
sense or not.

-Alan

From forax at univ-mlv.fr  Tue Nov 21 09:29:51 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 21 Nov 2017 10:29:51 +0100 (CET)
Subject: Resolution exception when service interface gets exposed via
 --add-exports
In-Reply-To: <5d87c9c4-2b02-adc4-2bfd-1129df37565f@oracle.com>
References: <CADGJaX9+TZZ36WBkGKgYAvmnh33nVprgj6HO-vitOwtaBwhvEA@mail.gmail.com>
 <5d0433e7-524a-9a66-bd8b-865a113b1098@oracle.com>
 <CADGJaX89_wo_fd1_m6T9-beWYE-FM-ufJGSfL-pnxHOQmKkY+A@mail.gmail.com>
 <5d87c9c4-2b02-adc4-2bfd-1129df37565f@oracle.com>
Message-ID: <1021182804.637686.1511256591841.JavaMail.zimbra@u-pem.fr>

Hi Alan,
I use jlink plugins for 2 things,
- code generation, i.e. find patterns in the bytecode and optimize them because at link time you are in a closed world, so something that was dynamic is not anymore.
- just bytecode crawling to find specific annotations to improve startup.

I believe implementation like Weld or Spring should have access to an open API to be able to do thing kind of optimizations, imagine, you could create all proxies upfront or better use invokedynamic to even avoid proxy creation at all.

The plugin API doesn't have to be complex, it's a read/replace/append of bytecode files.

R?mi

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> ?: "Gunnar Morling" <gunnar at hibernate.org>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoy?: Mardi 21 Novembre 2017 09:33:33
> Objet: Re: Resolution exception when service interface gets exposed via --add-exports

> On 20/11/2017 21:56, Gunnar Morling wrote:
>> I see, thanks for the clarification.
>>
>> It's a pity, though, I hoped to employ that approach for providing a
>> custom jlink plug-in (implementation of
>> jdk.tools.jlink.plugin.Plugin). So it seems that's not possible until
>> jdk.jlink exports j.t.j.plugin? Are there any plans to do so some time
>> soon?
>>
>> Even if it was marked as experimental/incubating, being able to
>> provide custom jlink plug-ins would enable interesting use cases.
>>
> There was interest in creating an incubating module in JDK 9 but it was
> put aside due to the issues of tool modules depending on an incubating
> module. The other issue is that most of the interesting plugins to date
> do code generation at link time and are deeply tied to specific areas of
> java.base and other core modules (they can't really live outside of the
> jdk repo). So while it might be desirable to expose the interface for
> plugins, I think it will need further exploration to see if it makes
> sense or not.
> 
> -Alan

From gunnar at hibernate.org  Tue Nov 21 10:18:40 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 21 Nov 2017 11:18:40 +0100
Subject: Resolution exception when service interface gets exposed via
 --add-exports
In-Reply-To: <1021182804.637686.1511256591841.JavaMail.zimbra@u-pem.fr>
References: <CADGJaX9+TZZ36WBkGKgYAvmnh33nVprgj6HO-vitOwtaBwhvEA@mail.gmail.com>
 <5d0433e7-524a-9a66-bd8b-865a113b1098@oracle.com>
 <CADGJaX89_wo_fd1_m6T9-beWYE-FM-ufJGSfL-pnxHOQmKkY+A@mail.gmail.com>
 <5d87c9c4-2b02-adc4-2bfd-1129df37565f@oracle.com>
 <1021182804.637686.1511256591841.JavaMail.zimbra@u-pem.fr>
Message-ID: <CADGJaX-FweZbT=h8Y8EVpWX9C2b7qqjjb4sjNy94xW63PdamHw@mail.gmail.com>

Thanks for the patching idea, Remi. I'll try that.

> So while it might be desirable to expose the interface for plugins, I
think it will need further exploration to see if it makes sense or not.

Understood, it's just that in the current form I don't think many people
(outside of the JDK) will ever try it out and give feedback. Having a
public incubating API might help with that.

In terms of use cases I was thinking of generating annotation indexes and
adding them to the image, removing unused code or applying byte code
enhancements e.g. for Hibernate entities. Currently, plug-ins for the
specific build system are used in such cases (e.g. Maven/Gradle plug-ins),
but providing this functionality via generally usable jlink plug-ins would
be awesome.

2017-11-21 10:29 GMT+01:00 Remi Forax <forax at univ-mlv.fr>:

> Hi Alan,
> I use jlink plugins for 2 things,
> - code generation, i.e. find patterns in the bytecode and optimize them
> because at link time you are in a closed world, so something that was
> dynamic is not anymore.
> - just bytecode crawling to find specific annotations to improve startup.
>
> I believe implementation like Weld or Spring should have access to an open
> API to be able to do thing kind of optimizations, imagine, you could create
> all proxies upfront or better use invokedynamic to even avoid proxy
> creation at all.
>
> The plugin API doesn't have to be complex, it's a read/replace/append of
> bytecode files.
>
> R?mi
>
> ----- Mail original -----
> > De: "Alan Bateman" <Alan.Bateman at oracle.com>
> > ?: "Gunnar Morling" <gunnar at hibernate.org>
> > Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> > Envoy?: Mardi 21 Novembre 2017 09:33:33
> > Objet: Re: Resolution exception when service interface gets exposed via
> --add-exports
>
> > On 20/11/2017 21:56, Gunnar Morling wrote:
> >> I see, thanks for the clarification.
> >>
> >> It's a pity, though, I hoped to employ that approach for providing a
> >> custom jlink plug-in (implementation of
> >> jdk.tools.jlink.plugin.Plugin). So it seems that's not possible until
> >> jdk.jlink exports j.t.j.plugin? Are there any plans to do so some time
> >> soon?
> >>
> >> Even if it was marked as experimental/incubating, being able to
> >> provide custom jlink plug-ins would enable interesting use cases.
> >>
> > There was interest in creating an incubating module in JDK 9 but it was
> > put aside due to the issues of tool modules depending on an incubating
> > module. The other issue is that most of the interesting plugins to date
> > do code generation at link time and are deeply tied to specific areas of
> > java.base and other core modules (they can't really live outside of the
> > jdk repo). So while it might be desirable to expose the interface for
> > plugins, I think it will need further exploration to see if it makes
> > sense or not.
> >
> > -Alan
>

From Alan.Bateman at oracle.com  Tue Nov 21 10:46:06 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Nov 2017 10:46:06 +0000
Subject: Resolution exception when service interface gets exposed via
 --add-exports
In-Reply-To: <1021182804.637686.1511256591841.JavaMail.zimbra@u-pem.fr>
References: <CADGJaX9+TZZ36WBkGKgYAvmnh33nVprgj6HO-vitOwtaBwhvEA@mail.gmail.com>
 <5d0433e7-524a-9a66-bd8b-865a113b1098@oracle.com>
 <CADGJaX89_wo_fd1_m6T9-beWYE-FM-ufJGSfL-pnxHOQmKkY+A@mail.gmail.com>
 <5d87c9c4-2b02-adc4-2bfd-1129df37565f@oracle.com>
 <1021182804.637686.1511256591841.JavaMail.zimbra@u-pem.fr>
Message-ID: <41dd98fa-624d-942b-5fa0-aabc69e955a9@oracle.com>

On 21/11/2017 09:29, Remi Forax wrote:
> Hi Alan,
> I use jlink plugins for 2 things,
> - code generation, i.e. find patterns in the bytecode and optimize them because at link time you are in a closed world, so something that was dynamic is not anymore.
> - just bytecode crawling to find specific annotations to improve startup.
>
> I believe implementation like Weld or Spring should have access to an open API to be able to do thing kind of optimizations, imagine, you could create all proxies upfront or better use invokedynamic to even avoid proxy creation at all.
>
> The plugin API doesn't have to be complex, it's a read/replace/append of bytecode files.
>
Good work was done in JDK 9 to get the plugin API to its current state. 
We had hoped to expose it in an incubating module but it didn't happen 
as it would have required splitting the jdk.jlink module in an awkward 
way. Yes, it should be revisited.

-Alan

From gunnar at hibernate.org  Wed Nov 22 11:49:10 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 22 Nov 2017 12:49:10 +0100
Subject: Resolution exception when service interface gets exposed via
 --add-exports
In-Reply-To: <41dd98fa-624d-942b-5fa0-aabc69e955a9@oracle.com>
References: <CADGJaX9+TZZ36WBkGKgYAvmnh33nVprgj6HO-vitOwtaBwhvEA@mail.gmail.com>
 <5d0433e7-524a-9a66-bd8b-865a113b1098@oracle.com>
 <CADGJaX89_wo_fd1_m6T9-beWYE-FM-ufJGSfL-pnxHOQmKkY+A@mail.gmail.com>
 <5d87c9c4-2b02-adc4-2bfd-1129df37565f@oracle.com>
 <1021182804.637686.1511256591841.JavaMail.zimbra@u-pem.fr>
 <41dd98fa-624d-942b-5fa0-aabc69e955a9@oracle.com>
Message-ID: <CADGJaX8Fo=mHVWfJf5H=kudRPMekJ+G-agsJWJ7YnuWTqMnc=w@mail.gmail.com>

Just in case others end up in the same situation: --patch-module (alone)
doesn't do the trick as it can't be used to override the module-info.class
of the jdk.jlink module. So I'm just using it to inject my plug-in and then
use a Java Agent to register that one as a service provider (via
Instrumentation#redefineModule()).

If I find the time I'll try and blog about it; needless to say, that a
public, supported API would be much appreciated :) Thanks Alan and Remi for
your help!


2017-11-21 11:46 GMT+01:00 Alan Bateman <Alan.Bateman at oracle.com>:

> On 21/11/2017 09:29, Remi Forax wrote:
>
>> Hi Alan,
>> I use jlink plugins for 2 things,
>> - code generation, i.e. find patterns in the bytecode and optimize them
>> because at link time you are in a closed world, so something that was
>> dynamic is not anymore.
>> - just bytecode crawling to find specific annotations to improve startup.
>>
>> I believe implementation like Weld or Spring should have access to an
>> open API to be able to do thing kind of optimizations, imagine, you could
>> create all proxies upfront or better use invokedynamic to even avoid proxy
>> creation at all.
>>
>> The plugin API doesn't have to be complex, it's a read/replace/append of
>> bytecode files.
>>
>> Good work was done in JDK 9 to get the plugin API to its current state.
> We had hoped to expose it in an incubating module but it didn't happen as
> it would have required splitting the jdk.jlink module in an awkward way.
> Yes, it should be revisited.




>
>
> -Alan
>

From forax at univ-mlv.fr  Wed Nov 22 11:59:47 2017
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 22 Nov 2017 12:59:47 +0100 (CET)
Subject: Resolution exception when service interface gets exposed via
 --add-exports
In-Reply-To: <CADGJaX8Fo=mHVWfJf5H=kudRPMekJ+G-agsJWJ7YnuWTqMnc=w@mail.gmail.com>
References: <CADGJaX9+TZZ36WBkGKgYAvmnh33nVprgj6HO-vitOwtaBwhvEA@mail.gmail.com>
 <5d0433e7-524a-9a66-bd8b-865a113b1098@oracle.com>
 <CADGJaX89_wo_fd1_m6T9-beWYE-FM-ufJGSfL-pnxHOQmKkY+A@mail.gmail.com>
 <5d87c9c4-2b02-adc4-2bfd-1129df37565f@oracle.com>
 <1021182804.637686.1511256591841.JavaMail.zimbra@u-pem.fr>
 <41dd98fa-624d-942b-5fa0-aabc69e955a9@oracle.com>
 <CADGJaX8Fo=mHVWfJf5H=kudRPMekJ+G-agsJWJ7YnuWTqMnc=w@mail.gmail.com>
Message-ID: <25190197.1197946.1511351987077.JavaMail.zimbra@u-pem.fr>

My opinion is that we should fix --patch-module to allow to patch the module-info.class, 
you always end up with this restriction once you use --patch-module. 

R?mi 

> De: "Gunnar Morling" <gunnar at hibernate.org>
> ?: "Alan Bateman" <Alan.Bateman at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoy?: Mercredi 22 Novembre 2017 12:49:10
> Objet: Re: Resolution exception when service interface gets exposed via
> --add-exports

> Just in case others end up in the same situation: --patch-module (alone) doesn't
> do the trick as it can't be used to override the module-info.class of the
> jdk.jlink module. So I'm just using it to inject my plug-in and then use a Java
> Agent to register that one as a service provider (via
> Instrumentation#redefineModule()).
> If I find the time I'll try and blog about it; needless to say, that a public,
> supported API would be much appreciated :) Thanks Alan and Remi for your help!

> 2017-11-21 11:46 GMT+01:00 Alan Bateman < [ mailto:Alan.Bateman at oracle.com |
> Alan.Bateman at oracle.com ] > :

>> On 21/11/2017 09:29, Remi Forax wrote:

>>> Hi Alan,
>>> I use jlink plugins for 2 things,
>>> - code generation, i.e. find patterns in the bytecode and optimize them because
>>> at link time you are in a closed world, so something that was dynamic is not
>>> anymore.
>>> - just bytecode crawling to find specific annotations to improve startup.

>>> I believe implementation like Weld or Spring should have access to an open API
>>> to be able to do thing kind of optimizations, imagine, you could create all
>>> proxies upfront or better use invokedynamic to even avoid proxy creation at
>>> all.

>>> The plugin API doesn't have to be complex, it's a read/replace/append of
>>> bytecode files.

>> Good work was done in JDK 9 to get the plugin API to its current state. We had
>> hoped to expose it in an incubating module but it didn't happen as it would
>> have required splitting the jdk.jlink module in an awkward way. Yes, it should
>> be revisited.
>> -Alan

From mik3hall at gmail.com  Mon Nov 27 23:16:17 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 27 Nov 2017 17:16:17 -0600
Subject: Adding module causes classloading issues
Message-ID: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>

JMX attach keeps telling me that RMI is not a accepted protocol.
I wondered if possibly this was a modular issue, I checked my main app jar?
jdeps halfpipe.jar
...
halfpipe.jar -> java.corba
?

which seems to say I need java.corba which I didn?t have.
If I add that with jlink I get?

java.lang.NoClassDefFoundError: javax/transaction/UserTransaction

from the quartz scheduler. This class should come from the included jta.jar, and usually does without the java.corba module.

This doesn?t appear to be included in any existing modules including corba. 
java -cp halfpipe.jar us.hall.cmdline.cmds.JRTLister /modules | grep javax.transaction
   /modules/java.sql/javax/transaction
    /modules/java.sql/javax/transaction/xa
     /modules/java.sql/javax/transaction/xa/XAException.class
     /modules/java.sql/javax/transaction/xa/XAResource.class
     /modules/java.sql/javax/transaction/xa/Xid.class
   /modules/java.transaction/javax/transaction
    /modules/java.transaction/javax/transaction/InvalidTransactionException.class
    /modules/java.transaction/javax/transaction/TransactionRequiredException.class
    /modules/java.transaction/javax/transaction/TransactionRolledbackException.class

So it doesn?t seem like it should be a ?split package? situation, unless possibly with java.transaction, not java.corba.
I?m not sure if ?split package? applies module to jar anyhow?

I?m still very new to this. Is there a command that would give me the module descriptor information for java.corba?
That might give me some idea why it is interfering with my jar classloading. 
Or any other suggestions as to why it might be doing this?



From alex.buckley at oracle.com  Tue Nov 28 00:40:47 2017
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 27 Nov 2017 16:40:47 -0800
Subject: Adding module causes classloading issues
In-Reply-To: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
Message-ID: <5A1CB08F.1000505@oracle.com>

On 11/27/2017 3:16 PM, Michael Hall wrote:
> JMX attach keeps telling me that RMI is not a accepted protocol.
> I wondered if possibly this was a modular issue, I checked my main app jar?
> jdeps halfpipe.jar
> ...
> halfpipe.jar -> java.corba
> ?
>
> which seems to say I need java.corba which I didn?t have.
> If I add that with jlink I get?
>
> java.lang.NoClassDefFoundError: javax/transaction/UserTransaction
>
> from the quartz scheduler. This class should come from the included jta.jar, and usually does without the java.corba module.

java --list-modules
// Will show java.corba in your jlinked image

java --describe-module java.corba
// Will show 'requires java.transaction'
// Since this is an implementation dependency, it's not listed in 
https://docs.oracle.com/javase/9/docs/api/java.corba-summary.html

java --show-module-resolution -jar halfpipe.jar
// Will show java.transaction being resolved in support of java.corba

Because java.transaction is resolved, the miniature javax.transaction 
package that it exports will "win", and the full-strength 
javax.transaction package in jta.jar on the classpath will "lose".

The story of java.transaction is unfortunate and complicated (see 
http://openjdk.java.net/jeps/8189188) but you can augment it with the 
stuff in jta.jar:

java --patch-module java.transaction=jta.jar -jar halfpipe.jar
// See http://openjdk.java.net/jeps/261#Patching-module-content

Alex

From mik3hall at gmail.com  Tue Nov 28 01:03:18 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 27 Nov 2017 19:03:18 -0600
Subject: Adding module causes classloading issues
In-Reply-To: <5A1CB08F.1000505@oracle.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
Message-ID: <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>


> On Nov 27, 2017, at 6:40 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> On 11/27/2017 3:16 PM, Michael Hall wrote:
>> JMX attach keeps telling me that RMI is not a accepted protocol.
>> I wondered if possibly this was a modular issue, I checked my main app jar?
>> jdeps halfpipe.jar
>> ...
>> halfpipe.jar -> java.corba
>> ?
>> 
>> which seems to say I need java.corba which I didn?t have.
>> If I add that with jlink I get?
>> 
>> java.lang.NoClassDefFoundError: javax/transaction/UserTransaction
>> 
>> from the quartz scheduler. This class should come from the included jta.jar, and usually does without the java.corba module.
> 
> java --list-modules
> // Will show java.corba in your jlinked image
> 
> java --describe-module java.corba
> // Will show 'requires java.transaction'
> // Since this is an implementation dependency, it's not listed in https://docs.oracle.com/javase/9/docs/api/java.corba-summary.html
> 
> java --show-module-resolution -jar halfpipe.jar
> // Will show java.transaction being resolved in support of java.corba
> 
Thanks for the above, searches hadn?t hit them yet.

> Because java.transaction is resolved, the miniature javax.transaction package that it exports will "win", and the full-strength javax.transaction package in jta.jar on the classpath will "lose".
> 
> The story of java.transaction is unfortunate and complicated (see http://openjdk.java.net/jeps/8189188) but you can augment it with the stuff in jta.jar:
> 
> java --patch-module java.transaction=jta.jar -jar halfpipe.jar
> // See http://openjdk.java.net/jeps/261#Patching-module-content <http://openjdk.java.net/jeps/261#Patching-module-content>

The application usually runs as an OS X application. So I don?t use -jar. I do have a shell script launch for testing?

#!/bin/bash

APP_ROOT=HalfPipe7.app
JAVA=${APP_ROOT}/Contents/Java
export R_HOME=/Library/Frameworks/R.framework/Resources
java --patch-module java.transaction=${JAVA}/jta.jar -XX:+CITime -Xms32M -Xmx256M -Xdock:name=HalfPipe -Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe -Dapple.laf.useScreenMenuBar=true -Djava.library.path=$APP_ROOT/Contents/MacOS -Djava.security.manager -Djava.security.policy=$APP_ROOT/Contents/JavaApp/all.policy -Dapp.lib=$APP_ROOT/Contents/JavaApp -Dconsole=pane -cp .:..:hp_jshell.jar:${JAVA}/halfpipe.jar:${JAVA}/log4j-1.2.16.jar:${JAVA}/quartz-2.2.2.jar:${JAVA}/quartz-jobs-2.2.2.jar:${JAVA}/httpcore-4.1.jar:${JAVA}/httpclient-4.1.jar:${JAVA}/commons-logging-1.1.1.jar:${JAVA}/slf4j-api-1.7.7.jar:${JAVA}/slf4j-log4j12-1.7.7.jar:${JAVA}/antlr-2.7.7.jar:${JAVA}/AppleScriptEngine.jar:${JAVA}/Classes:${JAVA}/groovy-all-2.4.5.jar:${JAVA}/JRI.jar:${JAVA}/JRIEngine.jar:${JAVA}/JRS.jar:${JAVA}/REngine.jar:${JAVA}/RserveEngine.jar:${JAVA}/jta.jar:${JAVA}/macnio2.jar:${JAVA}/stringtemplate-3.2.1.jar:${JAVA}/weka.jar:${JAVA}/js.jar us.hall.hp.common.LoaderLaunchStub

Note?patch-module at start if I am doing that correctly, gets?
WARNING: Unknown module: java.transaction specified to --patch-module

This is the installed jvm, not the embedded application one (I could point it at that if useful), but it should have all modules included?



From alex.buckley at oracle.com  Tue Nov 28 01:15:08 2017
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 27 Nov 2017 17:15:08 -0800
Subject: Adding module causes classloading issues
In-Reply-To: <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
Message-ID: <5A1CB89C.2060305@oracle.com>

On 11/27/2017 5:03 PM, Michael Hall wrote:
> The application usually runs as an OS X application. So I don?t use
> -jar. I do have a shell script launch for testing?
>
> #!/bin/bash
>
> APP_ROOT=HalfPipe7.app
> JAVA=${APP_ROOT}/Contents/Java
> export R_HOME=/Library/Frameworks/R.framework/Resources
> java --patch-module java.transaction=${JAVA}/jta.jar -XX:+CITime -Xms32M
> -Xmx256M -Xdock:name=HalfPipe
> -Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe
> -Dapple.laf.useScreenMenuBar=true
> -Djava.library.path=$APP_ROOT/Contents/MacOS -Djava.security.manager
> -Djava.security.policy=$APP_ROOT/Contents/JavaApp/all.policy
> -Dapp.lib=$APP_ROOT/Contents/JavaApp -Dconsole=pane -cp
> .:..:hp_jshell.jar:${JAVA}/halfpipe.jar:${JAVA}/log4j-1.2.16.jar:${JAVA}/quartz-2.2.2.jar:${JAVA}/quartz-jobs-2.2.2.jar:${JAVA}/httpcore-4.1.jar:${JAVA}/httpclient-4.1.jar:${JAVA}/commons-logging-1.1.1.jar:${JAVA}/slf4j-api-1.7.7.jar:${JAVA}/slf4j-log4j12-1.7.7.jar:${JAVA}/antlr-2.7.7.jar:${JAVA}/AppleScriptEngine.jar:${JAVA}/Classes:${JAVA}/groovy-all-2.4.5.jar:${JAVA}/JRI.jar:${JAVA}/JRIEngine.jar:${JAVA}/JRS.jar:${JAVA}/REngine.jar:${JAVA}/RserveEngine.jar:${JAVA}/jta.jar:${JAVA}/macnio2.jar:${JAVA}/stringtemplate-3.2.1.jar:${JAVA}/weka.jar:${JAVA}/js.jar
> us.hall.hp.common.LoaderLaunchStub
>
> Note?patch-module at start if I am doing that correctly, gets?
> WARNING: Unknown module: java.transaction specified to --patch-module
>
> This is the installed jvm, not the embedded application one (I could
> point it at that if useful), but it should have all modules included?

You said that you jlinked an image to include java.corba, which means 
the image will contain java.transaction as well. I don't know what the 
quartz scheduler that you mentioned is doing when you run it on your 
custom image, but evidently java.corba was being resolved at run time 
because it triggered resolution of java.transaction with its miniature 
javax.transaction package.

If you're running a classpath application on the JDK out of the box, 
then java.corba will not even be resolved, and nor will 
java.transaction. Hence the warning that patching it is fishy. You can 
use --add-modules java.transaction to force its resolution.

Please note that java.corba and java.transaction are both deprecated FOR 
REMOVAL. There will soon be a modular version of JTA which you can 
deploy on the upgrade module path rather than via patching. See the very 
end of http://openjdk.java.net/jeps/8189188.

Alex

From mik3hall at gmail.com  Tue Nov 28 01:22:26 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 27 Nov 2017 19:22:26 -0600
Subject: Adding module causes classloading issues
In-Reply-To: <5A1CB89C.2060305@oracle.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
Message-ID: <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>


> On Nov 27, 2017, at 7:15 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> --add-modules java.transaction

Tried to simplify.

java -cp . --patch-module java.transaction=jta.jar --add-modules java.transaction ModuleForClass javax.transaction.UserTransaction
Error occurred during initialization of boot layer
java.lang.LayerInstantiationException: Package javax.transaction.xa in both module java.transaction and module java.sql

import javax.transaction.UserTransaction;

public class ModuleForClass {

	public static void main(String[] args) {
		try {
			Module m = Class.forName("javax.transaction.UserTransaction").getModule();
			System.out.println(m.getName());
		}
		catch (Throwable tossed) { tossed.printStackTrace(); }
	}
}

From mik3hall at gmail.com  Tue Nov 28 01:28:25 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 27 Nov 2017 19:28:25 -0600
Subject: Adding module causes classloading issues
In-Reply-To: <5A1CB89C.2060305@oracle.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
Message-ID: <7E15D6D9-6D7A-4A12-9E8F-06F1EF513BCF@gmail.com>


> On Nov 27, 2017, at 7:15 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> You said that you jlinked an image to include java.corba,

For that?

HalfPipe7.app/Contents/PlugIns/Java.runtime/Contents/Home/bin/java -cp . --patch-module java.transaction=jta.jar --add-modules java.transaction ModuleForClass javax.transaction.UserTransaction
Error occurred during initialization of boot layer
java.lang.LayerInstantiationException: Package javax.transaction.xa in both module java.transaction and module java.sql

From mik3hall at gmail.com  Tue Nov 28 01:35:52 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 27 Nov 2017 19:35:52 -0600
Subject: Adding module causes classloading issues
In-Reply-To: <5A1CB89C.2060305@oracle.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
Message-ID: <05EB4CA8-B91A-4A33-A9B8-8D40C3D0537E@gmail.com>


> On Nov 27, 2017, at 7:15 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> here will soon be a modular version of JTA which you can deploy on the upgrade module path rather than via patching. 

Oh, and looking forward to that of course.



From alex.buckley at oracle.com  Tue Nov 28 01:40:48 2017
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 27 Nov 2017 17:40:48 -0800
Subject: Adding module causes classloading issues
In-Reply-To: <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
 <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
Message-ID: <5A1CBEA0.9030300@oracle.com>

On 11/27/2017 5:22 PM, Michael Hall wrote:
>> On Nov 27, 2017, at 7:15 PM, Alex Buckley <alex.buckley at oracle.com
>> <mailto:alex.buckley at oracle.com>> wrote:
>>
>> --add-modules java.transaction
>
> Tried to simplify.
>
> java -cp . --patch-module java.transaction=jta.jar --add-modules
> java.transaction ModuleForClass javax.transaction.UserTransaction
> Error occurred during initialization of boot layer
> java.lang.LayerInstantiationException: Package javax.transaction.xa in
> both module java.transaction and module java.sql

Oh yes, jta.jar includes the XA package, so force-patching that package 
into java.transaction will conflict with the same package in java.sql.

If your app doesn't use JDBC, then you could prevent java.sql from being 
resolved by passing the JDK modules that you DO want to be resolved to 
the --limit-modules option. Being precise about your app's use of JDK 
modules is a down payment on writing its module declaration.

But most likely, you need the new, XA-less JTA jar which is coming soon 
from the JSR 907 Maintenance Lead.

Alex

From mik3hall at gmail.com  Tue Nov 28 01:46:11 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 27 Nov 2017 19:46:11 -0600
Subject: Adding module causes classloading issues
In-Reply-To: <5A1CBEA0.9030300@oracle.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
 <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
 <5A1CBEA0.9030300@oracle.com>
Message-ID: <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com>


> On Nov 27, 2017, at 7:40 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> On 11/27/2017 5:22 PM, Michael Hall wrote:
>>> On Nov 27, 2017, at 7:15 PM, Alex Buckley <alex.buckley at oracle.com
>>> <mailto:alex.buckley at oracle.com>> wrote:
>>> 
>>> --add-modules java.transaction
>> 
>> Tried to simplify.
>> 
>> java -cp . --patch-module java.transaction=jta.jar --add-modules
>> java.transaction ModuleForClass javax.transaction.UserTransaction
>> Error occurred during initialization of boot layer
>> java.lang.LayerInstantiationException: Package javax.transaction.xa in
>> both module java.transaction and module java.sql
> 
> Oh yes, jta.jar includes the XA package, so force-patching that package into java.transaction will conflict with the same package in java.sql.
> 
> If your app doesn't use JDBC, then you could prevent java.sql from being resolved by passing the JDK modules that you DO want to be resolved to the --limit-modules option. Being precise about your app's use of JDK modules is a down payment on writing its module declaration.
> 
> But most likely, you need the new, XA-less JTA jar which is coming soon from the JSR 907 Maintenance Lead.
> 
> Alex

Thanks again, for the time.

It is a little difficult for me to track these things. For now I will probably just omit java.corba and hope it isn?t really my problem with JMX attach. 
I will take a closer look at jconsole to try and figure that out.

I will maybe check back on the newer JTA later.


From alex.buckley at oracle.com  Tue Nov 28 02:00:41 2017
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 27 Nov 2017 18:00:41 -0800
Subject: Adding module causes classloading issues
In-Reply-To: <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
 <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
 <5A1CBEA0.9030300@oracle.com>
 <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com>
Message-ID: <5A1CC349.30401@oracle.com>

On 11/27/2017 5:46 PM, Michael Hall wrote:
> Thanks again, for the time.
>
> It is a little difficult for me to track these things. For now I will probably just omit java.corba and hope it isn?t really my problem with JMX attach.
> I will take a closer look at jconsole to try and figure that out.
>
> I will maybe check back on the newer JTA later.

Thank you, for investigating how your app relates to CORBA, JTA, and 
Attach. I hope http://openjdk.java.net/jeps/8189188 was informative at 
least. Alan will probably be along shortly with some points I missed.

Alex

From mik3hall at gmail.com  Tue Nov 28 02:03:49 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 27 Nov 2017 20:03:49 -0600
Subject: Adding module causes classloading issues
In-Reply-To: <5A1CC349.30401@oracle.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
 <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
 <5A1CBEA0.9030300@oracle.com>
 <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com> <5A1CC349.30401@oracle.com>
Message-ID: <8A9C76F1-C000-47B3-8F9A-E94142DFBBED@gmail.com>


> On Nov 27, 2017, at 8:00 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> I hope http://openjdk.java.net/jeps/8189188 <http://openjdk.java.net/jeps/8189188> was informative at least. 

Reading it now...

From Alan.Bateman at oracle.com  Tue Nov 28 08:35:07 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 28 Nov 2017 08:35:07 +0000
Subject: Adding module causes classloading issues
In-Reply-To: <5A1CC349.30401@oracle.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
 <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
 <5A1CBEA0.9030300@oracle.com>
 <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com> <5A1CC349.30401@oracle.com>
Message-ID: <035ffe35-67ae-da8e-1dd0-fe591784bd81@oracle.com>

On 28/11/2017 02:00, Alex Buckley wrote:
>
> Thank you, for investigating how your app relates to CORBA, JTA, and 
> Attach. I hope http://openjdk.java.net/jeps/8189188 was informative at 
> least. Alan will probably be along shortly with some points I missed.
One point that I didn't see mentioned in the thread so far is a detail 
in the JEP 261 policy on root modules for the case that module java.se 
is not observable. When java.se is not observable then all modules 
(system or upgrade module path) that export an API are resolved. The 
output of `java --list-modules` will answer his quickly but I'll bet the 
image doesn't have java.se.

I don't know what halfpipe is but it would be interesting to paste in 
the detailed output from jdeps so we can see if it really depends on 
classes in java.corba. I'm also interested in the first mail about "JMX 
Attach" as it's not clear what that means. Is jconsole or VisualVM in 
the picture? This would require the java.management.rmi module to be 
included.

As Alex mentioned, this case is crying out for the XA-less JTA that Alex 
mentioned. Hopefully the JSR 907 spec lead will sort this out soon.

-Alan

From mik3hall at gmail.com  Tue Nov 28 09:14:55 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 28 Nov 2017 03:14:55 -0600
Subject: Adding module causes classloading issues
In-Reply-To: <035ffe35-67ae-da8e-1dd0-fe591784bd81@oracle.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
 <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
 <5A1CBEA0.9030300@oracle.com>
 <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com> <5A1CC349.30401@oracle.com>
 <035ffe35-67ae-da8e-1dd0-fe591784bd81@oracle.com>
Message-ID: <7F1291A3-3842-4AD9-B88E-B34298776D4F@gmail.com>


> On Nov 28, 2017, at 2:35 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 28/11/2017 02:00, Alex Buckley wrote:
>> 
>> Thank you, for investigating how your app relates to CORBA, JTA, and Attach. I hope http://openjdk.java.net/jeps/8189188 was informative at least. Alan will probably be along shortly with some points I missed.
> One point that I didn't see mentioned in the thread so far is a detail in the JEP 261 policy on root modules for the case that module java.se is not observable. When java.se is not observable then all modules (system or upgrade module path) that export an API are resolved. The output of `java --list-modules` will answer his quickly but I'll bet the image doesn't have java.se.
> 
HalfPipe7.app/Contents/PlugIns/Java.runtime/Contents/Home/bin/java --list-modules | grep java.se
java.security.sasl at 9


> I don't know what halfpipe is

java shell application - halfpipe = platform for skateboarding tricks. Sort of a lot of different body parts put together to make a Frankenstein monster.

> but it would be interesting to paste in the detailed output from jdeps so we can see if it really depends on classes in java.corba.

It?s a little alarming jdeps might report false dependencies? I would rather spare you the full output. How about?

jdeps halfpipe.jar | grep corba
halfpipe.jar -> java.corba
   org.cmdline                                        -> javax.rmi                                          java.corba
 

> I'm also interested in the first mail about "JMX Attach" as it's not clear what that means. Is jconsole or VisualVM in the picture? This would require the java.management.rmi module to be included.

At one point I was adding JSR 223 interfaces into the application. During the OS X port days when there was no java provided javascript JSR 223 interface yet I did one for Rhino javascript that included code, based on a blog of yours actually, that allowed it to pid attach to java processes and do scripting. Sort of like the Notebook example but again before I knew of any other way to do this it also allowed attaching to any java process. 
One thing I thought the application might work as would be a monitoring/automation type app. At one point I worked on a IBM mainframe product for one of those for data center automation - CA OPS/MVS. REXX based for the language I?m afraid. So a little nostalgia coding getting my app to do some things similar.
I was thinking of re-doing this code for Java 9. JMX attach now seemed to be the way to go. jconsole I believe does this successfully and I have started looking at that to see what it might be doing right that I am not. So far no matter what I do I always end up with the same rmi: url that is rejected. Even based on what jconsole seems to be doing.
I thought maybe the missing corba explains this but since that seems to conflict with the Quartz scheduler I added. Another ?automation? like feature. 
Maybe I will put this on hold for now.

> 
> As Alex mentioned, this case is crying out for the XA-less JTA that Alex mentioned. Hopefully the JSR 907 spec lead will sort this out soon.

Also a little sorry to hear the code is crying out but again it may be best to put it on hold then.

> 
> -Alan

Thanks. I will try to remain aware of these coming related changes.


From mik3hall at gmail.com  Tue Nov 28 09:55:21 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 28 Nov 2017 03:55:21 -0600
Subject: Adding module causes classloading issues
In-Reply-To: <035ffe35-67ae-da8e-1dd0-fe591784bd81@oracle.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
 <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
 <5A1CBEA0.9030300@oracle.com>
 <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com> <5A1CC349.30401@oracle.com>
 <035ffe35-67ae-da8e-1dd0-fe591784bd81@oracle.com>
Message-ID: <4FE4C85B-8B0A-40E4-B9E7-AF02AC8D012F@gmail.com>


> On Nov 28, 2017, at 2:35 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> One point that I didn't see mentioned in the thread so far is a detail in the JEP 261 policy on root modules for the case that module java.se <http://java.se/> is not observable. When java.se <http://java.se/> is not observable then all modules (system or upgrade module path) that export an API are resolved. The output of `java --list-modules` will answer his quickly but I'll bet the image doesn't have java.se <http://java.se/>.

I added this. It works. java.corba included and the scheduler still working.

Still looking forward to the changes of course but this seems to give something to go on.

Thanks again.

HalfPipe7.app/Contents/PlugIns/Java.runtime/Contents/Home/bin/java --list-modules
java.activation at 9
java.base at 9
java.compiler at 9
java.corba at 9
java.datatransfer at 9
java.desktop at 9
java.instrument at 9
java.logging at 9
java.management at 9
java.management.rmi at 9
java.naming at 9
java.prefs at 9
java.rmi at 9
java.scripting at 9
java.se at 9
java.security.jgss at 9
java.security.sasl at 9
java.sql at 9
java.sql.rowset at 9
java.transaction at 9
java.xml at 9
java.xml.bind at 9
java.xml.crypto at 9
jdk.attach at 9
jdk.compiler at 9
jdk.internal.ed at 9
jdk.internal.jvmstat at 9
jdk.internal.le at 9
jdk.internal.opt at 9
jdk.jdi at 9
jdk.jdwp.agent at 9
jdk.jshell at 9
jdk.unsupported at 9


From Alan.Bateman at oracle.com  Tue Nov 28 10:48:48 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 28 Nov 2017 10:48:48 +0000
Subject: Adding module causes classloading issues
In-Reply-To: <7F1291A3-3842-4AD9-B88E-B34298776D4F@gmail.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
 <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
 <5A1CBEA0.9030300@oracle.com>
 <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com> <5A1CC349.30401@oracle.com>
 <035ffe35-67ae-da8e-1dd0-fe591784bd81@oracle.com>
 <7F1291A3-3842-4AD9-B88E-B34298776D4F@gmail.com>
Message-ID: <ee28ac82-1fbb-8d36-ce33-c3ee67c130f8@oracle.com>

On 28/11/2017 09:14, Michael Hall wrote:
> It?s a little alarming jdeps might report false dependencies? I would rather spare you the full output. How about?
>
> jdeps halfpipe.jar | grep corba
> halfpipe.jar -> java.corba
>     org.cmdline                                        -> javax.rmi                                          java.corba
I assume `jdeps -verbose:class` will reveal that there is some in the 
org.cmdline package with a reference to javax.rmi.PortableRemoteObject. 
That class isn't used much beyond RMI-IIOP and maybe something you can 
drop if an alternative is possible.


> :
>
>
>> As Alex mentioned, this case is crying out for the XA-less JTA that Alex mentioned. Hopefully the JSR 907 spec lead will sort this out soon.
> Also a little sorry to hear the code is crying out but again it may be best to put it on hold then.
>
Once there is a version of java.transaction published to Maven without 
the XA package then it will be a lot simpler.

-Alan

From stephen.felts at oracle.com  Tue Nov 28 12:54:10 2017
From: stephen.felts at oracle.com (Stephen Felts)
Date: Tue, 28 Nov 2017 04:54:10 -0800 (PST)
Subject: Adding module causes classloading issues
In-Reply-To: <ee28ac82-1fbb-8d36-ce33-c3ee67c130f8@oracle.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
 <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
 <5A1CBEA0.9030300@oracle.com>
 <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com> <5A1CC349.30401@oracle.com>
 <035ffe35-67ae-da8e-1dd0-fe591784bd81@oracle.com>
 <7F1291A3-3842-4AD9-B88E-B34298776D4F@gmail.com>
 <ee28ac82-1fbb-8d36-ce33-c3ee67c130f8@oracle.com>
Message-ID: <55487752-03c1-4176-ac91-ce9ea6cb9424@default>

I'm trying to get javax.transaction-api-1.3-ea.jar published to Maven Central as soon as possible.
In the meantime, you can make your own if you are blocked by starting with javax.transaction-api-1.2.jar, deleting the three classes in the javax.transaction.xa  package, and updating  META-INF/MANIFEST.MF to add Automatic-Module-Name: java.transaction

-----Original Message-----
From: Alan Bateman 
Sent: Tuesday, November 28, 2017 5:49 AM
To: Michael Hall <mik3hall at gmail.com>
Cc: jigsaw-dev at openjdk.java.net
Subject: Re: Adding module causes classloading issues

On 28/11/2017 09:14, Michael Hall wrote:
> It?s a little alarming jdeps might report false dependencies? I would 
> rather spare you the full output. How about?
>
> jdeps halfpipe.jar | grep corba
> halfpipe.jar -> java.corba
>     org.cmdline                                        -> javax.rmi                                          java.corba
I assume `jdeps -verbose:class` will reveal that there is some in the org.cmdline package with a reference to javax.rmi.PortableRemoteObject. 
That class isn't used much beyond RMI-IIOP and maybe something you can drop if an alternative is possible.


> :
>
>
>> As Alex mentioned, this case is crying out for the XA-less JTA that Alex mentioned. Hopefully the JSR 907 spec lead will sort this out soon.
> Also a little sorry to hear the code is crying out but again it may be best to put it on hold then.
>
Once there is a version of java.transaction published to Maven without the XA package then it will be a lot simpler.

-Alan

From gunnar at hibernate.org  Tue Nov 28 20:35:52 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 28 Nov 2017 21:35:52 +0100
Subject: Adding module causes classloading issues
In-Reply-To: <55487752-03c1-4176-ac91-ce9ea6cb9424@default>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com> <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com> <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
 <5A1CBEA0.9030300@oracle.com> <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com>
 <5A1CC349.30401@oracle.com> <035ffe35-67ae-da8e-1dd0-fe591784bd81@oracle.com>
 <7F1291A3-3842-4AD9-B88E-B34298776D4F@gmail.com>
 <ee28ac82-1fbb-8d36-ce33-c3ee67c130f8@oracle.com>
 <55487752-03c1-4176-ac91-ce9ea6cb9424@default>
Message-ID: <CADGJaX8GAcq6K7RMb5xHFXTZWi-Gr_37Pc+W2MmReSBmCbPEHg@mail.gmail.com>

Hi,

There's a preview version of JBoss' instance of the JTA API JAR without the
XA classes available already:


http://search.maven.org/#artifactdetails%7Corg.jboss.spec.javax.transaction%7Cjboss-transaction-api_1.2_spec%7C2.0.0.Alpha1%7Cjar

--Gunnar


2017-11-28 13:54 GMT+01:00 Stephen Felts <stephen.felts at oracle.com>:

> I'm trying to get javax.transaction-api-1.3-ea.jar published to Maven
> Central as soon as possible.
> In the meantime, you can make your own if you are blocked by starting with
> javax.transaction-api-1.2.jar, deleting the three classes in the
> javax.transaction.xa  package, and updating  META-INF/MANIFEST.MF to add
> Automatic-Module-Name: java.transaction
>
> -----Original Message-----
> From: Alan Bateman
> Sent: Tuesday, November 28, 2017 5:49 AM
> To: Michael Hall <mik3hall at gmail.com>
> Cc: jigsaw-dev at openjdk.java.net
> Subject: Re: Adding module causes classloading issues
>
> On 28/11/2017 09:14, Michael Hall wrote:
> > It?s a little alarming jdeps might report false dependencies? I would
> > rather spare you the full output. How about?
> >
> > jdeps halfpipe.jar | grep corba
> > halfpipe.jar -> java.corba
> >     org.cmdline                                        -> javax.rmi
>                                     java.corba
> I assume `jdeps -verbose:class` will reveal that there is some in the
> org.cmdline package with a reference to javax.rmi.PortableRemoteObject.
> That class isn't used much beyond RMI-IIOP and maybe something you can
> drop if an alternative is possible.
>
>
> > :
> >
> >
> >> As Alex mentioned, this case is crying out for the XA-less JTA that
> Alex mentioned. Hopefully the JSR 907 spec lead will sort this out soon.
> > Also a little sorry to hear the code is crying out but again it may be
> best to put it on hold then.
> >
> Once there is a version of java.transaction published to Maven without the
> XA package then it will be a lot simpler.
>
> -Alan
>

From mik3hall at gmail.com  Tue Nov 28 22:11:23 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 28 Nov 2017 16:11:23 -0600
Subject: Adding module causes classloading issues
In-Reply-To: <ee28ac82-1fbb-8d36-ce33-c3ee67c130f8@oracle.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
 <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
 <5A1CBEA0.9030300@oracle.com>
 <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com> <5A1CC349.30401@oracle.com>
 <035ffe35-67ae-da8e-1dd0-fe591784bd81@oracle.com>
 <7F1291A3-3842-4AD9-B88E-B34298776D4F@gmail.com>
 <ee28ac82-1fbb-8d36-ce33-c3ee67c130f8@oracle.com>
Message-ID: <9366D839-9CD2-487E-9D74-D25596E37B09@gmail.com>


> On Nov 28, 2017, at 4:48 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> javax.rmi.PortableRemoteObject

It does include PortableRemoteObject. At one point, it looks like about 2004, I had made the app RMI client/server. 
But having trouble coming up with a second machine to test on. I think I ended up just forgetting about that. 
A little strange that Eclipse seems to show that it is missing, flagging it as an error. However the project compiles just fine with it.
So maybe not a mystery that needs solving at this point. As you suggest eliminating that code might be easier. 
But theres a lot of dead code in this app so it hasn?t seemed that critical. 

Unless it does relate to current problems. I haven?t had a chance to test JMX again yet. 
But since getting the java.corba module in the runtime with the scheduler code still running was the concern then that isn?t a concern anymore is it?
Although, I still need to go back and look at why java.se <http://java.se/> was the apparent fix. 
As well as the other posts and suggested reading. 

The information was very helpful,  thanks again.

From mik3hall at gmail.com  Tue Nov 28 22:54:21 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 28 Nov 2017 16:54:21 -0600
Subject: Adding module causes classloading issues
In-Reply-To: <9366D839-9CD2-487E-9D74-D25596E37B09@gmail.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
 <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
 <5A1CBEA0.9030300@oracle.com>
 <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com> <5A1CC349.30401@oracle.com>
 <035ffe35-67ae-da8e-1dd0-fe591784bd81@oracle.com>
 <7F1291A3-3842-4AD9-B88E-B34298776D4F@gmail.com>
 <ee28ac82-1fbb-8d36-ce33-c3ee67c130f8@oracle.com>
 <9366D839-9CD2-487E-9D74-D25596E37B09@gmail.com>
Message-ID: <4E365FE2-93EA-4A6E-91F2-4002206E9159@gmail.com>


> On Nov 28, 2017, at 4:11 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Unless it does relate to current problems. I haven?t had a chance to test JMX again yet. 

That does seem to work. So java.corba was a answer there if not the best.

js> jmxAttach('994')
local service:jmx:rmi://127.0.0.1/stub/rO0ABXN9AAAAAQAlamF2YXgubWFuYWdlbWVudC5yZW1vdGUucm1pLlJNSVNlcnZlcnhyABdqYXZhLmxhbmcucmVmbGVjdC5Qcm94eeEn2iDMEEPLAgABTAABaHQAJUxqYXZhL2xhbmcvcmVmbGVjdC9JbnZvY2F0aW9uSGFuZGxlcjt4cHNyAC1qYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN0SW52b2NhdGlvbkhhbmRsZXIAAAAAAAAAAgIAAHhyABxqYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN002G0kQxhMx4DAAB4cHc4AAtVbmljYXN0UmVmMgAADTE5Mi4xNjguMS4xMDcAAMN5yW1cOzyQxCai3JwsAAABYATKoHeAAQB4
addr service:jmx:rmi://127.0.0.1/stub/rO0ABXN9AAAAAQAlamF2YXgubWFuYWdlbWVudC5yZW1vdGUucm1pLlJNSVNlcnZlcnhyABdqYXZhLmxhbmcucmVmbGVjdC5Qcm94eeEn2iDMEEPLAgABTAABaHQAJUxqYXZhL2xhbmcvcmVmbGVjdC9JbnZvY2F0aW9uSGFuZGxlcjt4cHNyAC1qYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN0SW52b2NhdGlvbkhhbmRsZXIAAAAAAAAAAgIAAHhyABxqYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN002G0kQxhMx4DAAB4cHc4AAtVbmljYXN0UmVmMgAADTE5Mi4xNjguMS4xMDcAAMN5yW1cOzyQxCai3JwsAAABYATKoHeAAQB4
Url service:jmx:rmi://127.0.0.1/stub/rO0ABXN9AAAAAQAlamF2YXgubWFuYWdlbWVudC5yZW1vdGUucm1pLlJNSVNlcnZlcnhyABdqYXZhLmxhbmcucmVmbGVjdC5Qcm94eeEn2iDMEEPLAgABTAABaHQAJUxqYXZhL2xhbmcvcmVmbGVjdC9JbnZvY2F0aW9uSGFuZGxlcjt4cHNyAC1qYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN0SW52b2NhdGlvbkhhbmRsZXIAAAAAAAAAAgIAAHhyABxqYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN002G0kQxhMx4DAAB4cHc4AAtVbmljYXN0UmVmMgAADTE5Mi4xNjguMS4xMDcAAMN5yW1cOzyQxCai3JwsAAABYATKoHeAAQB4

Shows how I kept coming up with the same url. But now it?s not saying that rmi isn?t a valid protocol. So I can again script JMX with javascript.

Yet again. Thanks.



From Alan.Bateman at oracle.com  Wed Nov 29 08:23:44 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Nov 2017 08:23:44 +0000
Subject: Adding module causes classloading issues
In-Reply-To: <9366D839-9CD2-487E-9D74-D25596E37B09@gmail.com>
References: <CE5432F1-A514-40A8-ADC1-79D273975F1F@gmail.com>
 <5A1CB08F.1000505@oracle.com>
 <918C50C3-86EF-4A87-B300-112C431A9718@gmail.com>
 <5A1CB89C.2060305@oracle.com>
 <6C02DDE5-133F-4F93-B17B-1F6920B365CC@gmail.com>
 <5A1CBEA0.9030300@oracle.com>
 <DC91FF4A-E4A1-49E7-A55D-1AE226057C49@gmail.com> <5A1CC349.30401@oracle.com>
 <035ffe35-67ae-da8e-1dd0-fe591784bd81@oracle.com>
 <7F1291A3-3842-4AD9-B88E-B34298776D4F@gmail.com>
 <ee28ac82-1fbb-8d36-ce33-c3ee67c130f8@oracle.com>
 <9366D839-9CD2-487E-9D74-D25596E37B09@gmail.com>
Message-ID: <6d230f35-d38e-033b-399e-b6066ee1b722@oracle.com>



On 28/11/2017 22:11, Michael Hall wrote:
>
>> On Nov 28, 2017, at 4:48 AM, Alan Bateman <Alan.Bateman at oracle.com 
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>> javax.rmi.PortableRemoteObject
>
> It does include PortableRemoteObject.
and this probably has references to classes in org.omg.CORBA and 
javax.rmi.CORBA. This will explain why jdeps reports a dependency on the 
java.corba module.

-Alan

From gregw at webtide.com  Wed Nov 29 09:33:39 2017
From: gregw at webtide.com (Greg Wilkins)
Date: Wed, 29 Nov 2017 10:33:39 +0100
Subject: Scanning Modules(take 2)?
Message-ID: <CAAPGdfGs=Rr+-vBbVxnuns85yOPLQVzNBMn+w6_3gO=iX5oadA@mail.gmail.com>

Back in September I asked a couple of questions about scanning modules (for
annotated classes):

http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-September/013178.html

Thanks for the answers, which have been helpful, but now a supplementary
question/suggestion.

Given that many java technologies (not just EE) need to scan jars for
annotated classes, is it possible for this to be a semantic provided by the
module system?  Currently multiple  java frameworks are implementing code
that asks for lists of modules, then lists of classes within those modules,
then finding the raw bytes of those classes and passing them to something
like ASM to determine how they are annotated in order to drive their
configuration.  This code can be rather complex and probably fragile when
you consider issues like:

   - multi release jars (specially as sometimes one JVM might need to
   process meta data to be deployed on a different java platform)
   - classpath vs module path vs upgrade paths etc
   - observable vs resolved vs platform modules
   - layers
   - jlink


Currently frameworks are having to reimplement much of the logic to
determine exactly what classes a JVM will resolve for a given environment.
The chances are low of every frameworks getting this right and doing so in
a way that is future proof as these features evolve through java 9, 10, 11.

So perhaps it would be a good idea for the library to provide some
semantics to assist frameworks to get this right?  Ideally there would be
an API to allow frameworks to query the JVM about what classes (which may
not be loaded and may even be for a different target platform) it can see
that are annotated in a particular way.

thoughts?


-- 
Greg Wilkins <gregw at webtide.com> CTO http://webtide.com

From Alan.Bateman at oracle.com  Wed Nov 29 10:01:58 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Nov 2017 10:01:58 +0000
Subject: Scanning Modules(take 2)?
In-Reply-To: <CAAPGdfGs=Rr+-vBbVxnuns85yOPLQVzNBMn+w6_3gO=iX5oadA@mail.gmail.com>
References: <CAAPGdfGs=Rr+-vBbVxnuns85yOPLQVzNBMn+w6_3gO=iX5oadA@mail.gmail.com>
Message-ID: <a49d0833-a072-6590-914e-5a22eded4c47@oracle.com>

On 29/11/2017 09:33, Greg Wilkins wrote:
> :
>
> So perhaps it would be a good idea for the library to provide some
> semantics to assist frameworks to get this right?  Ideally there would be
> an API to allow frameworks to query the JVM about what classes (which may
> not be loaded and may even be for a different target platform) it can see
> that are annotated in a particular way.
>
This was listed in the JSR 376 requirements document [1] but it didn't 
happen in Java SE 9. There were suggestions at the time to generate an 
index at packaging time. There were also suggestions (and some initial 
prototyping with a jlink plugin) to index at link time. I don't think 
the efforts got as far as thinking about an API.

So yes, it is an area where there is interest but I'm not aware of 
anyone working on it just now. If you or others have cycles to create a 
library and explore the area then it could be useful.

-Alan

[1] 
http://openjdk.java.net/projects/jigsaw/spec/reqs/#efficient-annotation-detection 


From blackdrag at gmx.org  Wed Nov 29 10:27:26 2017
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Wed, 29 Nov 2017 11:27:26 +0100
Subject: Should we create a compiler independent module tool?
Message-ID: <210a093a-9b18-aa74-c5b9-9e1d29a48faf@gmx.org>

Hi all,

I am wondering for quite a while already if there should not be an javac 
(and possibly jdk9) independent tool for handling module. I think the 
idea for such a tool would be a bit against several decision that have 
been taken by the jigsaw project, so bare with me, I am trying to be 
constructive here not trolling ;)

What such a tool could do:
* after compiling sources you can add module information
* let the tool check for module access rules
* read and extract module information from multi release jars
* allow alternative compiler to be "enhanced" with jdk9 module creation 
capabilities.. for example joint compilers
* let any build tool use the normal classpath logic to add module 
information in a later step
* being independent of the JDK means (and only on ASM6) to able to use 
JDK7 or 8 and still to be able to produce a module, if no JDK9 specific 
actions are to be taken
* provide a base for other tools for things missing in JDK9, like the 
proper handling of information extraction from multirelease jars (see 
'Scanning Modules(take 2)?' on this list)
* we can have some JDK10 functions in JDK9

If there is interest to create such a tool with a nice license (Apache 2 
for example) I would be happy to try to channel efforts and help 
creating this. I may end up doing this by myself, but then it is likely 
to be used only by my projects and I think it would be a shame not to 
have this wider spread and more people involved.

bye Jochen

From gregw at webtide.com  Wed Nov 29 12:17:16 2017
From: gregw at webtide.com (Greg Wilkins)
Date: Wed, 29 Nov 2017 13:17:16 +0100
Subject: Scanning Modules(take 2)?
In-Reply-To: <a49d0833-a072-6590-914e-5a22eded4c47@oracle.com>
References: <CAAPGdfGs=Rr+-vBbVxnuns85yOPLQVzNBMn+w6_3gO=iX5oadA@mail.gmail.com>
 <a49d0833-a072-6590-914e-5a22eded4c47@oracle.com>
Message-ID: <CAAPGdfGK4K6G1QuaV6JTtm3q4TK47Hf5nAMFD+oU5ByZWyFK2A@mail.gmail.com>

Alan,

good to know that there is at least interest and intent to help out with
this complex task.

Not so sure we have a lot of cycles,  but the eclipse jetty project is
already burning cycles now to implement, so in the long run it may be
better to put in a few more cycles to make this logic generally accepted.

I'm wondering if perhaps I should suggest as a new project within the
eclipse EE4J effort, as that will capture interest, expertise and cycles
from several frameworks that could benefit.   If successful, it might then
live there long term, but I think contribution to a future java platform
would be a better home for it as it would benefit from being part of future
considerations.

Unless anybody has a better suggestion of where such an effort could be
coordinated, I'll take this suggestion to eclipse EE4J.

cheers




On 29 November 2017 at 11:01, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 29/11/2017 09:33, Greg Wilkins wrote:
>
>> :
>>
>> So perhaps it would be a good idea for the library to provide some
>> semantics to assist frameworks to get this right?  Ideally there would be
>> an API to allow frameworks to query the JVM about what classes (which may
>> not be loaded and may even be for a different target platform) it can see
>> that are annotated in a particular way.
>>
>> This was listed in the JSR 376 requirements document [1] but it didn't
> happen in Java SE 9. There were suggestions at the time to generate an
> index at packaging time. There were also suggestions (and some initial
> prototyping with a jlink plugin) to index at link time. I don't think the
> efforts got as far as thinking about an API.
>
> So yes, it is an area where there is interest but I'm not aware of anyone
> working on it just now. If you or others have cycles to create a library
> and explore the area then it could be useful.
>
> -Alan
>
> [1] http://openjdk.java.net/projects/jigsaw/spec/reqs/#efficient
> -annotation-detection
>



-- 
Greg Wilkins <gregw at webtide.com> CTO http://webtide.com