From sgehwolf at redhat.com  Wed Jan  2 09:24:22 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 02 Jan 2019 10:24:22 +0100
Subject: [Proposal] jlink plugin which replaces dynamic shared libraries
In-Reply-To: <39bdc749-1d05-78d5-2417-7b31ee784034@oracle.com>
References: <4c46f7175ae671eee935a872f46cdbf819b43e6a.camel@redhat.com>
 <5d1dadeb-e0d8-3716-caa5-224cc6abcf81@oracle.com>
 <49e549c5c424e933c5e9a8331347daa8ed7d9507.camel@redhat.com>
 <b67c6c86-cf6c-773d-e82e-368b6886e81c@oracle.com>
 <c11a068bd2c2d9493c234ba03d97f18a2ba55cf3.camel@redhat.com>
 <0a503657799d539d54eecca6265911ca8320ed04.camel@redhat.com>
 <1b395bc1-ca6c-6aa7-c5c0-1ef7c30440a9@oracle.com>
 <86fca51b35d26b88e7705b54b262700e60a7d5f8.camel@redhat.com>
 <542334ad-44de-9d2d-8512-56865603625e@oracle.com>
 <39bdc749-1d05-78d5-2417-7b31ee784034@oracle.com>
Message-ID: <76636680bfb5a44c0fe5849663998cdf982ab729.camel@redhat.com>

On Mon, 2018-12-31 at 07:33 +0000, Alan Bateman wrote:
> On 21/12/2018 18:21, Mandy Chung wrote:
> > I also like this, stripping the native debug symbols, as a jlink plugin.
> > 
> > Currently jlink does not support platform-specific plugin.   The 
> > Plugin API will need
> > to be extended to specific the supported platforms, for example 
> > Plugin::isSupported
> > and default to return true.   jlink will need to filter the plugins 
> > when it finds the plugin
> > providers.   You can update PluginRepository to do the filtering and 
> > see if that covers
> > all cases (I suspect so).
> 
> It might be simpler to move the plugin to src/jdk.jlink/linux/classes 
> and create a module-info.java.extra to augment the module-info.java file 
> in the build. If that works then it would reduce the build work to 
> augmenting plugin.properties at build time with platform specific resources.

Thanks, Mandy and Alan for the input. I'll have a look and get back to
you.

Cheers,
Severin


From kasperni at gmail.com  Mon Jan 14 12:26:45 2019
From: kasperni at gmail.com (Kasper Nielsen)
Date: Mon, 14 Jan 2019 12:26:45 +0000
Subject: Missing a wildcard open statement
Message-ID: <CAPs6152_YbejAzr6aZuVkqi6RM-SJY3qV=5n4C6PKN_x+_P+Lg@mail.gmail.com>

Hi,

Having worked with the module system for some time now. There is one
situation I've started coming across a number of times now, that requires a
lot of boiler plate.
Opening every package of a module to another module. For example, for
dependency injection, code analysis, ect.
Basically you have 2 choices now.
* Opening it to every possible module, via open <Module> which you rarely
want
* For each package in your module add an opens <Package> to <OtherModule>

The last option is fine if you have a couple of packages, but when you have
many packages it starts to be a bit of a work.
And since I (and most people) are lazy, they are just going to go with the
first option, opening the whole module unqualified.

