Re: Ping - Re: RFR 8078812, Test RMI with client and servers as modules

[Jonathan Gibbons]

Stuart,

While I would agree on the use of one type, not two, for file paths, I 
would question the choice to use String instead of Path.  If something 
is a file path, use the type system to say so, and use a Path.


-- Jon

On 05/20/2016 04:52 PM, Stuart Marks wrote:

On 5/16/16 1:18 AM, Felix Yang wrote:
   please review the updated webrev, which remove not-suggested 
filesystem

modification and codebase stuff:

http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.02/


Hi Felix,

OK, this is looking much better and simpler. The big improvement is, 
as we had discussed, the creation of a common fixture for the tests. 
The tests then use the same fixture in different ways to exercise the 
different cases. This makes this more easily extensible to additional 
cases.


First to be done are a few easy cleanups:

* Since we're no longer using a registry, the starting and stopping of 
the registry process in the start- and shutdownRMIRegistry() methods 
is no longer necessary. They can be removed entirely, along with the 
rmiRegistry field.


* The imports they required, along with some other unused import 
statements, can also be removed.


* The fixture setup method, compileAll(), should be annotated 
@BeforeTest instead of @BeforeMethod. Compiling once at the beginning 
of the test should be sufficient.


With these out of the way, my observation is that it's still really 
quite difficult to follow what the test is doing, particularly in 
setting up the text fixture.


One reason for this is the repeated conversions between Path and 
String. Some places need Paths and some need Strings. Path elements 
are concatenated in some places with path.resolve(String) and string 
concatenation with File.separator or File.pathSeparator in others. In 
some cases, fields such as


MODS_DIR = Paths.get("mods")

are defined when in my opinion it'd just be better to use the string 
literal "mods" in a couple places.


In any case I've taken the liberty of posting some cleanups to a 
branch in the sandbox. I've written a couple utilities to concatenate 
strings using File.separator and File.pathSeparator, and I've kept 
things mostly as strings, only converting to Paths when absolutely 
necessary. I've also renamed the directory of compiled classes as the 
"exploded" directory since that's sort-of the descriptive term in use 
for a hierarchy of individual class files.


The sandbox branch is JDK-8078812-branch and the diff from your webrev 
can be viewed here:


http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/befcc172e68e

and the ModuleTest.java file (the only one I modified) can be viewed 
here:



http://hg.openjdk.java.net/jdk9/sandbox/jdk/file/befcc172e68e/test/java/rmi/module/ModuleTest.java 



It's up to you whether you want to accept my changes and continue from 
this point, or go in a different direction, but to my eye this is 
cleaner and easier to follow.


* * *

Now, finally, on to more substantive review issues. :-)

One thing that seemed to be missing was that the application itself 
wasn't wrapped up into a jar file. I've added another Jar command that 
does this.


Now we have the client, server, and app as separate hierarchies under 
the "exploded" directory, and as modules under the "mods" directory.


I think the idea of having the "exploded" class hierarchy as well as 
jar files useful as modules is a good one. This will let you add 
cases, where different components are on the classpath or are loaded 
as modules, in addition to the two already present here.


One issue here is that there's a module-info class for the app. This 
makes the app an actual named module (I think) as opposed to an 
automatic module like the client and server jar files. It seems like 
it would be preferable to be consistent and have them all be automatic 
modules.


Given this arrangement, it should be pretty easy to have tests for any 
of the combinations we want of classpath vs modules. I guess there are 
8 combinations: three components, each of which can be on the 
classpath or as a module. It's not clear to me that we need all 8 
combinations. It's probably sufficient to have a reasonable subset.


An idea for possible future expansion is to mix automatic modules with 
named modules. I'm not entirely sure how to do that. Perhaps one way 
is to have module-info files for all the components, and then create 
variant jar files with the module-info.class omitted. That way we'd 
have a modular jar, and then a "plain" jar (without module-info.class) 
that'd be suitable for use as an automatic module or to be put on the 
classpath. That'd be 3^3=27 combinations, which I certainly think is 
overkill.


In any case, for this initial changeset, I think it's sufficient to 
test a few combinations of automatic modules vs. classpath. We can 
extend the cases to include named modules later. Please make a 
recommendation for some set of combinations and implement it, and then 
send it out for a final round of review.

Re: Ping - Re: RFR 8078812, Test RMI with client and servers as modules

[Stuart Marks]

On 5/16/16 1:18 AM, Felix Yang wrote:

   please review the updated webrev, which remove not-suggested filesystem
modification and codebase stuff:

http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.02/


Hi Felix,

OK, this is looking much better and simpler. The big improvement is, as we had 
discussed, the creation of a common fixture for the tests. The tests then use 
the same fixture in different ways to exercise the different cases. This makes 
this more easily extensible to additional cases.


First to be done are a few easy cleanups:

* Since we're no longer using a registry, the starting and stopping of the 
registry process in the start- and shutdownRMIRegistry() methods is no longer 
necessary. They can be removed entirely, along with the rmiRegistry field.


* The imports they required, along with some other unused import statements, can 
also be removed.


* The fixture setup method, compileAll(), should be annotated @BeforeTest 
instead of @BeforeMethod. Compiling once at the beginning of the test should be 
sufficient.


With these out of the way, my observation is that it's still really quite 
difficult to follow what the test is doing, particularly in setting up the text 
fixture.


One reason for this is the repeated conversions between Path and String. Some 
places need Paths and some need Strings. Path elements are concatenated in some 
places with path.resolve(String) and string concatenation with File.separator or 
File.pathSeparator in others. In some cases, fields such as


MODS_DIR = Paths.get("mods")

are defined when in my opinion it'd just be better to use the string literal 
"mods" in a couple places.


In any case I've taken the liberty of posting some cleanups to a branch in the 
sandbox. I've written a couple utilities to concatenate strings using 
File.separator and File.pathSeparator, and I've kept things mostly as strings, 
only converting to Paths when absolutely necessary. I've also renamed the 
directory of compiled classes as the "exploded" directory since that's sort-of 
the descriptive term in use for a hierarchy of individual class files.


The sandbox branch is JDK-8078812-branch and the diff from your webrev can be 
viewed here:


http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/befcc172e68e

and the ModuleTest.java file (the only one I modified) can be viewed here:


http://hg.openjdk.java.net/jdk9/sandbox/jdk/file/befcc172e68e/test/java/rmi/module/ModuleTest.java

It's up to you whether you want to accept my changes and continue from this 
point, or go in a different direction, but to my eye this is cleaner and easier 
to follow.


* * *

Now, finally, on to more substantive review issues. :-)

One thing that seemed to be missing was that the application itself wasn't 
wrapped up into a jar file. I've added another Jar command that does this.


Now we have the client, server, and app as separate hierarchies under the 
"exploded" directory, and as modules under the "mods" directory.


