Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges

2017-02-14 Thread Mandy Chung 
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.00/

This is the first step to enable generating dot graph to be 
included in module summary javadoc, if desired.  jdeps already
supports generating the dot graph for modules.  This patch
converts GenGraphs build tool to use jdeps implementation
as well as fixes jdeps to work with -apionly to generate
a dot graph containing `requires transitive` edges only.

Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8173303

Re: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation?

2017-02-14 Thread mark . reinhold 
2017/2/13 9:17:47 -0800, Guillaume Smet :
> On Mon, Feb 13, 2017 at 6:10 PM, alan.bate...@oracle.com wrote:
>> On 13/02/2017 16:58, Guillaume Smet wrote:
>>> On Mon, Feb 13, 2017 at 5:12 PM, alan.bate...@oracle.com wrote:
 
 I agree that @Generated is awkward but I haven't suggested removing it.
>>> 
>>> What do you suggest then? As far as I understood you, you were suggesting
>>> removing the module in Java 10 so the @Generated annotation would also be
>>> gone? Or did I misunderstand?
>> 
>> That is the proposal. If it goes ahead then it means that tools that rely
>> on these annotations in the JDK would need to deploy the standalone version
>> on the class path or as a module on the module path.
> 
> Yeah, so basically, it would end up with
> http://hg.openjdk.java.net/code-tools/jmh/rev/d74b2861222c .
> 
> I don't think it's the best possible outcome for this useful annotation.

I agree.

The `@Generated` annotation falls outside the original charter of the
`java.lang.annotation` package, which was meant for annotations that
directly support the language's annotation facility, but we already
added `@Native` in SE 8, so let's add `@Generated` in SE 9 as David
suggests and encourage people to use it when running on this and later
releases.

The fact that `@Generated` is so widely used is new information to some
of us, so thanks for bringing it up.

- Mark

Re: RFR 8174718: "Module 's descriptor returns inconsistent package set" confusing

2017-02-14 Thread Mandy Chung 

> On Feb 14, 2017, at 5:52 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8174718/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8174718

JLinkNegativeTest.java - line 352 is not really needed.  Otherwise looks fine 
to me.

Mandy

Re: RFR 8174718: "Module 's descriptor returns inconsistent package set" confusing

2017-02-14 Thread Jim Laskey (Oracle) 
+1

> On Feb 14, 2017, at 9:52 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8174718/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8174718
> 
> Thanks,
> -Sundar

Re: RFR 8174718: "Module 's descriptor returns inconsistent package set" confusing

2017-02-14 Thread Alan Bateman 

On 14/02/2017 15:56, Sundararajan Athijegannathan wrote:

Yes - because the test module's name is "inconsistentJar" and jlink 
adds module name to the error message.


-Sundar


Got it, I thought it was a typo initially.

-Alan.

Re: RFR 8174718: "Module 's descriptor returns inconsistent package set" confusing

2017-02-14 Thread Alan Bateman 

On 14/02/2017 13:52, Sundararajan Athijegannathan wrote:

Please review http://cr.openjdk.java.net/~sundar/8174718/webrev.00/ 
for https://bugs.openjdk.java.net/browse/JDK-8174718
Is the output matching in the test correct to check for "Module 
inconsistentJar's descriptor ..."?


-Alan

Re: Running jaotc with an external Graal

2017-02-14 Thread Andrew Haley 
On 14/02/17 14:37, Alan Bateman wrote:
> --patch-module can be used to patch any module in the boot layer. So if 
> you are looking to override or add classes then --patch-module should work.

Aha!  Thanks,

Andrew.

Re: Running jaotc with an external Graal

2017-02-14 Thread Alan Bateman 

On 14/02/2017 14:20, Andrew Haley wrote:


On 14/02/17 13:34, Doug Simon wrote:


I don’t know how one patches a module in the middle of the module
graph. That is, we use --patch-module and --upgrade-module-path to
override the jdk.vm.compiler module in the JDK. I don’t know what
that means for modules such as jdk.aot that depend on
jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help.

OK, thanks.  I guess I could try to upgrade the copy of Graal that is
contained in HotSpot.  I'll have a look.


--patch-module can be used to patch any module in the boot layer. So if 
you are looking to override or add classes then --patch-module should work.


-Alan

Re: Running jaotc with an external Graal

2017-02-14 Thread Andrew Haley 
On 14/02/17 13:34, Doug Simon wrote:

> I don’t know how one patches a module in the middle of the module
> graph. That is, we use --patch-module and --upgrade-module-path to
> override the jdk.vm.compiler module in the JDK. I don’t know what
> that means for modules such as jdk.aot that depend on
> jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help.

OK, thanks.  I guess I could try to upgrade the copy of Graal that is
contained in HotSpot.  I'll have a look.

Andrew.