What I am missing is a "open all packages to this module" option ("opens *
to mod1, mod2")
This could be implemented, for example, by adding simply by making the
package statement in opens <Package> to <OtherModule> optionally (maybe
there are some corner cases so it would'nt work syntactically).
Or maybe by adding an openallto <OtherModules> statement.
Implementation wise, it would just enumerate all packages and add a
qualified open statement for each of them. So no changes would be required
at runtime.

Anyone else had the same experience?

/Kasper

From Alan.Bateman at oracle.com  Mon Jan 14 14:36:10 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 14 Jan 2019 14:36:10 +0000
Subject: Missing a wildcard open statement
In-Reply-To: <CAPs6152_YbejAzr6aZuVkqi6RM-SJY3qV=5n4C6PKN_x+_P+Lg@mail.gmail.com>
References: <CAPs6152_YbejAzr6aZuVkqi6RM-SJY3qV=5n4C6PKN_x+_P+Lg@mail.gmail.com>
Message-ID: <fc681138-f756-db88-380b-2b5984e4052a@oracle.com>

On 14/01/2019 12:26, Kasper Nielsen wrote:
> Hi,
>
> Having worked with the module system for some time now. There is one
> situation I've started coming across a number of times now, that requires a
> lot of boiler plate.
> Opening every package of a module to another module. For example, for
> dependency injection,
This is the type of use-case where using Lookup objects might be a 
better choice. If you can coerce the user module to pass a suitably 
privileged Lookup to the framework then the framework will be able to 
inject classes without needing to open packages to the framework. I 
think this is an area where we need framework maintainers to do more 
exploration.

-Alan

From kasperni at gmail.com  Mon Jan 14 16:18:59 2019
From: kasperni at gmail.com (Kasper Nielsen)
Date: Mon, 14 Jan 2019 16:18:59 +0000
Subject: Missing a wildcard open statement
In-Reply-To: <fc681138-f756-db88-380b-2b5984e4052a@oracle.com>
References: <CAPs6152_YbejAzr6aZuVkqi6RM-SJY3qV=5n4C6PKN_x+_P+Lg@mail.gmail.com>
 <fc681138-f756-db88-380b-2b5984e4052a@oracle.com>
Message-ID: <CAPs6153wwkG+kL-3M=qYn_c9KWLUnZdVZB5K6W0oXWYa_cE5bw@mail.gmail.com>

>
> This is the type of use-case where using Lookup objects might be a
> better choice. If you can coerce the user module to pass a suitably
> privileged Lookup to the framework then the framework will be able to
> inject classes without needing to open packages to the framework. I
> think this is an area where we need framework maintainers to do more
> exploration.
>

Yes, but we have found this to be equally tedious when you are trying to
aggregate multiple modules.
Because every module has to supply their own Lookup object.

So you need some kind of bootstrap class in every module that registers
their Lookup object somehow. And, you also have to make sure that the
bootstrap class does not make the Lookup object available to someone who
should not have access to it. This is solvable, for example, by using a
ServiceLoader.

But now, you also have X number of Lookup objects you need to keep track
of. And then someone gets the idea that you need an extension
hierarchy that crosses module boundaries. So you end up with needing one
Lookup object for one method on an object and another Lookup object on
another method on the object. Because the first method is on an abstract
class located in another modul.

In the end it might just be simpler to add an open statement for every
package in your module-info. At least for some use cases.

/Kasper

From blackdrag at gmx.org  Tue Jan 15 06:57:14 2019
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Tue, 15 Jan 2019 07:57:14 +0100
Subject: Missing a wildcard open statement
In-Reply-To: <CAPs6153wwkG+kL-3M=qYn_c9KWLUnZdVZB5K6W0oXWYa_cE5bw@mail.gmail.com>
References: <CAPs6152_YbejAzr6aZuVkqi6RM-SJY3qV=5n4C6PKN_x+_P+Lg@mail.gmail.com>
 <fc681138-f756-db88-380b-2b5984e4052a@oracle.com>
 <CAPs6153wwkG+kL-3M=qYn_c9KWLUnZdVZB5K6W0oXWYa_cE5bw@mail.gmail.com>
Message-ID: <95d44a24-b411-5064-df07-f483cc7e0b43@gmx.org>

On 14.01.19 17:18, Kasper Nielsen wrote:
[...]
> So you need some kind of bootstrap class in every module that registers
> their Lookup object somehow. And, you also have to make sure that the
> bootstrap class does not make the Lookup object available to someone who
> should not have access to it. This is solvable, for example, by using a
> ServiceLoader.
> 
> But now, you also have X number of Lookup objects you need to keep track
> of. And then someone gets the idea that you need an extension
> hierarchy that crosses module boundaries. So you end up with needing one
> Lookup object for one method on an object and another Lookup object on
> another method on the object. Because the first method is on an abstract
> class located in another modul.

Maybe I understood something wrong, but assuming

Module A
public abstract class A {
   public abstract void foo();
}

Module B (reads A)
public class B extends A {
   public void foo(){}
   public void bar(){}
}

then in Module C to call bar on an instance of B I need a Lookup object 
with the correct rights for B. But I can use the same Lookup object to 
call foo on an instance of B.

If B does not read A when loading the class B I would actually expect 
the module system to deny loading the class... never tested that though. 
Is that not the case?

> In the end it might just be simpler to add an open statement for every
> package in your module-info. At least for some use cases.

For many cases in which you have to load things dynamically. If not, you 
can figure out these things statically and patch the modules to have the 
right settings, which means to make a tailored module loading in the end.

bye Jochen

From Alan.Bateman at oracle.com  Tue Jan 15 07:48:23 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 15 Jan 2019 07:48:23 +0000
Subject: Missing a wildcard open statement
In-Reply-To: <CAPs6153wwkG+kL-3M=qYn_c9KWLUnZdVZB5K6W0oXWYa_cE5bw@mail.gmail.com>
References: <CAPs6152_YbejAzr6aZuVkqi6RM-SJY3qV=5n4C6PKN_x+_P+Lg@mail.gmail.com>
 <fc681138-f756-db88-380b-2b5984e4052a@oracle.com>
 <CAPs6153wwkG+kL-3M=qYn_c9KWLUnZdVZB5K6W0oXWYa_cE5bw@mail.gmail.com>
Message-ID: <8b4e6e00-226f-69d0-eca1-5138aa061901@oracle.com>

On 14/01/2019 16:18, Kasper Nielsen wrote:
> Yes, but we have found this to be equally tedious when you are trying 
> to aggregate multiple modules.
> Because every module has to supply their own Lookup object.
>
> So you need some kind of bootstrap class in every module that 
> registers their Lookup object somehow. And, you also have to make sure 
> that the bootstrap class does not make the Lookup object available to 
> someone who should not have access to it. This is solvable, for 
> example, by using a ServiceLoader.
>
> But now, you also have X number of Lookup objects you need to keep 
> track of. And then someone gets the idea that you need an extension 
> hierarchy?that crosses module boundaries. So you end up with needing 
> one Lookup object for one method on an object and another Lookup 
> object on another method on the object. Because the first method is on 
> an abstract class located in another modul.
>
> In the end it might just be simpler to add an open statement for every 
> package in your module-info. At least for some use cases.
>
Which library or framework is this and is there a write-up of the issues 
encountered when migrating it to use Lookup objects?

-Alan

From kasperni at gmail.com  Wed Jan 16 16:06:49 2019
From: kasperni at gmail.com (Kasper Nielsen)
Date: Wed, 16 Jan 2019 16:06:49 +0000
Subject: Missing a wildcard open statement
In-Reply-To: <8b4e6e00-226f-69d0-eca1-5138aa061901@oracle.com>
References: <CAPs6152_YbejAzr6aZuVkqi6RM-SJY3qV=5n4C6PKN_x+_P+Lg@mail.gmail.com>
 <fc681138-f756-db88-380b-2b5984e4052a@oracle.com>
 <CAPs6153wwkG+kL-3M=qYn_c9KWLUnZdVZB5K6W0oXWYa_cE5bw@mail.gmail.com>
 <8b4e6e00-226f-69d0-eca1-5138aa061901@oracle.com>
Message-ID: <CAPs61507rs=NuNNyObGKfainJCOct4PpY-Zgb52dNmVKf9sgaw@mail.gmail.com>

On Tue, 15 Jan 2019 at 07:48, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> Which library or framework is this and is there a write-up of the issues
> encountered when migrating it to use Lookup objects?
>
> -Alan
>

It is a small dependency injection/application I am trying to built on top
of the module system.
It is not in finished form yet, however, I have made some notes about some
observations I've done.

# Naming / User Friendliness
I know this is to late to change, but I think the Lookup mechanism could
have been designed a bit more user friendly.

Here is a simple method that lets a user construct a new object using
dependency injection. The two parameters are: The type of object that
should be constructed, and a Lookup object that can be used by the
underlying framework for invoking a constructor on the specified type.

import java.lang.invoke.MethodHandles;
public <T> inject(Class<T> type, MethodHandles.Lookup lookup)

Having Lookup defined as a static nested class of MethodHandles kind of
requires you to introduce two topics at the same time. It is quite a bit to
explain if you only have 10 lines for a getting started guide. Especially
since the usage of both of them are more or less unknown to 99% of Java
developers.

I could use this signature
import java.lang.invoke.MethodHandles.Lookup;
public <T> inject(Class<T> type, Lookup lookup)

But unless you know how to acquire a lookup object, it is a bit hard to
figure out you need to look in its parent object to find the method.
Buried, among tons of other methods. I think adding a static method such as
Lookup.of() could make it a bit less painful. Its still a bit difficult to
explain why this is needed without getting to technical. But I hope this
will change if it sees widespread use.

# Single Module
In general, Lookup objects are really easy to work with when you are have a
_single_ module that has a dependency on a library that needs a Lookup
object to be initialized. And you are in full control of initializing the
library.

# Inversion of Control/Container deployment
Here I am thinking about something like how people would normally deploy a
modern servlet WAR; A bunch of annotated classes packaged in a single jar.
Since your code is being initialized by the container you cannot directly
handoff a Lookup object to the container. Instead you need to rely on some
kind of delivery mechanism. For example, by requiring all deployable
bundles to provide a service (that secretly exposes the Lookup object) via
a ServiceLoader to the container. However, this quickly gets complicated
because if you work with something like Jakarte EE, where you have to
provide a standardized mechanism. With which any implementor can get a hold
of the provided lookup object. But at the same time make sure no one else
can read it.

This is an issue with qualified open statements via module-info as well. If
you do not know which implementation you are going to deploy your WAR in.
You cannot use a qualified open statement. So you are left with "open
module", which I suspect will be how things are going to work for a long
time.

Some of these issues might be solvable by using something like Module
layers.

# Multiple Modules
If your application consists of multiple modules. For example, you might
have some customer-services in one module and some order-service in a
another module. Then a third module that kind of glues the two modules
together. You might also have a DI framework, a JPA implementation and a
JaxRS container.

It is a bit of similar problem here, you need to handoff a Lookup object
from customer-services->main module and from order-services->main module.
And then the main module then needs to initialize each library with each of
the Lookup objects for every module.

You also sometimes get into some complex situations where an abstract class
is located in one module, and the concrete class in another module. Each of
them having an annotated method/field that you need to access. So you need
one Lookup object to access the method on the abstract class and another
Lookup object to access the method on the concrete class. Depending on how
you track your Loookup objects, you worst case end of with API's like this
public <T> inject(Class<T> type, MethodHandles.Lookup... lookup) and then
some complex logic to match methods with Lookup objects.

I actually really like working with Lookup objects. However, I think it
potentially could end up with a lot of micro management for larger projects.
And then people are going to be, fine, lets just put open module everywhere.

/Kasper

From andre.tadeu.de.carvalho at gmail.com  Mon Jan 21 12:57:22 2019
From: andre.tadeu.de.carvalho at gmail.com (Andre Tadeu de Carvalho)
Date: Mon, 21 Jan 2019 10:57:22 -0200
Subject: Newbie Jigsaw question: How should I use 'jmod hash'
Message-ID: <CANenTsOJC+ZmrB66baDqeGkoPHS7rQyspnjSL+P4b8wjooRe7w@mail.gmail.com>

Hi,

I am exploring the jmod utility and I am stuck with the following: I
already generated the jmod file and I want to add a hash from the dependent
module in it. I asked the same question in StackOverflow:
https://stackoverflow.com/questions/54269994/how-should-i-use-jmod-hash

What I am doing:

jmod create --class-path target/mods/A target/jmods/A.jmod
jmod create --class-path target/mods/B target/jmods/B.jmod

Where B depends on A. Assuming I understood the documentation right, I
could add B hash into A.jmod. I am trying the following:

jmod hash --hash-module B --module-path target/jmods target/jmods/A.jmod

When I run jmod describe, the hash is still not there. What I am doing
wrong? Can I use jmod hash the way I am using it?

Thanks in advance,

Andr? Tadeu de Carvalho

From Alan.Bateman at oracle.com  Tue Jan 22 12:06:04 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 22 Jan 2019 12:06:04 +0000
Subject: Newbie Jigsaw question: How should I use 'jmod hash'
In-Reply-To: <CANenTsOJC+ZmrB66baDqeGkoPHS7rQyspnjSL+P4b8wjooRe7w@mail.gmail.com>
References: <CANenTsOJC+ZmrB66baDqeGkoPHS7rQyspnjSL+P4b8wjooRe7w@mail.gmail.com>
Message-ID: <9ba6c1e4-3fb5-e695-727b-0bc343e9f8df@oracle.com>

On 21/01/2019 12:57, Andre Tadeu de Carvalho wrote:
> Hi,
>
> I am exploring the jmod utility and I am stuck with the following: I
> already generated the jmod file and I want to add a hash from the dependent
> module in it. I asked the same question in StackOverflow:
> https://stackoverflow.com/questions/54269994/how-should-i-use-jmod-hash
>
> What I am doing:
>
> jmod create --class-path target/mods/A target/jmods/A.jmod
> jmod create --class-path target/mods/B target/jmods/B.jmod
>
> Where B depends on A. Assuming I understood the documentation right, I
> could add B hash into A.jmod. I am trying the following:
>
> jmod hash --hash-module B --module-path target/jmods target/jmods/A.jmod
>
> When I run jmod describe, the hash is still not there. What I am doing
> wrong? Can I use jmod hash the way I am using it?
>
I think you've run a bug with the `hash` option to update an existing 
JMOD file.

Can you change the pattern you specify `--hash-modules .*` and see if 
that works for you? Alternatively, specify the --hash-modules option 
when creating the JMOD.

-Alan.



From andre.tadeu.de.carvalho at gmail.com  Tue Jan 22 12:59:04 2019
From: andre.tadeu.de.carvalho at gmail.com (Andre Tadeu de Carvalho)
Date: Tue, 22 Jan 2019 10:59:04 -0200
Subject: Newbie Jigsaw question: How should I use 'jmod hash'
In-Reply-To: <9ba6c1e4-3fb5-e695-727b-0bc343e9f8df@oracle.com>
References: <CANenTsOJC+ZmrB66baDqeGkoPHS7rQyspnjSL+P4b8wjooRe7w@mail.gmail.com>
 <9ba6c1e4-3fb5-e695-727b-0bc343e9f8df@oracle.com>
Message-ID: <CANenTsPq0V2Gt7YUgW_-==k9dLUA2n4Mi6HZNa3heYbioyCtBg@mail.gmail.com>

Em ter, 22 de jan de 2019 ?s 10:06, Alan Bateman <Alan.Bateman at oracle.com>
escreveu:

> On 21/01/2019 12:57, Andre Tadeu de Carvalho wrote:
> > Hi,
> >
> > I am exploring the jmod utility and I am stuck with the following: I
> > already generated the jmod file and I want to add a hash from the
> dependent
> > module in it. I asked the same question in StackOverflow:
> > https://stackoverflow.com/questions/54269994/how-should-i-use-jmod-hash
> >
> > What I am doing:
> >
> > jmod create --class-path target/mods/A target/jmods/A.jmod
> > jmod create --class-path target/mods/B target/jmods/B.jmod
> >
> > Where B depends on A. Assuming I understood the documentation right, I
> > could add B hash into A.jmod. I am trying the following:
> >
> > jmod hash --hash-module B --module-path target/jmods target/jmods/A.jmod
> >
> > When I run jmod describe, the hash is still not there. What I am doing
> > wrong? Can I use jmod hash the way I am using it?
> >
> I think you've run a bug with the `hash` option to update an existing
> JMOD file.
>
> Can you change the pattern you specify `--hash-modules .*` and see if
> that works for you? Alternatively, specify the --hash-modules option
> when creating the JMOD.
>
> -Alan.
>
>
> Hi Alan!

Thanks for your response. I've tried to use the parameter --hash-modules
with the pattern .*, but it didn't work. For now, I'm already creating the
modules with --hash-modules.
I've no further questions and thank you for your time.

Cheers,

Andr? Tadeu de Carvalho

From mandy.chung at oracle.com  Tue Jan 22 17:45:06 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 22 Jan 2019 09:45:06 -0800
Subject: Newbie Jigsaw question: How should I use 'jmod hash'
In-Reply-To: <CANenTsPq0V2Gt7YUgW_-==k9dLUA2n4Mi6HZNa3heYbioyCtBg@mail.gmail.com>
References: <CANenTsOJC+ZmrB66baDqeGkoPHS7rQyspnjSL+P4b8wjooRe7w@mail.gmail.com>
 <9ba6c1e4-3fb5-e695-727b-0bc343e9f8df@oracle.com>
 <CANenTsPq0V2Gt7YUgW_-==k9dLUA2n4Mi6HZNa3heYbioyCtBg@mail.gmail.com>
Message-ID: <0f223c9b-b574-c8e6-5e09-73d91e7aa864@oracle.com>



On 1/22/19 4:59 AM, Andre Tadeu de Carvalho wrote:
> Em ter, 22 de jan de 2019 ?s 10:06, Alan Bateman <Alan.Bateman at oracle.com>
> escreveu:
>
>> On 21/01/2019 12:57, Andre Tadeu de Carvalho wrote:
>>> Hi,
>>>
>>> I am exploring the jmod utility and I am stuck with the following: I
>>> already generated the jmod file and I want to add a hash from the
>> dependent
>>> module in it. I asked the same question in StackOverflow:
>>> https://stackoverflow.com/questions/54269994/how-should-i-use-jmod-hash
>>>
>>> What I am doing:
>>>
>>> jmod create --class-path target/mods/A target/jmods/A.jmod
>>> jmod create --class-path target/mods/B target/jmods/B.jmod
>>>
>>> Where B depends on A. Assuming I understood the documentation right, I
>>> could add B hash into A.jmod. I am trying the following:
>>>
>>> jmod hash --hash-module B --module-path target/jmods target/jmods/A.jmod
>>>
>>> When I run jmod describe, the hash is still not there. What I am doing
>>> wrong? Can I use jmod hash the way I am using it?
>>>
>> I think you've run a bug with the `hash` option to update an existing
>> JMOD file.
>>
>> Can you change the pattern you specify `--hash-modules .*` and see if
>> that works for you? Alternatively, specify the --hash-modules option
>> when creating the JMOD.
>>
>> -Alan.
>>
>>
>> Hi Alan!
> Thanks for your response. I've tried to use the parameter --hash-modules
> with the pattern .*, but it didn't work. For now, I'm already creating the
> modules with --hash-modules.
> I've no further questions and thank you for your time.
>

I created an issue to track this jmod hash command bug.? jmod create 
--hash-module works.
 ? https://bugs.openjdk.java.net/browse/JDK-8217527

I think jmod hash --hash-module "A|B" would be another workaround.

Mandy

From andre.tadeu.de.carvalho at gmail.com  Wed Jan 23 20:13:32 2019
From: andre.tadeu.de.carvalho at gmail.com (Andre Tadeu de Carvalho)
Date: Wed, 23 Jan 2019 18:13:32 -0200
Subject: Newbie Jigsaw question: How should I use 'jmod hash'
In-Reply-To: <0f223c9b-b574-c8e6-5e09-73d91e7aa864@oracle.com>
References: <CANenTsOJC+ZmrB66baDqeGkoPHS7rQyspnjSL+P4b8wjooRe7w@mail.gmail.com>
 <9ba6c1e4-3fb5-e695-727b-0bc343e9f8df@oracle.com>
 <CANenTsPq0V2Gt7YUgW_-==k9dLUA2n4Mi6HZNa3heYbioyCtBg@mail.gmail.com>
 <0f223c9b-b574-c8e6-5e09-73d91e7aa864@oracle.com>
Message-ID: <CANenTsNgGc_1TPoOBmO=nGjgCx5J_4ZpiS-Ks4sPmx-RSVbM5Q@mail.gmail.com>

I'm using Ubuntu 18.04 LTS, JDK 11.0.2-open, and bash. I discovered that
jmod --hash-modules "A|B" does not work, but jmod --hash-modules ".*" do
work.

Thanks,

Andr? Tadeu de Carvalho


Em ter, 22 de jan de 2019 ?s 15:44, Mandy Chung <mandy.chung at oracle.com>
escreveu:

>
>
> On 1/22/19 4:59 AM, Andre Tadeu de Carvalho wrote:
>
> Em ter, 22 de jan de 2019 ?s 10:06, Alan Bateman <Alan.Bateman at oracle.com> <Alan.Bateman at oracle.com>
> escreveu:
>
>
> On 21/01/2019 12:57, Andre Tadeu de Carvalho wrote:
>
> Hi,
>
> I am exploring the jmod utility and I am stuck with the following: I
> already generated the jmod file and I want to add a hash from the
>
> dependent
>
> module in it. I asked the same question in StackOverflow:https://stackoverflow.com/questions/54269994/how-should-i-use-jmod-hash
>
> What I am doing:
>
> jmod create --class-path target/mods/A target/jmods/A.jmod
> jmod create --class-path target/mods/B target/jmods/B.jmod
>
> Where B depends on A. Assuming I understood the documentation right, I
> could add B hash into A.jmod. I am trying the following:
>
> jmod hash --hash-module B --module-path target/jmods target/jmods/A.jmod
>
> When I run jmod describe, the hash is still not there. What I am doing
> wrong? Can I use jmod hash the way I am using it?
>
>
> I think you've run a bug with the `hash` option to update an existing
> JMOD file.
>
> Can you change the pattern you specify `--hash-modules .*` and see if
> that works for you? Alternatively, specify the --hash-modules option
> when creating the JMOD.
>
> -Alan.
>
>
> Hi Alan!
>
> Thanks for your response. I've tried to use the parameter --hash-modules
> with the pattern .*, but it didn't work. For now, I'm already creating the
> modules with --hash-modules.
> I've no further questions and thank you for your time.
>
>
>
> I created an issue to track this jmod hash command bug.  jmod create
> --hash-module works.
>   https://bugs.openjdk.java.net/browse/JDK-8217527
>
> I think jmod hash --hash-module "A|B" would be another workaround.
>
> Mandy
>

From Alan.Bateman at oracle.com  Sun Jan 27 08:14:33 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 27 Jan 2019 08:14:33 +0000
Subject: Help with build changes for: 8214796: Create a jlink plugin for
 stripping debug info symbols from native libraries
In-Reply-To: <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com>
References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com>
 <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com>
Message-ID: <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com>

On 26/01/2019 00:06, Mandy Chung wrote:
> Hi Severin,
>
> Another alternative would be to support per-jlink-plugin resource
> bundle to avoid merging .properties files at build time.? The
> plugin-specific messages should only be used by the plugin itself
> and it would be cleaner for each plugin to manage its resource bundle.
That seems a cleaner idea than the suggestion we had on jigsaw-dev to 
merge the properties. If Severin does this for this plugin then I assume 
the resources for the other plugins could be moved to their own resource 
files in their own time.

I skimmed the current patch and I see the usability has improved since 
the original proposal. It would be nice to get to 
`--strip-native-debug-symbols` without needing the "=defaults" suffix.? 
There are details around the sub-options and naming that I assume will 
need detailed review at some point too.

The current patch doesn't include any tests but I assume they will come 
in time.

There's probably a cleanup in StripNativeDebugSymbolsPlugin.java needed 
too to make it easier to maintain and review going forward but that is 
not important now, I think the main thing is to get past the issue of 
being the first plugin that is platform specific.

-Alan.

From sgehwolf at redhat.com  Mon Jan 28 09:26:39 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 28 Jan 2019 10:26:39 +0100
Subject: Help with build changes for: 8214796: Create a jlink plugin for
 stripping debug info symbols from native libraries
In-Reply-To: <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com>
References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com>
 <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com>
 <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com>
Message-ID: <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com>

Hi Alan, Mandy,

On Sun, 2019-01-27 at 08:14 +0000, Alan Bateman wrote:
> On 26/01/2019 00:06, Mandy Chung wrote:
> > Hi Severin,
> > 
> > Another alternative would be to support per-jlink-plugin resource
> > bundle to avoid merging .properties files at build time.  The
> > plugin-specific messages should only be used by the plugin itself
> > and it would be cleaner for each plugin to manage its resource bundle.
> 
> That seems a cleaner idea than the suggestion we had on jigsaw-dev to 
> merge the properties. If Severin does this for this plugin then I assume 
> the resources for the other plugins could be moved to their own resource 
> files in their own time.

Alright. I'll try this then.

> I skimmed the current patch and I see the usability has improved since 
> the original proposal. It would be nice to get to 
> `--strip-native-debug-symbols` without needing the "=defaults" suffix.  
> There are details around the sub-options and naming that I assume will 
> need detailed review at some point too.

This sounds like a different patch to me, I'll investigate.

> The current patch doesn't include any tests but I assume they will come 
> in time.

Sure.

Thanks,
Severin

> There's probably a cleanup in StripNativeDebugSymbolsPlugin.java needed 
> too to make it easier to maintain and review going forward but that is 
> not important now, I think the main thing is to get past the issue of 
> being the first plugin that is platform specific.
> 
> -Alan.


From Alan.Bateman at oracle.com  Mon Jan 28 14:40:44 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 28 Jan 2019 14:40:44 +0000
Subject: Help with build changes for: 8214796: Create a jlink plugin for
 stripping debug info symbols from native libraries
In-Reply-To: <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com>
References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com>
 <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com>
 <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com>
 <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com>
Message-ID: <7c42f18f-0bc7-7310-9a64-f08e6f305b9e@oracle.com>

On 28/01/2019 09:26, Severin Gehwolf wrote:
> :
>> I skimmed the current patch and I see the usability has improved since
>> the original proposal. It would be nice to get to
>> `--strip-native-debug-symbols` without needing the "=defaults" suffix.
>> There are details around the sub-options and naming that I assume will
>> need detailed review at some point too.
> This sounds like a different patch to me, I'll investigate.
>
If the common case is to not require any complicated options then 
`--strip-native-debug-symbols` would be nice and would be consistent 
with the existing `--strip-XXXX` options. The cross targeting case, or 
cases where debuginfo options are need, would of course mean a more 
complicated command.

-Alan

From sgehwolf at redhat.com  Mon Jan 28 14:54:47 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 28 Jan 2019 15:54:47 +0100
Subject: Help with build changes for: 8214796: Create a jlink plugin for
 stripping debug info symbols from native libraries
In-Reply-To: <7c42f18f-0bc7-7310-9a64-f08e6f305b9e@oracle.com>
References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com>
 <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com>
 <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com>
 <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com>
 <7c42f18f-0bc7-7310-9a64-f08e6f305b9e@oracle.com>
Message-ID: <58ea39e2849ed3d270a9373d49f75eb75cb57f59.camel@redhat.com>

On Mon, 2019-01-28 at 14:40 +0000, Alan Bateman wrote:
> On 28/01/2019 09:26, Severin Gehwolf wrote:
> > :
> > > I skimmed the current patch and I see the usability has improved since
> > > the original proposal. It would be nice to get to
> > > `--strip-native-debug-symbols` without needing the "=defaults" suffix.
> > > There are details around the sub-options and naming that I assume will
> > > need detailed review at some point too.
> > 
> > This sounds like a different patch to me, I'll investigate.
> > 
> 
> If the common case is to not require any complicated options then 
> `--strip-native-debug-symbols` would be nice and would be consistent 
> with the existing `--strip-XXXX` options. The cross targeting case, or 
> cases where debuginfo options are need, would of course mean a more 
> complicated command.

Yes, but I was referring to the current state of the jlink plugin
system. AFAIK, there is two --strip-XXX plugins:
StripNativeCommandsPlugin and StripDebugPlugin. Both of these have
hasArguments() == false. This new one has hasArguments() == true. Then
the plugin system wants at least 1 argument.

What has to be implemented first is a way for a plugin to allow both:
no-args *and* 1+ args. Currently it's 1+ args XOR 0 args. This
functionality doesn't seem related to this particular patch but would
be generic.

Thanks,
Severin


From sgehwolf at redhat.com  Mon Jan 28 15:00:36 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 28 Jan 2019 16:00:36 +0100
Subject: RFR: 8217877: Dead code in jdk.jlink's TaskHelper
Message-ID: <380a886767b3a6ff59d37ed65d70cc9e98022a83.camel@redhat.com>

Hi,

There seems to be dead code in class TaskHelper. Plugins are loaded via
ServiceLoader from the module boot loader. I don't see how this code
could ever be reached. The proposal is to remove it for clarity.

Bug: https://bugs.openjdk.java.net/browse/JDK-8217877
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217877/webrev.01/

Testing: jdk/submit + test/jdk/tools/jlink and test/jdk/jdk/modules
tests on Linux x86_64

Thoughts?

Thanks,
Severin


From Alan.Bateman at oracle.com  Mon Jan 28 19:01:15 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 28 Jan 2019 19:01:15 +0000
Subject: RFR: 8217877: Dead code in jdk.jlink's TaskHelper
In-Reply-To: <380a886767b3a6ff59d37ed65d70cc9e98022a83.camel@redhat.com>
References: <380a886767b3a6ff59d37ed65d70cc9e98022a83.camel@redhat.com>
Message-ID: <6e34aaee-86f1-1986-68a7-41eefc675c30@oracle.com>

On 28/01/2019 15:00, Severin Gehwolf wrote:
> Hi,
>
> There seems to be dead code in class TaskHelper. Plugins are loaded via
> ServiceLoader from the module boot loader. I don't see how this code
> could ever be reached. The proposal is to remove it for clarity.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8217877
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217877/webrev.01/
>
This code was used in JDK 9 for the experimental plugin interface, it 
was disabled near the end of the release. So I think it's okay to remove 
this code, meaning your patch looks okay, but it might of course come 
back when that plugin interface is looked at again.

-Alan

From mandy.chung at oracle.com  Mon Jan 28 19:16:45 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 28 Jan 2019 11:16:45 -0800
Subject: RFR: 8217877: Dead code in jdk.jlink's TaskHelper
In-Reply-To: <6e34aaee-86f1-1986-68a7-41eefc675c30@oracle.com>
References: <380a886767b3a6ff59d37ed65d70cc9e98022a83.camel@redhat.com>
 <6e34aaee-86f1-1986-68a7-41eefc675c30@oracle.com>
Message-ID: <b453eee2-9193-03c5-893b-f7573f194dc2@oracle.com>



On 1/28/19 11:01 AM, Alan Bateman wrote:
> On 28/01/2019 15:00, Severin Gehwolf wrote:
>> Hi,
>>
>> There seems to be dead code in class TaskHelper. Plugins are loaded via
>> ServiceLoader from the module boot loader. I don't see how this code
>> could ever be reached. The proposal is to remove it for clarity.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217877
>> webrev: 
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217877/webrev.01/
>>
> This code was used in JDK 9 for the experimental plugin interface, it 
> was disabled near the end of the release. So I think it's okay to 
> remove this code, meaning your patch looks okay, but it might of 
> course come back when that plugin interface is looked at again.

Removing this unused code is okay to me.

Mandy

From sgehwolf at redhat.com  Mon Jan 28 19:26:49 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 28 Jan 2019 20:26:49 +0100
Subject: RFR: 8217877: Dead code in jdk.jlink's TaskHelper
In-Reply-To: <b453eee2-9193-03c5-893b-f7573f194dc2@oracle.com>
References: <380a886767b3a6ff59d37ed65d70cc9e98022a83.camel@redhat.com>
 <6e34aaee-86f1-1986-68a7-41eefc675c30@oracle.com>
 <b453eee2-9193-03c5-893b-f7573f194dc2@oracle.com>
Message-ID: <a46e89464abc611f8a3fa19e8c41cd138e54ae57.camel@redhat.com>

On Mon, 2019-01-28 at 11:16 -0800, Mandy Chung wrote:
> 
> 
> On 1/28/19 11:01 AM, Alan Bateman wrote:
> > On 28/01/2019 15:00, Severin Gehwolf wrote: 
> > > Hi, 
> > > 
> > > There seems to be dead code in class TaskHelper. Plugins are loaded via 
> > > ServiceLoader from the module boot loader. I don't see how this code 
> > > could ever be reached. The proposal is to remove it for clarity. 
> > > 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217877 
> > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217877/webrev.01/ 
> > > 
> >  This code was used in JDK 9 for the experimental plugin interface,
> > it was disabled near the end of the release. So I think it's okay
> > to remove this code, meaning your patch looks okay, but it might of
> > course come back when that plugin interface is looked at again. 
>  
> Removing this unused code is okay to me.

Thanks for the reviews, Alan, Mandy!

Cheers,
Severin


From mandy.chung at oracle.com  Mon Jan 28 21:02:33 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 28 Jan 2019 13:02:33 -0800
Subject: Help with build changes for: 8214796: Create a jlink plugin for
 stripping debug info symbols from native libraries
In-Reply-To: <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com>
References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com>
 <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com>
 <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com>
 <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com>
Message-ID: <fb58ec4f-171f-35e5-9631-09194d488b0e@oracle.com>



On 1/28/19 1:26 AM, Severin Gehwolf wrote:
> Hi Alan, Mandy,
>
> On Sun, 2019-01-27 at 08:14 +0000, Alan Bateman wrote:
>> On 26/01/2019 00:06, Mandy Chung wrote:
>>> Hi Severin,
>>>
>>> Another alternative would be to support per-jlink-plugin resource
>>> bundle to avoid merging .properties files at build time.  The
>>> plugin-specific messages should only be used by the plugin itself
>>> and it would be cleaner for each plugin to manage its resource bundle.
>> That seems a cleaner idea than the suggestion we had on jigsaw-dev to
>> merge the properties. If Severin does this for this plugin then I assume
>> the resources for the other plugins could be moved to their own resource
>> files in their own time.
> Alright. I'll try this then.

One simplest way is to have StripNativeDebugSymbolsPlugin loads its own 
ResourceBundle.

I would add a new PluginsResourceBundle::getMessage method taking a 
ResourceBundle object
that StripNativeDebugSymbolsPlugin can call.

This is a patch for PluginsResourceBundle that you can use.

diff --git 
a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java 
b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java
--- 
a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java
+++ 
b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java
@@ -62,7 +62,11 @@
 ???? }

 ???? public static String getMessage(String key, Object... args) throws 
MissingResourceException {
-??????? String val = pluginsBundle.getString(key);
+??????? return getMessage(pluginsBundle, key, args);
+??? }
+
+??? public static String getMessage(ResourceBundle rb, String key, 
Object... args) throws MissingResourceException {
+??????? String val = rb.getString(key);
 ???????? return MessageFormat.format(val, args);
 ???? }
 ?}