I think the idea of having the "exploded" class hierarchy as well as jar files 
useful as modules is a good one. This will let you add cases, where different 
components are on the classpath or are loaded as modules, in addition to the two 
already present here.


One issue here is that there's a module-info class for the app. This makes the 
app an actual named module (I think) as opposed to an automatic module like the 
client and server jar files. It seems like it would be preferable to be 
consistent and have them all be automatic modules.


Given this arrangement, it should be pretty easy to have tests for any of the 
combinations we want of classpath vs modules. I guess there are 8 combinations: 
three components, each of which can be on the classpath or as a module. It's not 
clear to me that we need all 8 combinations. It's probably sufficient to have a 
reasonable subset.


An idea for possible future expansion is to mix automatic modules with named 
modules. I'm not entirely sure how to do that. Perhaps one way is to have 
module-info files for all the components, and then create variant jar files with 
the module-info.class omitted. That way we'd have a modular jar, and then a 
"plain" jar (without module-info.class) that'd be suitable for use as an 
automatic module or to be put on the classpath. That'd be 3^3=27 combinations, 
which I certainly think is overkill.


In any case, for this initial changeset, I think it's sufficient to test a few 
combinations of automatic modules vs. classpath. We can extend the cases to 
include named modules later. Please make a recommendation for some set of 
combinations and implement it, and then send it out for a final round of review.


Thanks.

s'marks

Re: 8152650: ModuleFinder.compose should accept varargs

[Mandy Chung]

> On May 20, 2016, at 1:57 PM, Alan Bateman  wrote:
> 
> 
> There are several patches that didn't go in with the last update, the change 
> to ModuleFinder.compose to use varargs was one of them. The other part to 
> this is removing the empty() method as it is redundant. The changes are 
> straight-forward:
>  http://cr.openjdk.java.net/~alanb/8152650/webrev/

This looks good to me.

Mandy

RE: Compact profiles broken?

[Uwe Schindler]

Hi Alan,

Look here:

import javax.xml.bind.DatatypeConverter;

public class Test {
  public static void main(String... args) throws Exception {
DatatypeConverter.parseBoolean("true");
  }
}


$ javac Test.java
Test.java:1: error: package javax.xml.bind does not exist
import javax.xml.bind.DatatypeConverter;
 ^
Test.java:5: error: cannot find symbol
DatatypeConverter.parseBoolean("true");
^
  symbol:   variable DatatypeConverter
  location: class Test
2 errors

$ javac -source 8 -target 8 Test.java
warning: [options] bootstrap class path not set in conjunction with -source 1.8
1 warning

Of course it also passes with -release 8, but thats very clear, because it uses 
ct.sym of older version.

Uwe

-
Uwe Schindler
uschind...@apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
> From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf
> Of Uwe Schindler
> Sent: Saturday, May 21, 2016 12:23 AM
> To: 'Alan Bateman' ; jigsaw-
> d...@openjdk.java.net
> Subject: RE: Compact profiles broken?
> 
> Hi,
> 
> > > FYI, this also explains why we did not see a compile failure about the
> > java.xml.bind issue (see previous mails)! This only failed at runtime,
> because
> > with Jigsaw, the java.xml.bind is not exposed by the root modules. But
> while
> > compiling it seems to see all those classes, as its compiled against
> > source/target 8 where the module system is ignored. So there is also room
> > for improvement! Alan?
> > >
> > I think that's right as when compiling with -source/-target 8 they you
> > are also specifying -bootclasspath (at least I assume you are) and so
> > those types should be visible.
> 
> No, we don't. But they were still visible to javac. But that’s fixed already 
> in
> our build (we removed the class reference and we changed the build in Java
> 9, see below)!
> 
> Please note: I changed the Lucene/Solr build to now use "-release" if it
> detects Java 9 (very easy with Apache Ant). Elasticsearch is still 
> investiagting
> how to do this with Gradle... :(
> 
> https://issues.apache.org/jira/browse/LUCENE-7292
> 
> Uwe

Re: RFR 8156497: Add jar tool support for Multi-release modular JARs

[Alan Bateman]

On 20/05/2016 16:55, Chris Hegarty wrote:

:

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

Note: while there are some new test scenarios added, which give
reasonable coverage, further tests will be added later. Steve has some
additional jar tools support coming for easier creation of MRJARS.



The checks looks right.

In checkModuleInfos then I assume you can use findFirst instead of 
collecting the module-infos into a set.


The comment in computeHashes is confusing - too many "as" :-)

You might want to re-read the error messages to see if they can be 
improved. For example "Invalid versioned module-info.class ..." might be 
better as "module-info.class in versioned section ...". Another one is 
"Unexpected versioned module-info.class without root module-info.class" 
where it might be clearer to say "module-info.class found in versions 
section of JAR file, no module-info.class found in root directory" or 
something like that.


Looks like the copyright headers have the Classpath exception so now 
might be a good time to fix those.


-Alan

8152650: ModuleFinder.compose should accept varargs

[Alan Bateman]

There are several patches that didn't go in with the last update, the 
change to ModuleFinder.compose to use varargs was one of them. The other 
part to this is removing the empty() method as it is redundant. The 
changes are straight-forward:

  http://cr.openjdk.java.net/~alanb/8152650/webrev/

I dropped the changes to the langtools repo as Jon/Vicente have a patch 
in flight that drops empty(). Also the last round of jdeps updates 
removed the use of empty().


-Alan.

Re: Weird use case: compiling against dummy sun.misc.* class

[Aleksey Shipilev]

On 05/20/2016 07:13 PM, Alan Bateman wrote:
> On 20/05/2016 16:55, Aleksey Shipilev wrote:
> jcstress is boot loader so I assume multi-release JARs are out of the
> question?

Yes, a simple workaround would be better than doing MR JARs at this
point. We have >50 Mb JARs as it is, MR JARs would be at least twice as
that if we ship JDK <=8 and JDK >=9 classes in the same package.

> So what is the javac command that you are using? If you are compiling
> sun/misc/Contented.java then I would expect to see `javac
> -Xmodule:jdk.unsupported` so that it is compiled "as if" part of the
> jdk.unsupported module.

-Xmodule:jdk.unsupported definitely works, thanks!

What are the drawbacks for enabling this? I can easily enable that
globally for the entire project, but that would compile all project
files as if in the jdk.unsupported module? I guess that does not matter
if I don't produce/deploy the module as the build artifact.

(Aside: by reading the javac source code, I discovered -XDnoModules,
which also works, but hidden, unsupported, fragile, and scary)

Thanks,
-Aleksey

Re: RFR 8156497: Add jar tool support for Multi-release modular JARs

[Chris Hegarty]

