Re: Compiling Java 9 (take 2)

[Alex Buckley]

On 1/13/2017 3:52 PM, Stephan Herrmann wrote:

Speaking of which, I'm confused by these sentences:

7.2:
"The host system is free to decide that a compilation unit containing a
module declaration is not, in fact, associated with the module declared
therein."


Should be "an observable compilation unit containing a ...". Per 7.3, 
once you've decided a compilation unit is observable, then if it 
contains a module declaration you're required to associate the c.u. with 
the declared module and not with (say) java.base. And if the c.u. is not 
observable then associated-with is moot.


Alex


7.3:
"A modular compilation unit consists of a module declaration, optionally
preceded by import declarations."

"An observable modular compilation unit is associated with the module
that it declares."

If "compilation unit containing a module declaration" and "modular
compilation unit"
is the same thing, then it is associated with the module declared
therein, and may
at the same time not be associated with it.

What am I missing?

Re: Review Request JDK-8160286: jmod hash is creating unlinkable modules.

[Mandy Chung]

> On Jan 13, 2017, at 6:09 AM, Alan Bateman  wrote:
> 
> On 13/01/2017 05:13, Mandy Chung wrote:
> 
>> Updated webrev:
>>http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160286/webrev.01/
>> 
>> I did a further clean up and ModuleHashesBuilder now has one constructor.
>> Also updated the comment to avoid using the term “base”.  Due to the
>> refactoring, I moved the location of the tmp jmod file to be in the
>> tmp directory rather than the same directory of the jmod file;
>> otherwise, it would confuse the ModuleFinder with the tmp file.
>> 
> The updated patches look good and ModuleHashesBuilder is much simpler with 
> one constructor.
> 
> For computeHashes then it says "... in a subgraph and that has .." which 
> might need a few tweaks to make more readable.
> 

What about this:

* The key for each entry in the returned map is a module M that has
* no outgoing edges to any of the candidate modules to be hashed
* i.e. M is a leaf node in a connected subgraph containing M and
* other candidate modules from the module graph filtering
* the outgoing edges from M to non-candidate modules.

Webrev at:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160286/webrev.02/

> A typo in JmodTask.Hasher L829, should be "the". Also I assume the field 
> Hasher.moduleName should be a String as Andrej noted.

Fixed.

Mandy

Re: Compiling Java 9 (take 2)

[Stephan Herrmann]

On 01/08/2017 08:13 PM, Stephan Herrmann wrote:

[...]
Lastly, with the interplay of things defined in JLS vs. observability
which is subject to the host system, I wonder if JLS will at least include
"recommendations" regarding the structure of directories and compilation
units. The same holds for "association of a compilation unit to a module".


Speaking of which, I'm confused by these sentences:

7.2:
"The host system is free to decide that a compilation unit containing a module
 declaration is not, in fact, associated with the module declared therein."

7.3:
"A modular compilation unit consists of a module declaration, optionally 
preceded
 by import declarations."

"An observable modular compilation unit is associated with the module that it
 declares."

If "compilation unit containing a module declaration" and "modular compilation 
unit"
is the same thing, then it is associated with the module declared therein, and 
may
at the same time not be associated with it.

What am I missing?

Somehow that paragraph in 7.2 is strangely jumping from "presence of" to
"associated with" and back to "lack of", as if two paragraphs were merged
inadvertently.

Stephan

Re: MethodHandle performance

[Remi Forax]

The problem is more that if you have played a little with the API, you know 
that invokeWithArguments is slow because it may do a lot of work with no way to 
cache the intermediary representation into the user code (and even if you add a 
cache, it will not handle all the cases, if the arrays do not have the same 
size or if the signature of the mh is not generic, etc). 

I think we (the JSR 292 EG) have failed here, we should not have introduced a 
method which is perhaps too convenient but hard to optimize.

Why not adding a line in the javadoc of invokeWitharguments, saying something 
like this:
Don't expect invokeWithArguments to be fast! Use invokeExact or invoke if you 
need performance.

cheers,
Rémi

- Mail original -
> De: "John Rose" 
> À: "Claes Redestad" , "Stephen Colebourne" 
> 
> Cc: "jigsaw-dev" 
> Envoyé: Vendredi 13 Janvier 2017 20:04:20
> Objet: Re: MethodHandle performance

> On Jan 12, 2017, at 12:29 PM, Claes Redestad  
> wrote:
>> 
>> Right, I was just looking at the micro Stephen provided me, and it does
>> seem that the added cost for this case is due to invokeWithArguments
>> creating a new invoker every time.
> 
> This is a good workaround, and Stephen's report is a helpful reminder
> that our performance story has a sharp edge.
> 
> We cache spreaders in the case of varargs methods,
> for full performance, but not for the ad hoc spreader used by MH.iWA.
> 
> We should cache them, to remove this sharp edge (or performance pothole).
> There are small technical challenges to do so.  Claes and I added
> some notes to the bug report; maybe someone can look into it more.
> 
> — John

Re: MethodHandle performance

[John Rose]

On Jan 12, 2017, at 12:29 PM, Claes Redestad  wrote:
> 
> Right, I was just looking at the micro Stephen provided me, and it does
> seem that the added cost for this case is due to invokeWithArguments
> creating a new invoker every time.

This is a good workaround, and Stephen's report is a helpful reminder
that our performance story has a sharp edge.

We cache spreaders in the case of varargs methods,
for full performance, but not for the ad hoc spreader used by MH.iWA.

We should cache them, to remove this sharp edge (or performance pothole).
There are small technical challenges to do so.  Claes and I added
some notes to the bug report; maybe someone can look into it more.

— John

Re: jdk 9 build release notes incorrectly has jigsaw data

[dalibor topic]

Thanks, Martin - I've passed your feedback on to the team publishing the 
builds.


cheers,
dalibor topic

On 13.01.2017 19:04, Martin Buchholz wrote:

I tried to look at build 151 "Summary of changes" and went to
http://download.java.net/java/jdk9/changes/jdk-9+151.html
but that only gave me content-free list of changesets for "Jigsaw build 151"
(and the Jigsaw forest may not actually be in use any more) .

The build 152 version is fine
http://download.java.net/java/jdk9/changes/jdk-9+152.html


--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

jdk 9 build release notes incorrectly has jigsaw data

[Martin Buchholz]

I tried to look at build 151 "Summary of changes" and went to
http://download.java.net/java/jdk9/changes/jdk-9+151.html
but that only gave me content-free list of changesets for "Jigsaw build 151"
(and the Jigsaw forest may not actually be in use any more) .

The build 152 version is fine
http://download.java.net/java/jdk9/changes/jdk-9+152.html

hg: jigsaw/jake/jdk: Clarify javadoc for cases where builder throws IllegalArgumentException

[alan . bateman]

Changeset: 5bbbdf80c043
Author:alanb
Date:  2017-01-13 17:45 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5bbbdf80c043

Clarify javadoc for cases where builder throws IllegalArgumentException

! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java

hg: jigsaw/jake/jdk: 2 new changesets

[alan . bateman]

Changeset: 0c3c4c0097c7
Author:alanb
Date:  2017-01-13 15:21 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c3c4c0097c7

Further clarifications to builder javadoc

! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
! src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java
! src/java.base/share/classes/jdk/internal/module/Checks.java
! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java
! src/java.base/share/classes/jdk/internal/module/ModulePath.java
! src/jdk.jartool/share/classes/sun/tools/jar/Main.java

Changeset: 37c021140e75
Author:alanb
Date:  2017-01-13 16:02 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/37c021140e75

Further javadoc clarifications
JVM_AddModulePackage will throw ISE when JDK-8172288 integrated

! src/java.base/share/classes/java/lang/reflect/Layer.java
! src/java.base/share/classes/java/lang/reflect/Module.java

Re: Review Request JDK-8160286: jmod hash is creating unlinkable modules.

[Mandy Chung]

Not really need to be. I can take it out.
Mandy

> On Jan 13, 2017, at 1:43 AM, Andrej Golovnin  
> wrote:
> 
> Hi Mandy,
> 
> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java
> 
> 806 final Optional moduleName;  // a specific module
> to record hashes
> 
> I thought that using Optional in a class field is considered a misuse
> of the API. The field hashesBuilder can also be null. But you don't
> wrap it into an Optional. So why it is needed to wrap moduleName into
> Optional?
>  
> Best regards,
> Andrej Golovnin
> 
> On Fri, Jan 13, 2017 at 6:13 AM, Mandy Chung  wrote:
>> Updated webrev:
>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160286/webrev.01/
>> 
>> I did a further clean up and ModuleHashesBuilder now has one constructor.
>> Also updated the comment to avoid using the term “base”.  Due to the
>> refactoring, I moved the location of the tmp jmod file to be in the
>> tmp directory rather than the same directory of the jmod file;
>> otherwise, it would confuse the ModuleFinder with the tmp file.
>> 
>> I added a few more test cases that remind me that a packaged user
>> module can’t tie with a specific JDK build since a module requiring
>> a JDK module that would be a leaf node of the subgraph rather than
>> that module.  The `jar` tool locating JMOD files on the module path
>> allows to tie a modular JAR with a module requiring it but packaged
>> as JMOD file (e.g. with native library).
>> 
>> Mandy
>> 
>>> On Jan 12, 2017, at 7:52 AM, Mandy Chung  wrote:
>>> 
>>> 
 On Jan 12, 2017, at 7:08 AM, Alan Bateman  wrote:
 
 On 11/01/2017 23:47, Mandy Chung wrote:
 
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160286/webrev.00/
> 
> jmod and jar -—hash-modules option to specify a pattern of modules
> to be hashed in the module M being created.  It records the modules
> that depend on M directly and indirectly.
> 
 This looks quite good.  At some point then we'll need to move the tool 
 support out of jdk.internal.module but is something for another day.
 
 For ModuleHashesBuilder then it might be useful to put a comment on the 
 constructors as it's not immediately obvious why both are needed. Also I 
 wonder if we should use a term other than "base" for the modules that 
 don't have references to other modules in the sub-graph (they are sort of 
 leaf modules in the sub-graph).  A typo at L96 "in topological orders" -> 
 "order”.
>>> 
>>> I’ll take a pass and update the comments.  I can see “base” can be 
>>> confusing.
>>> 
 One of the changes in this patch is that the `jar` tool will locate JMOD 
 files on the module path. I assume this is to provide flexibility to those 
 creating a modular JAR that want to tie it to a specific JDK build. I 
 guess it's okay but I suspect will not be widely used.
>>> 
>>> Right and another case is packaged module with a native library (security 
>>> providers). It will not be widey used.
>>> 
>>> Mandy
>> 

Re: #CompileTimeDependencies and module resolution

[Remi Forax]

Ok, thanks.

Rémi

- Mail original -
> De: "Sander Mak" 
> À: "jigsaw-dev" 
> Envoyé: Vendredi 13 Janvier 2017 14:47:59
> Objet: Re: #CompileTimeDependencies and module resolution

> On 13 Jan 2017, at 14:37, fo...@univ-mlv.fr wrote:
> 
> As i've read the mail of Sander,
> the module which is required statically is present in the module path but not
> resolved by default, you have to use --add-modules. But maybe i'm wrong ?
> 
> You're not wrong, see the email exchange with Stephen as well. Just a 
> `requires
> static` does not cause a module to be resolved from the module path, there
> needs to be a non-static requires or --add-modules for the optional module.
> This is intentional behaviour according to the proposal:
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-June/000306.html
> 
> 
> Sander

Re: #CompileTimeDependencies and module resolution

[Remi Forax]