Mandy

From sgehwolf at redhat.com  Tue Jan 29 10:44:01 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 29 Jan 2019 11:44:01 +0100
Subject: RFR: Move jlink plugin resources into their own files (was: Re:
 Help with build changes for: 8214796: Create a jlink plugin for stripping
 debug info symbols from native libraries)
In-Reply-To: <fb58ec4f-171f-35e5-9631-09194d488b0e@oracle.com>
References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com>
 <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com>
 <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com>
 <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com>
 <fb58ec4f-171f-35e5-9631-09194d488b0e@oracle.com>
Message-ID: <a2677a4439540be97d5ac5a94468fa9fc1cd8afc.camel@redhat.com>

Hi Mandy, Alan,

On Mon, 2019-01-28 at 13:02 -0800, Mandy Chung wrote:
> 
> On 1/28/19 1:26 AM, Severin Gehwolf wrote:
> > Hi Alan, Mandy,
> > 
> > On Sun, 2019-01-27 at 08:14 +0000, Alan Bateman wrote:
> > > On 26/01/2019 00:06, Mandy Chung wrote:
> > > > Hi Severin,
> > > > 
> > > > Another alternative would be to support per-jlink-plugin resource
> > > > bundle to avoid merging .properties files at build time.  The
> > > > plugin-specific messages should only be used by the plugin itself
> > > > and it would be cleaner for each plugin to manage its resource bundle.
> > > 
> > > That seems a cleaner idea than the suggestion we had on jigsaw-dev to 
> > > merge the properties. If Severin does this for this plugin then I assume 
> > > the resources for the other plugins could be moved to their own resource 
> > > files in their own time.
> > 
> > Alright. I'll try this then.
>  
> One simplest way is to have StripNativeDebugSymbolsPlugin loads its own ResourceBundle.
> 
> I would add a new PluginsResourceBundle::getMessage method taking a ResourceBundle object
> that StripNativeDebugSymbolsPlugin can call.
> 
> This is a patch for PluginsResourceBundle that you can use.
> 
> diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java
> --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java
> +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java
> @@ -62,7 +62,11 @@
>      }
>  
>      public static String getMessage(String key, Object... args) throws MissingResourceException {
> -        String val = pluginsBundle.getString(key);
> +        return getMessage(pluginsBundle, key, args);
> +    }
> +
> +    public static String getMessage(ResourceBundle rb, String key, Object... args) throws MissingResourceException {
> +        String val = rb.getString(key);
>          return MessageFormat.format(val, args);
>      }
>  }