> On 20 May 2016, at 17:01, Jonathan Gibbons  
> wrote:
> 
> It would be good if (eventually) there were test cases involving the use
> of MRM jars, both via the JarFile API and jar-fs file system, perhaps
> extending to the use of MRM jars in javac as well.

I agree.

Just to note, the updated test in the webrev is already exercising the JarFile
API, indirectly. Support for Modular JARs on the module path uses the 
JarFile constructor that accepts a JarFile.Release value when opening.
The test exercises this when it verifies the newly created, or updated, JAR
file by running the module’s entry point.

But I agree, more test scenarios will need to be added.

-Chris.

> -- Jon
> 
> On 05/20/2016 08:55 AM, Chris Hegarty wrote:
>> What do you get if you mix JEP 261 [1] with JEP 238 [2]?
>> A Multi-release modular JAR.
>> 
>> This issue proposes to add support to the jar tool for creating and
>> updating modular JAR files with an optional module-info.class in the
>> versioned section.
>> 
>> MRJARs are intended to target multiple releases of the Java platform, so
>> it seems reasonable for a Multi-release modular JAR ( MRMJAR ) to be
>> able to declare a different set of dependencies on modules that are part
>> of the Java platform. The reasoning here is that these are
>> implementation details rather than parts of a module's API surface, and
>> that one may well want to change them as the JDK itself evolves. The
>> runtime already has support for loading from the versioned section.
>> 
>> Specifically, a versioned module descriptor must be identical to the
>> root module descriptor, with two exceptions:
>> 
>> - A versioned descriptor can have different non-public `requires`
>> clauses of platform ( `java.*` and `jdk.*` ) modules, and
>> 
>> - A versioned descriptor can have different `uses` clauses, even of
>> service types defined outside of `java.*` and `jdk.*` modules.
>> 
>> http://cr.openjdk.java.net/~chegar/8156497.00/
>> 
>> Note: while there are some new test scenarios added, which give
>> reasonable coverage, further tests will be added later. Steve has some
>> additional jar tools support coming for easier creation of MRJARS.
>> 
>> -Chris.
>> 
>> [1] http://openjdk.java.net/jeps/261
>> [2] http://openjdk.java.net/jeps/238
> 

Re: Weird use case: compiling against dummy sun.misc.* class

[Alex Buckley]

If you have your own sun.misc.FOO on the classpath, then you DON'T want 
a module exporting sun.misc to be readable, because that module is where 
javac and the runtime will get sun.misc.* types from. So, no need to add 
readability of the jdk.unsupported module which is not read by default 
on JDK 9b118.


javac "should" be observing your sun.misc.Contended type out of the box 
-- there may be a javac bug or some other problem with how javac is 
invoked, please send more details.


I assume that the jdk.internal.annotations package exists in java.base 
so at run time you'll need to -Xpatch your 
jdk.internal.annotations.Contended type into java.base.


Alex

On 5/20/2016 8:55 AM, Aleksey Shipilev wrote:

Hi,

I have a weird use case in jcstress around @Contended.

In order to support both JDK 8 and JDK 9 we build against *our own*
sun.misc.Contended and jdk.internal.annotations.Contended. This works
arguably well for both compiling and running with both JDK 8 and JDK 9:
the real annotation gets picked up from the JDK.

However, since JDK 9b118 we cannot build anymore, because:

LongResult1_jcstress.java:[3,13] error: Contended is not visible because
package sun.misc is not visible

...even though sun/misc/Contended.java is right here in my source tree.
Is there a magic incantation to make javac proceed? The usual tricks did
not help (probably because the target class is not in jdk.unsupported,
but rather in the source tree itself):
   -addmods jdk.unsupported
   -XaddExports:jdk.unsupported/sun.misc=ALL-UNNAMED
   -XaddReads:jdk.unsupported=ALL-UNNAMED

Thanks,
-Aleksey

Re: Weird use case: compiling against dummy sun.misc.* class

[Alan Bateman]

On 20/05/2016 16:55, Aleksey Shipilev wrote:

Hi,

I have a weird use case in jcstress around @Contended.

In order to support both JDK 8 and JDK 9 we build against *our own*
sun.misc.Contended and jdk.internal.annotations.Contended. This works
arguably well for both compiling and running with both JDK 8 and JDK 9:
the real annotation gets picked up from the JDK.

However, since JDK 9b118 we cannot build anymore, because:

LongResult1_jcstress.java:[3,13] error: Contended is not visible because
package sun.misc is not visible

...even though sun/misc/Contended.java is right here in my source tree.
Is there a magic incantation to make javac proceed? The usual tricks did
not help (probably because the target class is not in jdk.unsupported,
but rather in the source tree itself):
   -addmods jdk.unsupported
   -XaddExports:jdk.unsupported/sun.misc=ALL-UNNAMED
   -XaddReads:jdk.unsupported=ALL-UNNAMED

jcstress is boot loader so I assume multi-release JARs are out of the 
question?


So what is the javac command that you are using? If you are compiling 
sun/misc/Contented.java then I would expect to see `javac 
-Xmodule:jdk.unsupported` so that it is compiled "as if" part of the 
jdk.unsupported module.


-Alan

Re: RFR 8156497: Add jar tool support for Multi-release modular JARs

[Alexandre (Shura) Iline]

Chris,

Does the test need to use @modules for jdk.jartool and java.compiler?

Shura

> On May 20, 2016, at 8:55 AM, Chris Hegarty  wrote:
> 
> What do you get if you mix JEP 261 [1] with JEP 238 [2]?
> A Multi-release modular JAR.
> 
> This issue proposes to add support to the jar tool for creating and
> updating modular JAR files with an optional module-info.class in the
> versioned section.
> 
> MRJARs are intended to target multiple releases of the Java platform, so
> it seems reasonable for a Multi-release modular JAR ( MRMJAR ) to be
> able to declare a different set of dependencies on modules that are part
> of the Java platform. The reasoning here is that these are
> implementation details rather than parts of a module's API surface, and
> that one may well want to change them as the JDK itself evolves. The
> runtime already has support for loading from the versioned section.
> 
> Specifically, a versioned module descriptor must be identical to the
> root module descriptor, with two exceptions:
> 
> - A versioned descriptor can have different non-public `requires`
> clauses of platform ( `java.*` and `jdk.*` ) modules, and
> 
> - A versioned descriptor can have different `uses` clauses, even of
> service types defined outside of `java.*` and `jdk.*` modules.
> 
> http://cr.openjdk.java.net/~chegar/8156497.00/
> 
> Note: while there are some new test scenarios added, which give
> reasonable coverage, further tests will be added later. Steve has some
> additional jar tools support coming for easier creation of MRJARS. 
> 
> -Chris.
> 
> [1] http://openjdk.java.net/jeps/261
> [2] http://openjdk.java.net/jeps/238

Re: RFR 8156497: Add jar tool support for Multi-release modular JARs