- Mail original -
> De: "David M. Lloyd" 
> À: "Sander Mak" , "jigsaw-dev" 
> 
> Envoyé: Vendredi 13 Janvier 2017 15:23:56
> Objet: Re: #CompileTimeDependencies and module resolution

> On 01/13/2017 06:48 AM, Sander Mak wrote:
>>
>>> The standard use case for the feature is for libraries with optional
>>> dependencies:
>>
>> That is indeed the use case I was thinking of.
>>
>>> The --add-modules flag is only relevant when using the command line to
>>> turn setup #1 into setup #2, something which should be rare.
>>
>> Interesting, so what you're saying is if an application wants the optional
>> behaviour of Lib through A, the application module itself (or any of its
>> modules) has to declare a non-optional dependency in its descriptor on module
>> A. Even though, technically, this application module doesn't have any direct
>> relation at all with A. If you do that, the application can freely use types
>> exported from A. Which is not always what you want (in most cases even, I'd
>> say). For example, Lib would be a machine learning library that the 
>> application
>> uses and A would be a super-fast matrix multiplication library (possibly with
>> native code not available on all platforms, so it has to be optional). I 
>> won't
>> ever use the matrix multiplication lib A directly in my application, but I 
>> want
>> it to be used by Lib for increased performance.
>>
>> What I was expecting, is that the mere presence of A on the module path would
>> cause it to be resolved when Lib is resolved, without needing a non-static
>> requires or --add-modules. Conversely, if A isn't there, Lib would get 
>> resolved
>> without A just as well. Obviously Lib needs to guard for this situation, as 
>> you
>> said.
> 
> This is the intuitive behavior I also expect of an optional dependency.
> The problem however is that a static dependency isn't an optional
> dependency; it's a compile-time-only dependency, which is not exactly
> the same thing.
> 
> We (Jigsaw) don't have a concept of an optional dependency (i.e. one
> that is eagerly used if present but does not cause an error if absent)
> at all.  Maybe we should though, as experience has shown that this is a
> useful operating mode.

You can implement it at runtime if you control the Layer, either by removing 
the requires directive or by synthetising a fake module descriptor 
corresponding to the dependency.

> 
>> Alternatively, you can view optional dependency usage more like 'if the
>> application already uses A, then Lib should also use A as well' in which case
>> your suggested setup and the current implementation make total sense. This 
>> does
>> make the example I described above a bit awkward, but I don't have any data 
>> on
>> which use case is more prevalent.
>>
>> Thanks for the insights!
>>
>>
>> Sander
>>
> 
> --
> - DML

Rémi

Re: #CompileTimeDependencies and module resolution

[David M. Lloyd]

On 01/13/2017 06:48 AM, Sander Mak wrote:



The standard use case for the feature is for libraries with optional
dependencies:


That is indeed the use case I was thinking of.


The --add-modules flag is only relevant when using the command line to
turn setup #1 into setup #2, something which should be rare.


Interesting, so what you're saying is if an application wants the optional 
behaviour of Lib through A, the application module itself (or any of its 
modules) has to declare a non-optional dependency in its descriptor on module 
A. Even though, technically, this application module doesn't have any direct 
relation at all with A. If you do that, the application can freely use types 
exported from A. Which is not always what you want (in most cases even, I'd 
say). For example, Lib would be a machine learning library that the application 
uses and A would be a super-fast matrix multiplication library (possibly with 
native code not available on all platforms, so it has to be optional). I won't 
ever use the matrix multiplication lib A directly in my application, but I want 
it to be used by Lib for increased performance.

What I was expecting, is that the mere presence of A on the module path would 
cause it to be resolved when Lib is resolved, without needing a non-static 
requires or --add-modules. Conversely, if A isn't there, Lib would get resolved 
without A just as well. Obviously Lib needs to guard for this situation, as you 
said.


This is the intuitive behavior I also expect of an optional dependency. 
The problem however is that a static dependency isn't an optional 
dependency; it's a compile-time-only dependency, which is not exactly 
the same thing.


We (Jigsaw) don't have a concept of an optional dependency (i.e. one 
that is eagerly used if present but does not cause an error if absent) 
at all.  Maybe we should though, as experience has shown that this is a 
useful operating mode.



Alternatively, you can view optional dependency usage more like 'if the 
application already uses A, then Lib should also use A as well' in which case 
your suggested setup and the current implementation make total sense. This does 
make the example I described above a bit awkward, but I don't have any data on 
which use case is more prevalent.

Thanks for the insights!


Sander



--
- DML

Re: Review Request JDK-8160286: jmod hash is creating unlinkable modules.

[Alan Bateman]

On 13/01/2017 05:13, Mandy Chung wrote:


Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160286/webrev.01/

I did a further clean up and ModuleHashesBuilder now has one constructor.
Also updated the comment to avoid using the term “base”.  Due to the
refactoring, I moved the location of the tmp jmod file to be in the
tmp directory rather than the same directory of the jmod file;
otherwise, it would confuse the ModuleFinder with the tmp file.

The updated patches look good and ModuleHashesBuilder is much simpler 
with one constructor.


For computeHashes then it says "... in a subgraph and that has .." which 
might need a few tweaks to make more readable.


A typo in JmodTask.Hasher L829, should be "the". Also I assume the field 
Hasher.moduleName should be a String as Andrej noted.


-Alan

Re: #CompileTimeDependencies and module resolution

[Sander Mak]

On 13 Jan 2017, at 14:37, fo...@univ-mlv.fr wrote:

As i've read the mail of Sander,
the module which is required statically is present in the module path but not 
resolved by default, you have to use --add-modules. But maybe i'm wrong ?