Right, thanks! In fact, I've come up with something similar. Here is a
patch which moves resource files for jlink plugins into their own
properties files:

http://cr.openjdk.java.net/~sgehwolf/webrevs/jlink-plugins-resources/01/webrev/

It's not super clean as there is still this weird plugin.opt.<name>
artifact which has to do with TaskHelper and it's use of PluginOption,
but I wanted to keep the patch as minimal as possible.

Following this model, having platform specific plugins should be
easier. Would this be something acceptable upstream? If so, I'll file
an enhancement bug and an official RFR.

I've tested this with tools/jlink/ and jdk/modules tests.

Then the patch for the native debug strip plugin would become this:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796-wip/02/webrev/index.html

Is this going into the right direction?

Thanks,
Severin


From mandy.chung at oracle.com  Tue Jan 29 17:57:26 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 29 Jan 2019 09:57:26 -0800
Subject: RFR: Move jlink plugin resources into their own files
In-Reply-To: <a2677a4439540be97d5ac5a94468fa9fc1cd8afc.camel@redhat.com>
References: <8dfe0bcdf60bf7b99903c106cdc66fdf3b60cb23.camel@redhat.com>
 <07fd514a-feca-1427-8c98-eec8a6c249e7@oracle.com>
 <4377ec5f-14bf-c972-8702-8d4a653211eb@oracle.com>
 <3948f7727c976c65740f0b125702aacfe1c1c3e8.camel@redhat.com>
 <fb58ec4f-171f-35e5-9631-09194d488b0e@oracle.com>
 <a2677a4439540be97d5ac5a94468fa9fc1cd8afc.camel@redhat.com>