[Jonathan Gibbons]

It would be good if (eventually) there were test cases involving the use
of MRM jars, both via the JarFile API and jar-fs file system, perhaps
extending to the use of MRM jars in javac as well.

-- Jon

On 05/20/2016 08:55 AM, Chris Hegarty wrote:

What do you get if you mix JEP 261 [1] with JEP 238 [2]?
A Multi-release modular JAR.

This issue proposes to add support to the jar tool for creating and
updating modular JAR files with an optional module-info.class in the
versioned section.

MRJARs are intended to target multiple releases of the Java platform, so
it seems reasonable for a Multi-release modular JAR ( MRMJAR ) to be
able to declare a different set of dependencies on modules that are part
of the Java platform. The reasoning here is that these are
implementation details rather than parts of a module's API surface, and
that one may well want to change them as the JDK itself evolves. The
runtime already has support for loading from the versioned section.

Specifically, a versioned module descriptor must be identical to the
root module descriptor, with two exceptions:

- A versioned descriptor can have different non-public `requires`
clauses of platform ( `java.*` and `jdk.*` ) modules, and

- A versioned descriptor can have different `uses` clauses, even of
service types defined outside of `java.*` and `jdk.*` modules.

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

Note: while there are some new test scenarios added, which give
reasonable coverage, further tests will be added later. Steve has some
additional jar tools support coming for easier creation of MRJARS.

-Chris.

[1] http://openjdk.java.net/jeps/261
[2] http://openjdk.java.net/jeps/238

RFR 8156497: Add jar tool support for Multi-release modular JARs

[Chris Hegarty]

What do you get if you mix JEP 261 [1] with JEP 238 [2]?
A Multi-release modular JAR.

This issue proposes to add support to the jar tool for creating and
updating modular JAR files with an optional module-info.class in the
versioned section.

MRJARs are intended to target multiple releases of the Java platform, so
it seems reasonable for a Multi-release modular JAR ( MRMJAR ) to be
able to declare a different set of dependencies on modules that are part
of the Java platform. The reasoning here is that these are
implementation details rather than parts of a module's API surface, and
that one may well want to change them as the JDK itself evolves. The
runtime already has support for loading from the versioned section.

Specifically, a versioned module descriptor must be identical to the
root module descriptor, with two exceptions:

- A versioned descriptor can have different non-public `requires`
clauses of platform ( `java.*` and `jdk.*` ) modules, and

- A versioned descriptor can have different `uses` clauses, even of
service types defined outside of `java.*` and `jdk.*` modules.

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

Note: while there are some new test scenarios added, which give
reasonable coverage, further tests will be added later. Steve has some
additional jar tools support coming for easier creation of MRJARS. 

-Chris.

[1] http://openjdk.java.net/jeps/261
[2] http://openjdk.java.net/jeps/238

Weird use case: compiling against dummy sun.misc.* class

[Aleksey Shipilev]

Hi,

I have a weird use case in jcstress around @Contended.

In order to support both JDK 8 and JDK 9 we build against *our own*
sun.misc.Contended and jdk.internal.annotations.Contended. This works
arguably well for both compiling and running with both JDK 8 and JDK 9:
the real annotation gets picked up from the JDK.

However, since JDK 9b118 we cannot build anymore, because:

LongResult1_jcstress.java:[3,13] error: Contended is not visible because
package sun.misc is not visible

...even though sun/misc/Contended.java is right here in my source tree.
Is there a magic incantation to make javac proceed? The usual tricks did
not help (probably because the target class is not in jdk.unsupported,
but rather in the source tree itself):
  -addmods jdk.unsupported
  -XaddExports:jdk.unsupported/sun.misc=ALL-UNNAMED
  -XaddReads:jdk.unsupported=ALL-UNNAMED

Thanks,
-Aleksey

RE: Mutable modules

[Stephen Felts]

I was on a project using OSGi where some of the applications relied on removing 
and replacing modules.
Generally they replaced applications modules at the top with no dependencies 
into the module.
For example, in one application that dealt with RFID, it was common for new 
RFID clients to be introduced or modifications required to existing RFID 
clients (the technology was changing very quickly).
The handling of these clients was done with modules that could be swapped in as 
necessary.
There were well defined interfaces with various implementations for the 
different clients.

-Original Message-
From: Neil Bartlett [mailto:njbartl...@gmail.com] 
Sent: Friday, May 20, 2016 11:20 AM
To: Alan Bateman
Cc: jigsaw-dev
Subject: Re: Mutable modules


> On 20 May 2016, at 15:12, Alan Bateman  wrote:
> 
> On 18/05/2016 22:47, David M. Lloyd wrote:
>> 
>> I mean in *our* current concept of a module, we can add/remove/modify the 
>> contents of a module (its "class path") at run time.  It is up to the user 
>> to ensure that doing so makes sense.
> I don't think I can relate to the use case. As you probably know then ZIP 
> files have historically had their central directory mapped into memory. 
> Removing or replacing a file that is memory mapped will likely lead to 
> processes accessing the mapped file to crash (SIGBUS usually). So if users 
> are really doing such hairy things they would need a lot of insight into what 
> is running and whether the file is opened before taking this risk.
> 

Mutable module graphs have an 18 year history in OSGi, so they are certainly 
practical, of course with certain limitations. The use cases are to allow 
runtime installation or upgrade of modules without shutting down an entire 
application. Such capabilities proved indispensable in OSGi’s original market 
of home gateways, and now in the IoT world.

They key point is that it is a cooperative mechanism. When a module is 
uninstalled in OSGi, a callback is sent to the module in question, and it is 
then responsible for safely cleaning up anything that it was doing. If it does 
so properly then the module, along with all of its loaded objects, their 
classes and the classloader, become available for garbage collection. When a 
module is updated, a new classloader is created for the new version. Therefore 
if a module fails to implement correct clean-up and is updated many times, you 
have a memory leak. This is inescapable… the JVM can no more force a module to 
unload then it can force a thread to stop, and we all know the dire 
consequences of calling Thread#stop().

In case of a dependency (module A imports a package from module B), when B is 
uninstalled then module A must be refreshed. This involves calling the shutdown 
callback on modules A and B, and then re-resolving A. That resolution will 
likely fail as it will not be able to import the required packaged (unless they 
are exported from somewhere else).

Obviously this model depends heavily on a 1-to-1 mapping of classloaders to 
modules, in common with the JBoss Module System as described previously by 
David Lloyd.