You're not wrong, see the email exchange with Stephen as well. Just a `requires 
static` does not cause a module to be resolved from the module path, there 
needs to be a non-static requires or --add-modules for the optional module. 
This is intentional behaviour according to the proposal: 
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-June/000306.html


Sander

Re: #CompileTimeDependencies and module resolution

[Alan Bateman]

On 13/01/2017 12:48, Sander Mak wrote:


:
Alternatively, you can view optional dependency usage more like 'if the 
application already uses A, then Lib should also use A as well' in which case 
your suggested setup and the current implementation make total sense. This does 
make the example I described above a bit awkward, but I don't have any data on 
which use case is more prevalent.

For Stephen's example then it would be better to steer people to using 
services and avoid the reflection guard that Lib would need to cope with 
A not being resolved.


`requires static A` does have its usages of courses, the main one is 
where `module A` only exports packages containing annotations and where 
those annotations may not be present at run time.


-Alan.

Re: #CompileTimeDependencies and module resolution

[forax]

As i've read the mail of Sander,
the module which is required statically is present in the module path but not 
resolved by default, you have to use --add-modules. But maybe i'm wrong ?

Rémi

- Mail original -
> De: "Alan Bateman" 
> À: "Remi Forax" , "Sander Mak" 
> Cc: "jigsaw-dev" 
> Envoyé: Vendredi 13 Janvier 2017 12:33:53
> Objet: Re: #CompileTimeDependencies and module resolution

> On 13/01/2017 11:08, Remi Forax wrote:
> 
>> Hi Sander,
>> you're right, it's a bug, --add-modules should not be necessary.
>>
>> Rémi
> I don't think there is a bug here. Instead the example that Sander has
> chosen doesn't resolve a module that `requires B`. The "Notes" section
> in #CompileTimeDependences proposal has the rational for this. If the
> example is extended to:
> 
> module A { requires static B; requires C; }
> module B { ... }
> module C { requires B; }
> 
> then the resulting module graph will have contain at least A, B and C,
> and A will read at least B and C.
> 
> -Alan

Re: #CompileTimeDependencies and module resolution

[Sander Mak]

> The standard use case for the feature is for libraries with optional
> dependencies:

That is indeed the use case I was thinking of.

> The --add-modules flag is only relevant when using the command line to
> turn setup #1 into setup #2, something which should be rare.

Interesting, so what you're saying is if an application wants the optional 
behaviour of Lib through A, the application module itself (or any of its 
modules) has to declare a non-optional dependency in its descriptor on module 
A. Even though, technically, this application module doesn't have any direct 
relation at all with A. If you do that, the application can freely use types 
exported from A. Which is not always what you want (in most cases even, I'd 
say). For example, Lib would be a machine learning library that the application 
uses and A would be a super-fast matrix multiplication library (possibly with 
native code not available on all platforms, so it has to be optional). I won't 
ever use the matrix multiplication lib A directly in my application, but I want 
it to be used by Lib for increased performance. 

What I was expecting, is that the mere presence of A on the module path would 
cause it to be resolved when Lib is resolved, without needing a non-static 
requires or --add-modules. Conversely, if A isn't there, Lib would get resolved 
without A just as well. Obviously Lib needs to guard for this situation, as you 
said.

Alternatively, you can view optional dependency usage more like 'if the 
application already uses A, then Lib should also use A as well' in which case 
your suggested setup and the current implementation make total sense. This does 
make the example I described above a bit awkward, but I don't have any data on 
which use case is more prevalent.

Thanks for the insights!


Sander

Re: #CompileTimeDependencies and module resolution

[Stephen Colebourne]

The standard use case for the feature is for libraries with optional
dependencies:

module Lib { requires static A; requires B; }
module A { ... }
module B { ... }

Given this setup:
 module App1 { requires Lib; }
the module graph should include App1, Lib and B.
Any use of A from Lib must be guarded, as A is not present.

Given this setup:
 module App2 { requires Lib; requires A }
the module graph should include App1, Lib, A and B.
Module A will be visible and read by Lib.

ie. the optional depenedency expresses the concept of "use module A if
it is available, otherwise ignore it"


The --add-modules flag is only relevant when using the command line to
turn setup #1 into setup #2, something which should be rare.

Stephen


On 13 January 2017 at 11:33, Alan Bateman  wrote:
> On 13/01/2017 11:08, Remi Forax wrote:
>
>> Hi Sander,
>> you're right, it's a bug, --add-modules should not be necessary.
>>
>> Rémi
>
> I don't think there is a bug here. Instead the example that Sander has
> chosen doesn't resolve a module that `requires B`. The "Notes" section in
> #CompileTimeDependences proposal has the rational for this. If the example
> is extended to:
>
> module A { requires static B; requires C; }
> module B { ... }
> module C { requires B; }
>
> then the resulting module graph will have contain at least A, B and C, and A
> will read at least B and C.
>
> -Alan

Re: #CompileTimeDependencies and module resolution

[Alan Bateman]

On 13/01/2017 11:08, Remi Forax wrote:


Hi Sander,
you're right, it's a bug, --add-modules should not be necessary.

Rémi
I don't think there is a bug here. Instead the example that Sander has 
chosen doesn't resolve a module that `requires B`. The "Notes" section 
in #CompileTimeDependences proposal has the rational for this. If the 
example is extended to:


module A { requires static B; requires C; }
module B { ... }
module C { requires B; }

then the resulting module graph will have contain at least A, B and C, 
and A will read at least B and C.


-Alan

Re: MethodHandle performance

[Stephen Colebourne]

Thanks Claes and everyone else who took a look. The asSpreader() trick
does indeed work.

So it looks like method handles can be a viable alternative to
reflection for Jigsaw, but users of method handles do need to take
care about the pattern of usage of method handles to get performance.
Hopefully JDK-8078511 will get addressed at some point too.

(Part of the problem I suspect is that because fewer people have
looked at method handles, there is less experience of how to use them
effectively on the web)

thanks
Stephen


On 12 January 2017 at 20:29, Claes Redestad  wrote:
> Right, I was just looking at the micro Stephen provided me, and it does
> seem that the added cost for this case is due to invokeWithArguments
> creating a new invoker every time.
>
> This appears to be a known issue[1], so a design that can use invoke or
> invokeExact instead should be considered:
>
> -this.constructor = constructorHandle;
> +this.constructor = constructorHandle.asSpreader(Object[].class,
> propertyTypes.size());
>
> ...
>
> -return (T) constructor.invokeWithArguments(args);
> +return (T) constructor.invoke(args);
>
> This seems sufficient to get the MH-based implementation on par with
> the reflection based one in all tests.
>
> Thanks!
>
> /Claes
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8078511
>
>
> On 2017-01-12 20:46, Michael Rasmussen wrote:
>>
>> Doing a quick JMH benchmark here, with a constructor taking 4
>> arguments, invokeWithArguments was about 15-30x slower than invoke and
>> invokeExact.
>> Otherwise, static final MH was 2.5x faster then reflection, and
>> instance field MH was 1.3x faster
>>
>> For output and test code:
>> https://gist.github.com/anonymous/32e698d04c7456c10f069686072d7cc6
>>
>> /Michael
>>
>> On 12 January 2017 at 20:12, Stephen Colebourne 
>> wrote:
>>>
>>> @Claes
>>>
>>> Fat fingers - should have been 1.8.0_112
>>>
>>> The code is in the link:
>>>
>>> https://github.com/JodaOrg/joda-beans/commit/ad7d61a7ff72f932957127117dd8f377e1e2bf60
>>>
>>> where a HandleMetaBean (method handle) performs the same job as
>>> LightMetaBean (reflection) as shown in the non-JMH test
>>> TestHandle.main().
>>>
>>> @Jochen
>>>
>>> The method handle setup code is all done in static initializers. The
>>> performance tests are all testing runtime usage, excluding the static
>>> initializer setup cost (as one off startup costs are not relevant to
>>> my use case).
>>>
>>> @Remi
>>> Thanks for taking a look. Its the constructor invocation that is most
>>> obviously a problem. In HandleMetaBean.build(Object[]) where it uses
>>> invokeWithArguments(Object[]). I get 1650ms for reflection vs 3500ms
>>> for method handles.
>>>
>>> The meta-property getter code runs much quicker, so a JMH test would
>>> really be needed to confirm the difference there.
>>>
>>> The asType() and invokeExact() code was added to see if that made a
>>> difference, but it did not.
>>>
>>> @Aleksey
>>> I saw you post when researching before writing my mail today. The code
>>> cannot use static final method handles (I doubt there are many use
>>> cases for those, to be honest). The goal of the code here is to obtain
>>> an object implementing my interfaces that can be invoked in a general
>>> way to invoke a constructor or a getter. As such, the method handles
>>> need to be instance variables.
>>>
>>> I have now done a JMH test.
>>>
>>> The good news is that the method handle for the getter is slightly
>>> faster when taken in isolation:
>>>
>>> JodaBenchmark.testMethodHandleGetavgt   508.421 ± 0.078  ns/op
>>> JodaBenchmark.testReflectionGet  avgt   50   11.003 ± 0.050  ns/op
>>>
>>> The bad news is that the method handle constructor call is not 2x
>>> reflection, but 6x:
>>>
>>> JodaBenchmark.testMethodHandleBuild  avgt   50  219.212 ± 2.400  ns/op
>>> JodaBenchmark.testReflectionBuildavgt   50   36.012 ± 0.167  ns/op
>>>
>>> This test reduced the difference to :
>>>return (T) constructorHandle.invokeWithArguments(args);
>>> vs
>>> return constructor.newInstance(args);
>>>
>>> Email me privately for a zip of the JMH test:
>>>
>>> Any thoughts on the 6x slower call? thanks for looking
>>> Stephen
>>>
>>>
>>> On 12 January 2017 at 14:47, Claes Redestad 
>>> wrote:

 Hi Stephen,

 this is surprising; handles should typically be as fast or much
 faster than reflection (VarHandles can be faster than Unsafe in certain
 cases), but may carry a slightly more expensive setup cost - do you have
 a
 reproducer I could try?

 8b122 - do you mean 8u122 EA?

 Thanks!

 /Claes


 On 2017-01-12 15:23, Stephen Colebourne wrote:
>
>
> I've recently tried [1] converting Joda-Beans use of setAccessible()
> to use MethodHandle. Since it is a code generator, the actual coding
> is relatively easy, and obtaining the MethodHandles.Lookup 

Re: #CompileTimeDependencies and module resolution

[Remi Forax]

Hi Sander,
you're right, it's a bug, --add-modules should not be necessary.

Rémi

- Mail original -
> De: "Sander Mak" 
> À: "jigsaw-dev" 
> Envoyé: Vendredi 13 Janvier 2017 11:39:10
> Objet: #CompileTimeDependencies and module resolution

> When you have a module A with an optional dependency on B (`requires static 
> B`),
> module B is not resolved from the module path unless `--add-modules B` is
> provided at startup (tested with jigsaw-b151). In [1] this is mentioned as a
> detail, and in fact  it is phrased as a question there. Is this still an open
> question? Because in my mind, expressing an optional dependency *and* having 
> to
> add the module as root module to get it resolved seems a bit over the top (and
> typically you'd also have to add it as dependency in your build tool of choice
> to get it on the module path).
> 
> "If it's on the module path, use it, otherwise, ignore it" is intuitively more
> appealing to me for optional dependencies. It also more closely resembles the
> way things currently work on the classpath with many frameworks.
> 
> For linking, I can see why adding optional modules explicitly is better. 
> Still,
> I think not having to do this at run-time (just like service provider modules
> are resolved at run-time but not at link-time) makes more sense.
> 
> 
> Regards,
> Sander
> 
> 
> [1] 
> http://openjdk.java.net/projects/jigsaw/spec/issues/#CompileTimeDependences

#CompileTimeDependencies and module resolution

[Sander Mak]

When you have a module A with an optional dependency on B (`requires static 
B`), module B is not resolved from the module path unless `--add-modules B` is 
provided at startup (tested with jigsaw-b151). In [1] this is mentioned as a 
detail, and in fact  it is phrased as a question there. Is this still an open 
question? Because in my mind, expressing an optional dependency *and* having to 
add the module as root module to get it resolved seems a bit over the top (and 
typically you'd also have to add it as dependency in your build tool of choice 
to get it on the module path). 

"If it's on the module path, use it, otherwise, ignore it" is intuitively more 
appealing to me for optional dependencies. It also more closely resembles the 
way things currently work on the classpath with many frameworks. 

For linking, I can see why adding optional modules explicitly is better. Still, 
I think not having to do this at run-time (just like service provider modules 
are resolved at run-time but not at link-time) makes more sense.


Regards,
Sander


[1] http://openjdk.java.net/projects/jigsaw/spec/issues/#CompileTimeDependences 

Re: Review Request JDK-8160286: jmod hash is creating unlinkable modules.

[Andrej Golovnin]

Hi Mandy,

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java

806 final Optional moduleName;  // a specific module
to record hashes

I thought that using Optional in a class field is considered a misuse
of the API. The field hashesBuilder can also be null. But you don't
wrap it into an Optional. So why it is needed to wrap moduleName into
Optional?

Best regards,
Andrej Golovnin

On Fri, Jan 13, 2017 at 6:13 AM, Mandy Chung  wrote:
> Updated webrev:
>http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160286/webrev.01/
>
> I did a further clean up and ModuleHashesBuilder now has one constructor.
> Also updated the comment to avoid using the term “base”.  Due to the
> refactoring, I moved the location of the tmp jmod file to be in the
> tmp directory rather than the same directory of the jmod file;
> otherwise, it would confuse the ModuleFinder with the tmp file.
>
> I added a few more test cases that remind me that a packaged user
> module can’t tie with a specific JDK build since a module requiring
> a JDK module that would be a leaf node of the subgraph rather than
> that module.  The `jar` tool locating JMOD files on the module path
> allows to tie a modular JAR with a module requiring it but packaged
> as JMOD file (e.g. with native library).
>
> Mandy
>
>> On Jan 12, 2017, at 7:52 AM, Mandy Chung  wrote:
>>
>>
>>> On Jan 12, 2017, at 7:08 AM, Alan Bateman  wrote:
>>>
>>> On 11/01/2017 23:47, Mandy Chung wrote:
>>>
 Webrev:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160286/webrev.00/

 jmod and jar -—hash-modules option to specify a pattern of modules
 to be hashed in the module M being created.  It records the modules
 that depend on M directly and indirectly.

>>> This looks quite good.  At some point then we'll need to move the tool 
>>> support out of jdk.internal.module but is something for another day.
>>>
>>> For ModuleHashesBuilder then it might be useful to put a comment on the 
>>> constructors as it's not immediately obvious why both are needed. Also I 
>>> wonder if we should use a term other than "base" for the modules that don't 
>>> have references to other modules in the sub-graph (they are sort of leaf 
>>> modules in the sub-graph).  A typo at L96 "in topological orders" -> 
>>> "order”.
>>
>> I’ll take a pass and update the comments.  I can see “base” can be confusing.
>>
>>> One of the changes in this patch is that the `jar` tool will locate JMOD 
>>> files on the module path. I assume this is to provide flexibility to those 
>>> creating a modular JAR that want to tie it to a specific JDK build. I guess 
>>> it's okay but I suspect will not be widely used.
>>
>> Right and another case is packaged module with a native library (security 
>> providers). It will not be widey used.
>>
>> Mandy
>

hg: jigsaw/jake/jdk: 26 new changesets

[alan . bateman]

Changeset: 81b1a6a91b91
Author:xuelei
Date:  2017-01-04 00:08 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/81b1a6a91b91

8172217: Need debug log for the intermittent failure of 
AnonCipherWithWantClientAuth
Reviewed-by: weijun

! test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java

Changeset: 2136507bd9f0
Author:mli
Date:  2017-01-03 21:05 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2136507bd9f0

8170641: sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails 
with timeout
Summary: The fix sets timeout for the server and the client, and ignore 
SocketTimeoutException.
Reviewed-by: chegar
Contributed-by: John Jiang 

! test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java
- test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh
! test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java
- test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh
! test/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java

Changeset: 2c8fea47274d
Author:tidu
Date:  2017-01-03 22:26 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2c8fea47274d

8168769: javax/net/ssl/TLSv12/DisabledShortRSAKeys.java timed out
Reviewed-by: coffeys, xuelei
Contributed-by: Tim Du 

! test/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java

Changeset: 96b7fd41b420
Author:apetcher
Date:  2017-01-04 08:06 -0500
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/96b7fd41b420

8172003: getInstance() with unknown provider throws NPE
Reviewed-by: mullan

! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/TransformService.java
! 
src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java
! 
src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java
+ test/javax/xml/crypto/dsig/TransformService/UnknownProvider.java
+ test/javax/xml/crypto/dsig/XMLSignatureFactory/UnknownProvider.java
+ test/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory/UnknownProvider.java

Changeset: 5fed32a1d63d
Author:redestad
Date:  2017-01-04 18:32 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5fed32a1d63d

8170785: Excessive allocation in ParseUtil.encodePath
Reviewed-by: rriggs

! src/java.base/share/classes/sun/net/www/ParseUtil.java

Changeset: e77454faf897
Author:mchung
Date:  2017-01-04 09:50 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e77454faf897

8172215: java launcher no longer accepts -cp "" empty string
Reviewed-by: alanb, dholmes, psandoz

! src/java.base/share/native/libjli/java.c
+ test/lib/testlibrary/ModuleInfoMaker.java
- test/lib/testlibrary/ModuleSourceBuilder.java
! test/tools/launcher/modules/addexports/AddExportsTestWarningError.java
! test/tools/launcher/modules/addreads/AddReadsTestWarningError.java
! test/tools/launcher/modules/classpath/JavaClassPathTest.java

Changeset: 079290bdc3c3
Author:darcy
Date:  2017-01-04 10:20 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/079290bdc3c3

8172200: Mark StressLoopback.java as intermittently failing
Reviewed-by: lancea, bpb, rriggs

! test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java

Changeset: a9a5d14bfbb4
Author:lancea
Date:  2017-01-04 14:59 -0500
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a9a5d14bfbb4

8172254: Typo in DriverManager implNote
Reviewed-by: mchung, alanb

! src/java.sql/share/classes/java/sql/DriverManager.java

Changeset: 2866f5e1d57b
Author:psandoz
Date:  2017-01-04 17:20 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2866f5e1d57b

8172201: Replace assert of return type in VarHandle.AccessMode with test
Reviewed-by: mchung

! src/java.base/share/classes/java/lang/invoke/VarHandle.java
! test/java/lang/invoke/VarHandles/VarHandleTestAccessModeMethodNames.java

Changeset: d546cab5cb12
Author:plevart
Date:  2017-01-05 08:51 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d546cab5cb12

8172190: Re-apply the fix for bugs 8062389, 8029459, 8061950
Summary: Final fix for 8062389: Class.getMethod() is inconsistent with 
Class.getMethods() results, 8029459: getMethods returns methods that are not 
members of the class, 8061950: Class.getMethods() exhibits quadratic time 
complexity
Reviewed-by: alanb, mchung, psandoz, dfuchs, darcy, redestad

! src/java.base/share/classes/java/lang/Class.java
+ src/java.base/share/classes/java/lang/PublicMethods.java
! src/java.base/share/classes/java/lang/reflect/Constructor.java
! src/java.base/share/classes/java/lang/reflect/Executable.java
! src/java.base/share/classes/java/lang/reflect/Method.java
! src/java.base/share/classes/java/lang/reflect/ReflectAccess.java
! src/java.base/share/classes/jdk/internal/reflect/LangReflectAccess.java
! 

hg: jigsaw/jake/corba: 2 new changesets

[alan . bateman]

Changeset: 68a8e8658511
Author:lana
Date:  2017-01-12 23:41 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/68a8e8658511

Added tag jdk-9+152 for changeset ff8cb43c07c0

! .hgtags

Changeset: f5774ba60ae9
Author:alanb
Date:  2017-01-13 08:31 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/f5774ba60ae9

Merge

hg: jigsaw/jake/langtools: 16 new changesets

[alan . bateman]

Changeset: 9d2379f8dd41
Author:dlsmith
Date:  2017-01-03 16:27 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9d2379f8dd41

8144066: StackOverflowException when computing glb
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/generics/inference/CaptureGLB1.java
+ test/tools/javac/generics/inference/CaptureGLB2.java

Changeset: 7428762055ef
Author:mchung
Date:  2017-01-03 17:53 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7428762055ef

8172212: jdeps --require and --check should detect the specified module in the 
image
Reviewed-by: psandoz, lancea

! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleExportsAnalyzer.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
! test/tools/jdeps/listdeps/ListModuleDeps.java
! test/tools/jdeps/modules/CheckModuleTest.java
! test/tools/jdeps/modules/InverseDeps.java
! test/tools/jdeps/modules/SplitPackage.java

Changeset: 6acc773a9fc6
Author:cushon
Date:  2017-01-03 17:49 -0500
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6acc773a9fc6

8172214: typo in "intersection types in cast are not supported" message
Reviewed-by: mcimadamore

! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties

Changeset: 99eb5778a98e
Author:jjg
Date:  2017-01-04 16:08 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/99eb5778a98e

8171977: Add support for latest messages from 'tidy'
Reviewed-by: darcy

! test/tools/doclint/tidy/util/Main.java

Changeset: 6434bb450074
Author:jjg
Date:  2017-01-04 18:33 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6434bb450074

8172260: remove tests from ProblemList
Reviewed-by: rfield

! test/ProblemList.txt

Changeset: 6cb046ee1000
Author:cushon
Date:  2017-01-05 10:04 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6cb046ee1000

8065800: javac, fix diagnostic position for statement-bodied lambdas
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/tools/javac/lambda/MostSpecific09.java
! test/tools/javac/lambda/MostSpecific09.out

Changeset: 3fee06edc58e
Author:darcy
Date:  2017-01-05 11:02 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3fee06edc58e

8172220: Mark UserInputTest.java as intermittently failing and problem list it
Reviewed-by: jlahoda

! test/ProblemList.txt
! test/jdk/jshell/UserInputTest.java

Changeset: 43dfd4410cdc
Author:mcimadamore
Date:  2017-01-05 19:10 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/43dfd4410cdc

8172287: improve intellij logging to cover javac internal errors
Summary: add new message kind to custom intellij ant logger
Reviewed-by: jjg

! make/intellij/src/idea/LangtoolsIdeaAntLogger.java

Changeset: 9df6a80987de
Author:vromero
Date:  2017-01-05 11:16 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9df6a80987de

8148100: Convert lambda most specific positive tests to check runtime behavior
Reviewed-by: mcimadamore
Contributed-by: bsr...@gmail.com

! test/tools/javac/lambda/MostSpecific10.java
! test/tools/javac/lambda/MostSpecific11.java
! test/tools/javac/lambda/MostSpecific15.java
! test/tools/javac/lambda/MostSpecific17.java
! test/tools/javac/lambda/MostSpecific18.java
! test/tools/javac/lambda/MostSpecific20.java
! test/tools/javac/lambda/MostSpecific22.java
! test/tools/javac/lambda/MostSpecific27.java
! test/tools/javac/lambda/MostSpecific29.java

Changeset: 32ca8ae5899b
Author:vromero
Date:  2017-01-05 11:20 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/32ca8ae5899b

8026699: test 
test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest.java has an 
extra @compile attribute that should be removed
Reviewed-by: mcimadamore

! test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest.java

Changeset: 4bd18eaa387e
Author:lana
Date:  2017-01-05 19:47 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4bd18eaa387e

Merge


Changeset: 2c149bcd54c5
Author:jjg
Date:  2017-01-05 15:39 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2c149bcd54c5

8172311: MostSpecific09.java and PotentiallyAmbiguousWarningTest.java failing 
across platforms
Reviewed-by: vromero

! test/tools/javac/lambda/MostSpecific09.out
! test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest.java
! test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest.out

Changeset: c6b4fefd764c
Author:jlahoda
Date:  2017-01-06 14:16 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c6b4fefd764c

8172158: Annotation processor not 

hg: jigsaw/jake/hotspot: 3 new changesets

[alan . bateman]

Changeset: 31f1d26c60df
Author:erikj
Date:  2017-01-09 11:55 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/31f1d26c60df

8172037: Change log message of SetupCopyFiles
Reviewed-by: tbell

! make/CopyToExplodedJdk.gmk

Changeset: 217ba81b9a4c
Author:lana
Date:  2017-01-12 23:41 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/217ba81b9a4c

Added tag jdk-9+152 for changeset 31f1d26c60df

! .hgtags

Changeset: 4a5832bd159c
Author:alanb
Date:  2017-01-13 08:31 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4a5832bd159c

Merge

! .hgtags

hg: jigsaw/jake: 7 new changesets

[alan . bateman]

Changeset: 6309db93b5df
Author:erikj
Date:  2017-01-04 16:12 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/6309db93b5df

8171922: Hotspot code coverage doesn't seem to work
Reviewed-by: tbell

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4

Changeset: bc89d939e9af
Author:erikj
Date:  2017-01-04 16:14 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/bc89d939e9af

8171500: Explicitly set --with-target-bits=64 in 64bit jib profiles
Reviewed-by: tbell

! common/conf/jib-profiles.js

Changeset: 7b09422f5c83
Author:erikj
Date:  2017-01-04 16:58 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/7b09422f5c83

8171929: "make docs" in clean forest is broken
Reviewed-by: mchung, tbell

! make/Main.gmk

Changeset: b81e883b30fc
Author:lana
Date:  2017-01-05 19:46 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/b81e883b30fc

Merge


Changeset: ef056360ddf3
Author:erikj
Date:  2017-01-09 11:55 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/ef056360ddf3

8172037: Change log message of SetupCopyFiles
Reviewed-by: tbell

! make/CopyImportModules.gmk
! make/ModuleWrapper.gmk
! make/common/MakeBase.gmk

Changeset: c23956f5cbfc
Author:lana
Date:  2017-01-12 23:41 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/c23956f5cbfc

Added tag jdk-9+152 for changeset ef056360ddf3

! .hgtags

Changeset: f78b94f95ed7
Author:alanb
Date:  2017-01-13 08:30 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/f78b94f95ed7

Merge

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/conf/jib-profiles.js
! make/CopyImportModules.gmk
! make/Main.gmk
! make/ModuleWrapper.gmk
! make/common/MakeBase.gmk

hg: jigsaw/jake/nashorn: 5 new changesets

[alan . bateman]

Changeset: 4ec3a2683655
Author:sundar
Date:  2017-01-03 22:14 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/4ec3a2683655

8172183: Provide a javadoc description for jdk.dynalink module
Reviewed-by: attila, jlaskey

! README
- RELEASE_README
! src/jdk.dynalink/share/classes/jdk/dynalink/package-info.java
! src/jdk.dynalink/share/classes/module-info.java

Changeset: d45caa3cd523
Author:sundar
Date:  2017-01-04 18:47 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/d45caa3cd523

8164391: Provide a javadoc description for jdk.scripting.nashorn
Reviewed-by: attila, jlaskey

! make/build.xml
! src/jdk.scripting.nashorn/share/classes/module-info.java
- src/jdk.scripting.nashorn/share/classes/overview.html

Changeset: ddc52e727570
Author:lana
Date:  2017-01-05 19:46 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ddc52e727570

Merge

- RELEASE_README
- src/jdk.scripting.nashorn/share/classes/overview.html

Changeset: 1e35dd50449e
Author:lana
Date:  2017-01-12 23:41 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/1e35dd50449e

Added tag jdk-9+152 for changeset ddc52e727570

! .hgtags

Changeset: f3665ec7f81f
Author:alanb
Date:  2017-01-13 08:32 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f3665ec7f81f

Merge

! .hgtags
- RELEASE_README
! make/build.xml
! src/jdk.scripting.nashorn/share/classes/module-info.java
- src/jdk.scripting.nashorn/share/classes/overview.html

hg: jigsaw/jake/jaxws: 2 new changesets

[alan . bateman]

Changeset: 8da2ea3bc3a9
Author:lana
Date:  2017-01-12 23:41 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/8da2ea3bc3a9

Added tag jdk-9+152 for changeset 6f8fb1cf7e5f

! .hgtags

Changeset: 7cd4b35e4f3a
Author:alanb
Date:  2017-01-13 08:31 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/7cd4b35e4f3a

Merge

hg: jigsaw/jake/jaxp: 2 new changesets

[alan . bateman]

Changeset: 56cedce06f2d
Author:lana
Date:  2017-01-12 23:41 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/56cedce06f2d

Added tag jdk-9+152 for changeset 7e3da313b174

! .hgtags

Changeset: ddb2cfe470a8
Author:alanb
Date:  2017-01-13 08:31 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ddb2cfe470a8

Merge