Message-ID: <c26b59d8-9bcb-5fc7-9512-1a17d6ddb70a@oracle.com>



On 1/29/19 2:44 AM, Severin Gehwolf wrote:

> Right, thanks! In fact, I've come up with something similar. Here is a
> patch which moves resource files for jlink plugins into their own
> properties files:
> 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/jlink-plugins-resources/01/webrev/
> 
> It's not super clean as there is still this weird plugin.opt.<name>
> artifact which has to do with TaskHelper and it's use of PluginOption,
> but I wanted to keep the patch as minimal as possible.
> 
> Following this model, having platform specific plugins should be
> easier. Would this be something acceptable upstream? If so, I'll file
> an enhancement bug and an official RFR.


Thanks for doing this.  Yes this should be a separate RFE.
I think each plugin should have its own ResourceBundle instance
as jlink should use the Plugin API to get the description, arguments
etc for the output of --list-plugins.  It does not need to maintain
plugin to ResourceBundle map.   It may involve more cleanup that
I will have to look at the current implementation to give any
suggestion.

I think your patch does not necessarily depend on this refactoring
and it makes sense to do this RFE separately and get the strip native
debug symbol plugin in first.


> I've tested this with tools/jlink/ and jdk/modules tests.
> 
> Then the patch for the native debug strip plugin would become this:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796-wip/02/webrev/index.html
> 
> Is this going into the right direction?

