Re: RFR 8171380: Remove exports from jdk.jlink

[forax]

- Mail original -
> De: "Chris Hegarty" <chris.hega...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "jigsaw-dev" <jigsaw-dev@openjdk.java.net>
> Envoyé: Mardi 17 Janvier 2017 10:36:32
> Objet: Re: RFR 8171380: Remove exports from jdk.jlink

>> On 17 Jan 2017, at 00:02, Remi Forax <fo...@univ-mlv.fr> wrote:
>> 
>> Cris,
>> it seems that there is a mechanism for API that are experimental in the jdk,
>> by example java.net.http uses this mechanism, is it possible to reuse the 
>> same
>> mechanism for the jlink plugin API ?
> 
> I did look at the possibility exposing the JLink Plugin API through
> an incubator module, but found that it would add complication to
> the code in order to refactor out the API to the extent where regular
> plugins could co-exist with custom plugins, while not having the
> jlink module depend on the incubator module. I discussed this
> offline with the jlink folk and they seemed to think that since this
> is a niche area, having to add --add-exports to was a reasonable
> compromise at this point, rather than the potentially more invasive
> changes that would be required to use incubator modules.

Ok,
it seems i'm the only one to have played with the plugin API :)

I think you can also load jlink in an empty Layer to workaround the lack of the 
exported package, at least at runtime.

> 
> -Chris.

Rémi

Re: RFR 8171380: Remove exports from jdk.jlink

[Chris Hegarty]

> On 17 Jan 2017, at 00:02, Remi Forax  wrote:
> 
> Cris,
> it seems that there is a mechanism for API that are experimental in the jdk,
> by example java.net.http uses this mechanism, is it possible to reuse the 
> same mechanism for the jlink plugin API ?

I did look at the possibility exposing the JLink Plugin API through
an incubator module, but found that it would add complication to
the code in order to refactor out the API to the extent where regular
plugins could co-exist with custom plugins, while not having the
jlink module depend on the incubator module. I discussed this 
offline with the jlink folk and they seemed to think that since this
is a niche area, having to add --add-exports to was a reasonable
compromise at this point, rather than the potentially more invasive
changes that would be required to use incubator modules.

-Chris.

Re: RFR 8171380: Remove exports from jdk.jlink

[Remi Forax]

Cris,
it seems that there is a mechanism for API that are experimental in the jdk,
by example java.net.http uses this mechanism, is it possible to reuse the same 
mechanism for the jlink plugin API ?

Rémi

- Mail original -
> De: "Chris Hegarty" <chris.hega...@oracle.com>
> À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net>, "A. Sundararajan" 
> <sundararajan.athijegannat...@oracle.com>, "Jim Laskey
> (Oracle)" <james.las...@oracle.com>
> Envoyé: Lundi 16 Janvier 2017 16:46:16
> Objet: RFR 8171380: Remove exports from jdk.jlink

> The Jlink Plugin API is not going to be supported in 9, so
> should not be exported [1], for use by third parties. Besides
> the removal of the export, most of the changes are adding
> @modules tags to existing tests.
> 
> http://cr.openjdk.java.net/~chegar/8171380.00/
> 
> Note: Sundar will follow up with 8172864 [2] to remove the
> '--plugin-module-path'. Custom plugins can be written and
> deployed on the class path using the --add-exports command
> line, if required.
> 
> This change depends on fix in jtreg b05 [3], so bumps the
> minimum required version.
> 
> -Chris.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8171380
> [2] https://bugs.openjdk.java.net/browse/JDK-8172864
> [3] http://hg.openjdk.java.net/code-tools/jtreg/rev/f79ef1ecc483

Re: RFR 8171380: Remove exports from jdk.jlink

[Chris Hegarty]

On 16/01/17 16:26, Alan Bateman wrote:

This looks okay except CustomPluginTest where I assume you mean to add
it to the ProblemList file.


Ok, I'll remove the @ignore and put the test on the ProblemList
before pushing.  Thanks.

-Chris.

Re: RFR 8171380: Remove exports from jdk.jlink

[Alan Bateman]

On 16/01/2017 15:46, Chris Hegarty wrote:

The Jlink Plugin API is not going to be supported in 9, so
should not be exported [1], for use by third parties. Besides
the removal of the export, most of the changes are adding
@modules tags to existing tests.

http://cr.openjdk.java.net/~chegar/8171380.00/

Note: Sundar will follow up with 8172864 [2] to remove the
'--plugin-module-path'. Custom plugins can be written and
deployed on the class path using the --add-exports command
line, if required.

This change depends on fix in jtreg b05 [3], so bumps the
minimum required version.
This looks okay except CustomPluginTest where I assume you mean to add 
it to the ProblemList file.


-Alan.

Re: RFR 8171380: Remove exports from jdk.jlink

[Sundararajan Athijegannathan]

+1

-Sundar

On 16/01/17, 9:16 PM, Chris Hegarty wrote:

The Jlink Plugin API is not going to be supported in 9, so
should not be exported [1], for use by third parties. Besides
the removal of the export, most of the changes are adding
@modules tags to existing tests.

http://cr.openjdk.java.net/~chegar/8171380.00/

Note: Sundar will follow up with 8172864 [2] to remove the
'--plugin-module-path'. Custom plugins can be written and
deployed on the class path using the --add-exports command
line, if required.

This change depends on fix in jtreg b05 [3], so bumps the
minimum required version.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8171380
[2] https://bugs.openjdk.java.net/browse/JDK-8172864
[3] http://hg.openjdk.java.net/code-tools/jtreg/rev/f79ef1ecc483

RFR 8171380: Remove exports from jdk.jlink

[Chris Hegarty]

The Jlink Plugin API is not going to be supported in 9, so
should not be exported [1], for use by third parties. Besides
the removal of the export, most of the changes are adding
@modules tags to existing tests.

http://cr.openjdk.java.net/~chegar/8171380.00/

Note: Sundar will follow up with 8172864 [2] to remove the
'--plugin-module-path'. Custom plugins can be written and
deployed on the class path using the --add-exports command
line, if required.

This change depends on fix in jtreg b05 [3], so bumps the
minimum required version.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8171380
[2] https://bugs.openjdk.java.net/browse/JDK-8172864
[3] http://hg.openjdk.java.net/code-tools/jtreg/rev/f79ef1ecc483