>> :
>> 
>> Our modules each correspond to their own class loader: so far so good, we 
>> can just have one Module per class loader.  Problem is that we support 
>> circularity, and also we support dependencies that go across module systems 
>> with isolated namespaces (basically, our module loaders are a higher order 
>> of the exact same concept of class loaders).
> If there are cyclic relationships between your modules then it will be 
> problematic. Do you see much of this? If you've read Alex's JavaOne slides 
> then you'll know that some of us like Kirk Knoernschild's book on Java 
> Application Architecture and section "4.4 Cyclic Dependencies - the Death 
> Knell" where he poses the question "Are Cycles Always Bad?". I don't want to 
> say too much on this topic here as it is listed as an open issue on the JSR 
> issues list.
> 

OSGi permits cyclical dependencies, but such cycles can only be resolved 
all-at-once. This is essentially why OSGi separates its resolution phase (i.e. 
solving all dependencies) from its activation phase. Modules involved in a 
cycle will not be GC’d until all of the modules in that cycle are uninstalled 
or refreshed.


>> 
>> Our modules support specifications including the content of the module 
>> ("resource loaders") and the dependencies of the module. At run time, custom 
>> ModuleLoader implementations can change the resource loader list and/or the 
>> dependency list at any time, causing the module to be relinked on the spot; 
>> the most useful aspect of this is the ability to incrementally deploy 
>> applications which may include circular dependencies. 
> Aside from cycles then what other use-cases do you have here? I read "change 
> the resource loader list" to mean that the set of resources in the module 
> changes, which is a bit weird if those resources are class 

Re: Mutable modules

[David M. Lloyd]

On 05/20/2016 09:12 AM, Alan Bateman wrote:

On 18/05/2016 22:47, David M. Lloyd wrote:


I mean in *our* current concept of a module, we can add/remove/modify
the contents of a module (its "class path") at run time.  It is up to
the user to ensure that doing so makes sense.

I don't think I can relate to the use case. As you probably know then
ZIP files have historically had their central directory mapped into
memory. Removing or replacing a file that is memory mapped will likely
lead to processes accessing the mapped file to crash (SIGBUS usually).
So if users are really doing such hairy things they would need a lot of
insight into what is running and whether the file is opened before
taking this risk.


No, we don't support replacement of JAR files; more like we symbolically 
remove the resources and add overlays.  Internally, we generally explode 
JAR files for various reasons.  It has nothing to do with JAR files, 
more to do with the logical presence and absence of class files and 
resources.



Our modules each correspond to their own class loader: so far so good,
we can just have one Module per class loader.  Problem is that we
support circularity, and also we support dependencies that go across
module systems with isolated namespaces (basically, our module loaders
are a higher order of the exact same concept of class loaders).

If there are cyclic relationships between your modules then it will be
problematic. Do you see much of this? If you've read Alex's JavaOne
slides then you'll know that some of us like Kirk Knoernschild's book on
Java Application Architecture and section "4.4 Cyclic Dependencies - the
Death Knell" where he poses the question "Are Cycles Always Bad?". I
don't want to say too much on this topic here as it is listed as an open
issue on the JSR issues list.


We use circular dependencies in both our static module layouts and also 
in our dynamic deployment system.  I don't think we have a clear path 
out if we can't support them; it will certainly be a difficult situation.



Our modules support specifications including the content of the module
("resource loaders") and the dependencies of the module. At run time,
custom ModuleLoader implementations can change the resource loader
list and/or the dependency list at any time, causing the module to be
relinked on the spot; the most useful aspect of this is the ability to
incrementally deploy applications which may include circular
dependencies.

Aside from cycles then what other use-cases do you have here? I read
"change the resource loader list" to mean that the set of resources in
the module changes, which is a bit weird if those resources are class
files that have already been loaded. Maybe there is dynamic code
generation with class bytes generated to the file system or into
somewhere virtual? Or maybe these resources are something else, data
files? I'm just trying to understand what you mean as we are using
differently terminology.


Within our module concept, the "class path" is a sort of colloquial term 
which refers to the series of resource loaders used to locate classes 
and resources within each module.  Functionally it's somewhat analogous 
to the URLClassPath concept in the JDK, in the way that resources are 
sought (i.e. by a linear search from start to end of the list).


This is separate from the module dependency list, which, when combined 
with the resource loader list, is used to construct an index by path 
(which is a superset of packages that includes not just classes but also 
resources) which refers to dependencies and/or internal resources.


When the resource list is changed, all future lookups for classes and 
resources will use the new index.  If there are already classes loaded 
from the previous list, and those classes are sufficiently incompatible 
with the new code, obviously this will result in errors; however, this 
is usually not the case when (say) making incremental changes during 
development.  This is generally an edge case, but it is one which we 
presently support.


Changing the dependency list has effects that are somewhat similar. 
Existing loaded classes which have already linked against classes of the 
previous dependency may malfunction when doing this.  But in the hot 
deployment situation, most of the time these changes are additive, so 
the effect is generally to enable previously unlinked code to become 
linkable.  This could happen, for example, when deploying a JAR some 
time after a first JAR was deployed, which resolves some missing 
dependencies in the first JAR.