Looks reasonable.  I will review it and send feedback.

W.r.t. plugin resources, I suggest to have this plugin to maintain
its own ResourceBundle and format its own message so that this can
proceed independently with the existing plugin resource refactoring
work.  PluginsResourceBundle methods are convenient methods which
this new plugin does not have to use it.

Mandy

From cowwoc2020 at gmail.com  Wed Jan 30 17:40:53 2019
From: cowwoc2020 at gmail.com (cowwoc)
Date: Wed, 30 Jan 2019 10:40:53 -0700 (MST)
Subject: Annotation processors and the --processor-module-path
In-Reply-To: <555b0d80-82b7-a23d-f865-594bf52a372c@oracle.com>
References: <CA+pBWhvNGeY0jB0wS5vEc33V4a7Jq4xzQiNpOSPqkfjLG4h5+Q@mail.gmail.com>
 <aa273cff-5d43-bc83-64b2-495c96578ad9@oracle.com>
 <CA+pBWhvJbSd3XV=5siBDwfEEDWLOyfZig3a7FufOQvU6mc3T5A@mail.gmail.com>
 <2731474d-443a-2e7b-7f24-89765da22c7b@oracle.com>
 <5832C9AA.8010901@oracle.com>
 <CA+pBWhvOeE3w=UMZDDAJYHY9zVvMfs3bZudg96UzsiVZpmcHJA@mail.gmail.com>
 <CA+pBWhuJLHfwHH0rz9VdMMukDp9Ors6hH0oPp6zNvzPryjQp6Q@mail.gmail.com>
 <555b0d80-82b7-a23d-f865-594bf52a372c@oracle.com>
Message-ID: <1548870053671-0.post@n5.nabble.com>

Alan Bateman wrote
> On 22/11/2016 10:33, Eirik Bj?rsn?s wrote:
> 
>> :
>>
>> So again, I added -J-add-modules=java.xml.bind, and now my annotation
>> processor is loading.
>>
>> Given that my annotation processor does require java.xml.bind and I'm
>> using
>> --processor-module-path, my expectation would be that javac would resolve
>> that requires for me.
>>
>> What gives, am I expecting too much?
> When you deploy annotation processors on the --processor-module-path 
> then javac needs to resolve the annotation processor modules as part of 
> creating the dynamic configuration. The issue with the dependency on 
> java.xml.bind is that it's not in the boot layer and it's also not 
> observable on the processor module path. There is no support at this 
> time for augmenting the boot layer once it is created, also javac does 
> not attempt to resolve these modules from the original module path and 
> system image that were used to start the VM. So for now at least, 
> running with -J--add-modules=java.xml.bind is the only way to get this 
> to work.
> 
> -Alan

Hi Alan,

Seeing as `--add-modules=java.xml.bind` no longer works in Java 11 what is
the updated recommendation?

Thanks,
Gili



--
Sent from: http://jigsaw-dev.1059479.n5.nabble.com/

From alex.buckley at oracle.com  Wed Jan 30 19:26:18 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 30 Jan 2019 11:26:18 -0800
Subject: Annotation processors and the --processor-module-path
In-Reply-To: <1548870053671-0.post@n5.nabble.com>
References: <CA+pBWhvNGeY0jB0wS5vEc33V4a7Jq4xzQiNpOSPqkfjLG4h5+Q@mail.gmail.com>
 <aa273cff-5d43-bc83-64b2-495c96578ad9@oracle.com>
 <CA+pBWhvJbSd3XV=5siBDwfEEDWLOyfZig3a7FufOQvU6mc3T5A@mail.gmail.com>
 <2731474d-443a-2e7b-7f24-89765da22c7b@oracle.com>
 <5832C9AA.8010901@oracle.com>
 <CA+pBWhvOeE3w=UMZDDAJYHY9zVvMfs3bZudg96UzsiVZpmcHJA@mail.gmail.com>
 <CA+pBWhuJLHfwHH0rz9VdMMukDp9Ors6hH0oPp6zNvzPryjQp6Q@mail.gmail.com>
 <555b0d80-82b7-a23d-f865-594bf52a372c@oracle.com>
 <1548870053671-0.post@n5.nabble.com>