We also support delegating "fallback" class loading decisions to
outside suppliers for dynamic class loading behavior (this was done to
support a dynamic OSGi environment).  The ongoing integrity of the
system is up to the party doing the relinking (the EE deployer or the
OSGi resolver); most of the time it can reason about what is "safe"
and what might cause system breakage (but still might be useful to do

Re: Mutable modules

[Neil Bartlett]

> On 20 May 2016, at 15:12, Alan Bateman  wrote:
> 
> On 18/05/2016 22:47, David M. Lloyd wrote:
>> 
>> I mean in *our* current concept of a module, we can add/remove/modify the 
>> contents of a module (its "class path") at run time.  It is up to the user 
>> to ensure that doing so makes sense.
> I don't think I can relate to the use case. As you probably know then ZIP 
> files have historically had their central directory mapped into memory. 
> Removing or replacing a file that is memory mapped will likely lead to 
> processes accessing the mapped file to crash (SIGBUS usually). So if users 
> are really doing such hairy things they would need a lot of insight into what 
> is running and whether the file is opened before taking this risk.
> 

Mutable module graphs have an 18 year history in OSGi, so they are certainly 
practical, of course with certain limitations. The use cases are to allow 
runtime installation or upgrade of modules without shutting down an entire 
application. Such capabilities proved indispensable in OSGi’s original market 
of home gateways, and now in the IoT world.

They key point is that it is a cooperative mechanism. When a module is 
uninstalled in OSGi, a callback is sent to the module in question, and it is 
then responsible for safely cleaning up anything that it was doing. If it does 
so properly then the module, along with all of its loaded objects, their 
classes and the classloader, become available for garbage collection. When a 
module is updated, a new classloader is created for the new version. Therefore 
if a module fails to implement correct clean-up and is updated many times, you 
have a memory leak. This is inescapable… the JVM can no more force a module to 
unload then it can force a thread to stop, and we all know the dire 
consequences of calling Thread#stop().

In case of a dependency (module A imports a package from module B), when B is 
uninstalled then module A must be refreshed. This involves calling the shutdown 
callback on modules A and B, and then re-resolving A. That resolution will 
likely fail as it will not be able to import the required packaged (unless they 
are exported from somewhere else).

Obviously this model depends heavily on a 1-to-1 mapping of classloaders to 
modules, in common with the JBoss Module System as described previously by 
David Lloyd.

>> :
>> 
>> Our modules each correspond to their own class loader: so far so good, we 
>> can just have one Module per class loader.  Problem is that we support 
>> circularity, and also we support dependencies that go across module systems 
>> with isolated namespaces (basically, our module loaders are a higher order 
>> of the exact same concept of class loaders).
> If there are cyclic relationships between your modules then it will be 
> problematic. Do you see much of this? If you've read Alex's JavaOne slides 
> then you'll know that some of us like Kirk Knoernschild's book on Java 
> Application Architecture and section "4.4 Cyclic Dependencies - the Death 
> Knell" where he poses the question "Are Cycles Always Bad?". I don't want to 
> say too much on this topic here as it is listed as an open issue on the JSR 
> issues list.
> 

OSGi permits cyclical dependencies, but such cycles can only be resolved 
all-at-once. This is essentially why OSGi separates its resolution phase (i.e. 
solving all dependencies) from its activation phase. Modules involved in a 
cycle will not be GC’d until all of the modules in that cycle are uninstalled 
or refreshed.


>> 
>> Our modules support specifications including the content of the module 
>> ("resource loaders") and the dependencies of the module. At run time, custom 
>> ModuleLoader implementations can change the resource loader list and/or the 
>> dependency list at any time, causing the module to be relinked on the spot; 
>> the most useful aspect of this is the ability to incrementally deploy 
>> applications which may include circular dependencies. 
> Aside from cycles then what other use-cases do you have here? I read "change 
> the resource loader list" to mean that the set of resources in the module 
> changes, which is a bit weird if those resources are class files that have 
> already been loaded. Maybe there is dynamic code generation with class bytes 
> generated to the file system or into somewhere virtual? Or maybe these 
> resources are something else, data files? I'm just trying to understand what 
> you mean as we are using differently terminology.
> 
>> We also support delegating "fallback" class loading decisions to outside 
>> suppliers for dynamic class loading behavior (this was done to support a 
>> dynamic OSGi environment).  The ongoing integrity of the system is up to the 
>> party doing the relinking (the EE deployer or the OSGi resolver); most of 
>> the time it can reason about what is "safe" and what might cause system 
>> breakage (but still might be useful to do anyway).  These are the 

hg: jigsaw/jake/corba: 2 new changesets

[alan . bateman]

Changeset: 5943b791e131
Author:lana
Date:  2016-05-19 17:48 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/5943b791e131

Added tag jdk-9+119 for changeset daf533920b12

! .hgtags

Changeset: 5be3e5d01967
Author:alanb
Date:  2016-05-20 07:15 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/5be3e5d01967

Merge

hg: jigsaw/jake/langtools: 11 new changesets

[alan . bateman]

Changeset: f92cc177314f
Author:jjg
Date:  2016-05-09 16:52 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f92cc177314f

8075703: jdk.javadoc module exports com.sun.tools.javadoc package which 
contains a lot of internal API.
Reviewed-by: ksrini

! 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java
- 
src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Comment.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocEnv.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocLocale.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocletInvoker.java
- 
src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocClassFinder.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocEnter.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocTodo.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocTool.java
! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Main.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/MemberDocImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Messager.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/MethodDocImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ModifierFilter.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/PackageDocImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ParamTagImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ParameterImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/PrimitiveType.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/RootDocImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SerializedForm.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Start.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/TagImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ToolOption.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/TypeMaker.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java
+ src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AbstractTypeImpl.java
+ 
src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotatedTypeImpl.java
+ 
src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotationDescImpl.java
+ 
src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotationTypeDocImpl.java
+ 
src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotationTypeElementDocImpl.java
+ 
src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotationValueImpl.java
+ src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ClassDocImpl.java
+ src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/Comment.java
+ 
src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ConstructorDocImpl.java
+ src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocEnv.java
+ src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocImpl.java
+ src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocLocale.java
+ src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocletInvoker.java
+ 
src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ExecutableMemberDocImpl.java
+ src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/FieldDocImpl.java
+ 

hg: jigsaw/jake/jaxp: 9 new changesets

[alan . bateman]

Changeset: 6390a20678d6
Author:joehw
Date:  2016-05-09 14:58 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/6390a20678d6

8152912: SAX XMLReaderFactory needs to be ServiceLoader compliant
Reviewed-by: dfuchs

! src/java.xml/share/classes/module-info.java
! src/java.xml/share/classes/org/xml/sax/AttributeList.java
! src/java.xml/share/classes/org/xml/sax/DocumentHandler.java
! src/java.xml/share/classes/org/xml/sax/Parser.java
! src/java.xml/share/classes/org/xml/sax/helpers/NewInstance.java
! src/java.xml/share/classes/org/xml/sax/helpers/ParserFactory.java
! src/java.xml/share/classes/org/xml/sax/helpers/SecuritySupport.java
! src/java.xml/share/classes/org/xml/sax/helpers/XMLReaderFactory.java

Changeset: 78b710ed047a
Author:amlu
Date:  2016-05-10 10:45 +0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/78b710ed047a

8156513: Problem list javax/xml/jaxp/unittest/stream/FactoryFindTest.java
Reviewed-by: rriggs, joehw

! test/ProblemList.txt

Changeset: a3c5b5a6b125
Author:fyuan
Date:  2016-05-10 00:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a3c5b5a6b125

8156119: Update ServiceProviderTest for XMLReaderFactory
Reviewed-by: joehw
Contributed-by: Frank Yuan 

! test/javax/xml/jaxp/module/ServiceProviderTest/BasicModularXMLParserTest.java
! test/javax/xml/jaxp/module/ServiceProviderTest/LayerModularXMLParserTest.java
+ test/javax/xml/jaxp/module/ServiceProviderTest/XMLReaderFactoryTest.java
! 
test/javax/xml/jaxp/module/ServiceProviderTest/src/test/test/XMLFactoryHelper.java
! test/javax/xml/jaxp/module/ServiceProviderTest/src/unnamed/Main.java
! 
test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider2/module-info.java
+ 
test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider2/xp2/XMLReaderImpl.java
+ 
test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider3/legacy/META-INF/services/org.xml.sax.driver
+ 
test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider3/service/META-INF/services/org.xml.sax.XMLReader
+ 
test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider3/xp3/XMLReaderImpl.java

Changeset: bfc9ec1a816b
Author:joehw
Date:  2016-05-10 16:19 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/bfc9ec1a816b

8046274: Removing dependency on jakarta-regexp
Reviewed-by: lancea

! THIRD_PARTY_README
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/InstructionFinder.java
- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/CharacterArrayCharacterIterator.java
- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/CharacterIterator.java
- src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RE.java
- src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RECompiler.java
- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REDebugCompiler.java
- src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REProgram.java
- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RESyntaxException.java
- src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RETest.java
- src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REUtil.java
- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/ReaderCharacterIterator.java
- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/StreamCharacterIterator.java
- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/StringCharacterIterator.java
- src/java.xml/share/classes/com/sun/org/apache/regexp/internal/recompile.java

Changeset: e59017d60861
Author:sla
Date:  2016-05-11 11:05 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e59017d60861

8156658: Common way to run jtreg tests
Reviewed-by: erikj, dsamersoff

! test/Makefile

Changeset: f2bd0abeb775
Author:lana
Date:  2016-05-12 18:46 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f2bd0abeb775

Merge

- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/CharacterArrayCharacterIterator.java
- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/CharacterIterator.java
- src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RE.java
- src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RECompiler.java
- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REDebugCompiler.java
- src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REProgram.java
- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RESyntaxException.java
- src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RETest.java
- src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REUtil.java
- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/ReaderCharacterIterator.java
- 
src/java.xml/share/classes/com/sun/org/apache/regexp/internal/StreamCharacterIterator.java
- 

hg: jigsaw/jake/hotspot: 5 new changesets

[alan . bateman]

Changeset: c4db9d7b2ee1
Author:sla
Date:  2016-05-11 11:04 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c4db9d7b2ee1

8156658: Common way to run jtreg tests
Reviewed-by: erikj, dsamersoff

! test/Makefile

Changeset: a389eb33db44
Author:mchung
Date:  2016-05-12 11:16 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a389eb33db44

8155977: ObjectInputStream::resolveClass & resolveProxyClass for platform loader
Reviewed-by: acorn, alanb, chegar, dfuchs

! src/share/vm/prims/jvm.cpp

Changeset: 15f3fe264872
Author:lana
Date:  2016-05-12 18:46 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/15f3fe264872

Merge


Changeset: 7eab471aeaf0
Author:lana
Date:  2016-05-19 17:48 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7eab471aeaf0

Added tag jdk-9+119 for changeset 15f3fe264872

! .hgtags

Changeset: f2c539d0681f
Author:alanb
Date:  2016-05-20 07:15 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f2c539d0681f

Merge

! .hgtags
! src/share/vm/prims/jvm.cpp

hg: jigsaw/jake/jaxws: 2 new changesets

[alan . bateman]

Changeset: ecd0d6a71c7c
Author:lana
Date:  2016-05-19 17:48 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/ecd0d6a71c7c

Added tag jdk-9+119 for changeset 331a825f849a

! .hgtags

Changeset: 7e979d9e857b
Author:alanb
Date:  2016-05-20 07:15 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/7e979d9e857b

Merge

hg: jigsaw/jake/jdk: 42 new changesets

[alan . bateman]

Changeset: e935f0b48514
Author:prappo
Date:  2016-05-09 23:33 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e935f0b48514

8087113: Websocket API and implementation
Reviewed-by: chegar

- src/java.httpclient/share/classes/java/net/http/CharsetToolkit.java
! src/java.httpclient/share/classes/java/net/http/RawChannel.java
+ src/java.httpclient/share/classes/java/net/http/WS.java
+ src/java.httpclient/share/classes/java/net/http/WSBuilder.java
+ src/java.httpclient/share/classes/java/net/http/WSCharsetToolkit.java
+ src/java.httpclient/share/classes/java/net/http/WSDisposable.java
+ src/java.httpclient/share/classes/java/net/http/WSDisposableText.java
+ src/java.httpclient/share/classes/java/net/http/WSFrame.java
+ src/java.httpclient/share/classes/java/net/http/WSFrameConsumer.java
+ src/java.httpclient/share/classes/java/net/http/WSMessageConsumer.java
+ src/java.httpclient/share/classes/java/net/http/WSMessageSender.java
+ src/java.httpclient/share/classes/java/net/http/WSOpeningHandshake.java
+ src/java.httpclient/share/classes/java/net/http/WSOutgoingMessage.java
+ src/java.httpclient/share/classes/java/net/http/WSProtocolException.java
+ src/java.httpclient/share/classes/java/net/http/WSReceiver.java
+ src/java.httpclient/share/classes/java/net/http/WSShared.java
+ src/java.httpclient/share/classes/java/net/http/WSSharedPool.java
+ src/java.httpclient/share/classes/java/net/http/WSSignalHandler.java
+ src/java.httpclient/share/classes/java/net/http/WSTransmitter.java
+ src/java.httpclient/share/classes/java/net/http/WSUtils.java
+ src/java.httpclient/share/classes/java/net/http/WSWriter.java
+ src/java.httpclient/share/classes/java/net/http/WebSocket.java
+ 
src/java.httpclient/share/classes/java/net/http/WebSocketHandshakeException.java
! src/java.httpclient/share/classes/java/net/http/package-info.java
+ test/java/net/httpclient/BasicWebSocketAPITest.java
+ test/java/net/httpclient/HandshakePhase.java

Changeset: 2569a85ce76a
Author:xuelei
Date:  2016-05-10 00:44 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2569a85ce76a

8154344: sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris
Reviewed-by: weijun

! test/sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java

Changeset: f2553c90dbc2
Author:mli
Date:  2016-05-10 15:12 +0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f2553c90dbc2

8156002: java/nio/channels/SocketChannel/AdaptSocket.java Fails in Mesos on OSX
Reviewed-by: dfuchs

! test/java/nio/channels/SocketChannel/AdaptSocket.java
! test/java/nio/channels/TestServers.java

Changeset: c4fa801257f9
Author:redestad
Date:  2016-05-10 13:28 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c4fa801257f9

8155795: Optimize Integer/Long.reverse by using reverseBytes
Reviewed-by: redestad, shade
Contributed-by: jaros...@kamenik.cz

! src/java.base/share/classes/java/lang/Integer.java
! src/java.base/share/classes/java/lang/Long.java
! test/java/lang/Integer/BitTwiddle.java
! test/java/lang/Long/BitTwiddle.java

Changeset: b2f12e28d97b
Author:redestad
Date:  2016-05-10 13:33 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b2f12e28d97b

8156560: Remove AddJsum
Reviewed-by: alanb, erikj

! make/Tools.gmk
- make/src/classes/build/tools/addjsum/AddJsum.java

Changeset: deac814a49a0
Author:redestad
Date:  2016-05-10 14:52 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/deac814a49a0

8156561: Remove makeClasslist.js
Reviewed-by: erikj, chegar

- make/non-build-utils/src/build/tools/makeclasslist/makeClasslist.js

Changeset: 1049321b86cb
Author:igerasim
Date:  2016-05-10 17:16 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1049321b86cb

8156661: Handful of typos in javadoc
Reviewed-by: prappo, rriggs

! src/java.base/share/classes/java/lang/Integer.java
! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
! src/java.base/share/classes/java/lang/reflect/Field.java
! src/java.base/share/classes/java/lang/reflect/InaccessibleObjectException.java
! src/java.base/share/classes/java/math/BigInteger.java
! src/java.base/share/classes/java/net/InetSocketAddress.java
! src/java.base/share/classes/java/net/URLDecoder.java
! src/java.base/share/classes/java/net/URLEncoder.java
! 
src/java.base/share/classes/java/security/InvalidAlgorithmParameterException.java
! src/java.base/share/classes/java/security/InvalidKeyException.java
! src/java.base/share/classes/java/security/ProtectionDomain.java
! src/java.base/share/classes/java/security/Provider.java
! src/java.base/share/classes/java/security/Security.java
! src/java.base/share/classes/java/security/spec/InvalidKeySpecException.java
! src/java.base/share/classes/java/time/Instant.java
! src/java.base/share/classes/java/time/LocalDateTime.java
! src/java.base/share/classes/java/time/LocalTime.java
! src/java.base/share/classes/java/time/OffsetDateTime.java
! 

hg: jigsaw/jake/nashorn: 9 new changesets

[alan . bateman]

Changeset: fb8b5b560a57
Author:sundar
Date:  2016-05-10 22:26 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/fb8b5b560a57

8156665: ES6 for..of should work on Java Iterables and Java arrays
Reviewed-by: attila, hannesw

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java
+ test/script/basic/es6/JDK-8156665.js
+ test/script/basic/es6/JDK-8156665.js.EXPECTED

Changeset: 2470510268c7
Author:sla
Date:  2016-05-11 11:05 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/2470510268c7

8156658: Common way to run jtreg tests
Reviewed-by: erikj, dsamersoff

+ test/Makefile

Changeset: 21421eec73d6
Author:attila
Date:  2016-05-11 19:24 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/21421eec73d6

8156738: Use StackWalker for DynamicLinker.getLinkedCallSiteLocation
Reviewed-by: hannesw, sundar

! src/jdk.dynalink/share/classes/jdk/dynalink/DynamicLinker.java
+ test/src/jdk/dynalink/test/LinkedCallSiteLocationTest.java

Changeset: ad496474746e
Author:sundar
Date:  2016-05-12 13:07 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ad496474746e

8156820: Nashorn nightly test failure after fix for 8156738
Reviewed-by: hannesw, mhaupt

! test/src/jdk/dynalink/test/LinkedCallSiteLocationTest.java

Changeset: 4b118e012ac4
Author:lana
Date:  2016-05-12 18:46 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/4b118e012ac4

Merge


Changeset: 809ef81502ed
Author:hannesw
Date:  2016-05-13 14:30 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/809ef81502ed

8156896: Script stack trace should display function names
Reviewed-by: attila, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornException.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilerConstants.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Namespace.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
! test/script/basic/JDK-8025515.js
+ test/script/basic/JDK-8156896.js

Changeset: 621ad507bf9b
Author:hannesw
Date:  2016-05-13 18:38 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/621ad507bf9b

8156714: Parsing issue with automatic semicolon insertion
Reviewed-by: jlaskey, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/AbstractParser.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
+ test/script/basic/JDK-8156714.js
! test/script/nosecurity/parserapi.js.EXPECTED

Changeset: eac5955924af
Author:lana
Date:  2016-05-19 17:48 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/eac5955924af

Added tag jdk-9+119 for changeset 621ad507bf9b

! .hgtags

Changeset: 7b912985fb7e
Author:alanb
Date:  2016-05-20 07:15 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7b912985fb7e

Merge

! .hgtags

hg: jigsaw/jake: 9 new changesets

[alan . bateman]

Changeset: 95b270614957
Author:chegar
Date:  2016-05-10 13:34 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/95b270614957

8074716: IntelliJ IDEA project support
Reviewed-by: rriggs
Contributed-by: Chris Hegarty , Maurizio Cimadamore 


! .hgignore
+ common/bin/idea.sh
+ make/idea/idea.gmk
+ make/idea/template/.name
+ make/idea/template/ant.xml
+ make/idea/template/build.xml
+ make/idea/template/compiler.xml
+ make/idea/template/copyright/profiles_settings.xml
+ make/idea/template/jdk.iml
+ make/idea/template/misc.xml
+ make/idea/template/modules.xml
+ make/idea/template/scopes/scope_settings.xml
+ make/idea/template/src/idea/JdkIdeaAntLogger.java
+ make/idea/template/vcs.xml
+ make/idea/template/workspace.xml
+ test/make/TestIdea.gmk
! test/make/TestMake.gmk

Changeset: 9dc9039053d5
Author:erikj
Date:  2016-05-11 13:42 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/9dc9039053d5

8156733: JIB fails to follow redirects
Summary: Make jib more resilient, let it follow redirects, and handle network 
hickups with 3 retries.
Reviewed-by: erikj
Contributed-by: Stefan Sarne 

! common/bin/jib.sh

Changeset: 733c7be12b39
Author:sla
Date:  2016-05-11 11:06 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/733c7be12b39

8156658: Common way to run jtreg tests
Reviewed-by: erikj, dsamersoff

! test/Makefile

Changeset: b12ea8f800aa
Author:erikj
Date:  2016-05-11 14:48 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/b12ea8f800aa

8155587: Cross compilation may cause compiler warnings for "build" compiler
Reviewed-by: dholmes, cjplummer

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: 1e9f3cc22044
Author:redestad
Date:  2016-05-12 14:57 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/1e9f3cc22044

8156756: Enable build-time use of resource ordering plugin
Reviewed-by: jlaskey, alanb, erikj

! make/Images.gmk

Changeset: 996f9fa4f8e6
Author:lana
Date:  2016-05-12 18:46 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/996f9fa4f8e6

Merge


Changeset: 3463a3f14f0f
Author:erikj
Date:  2016-05-13 09:21 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/3463a3f14f0f

8156837: RC resource compilation on windows generates false build failure 
reports
Reviewed-by: tbell, prr

! make/common/NativeCompilation.gmk

Changeset: e3b62687563c
Author:lana
Date:  2016-05-19 17:48 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/e3b62687563c

Added tag jdk-9+119 for changeset 3463a3f14f0f

! .hgtags

Changeset: 8dc9e89c0fb2
Author:alanb
Date:  2016-05-20 07:15 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/8dc9e89c0fb2

Merge

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4
! make/Images.gmk
! make/common/NativeCompilation.gmk
! test/make/TestMake.gmk