Message-ID: <5C51FA5A.4020108@oracle.com>

On 1/30/2019 9:40 AM, cowwoc wrote:
> Seeing as `--add-modules=java.xml.bind` no longer works in Java 11 what is
> the updated recommendation?

The Java SE Platform no longer includes JAXB. JEP 320 discusses where to 
find standalone versions of JAXB (http://openjdk.java.net/jeps/320).

StackOverflow also has a question on this topic, with many suggestions 
and more than 250,000 views 
(https://stackoverflow.com/questions/43574426/how-to-resolve-java-lang-noclassdeffounderror-javax-xml-bind-jaxbexception-in-j).

Alex

From cowwoc2020 at gmail.com  Wed Jan 30 23:15:11 2019
From: cowwoc2020 at gmail.com (cowwoc)
Date: Wed, 30 Jan 2019 16:15:11 -0700 (MST)
Subject: Annotation processors and the --processor-module-path
In-Reply-To: <5C51FA5A.4020108@oracle.com>
References: <CA+pBWhvNGeY0jB0wS5vEc33V4a7Jq4xzQiNpOSPqkfjLG4h5+Q@mail.gmail.com>
 <aa273cff-5d43-bc83-64b2-495c96578ad9@oracle.com>
 <CA+pBWhvJbSd3XV=5siBDwfEEDWLOyfZig3a7FufOQvU6mc3T5A@mail.gmail.com>
 <2731474d-443a-2e7b-7f24-89765da22c7b@oracle.com>
 <5832C9AA.8010901@oracle.com>
 <CA+pBWhvOeE3w=UMZDDAJYHY9zVvMfs3bZudg96UzsiVZpmcHJA@mail.gmail.com>
 <CA+pBWhuJLHfwHH0rz9VdMMukDp9Ors6hH0oPp6zNvzPryjQp6Q@mail.gmail.com>
 <555b0d80-82b7-a23d-f865-594bf52a372c@oracle.com>
 <1548870053671-0.post@n5.nabble.com> <5C51FA5A.4020108@oracle.com>
Message-ID: <1548890111553-0.post@n5.nabble.com>

Sorry, I asked the wrong question (similar to the above but different).

What I was trying to say is that if you stick jmh on the module path, the
annotation processor stops working:
https://stackoverflow.com/q/53927874/14731

If I explicitly add the JAR file to the annotation processor path then it
works. Why do I need to explicitly add an entry to the annotation processor
path when this was working file on the classpath? Is there another way to
make this work?

Thank you,
Gili



--
Sent from: http://jigsaw-dev.1059479.n5.nabble.com/