Re: 8233922: Service binding augments module graph with observable incubator modules

[Chris Hegarty]

> On 18 Nov 2019, at 17:54, Alex Buckley  wrote:
>> ..
> An incubator module's service providers will now be unavailable by default 
> even if a module on the module path says `uses`. I believe that JEP 11 should 
> say the following:
> 
> -
> Incubator modules are part of the JDK run-time image produced by the standard 
> JDK build. *However, by default, incubator modules are not resolved for 
> applications on the class path. Furthermore, by default, incubator modules do 
> not participate in service binding for applications on the class path or the 
> module path.*
> 
> Applications on the class path must use the --add-modules command-line option 
> to request that an incubator module be resolved. Applications developed as 
> modules can specify `requires` or `requires transitive` dependences upon an 
> incubator module directly. *(Some incubator modules do not export 
> packages but rather provide implementations of services. It is usually not 
> recommended to require a module that exports no packages, but it is necessary 
> in this case in order to resolve the incubator module and thus have it 
> participate in service binding.)*
> 
> During the JDK build, incubator modules must be packaged ...
> -

Thanks for the updates to JEP 11 Alex, they look good.

-Chris.

Re: 8233922: Service binding augments module graph with observable incubator modules

[Chris Hegarty]

> On 19 Nov 2019, at 13:51, Alan Bateman  wrote:
> 
> ...
> The warn-incubating flag is used in all phases to indicate that a module is 
> an incubator module and to warn when the module is resolved. Technically 
> these two concerns could be separated but this need hasn't arisen to date.
> 
> The do-not-resolve-by-default flag excludes modules exporting APIs from the 
> default set of named modules to resolve when the initial module is the 
> unnamed module, i.e. class path applications. Technically this could be used 
> to exclude modules that aren't incubator modules (and I think we've got close 
> once or two to doing that).

The original design of ModuleResolution intended do-not-resolve-by-default to 
be consulted by the resolver when making decisions about whether or not to 
include the module in the resolution process by default.

The warn-if-resolved value was intended to be used by tools and the launcher, 
to provide a warning reason if the module in question was resolved.

-Chris.

Re: 8233922: Service binding augments module graph with observable incubator modules

[Chris Hegarty]

> On 18 Nov 2019, at 12:34, Alan Bateman  wrote:
> 
> ...
>   http://cr.openjdk.java.net/~alanb/8233922/webrev/

I think this looks ok.

The original patch that added incubator module support had similar changes ( to 
exclude incubator modules from service binding ), but it impacted on the public 
Configuration::resolveAndBind ( so backed away from doing this ). Your changes 
to limit this to the boot layer are good ( since it is unlikely to be a more 
general issue ).

I’m surprise to see the resolver use `mres.hasIncubatingWarning() == false`, 
rather than ModuleResolution.doNotResolveByDefault(mres).

-Chris.

Re: RFR 8193033 remove terminally deprecated sun.misc.Unsafe.defineClass

[Chris Hegarty]

> On 15 Mar 2018, at 17:06, Paul Sandoz  wrote:
> 
> Hi,
> 
> Please review this patch to remove sun.misc.Unsafe.defineClass in 11.
> 
> There has been much outreach, by Alan and the Jigsaw team, about its public 
> replacement MethodHandles.Lookup.defineClass.
> 
> CSR is here:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8199699

Looks good Paul.   I don’t think that a CSR is strictly needed, but does no 
harm.

-Chris.

> Thanks,
> Paul.
> 
> 
> diff -r 3c0a12972165 src/jdk.unsupported/share/classes/sun/misc/Unsafe.java
> --- a/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java  Thu Mar 15 
> 08:11:01 2018 -0700
> +++ b/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java  Thu Mar 15 
> 09:51:00 2018 -0700
> @@ -811,25 +811,6 @@
> /// random trusted operations from JNI:
> 
> /**
> - * Tells the VM to define a class, without security checks.  By default, 
> the
> - * class loader and protection domain come from the caller's class.
> - *
> - * @deprecated Use {@link 
> java.lang.invoke.MethodHandles.Lookup#defineClass 
> MethodHandles.Lookup#defineClass}
> - * to define a class to the same class loader and in the same runtime 
> package
> - * and {@linkplain java.security.ProtectionDomain protection domain} of a
> - * given {@code Lookup}'s {@linkplain 
> java.lang.invoke.MethodHandles.Lookup#lookupClass() lookup class}.
> - *
> - * @see java.lang.invoke.MethodHandles.Lookup#defineClass(byte[])
> - */
> -@Deprecated(since="9", forRemoval=true)
> -@ForceInline
> -public Class defineClass(String name, byte[] b, int off, int len,
> -ClassLoader loader,
> -ProtectionDomain protectionDomain) {
> -return theInternalUnsafe.defineClass(name, b, off, len, loader, 
> protectionDomain);
> -}
> -
> -/**
>  * Defines a class but does not make it known to the class loader or 
> system dictionary.
>  * 
>  * For each CP entry, the corresponding CP patch must either be null or 
> have

Re: 8178380: Module system implementation refresh (5/2017 update)

[Chris Hegarty]

Mandy,

On 02/05/17 03:47, Mandy Chung wrote:



...

src/jdk.jartool/share/classes/sun/tools/jar/Main.java
 619 if (dflag) {
 620 // "--describe-module/-d" does not require 
file argument(s),
 621 // but does accept --release
 622 usageError(getMsg("error.bad.dflag"));
 623 return false;
 624 }


Sorry, I'm not sure of the issue here. I added this check when
updating the describe option to accept an optional `--release`
( the effective runtime version ) when describing a multi-release
modular JAR. This check is required as passing `-C`, in this
context, is an error. There are exiting tests that verify this.

-Chris.

hg: jigsaw/jake/jdk: jar tool: remove superflous newlines in describe output

[chris . hegarty]

Changeset: 245e5e5c0c8e
Author:chegar
Date:  2017-04-12 13:51 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/245e5e5c0c8e

jar tool: remove superflous newlines in describe output

! src/jdk.jartool/share/classes/sun/tools/jar/Main.java

hg: jigsaw/jake/jdk: 2 new changesets

[chris . hegarty]

Changeset: 3277e976d3c4
Author:chegar
Date:  2017-04-12 12:13 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3277e976d3c4

bug fix in jar Validator comparator

! src/jdk.jartool/share/classes/sun/tools/jar/Validator.java
+ test/tools/jar/multiRelease/whitebox/Driver.java
+ 
test/tools/jar/multiRelease/whitebox/jdk.jartool/sun/tools/jar/ValidatorComparatorTest.java

Changeset: 3c03f035f74d
Author:chegar
Date:  2017-04-12 12:14 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3c03f035f74d

jar tool describe module consistency with launcher

! src/jdk.jartool/share/classes/sun/tools/jar/Main.java
! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties
! test/tools/jar/mmrjar/Basic.java
! test/tools/jar/modularJar/Basic.java

Re: Review Request: JDK-8173303: Add module-subgraph images to main platform documentation

[Chris Hegarty]

> On 23 Mar 2017, at 23:55, Mandy Chung  wrote:
> 
> Jon and I work on this patch as the first step to enable module
> graphs for inclusion in the javadoc.  It includes a @moduleGraph
> taglet, an updated GenGraphs tool, and also updates javadoc of 
> module-info.java to include @moduleGraph.  I also take the 
> opportunity to add simple javadoc to a few JDK modules preparing
> for JEP 299 that will generate module summary page for JDK modules.
> 
> Webrev at:
>  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173303/webrev.00/
> 
> Here shows some sample of the javadoc with module graph images:
>  
> http://cr.openjdk.java.net/~mchung/jdk9/module-graph-docs/overview-summary.html

This looks really nice, and quite straight forward with the use of a block
tag. I see Alan has given some comments on the module-level descriptions,
which I agree with.

-Chris. 

Re: 8177474: Do not emit warnings when illegal access is allowed by --add-exports/--add-opens

[Chris Hegarty]

> On 23 Mar 2017, at 19:16, Alan Bateman  wrote:
> 
> I'd like to get jdk9/dev updated to align with the latest proposal for 
> --add-exports/--add-opens to not emit warnings. I've put the webrev with the 
> changes here:
> 
>http://cr.openjdk.java.net/~alanb/8177474/webrev/index.html

These changes look good to me Alan.

-Chris.

Re: 8174823: Module system implementation refresh (3/2017)

[Chris Hegarty]

> On 21 Mar 2017, at 21:42, Alan Bateman  wrote:
> 
> We have been accumulating changes in the jake forest for the last few weeks 
> to align with the proposals in JSR 376 and also to pick up API changes and 
> bug fixes. It's time to bring these changes into jdk9/dev. The issue to bring 
> these changes into jdk9/dev in bulk has been approved via the FC extension 
> process (still in use during JDK 9 RDP2).
> 
> A summary of the main changes is listed in JDK-8174823 [1], and the webrevs 
> with the changes to bring to jdk9/dev are here:
>   http://cr.openjdk.java.net/~alanb/8174823/1/

The changes in the jdk repo look fine.

Should the @return for ModuleDescriptor.Requires::rawCompiledVersion contain
the same caveat as was added to compiledVersion?

  * @return The string containing the version of the module if recorded
  *at compile-time, OR AN EMPTY OPTIONAL IF NO VERSION WAS 
RECORDED

-Chris.

Re: RFR [9] 8176772: jar tool support to report automatic module names

[Chris Hegarty]

On 16 Mar 2017, at 13:09, Chris Hegarty <chris.hega...@oracle.com> wrote:
> 
>> On 15 Mar 2017, at 17:30, Mandy Chung <mandy.ch...@oracle.com> wrote:
>> 
>> ...
>> provides and main class, if present. 
>> 
>> The modifier of ModuleDescriptor will have AUTOMATIC and so all packages are 
>> exported and open implicitly and not shown in the output which is okay.

cut’n’paste error fixed inline.

> This is a good idea. Here’s an example:
> 
> jar --describe-module --file describeAutomaticModule/foo.jar 
> No module descriptor found. Derived automatic module.
> 
> module foo (automatic)
>  requires mandated java.base
>  contains foo
>  main-class foo.Main
> 
> ---
> 
> Updated webrev:
>  http://cr.openjdk.java.net/~chegar/8176772.01/
> 
> -Chris.

Re: RFR [9] 8176772: jar tool support to report automatic module names

[Chris Hegarty]

> On 15 Mar 2017, at 17:30, Mandy Chung  wrote:
> 
> ...
> provides and main class, if present. 
> 
> The modifier of ModuleDescriptor will have AUTOMATIC and so all packages are 
> exported and open implicitly and not shown in the output which is okay.

This is a good idea. Here’s an example:

jar --describe-module --file describeAutomaticModule/foo.jar 
No module descriptor found. Derived automatic module.

module foo@1.2-SNAPSHOT (automatic)
  requires mandated java.base
  contains foo
  main-class foo.Main

---

Updated webrev:
  http://cr.openjdk.java.net/~chegar/8176772.01/

-Chris.

Re: RFR [9] 8176772: jar tool support to report automatic module names

[Chris Hegarty]

> On 15 Mar 2017, at 16:54, Mandy Chung <mandy.ch...@oracle.com> wrote:
> 
>> 
>> On Mar 15, 2017, at 8:31 AM, Chris Hegarty <chris.hega...@oracle.com> wrote:
>> 
>> 
>>> On 15 Mar 2017, at 14:42, Alan Bateman <alan.bate...@oracle.com> wrote:
>>> 
>>> On 15/03/2017 14:21, Chris Hegarty wrote:
>>> 
>>>> :
>>>> 
>>>> Webrev:
>>>> 
>>>> http://cr.openjdk.java.net/~chegar/8176772.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8176772
>>>> 
>>> If findAll returns an empty set then the error.unable.derive.automodule 
>>> message might be more appropriate. Otherwise looks good to me.
>> 
>> That would be better. Updated in-place.
>> http://cr.openjdk.java.net/~chegar/8176772.00/
> 
> Is there any reason why this option does not print the synthesized 
> descriptor?  I understand that the issue is specific to show the derived 
> module name.  But it’d be nice for this option to print the descriptor 
> consistent with a normal module.

Unless I am mistaken, the synthesised descriptor does not contain
any more information. What are you expecting?

-Chris.

Re: RFR [9] 8176772: jar tool support to report automatic module names

[Chris Hegarty]

> On 15 Mar 2017, at 14:42, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> On 15/03/2017 14:21, Chris Hegarty wrote:
> 
>> :
>> 
>> Webrev:
>> 
>>   http://cr.openjdk.java.net/~chegar/8176772.00/
>>   https://bugs.openjdk.java.net/browse/JDK-8176772
>> 
> If findAll returns an empty set then the error.unable.derive.automodule 
> message might be more appropriate. Otherwise looks good to me.

That would be better. Updated in-place.
  http://cr.openjdk.java.net/~chegar/8176772.00/

-Chris.

Re: RFR: 8175010: ImageReader is not thread-safe

[Chris Hegarty]

> On 15 Feb 2017, at 13:22, Claes Redestad  wrote:
> 
> Hi,
> 
> a few intermittent but rare test failures[1] that has appeared
> since the latest jake integration, and since one of the changes
> in there was to make initialization of the system ImageReader
> lazy there appears to be cases where ImageReaders are not
> safely published:
> 
> - Ensure ImageReader::open is called only once per Path in
> ImageReaderFactory by using CHM.computeIfAbsent
> - Ensure ImageReader.reader is safely published to a
> final field and signal close using a volatile boolean instead
> 
> webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/

Looks good Claes.

-Chris.

> bug: https://bugs.openjdk.java.net/browse/JDK-8175010
> 
> Testing shows no issues (which admittedly doesn't mean we're
> actually solving the root cause for JDK-8174817), and performance
> numbers from adding a volatile read indicate that any overhead
> is lost in the noise on ImageReader-heavy workloads.
> 
> Thanks!
> 
> /Claes
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8174817

Re: Extending java.base module

[Chris Hegarty]

> On 15 Feb 2017, at 08:51, Weijun Wang  wrote:
> 
> Disclaimer: I am not a jigsaw expert.
> 
> The provides/uses mechanism is certainly more formal, but you can also do 
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d282c1a8d20b.

This is, at best, a hack. The use of Services is a better approach, where 
possible.

-Chris.

Re: Review Request: JDK-8173096 jmod files are not world-readable

[Chris Hegarty]

On 21/01/17 02:32, Mandy Chung wrote:

Updated webrev to put the temporary file in the same containing directory of 
the target file:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173096/webrev.01


Looks fine. Trivially, the test can now drop "-Djava.io.tmpdir=." .

-Chris.


I want to fix this regression in jdk-9+154.  We can revisit the approach after 
this fix if necessary.

Mandy


On Jan 20, 2017, at 8:55 AM, Mandy Chung  wrote:

Webrev:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173096/webrev.00/index.html

A recent change in jmod tool [1] creates the JMOD file with no group
and other readable permission as that’s the default permission when
creating a temporary file with Files::createTempFile.  This fixes
the permission issue by creating the JMOD file in a temporary directory.

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

RFR [9] 8172982: tools/jlink/ResourceDuplicateCheckTest.java requires jdk.tools.jlink.plugin to be exported

[Chris Hegarty]

Since the jlink plugin package is no longer exported this test should
add the appropriate @modules tag.

diff -r 5b75946223fb test/tools/jlink/ResourceDuplicateCheckTest.java
--- a/test/tools/jlink/ResourceDuplicateCheckTest.java  Wed Jan 18 13:56:50 
2017 +
+++ b/test/tools/jlink/ResourceDuplicateCheckTest.java  Wed Jan 18 17:05:11 
2017 +
@@ -27,6 +27,7 @@
  * @summary Detect duplicated resources in packaged modules
  * @modules jdk.jlink/jdk.tools.jlink.builder
  *  jdk.jlink/jdk.tools.jlink.internal
+ *  jdk.jlink/jdk.tools.jlink.plugin
  * @run build ResourceDuplicateCheckTest
  * @run main ResourceDuplicateCheckTest
  */

-Chris.

Re: Review request: JDK-8172870 test/tools/jmod/JmodTest.java fails on windows with AccessDeniedException

[Chris Hegarty]

> On 18 Jan 2017, at 07:38, Alan Bateman  wrote:
> 
> On 17/01/2017 21:23, Mandy Chung wrote:
> 
>> This test case attempts to verify that the temp file created by jmod is 
>> cleaned up and removed if jmod create command fails.  It first cleans up any 
>> temp files matching the prefix and suffix created for this test case.  The 
>> test fails because the fix for JDK-8160286 that creates the jmod temp file 
>> in the tmp directory and it was updated to use Files.walk that may fail to 
>> read the file attributes if the user doesn’t have access.
>> 
>> The patch fixes the test to call Files.list and find only the writeable 
>> files matching the prefix and suffix.
>> 
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172870/webrev.00/

When this test was added originally jmod was creating the tmp file in 
the current working directory. 

To avoid interference you could run with test with java.io.tmpdir set
to the current working directory, “testng/othervm -Djava.io.tmpdir=. ..."

-Chris.

Re: RFR 8171380: Remove exports from jdk.jlink

[Chris Hegarty]

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

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

-Chris.

Re: RFR 8171380: Remove exports from jdk.jlink

[Chris Hegarty]

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

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


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

-Chris.

RFR 8171380: Remove exports from jdk.jlink

[Chris Hegarty]

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

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

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

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

-Chris.

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

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

[Chris Hegarty]

> On 11 Jan 2017, at 23:47, Mandy Chung  wrote:
> 
> Webrev:
>  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160286/webrev.00/

Looks fine. It’s good to share as much of this code as possible between
these packaging tools.

I didn’t look too hard at Graph and TopoSorter, these look similar to
what is in other areas, e.g. jdeps, 

In the jar option parsing did you mean to construct ModulePath with true?
This will support jmod files.

-Chris.

Re: RFR [9] 8168149: Examine the behavior of jmod command-line options - repeating vs last one wins

[Chris Hegarty]

> On 4 Jan 2017, at 21:03, Mandy Chung <mandy.ch...@oracle.com> wrote:
> 
> 
>> On Dec 22, 2016, at 9:11 AM, Chris Hegarty <chris.hega...@oracle.com> wrote:
>> 
>> Most options for the jmod tool should be last one wins, to be consistent
>> with the JDK tool convention, 8168149 [1]. Excludes is the only
>> repeatable option.
>> 
>> Given the existing usage of JOpt Simple, the most straight forward way
>> to achieve the last-one-wins behaviour is to drop the
>> withValuesSeparatedBy() from the OptionSpec have have the ValueConverters
>> themselves do the separation, if any. That way all options can be made
>> repeatable and the last element of the list of the option’s values will
>> be the final one on the command line.
>> 
>> http://cr.openjdk.java.net/~chegar/8168149.00/
> 
> This looks okay.

Thanks for looking at this Mandy.

> I wonder if it would be more helpful if it fails when a non-repeating option 
> is specified more than once for a packaging tool.  Otherwise, the only way to 
> find out if the command-line is correct is to list the content after the JMOD 
> file is created.  OptionSpec::value throws an exception if the option is 
> specified more than once.

Right. I was following the existing longstanding precedent of
last-one-wins for JDK tool options. If I read your comment
correctly you are suggesting that packaging tools do not
follow this, correct?  This will need further discussion, and 
maybe a clarification in JEP 293 "Guidelines for JDK
Command-Line Tool Options”.

-Chris.

[1] http://openjdk.java.net/jeps/293

RFR [9] 8168149: Examine the behavior of jmod command-line options - repeating vs last one wins

[Chris Hegarty]

Most options for the jmod tool should be last one wins, to be consistent
with the JDK tool convention, 8168149 [1]. Excludes is the only
repeatable option.

Given the existing usage of JOpt Simple, the most straight forward way
to achieve the last-one-wins behaviour is to drop the
withValuesSeparatedBy() from the OptionSpec have have the ValueConverters
themselves do the separation, if any. That way all options can be made
repeatable and the last element of the list of the option’s values will
be the final one on the command line.

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


-Chris.

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

Re: RFR 8170618: jmod should validate if any exported or open package is missing

[Chris Hegarty]

On 21/12/16 12:08, Sundararajan Athijegannathan wrote:

Please review http://cr.openjdk.java.net/~sundar/8170618/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8170618


Looks good Sundar.

-Chris.

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

[Chris Hegarty]

> On 19 Dec 2016, at 19:21, Uwe Schindler <uschind...@apache.org> wrote:
> 
> Hi,
> 
> will there be an update for JEP 260, so this is documented?

Yes, working on it.

-Chris.

> Uwe
> 
> -
> Uwe Schindler
> uschind...@apache.org 
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
> 
>> -Original Message-
>> From: Chris Hegarty [mailto:chris.hega...@oracle.com]
>> Sent: Friday, December 16, 2016 6:39 PM
>> To: Peter Levart <peter.lev...@gmail.com>; Core-Libs-Dev > d...@openjdk.java.net>; jigsaw-dev <jigsaw-dev@openjdk.java.net>; Uwe
>> Schindler <uschind...@apache.org>
>> Subject: Re: Java 9 build 148 causes trouble in Apache
>> Lucene/Solr/Elasticsearch
>> 
>> Pushed to jdk9/dev. Should make b150.
>> 
>>  https://bugs.openjdk.java.net/browse/JDK-8171377
>> 
>> -Chris.
>> 
>>> On 14 Dec 2016, at 11:58, Chris Hegarty <chris.hega...@oracle.com>
>> wrote:
>>> 
>>> Webrev updated in-place.
>>> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/
>>> 
>>> -Chris.
>>> 
>>> On 13/12/16 21:18, Peter Levart wrote:
>>>> I think this is OK.
>>>> 
>>>> Just a couple of nits in test:
>>>> 
>>>> 1. You create a static Path bob = Paths.get("bob") field, but then you
>>>> don't use it in:
>>>> 
>>>> 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"),
>>>> CREATE, WRITE)) {
>>>> 
>>>> 2. badBuffers could include a duplicate and a slice of a direct buffer
>>>> allocated with ByteBuffer.allocateDirect()
>>>> 
>>>> 3. The comment in the test is referencing the old method name:
>>>> 
>>>> 26  * @summary Basic test for Unsafe::deallocate
>>>> 
>>>> 
>>>> Regards, Peter
>>>> 
>>>> On 12/13/2016 08:47 PM, Chris Hegarty wrote:
>>>>> Taking into account the feedback so far, and changing the method name
>> ( since
>>>>> it is an attractive nuisance ), here is where I think we ended up.
>>>>> 
>>>>> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/
>>>>> 
>>>>> If this is agreeable, I’ll file an issue in JIRA to track the code 
>>>>> changes, and
>>>>> update JEP 260.
>>>>> 
>>>>> -Chris.
>>>> 
> 

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

[Chris Hegarty]

Pushed to jdk9/dev. Should make b150.

  https://bugs.openjdk.java.net/browse/JDK-8171377

-Chris.

> On 14 Dec 2016, at 11:58, Chris Hegarty <chris.hega...@oracle.com> wrote:
> 
> Webrev updated in-place.
>  http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/
> 
> -Chris.
> 
> On 13/12/16 21:18, Peter Levart wrote:
>> I think this is OK.
>> 
>> Just a couple of nits in test:
>> 
>> 1. You create a static Path bob = Paths.get("bob") field, but then you
>> don't use it in:
>> 
>>  56 try (FileChannel fc = FileChannel.open(Paths.get("bob"),
>> CREATE, WRITE)) {
>> 
>> 2. badBuffers could include a duplicate and a slice of a direct buffer
>> allocated with ByteBuffer.allocateDirect()
>> 
>> 3. The comment in the test is referencing the old method name:
>> 
>>  26  * @summary Basic test for Unsafe::deallocate
>> 
>> 
>> Regards, Peter
>> 
>> On 12/13/2016 08:47 PM, Chris Hegarty wrote:
>>> Taking into account the feedback so far, and changing the method name ( 
>>> since
>>> it is an attractive nuisance ), here is where I think we ended up.
>>> 
>>> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/
>>> 
>>> If this is agreeable, I’ll file an issue in JIRA to track the code changes, 
>>> and
>>> update JEP 260.
>>> 
>>> -Chris.
>> 

Re: RFR: 8171373: Reduce copying during initialization of ModuleHashes

[Chris Hegarty]

> On 16 Dec 2016, at 16:00, Claes Redestad  wrote:
> 
> Hi,
> 
> recent changes to split out ModuleHashes from ModuleDescriptor caused a 
> small/tiny increase in HashMap creation, resize and copying:
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8171373/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8171373
> 
> This decreases #bytecode executed during startup by ~20K (around 1.5% of 
> total).

Nicely done Claes. Looks good to me.

Builder.nameToHash can be final, no?

-Chris.

hg: jigsaw/jake/jdk: jmod/jar tool: Document extra options in help

[chris . hegarty]

Changeset: 1bd62b2bc515
Author:chegar
Date:  2016-12-15 21:28 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1bd62b2bc515

jmod/jar tool: Document extra options in help

! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java
! src/jdk.jartool/share/classes/sun/tools/jar/Main.java
! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties
! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java
! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties
! test/jdk/modules/incubator/DefaultImage.java
! test/tools/jar/compat/CLICompatibility.java
! test/tools/jmod/JmodTest.java

Re: 8170987: Module system implementation refresh (12/2016)

[Chris Hegarty]

> On 15 Dec 2016, at 01:17, Mandy Chung  wrote:
> ...
> 
> src/java.base/share/classes/jdk/internal/module/ModuleResolution.java
> 
>  64 throw new RuntimeException("cannot add deprecated to " + 
> value);
> 
> This comment applies to ModuleResoluton::with* methods.  This should
> probably be an InternalError?  

I think InternalError is suitable here. These checks are to ensure tools don’t 
do
anything inappropriate.

> 108 return String.valueOf(value);
> 
> Nit: since you override toString method, might be helpful to print
> an informative description.  

Done.

> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java
> 
> 1102 if (value.equals("deprecated"))
> 1103 return (new ModuleResolution(0)).withDeprecated();
> 1104 else if (value.equals("deprecated-for-removal"))
> 1105 return (new 
> ModuleResolution(0)).withDeprecatedForRemoval();
> 1106 else if (value.equals("incubating"))
> 1107 return (new ModuleResolution(0)).withIncubating();
> 
> Why not passing the flag to ModuleResolution constructor?  Similar
> statement is also in sun/tools/jar/GNUStyleOptions.java.

I cleaned this up a little. I don’t want the tools to have knowledge of the 
actual 
flag values.

> I was wondering if jmod describe and jar —-print-module-descriptor should
> print all optional attributes.  While the module resolution is of limited
> use, it would be handy to print all optional attributes, if present rather
> than having to run java.

Agreed.

> It’s okay to follow up as a separate JBS issue if we want to do that.

If I don’t get to it before this Friday, I’ll follow up with a separate issue.

> test/jdk/modules/incubator/ImageModules.java
>  @modules jdk.jlink jdk.jartool are missing.  I have fixed it.

Thanks.
-Chris.

hg: jigsaw/jake/jdk: Additional test coverage in ImageModules.java

[chris . hegarty]

Changeset: ae2572dcd89a
Author:chegar
Date:  2016-12-14 16:01 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ae2572dcd89a

Additional test coverage in ImageModules.java

! test/jdk/modules/incubator/ImageModules.java

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

[Chris Hegarty]

Webrev updated in-place.
  http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/

-Chris.

On 13/12/16 21:18, Peter Levart wrote:

I think this is OK.

Just a couple of nits in test:

1. You create a static Path bob = Paths.get("bob") field, but then you
don't use it in:

  56 try (FileChannel fc = FileChannel.open(Paths.get("bob"),
CREATE, WRITE)) {

2. badBuffers could include a duplicate and a slice of a direct buffer
allocated with ByteBuffer.allocateDirect()

3. The comment in the test is referencing the old method name:

  26  * @summary Basic test for Unsafe::deallocate


Regards, Peter

On 12/13/2016 08:47 PM, Chris Hegarty wrote:

Taking into account the feedback so far, and changing the method name ( since
it is an attractive nuisance ), here is where I think we ended up.

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

If this is agreeable, I’ll file an issue in JIRA to track the code changes, and
update JEP 260.

-Chris.

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

[Chris Hegarty]

Taking into account the feedback so far, and changing the method name ( since 
it is an attractive nuisance ), here is where I think we ended up.

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

If this is agreeable, I’ll file an issue in JIRA to track the code changes, and 
update JEP 260.

-Chris.

hg: jigsaw/jake/jdk: Move tests to jdk/modules

[chris . hegarty]

Changeset: 55586b951ae1
Author:chegar
Date:  2016-12-13 14:31 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/55586b951ae1

Move tests to jdk/modules

+ test/jdk/modules/incubator/DefaultImage.java
+ test/jdk/modules/incubator/ImageModules.java
+ test/jdk/modules/incubator/src/cp/listmods/ListModules.java
+ test/jdk/modules/incubator/src/cp/test/ConvertToLowerCase.java
+ test/jdk/modules/incubator/src/cp/test/WriteUpperCase.java
+ 
test/jdk/modules/incubator/src/message.converter/converter/MessageConverter.java
+ test/jdk/modules/incubator/src/message.converter/module-info.java
+ test/jdk/modules/incubator/src/message.writer/module-info.java
+ test/jdk/modules/incubator/src/message.writer/writer/MessageWriter.java
- test/tools/modules/incubator/DefaultImage.java
- test/tools/modules/incubator/ImageModules.java
- test/tools/modules/incubator/src/cp/listmods/ListModules.java
- test/tools/modules/incubator/src/cp/test/ConvertToLowerCase.java
- test/tools/modules/incubator/src/cp/test/WriteUpperCase.java
- 
test/tools/modules/incubator/src/message.converter/converter/MessageConverter.java
- test/tools/modules/incubator/src/message.converter/module-info.java
- test/tools/modules/incubator/src/message.writer/module-info.java
- test/tools/modules/incubator/src/message.writer/writer/MessageWriter.java

hg: jigsaw/jake: 8170859: Run time and tool support for ModuleResolution

[chris . hegarty]

Changeset: 1be9ce97598d
Author:chegar
Date:  2016-12-13 14:22 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/1be9ce97598d

8170859: Run time and tool support for ModuleResolution

! make/CreateJmods.gmk

hg: jigsaw/jake/jdk: 8170859: Run time and tool support for ModuleResolution

[chris . hegarty]

Changeset: 7096176b5e14
Author:chegar
Date:  2016-12-12 14:40 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7096176b5e14

8170859: Run time and tool support for ModuleResolution

! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java
! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java
! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java
! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java
! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java
! src/java.base/share/classes/jdk/internal/module/ModulePath.java
! src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java
! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java
+ src/java.base/share/classes/jdk/internal/module/ModuleResolution.java
! src/java.base/share/classes/jdk/internal/module/SystemModuleFinder.java
! src/java.base/share/classes/jdk/internal/module/SystemModules.java
! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java
! src/jdk.jartool/share/classes/sun/tools/jar/Main.java
! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java
! 
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java
! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties
+ test/tools/modules/incubator/DefaultImage.java
+ test/tools/modules/incubator/ImageModules.java
+ test/tools/modules/incubator/src/cp/listmods/ListModules.java
+ test/tools/modules/incubator/src/cp/test/ConvertToLowerCase.java
+ test/tools/modules/incubator/src/cp/test/WriteUpperCase.java
+ 
test/tools/modules/incubator/src/message.converter/converter/MessageConverter.java
+ test/tools/modules/incubator/src/message.converter/module-info.java
+ test/tools/modules/incubator/src/message.writer/module-info.java
+ test/tools/modules/incubator/src/message.writer/writer/MessageWriter.java

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

[Chris Hegarty]

> On 10 Dec 2016, at 19:47, Peter Levart <peter.lev...@gmail.com> wrote:
> 
> Hi Chris,
> 
> On 12/10/2016 06:11 PM, Chris Hegarty wrote:
>> How about: Unsafe::deallocate(ByteBuffer directBuffer)?
>>   
>> http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/
> 
> Apart from the fact that Unsafe is (was?) reserved for low-level stuff, I 
> think this approach is reasonable. Is the method in jdk.internal.misc.Unsafe 
> needed? You could add the method just to the sun.misc.Unsafe (to keep 
> internal Unsafe free from hacks) and export the two packages selectively to 
> jdk.unsupported.

Yes, possibly.

>> We could attempt to limit this to the direct buffer that "owns" the
>> memory, i.e. not a duplicate or a slice, but I'm not sure it is worth
>> it.
>> 
> 
> What you have here *is* limited to direct ByteBuffer(s) that "own" the memory.

Understood, what I meant was throwing an exception if the given buffer
does not “own” the memory.

> Derived buffer(s) (duplicated or sliced) do not have a Cleaner instance (they 
> have an 'attachment' to keep the 1st-level buffer reachable while they are 
> reachable). I would even make it more unforgiving by throwing an IAE if the 
> passed-in buffer didn't have a Cleaner. In addition I would specify this 
> behavior. For example:
> 
> "Deallocates the underlying memory associated with given directBuffer if the 
> buffer was obtained from either {@link ByteBuffer#allocateDirect} or {@link 
> FileChannel#map} methods. In any other case (when the buffer is not a direct 
> buffer or was obtained by  {@link ByteBuffer#duplicate() duplicating} or 
> {@link ByteBuffer#slice(int, int) slicing} a direct buffer), the method 
> throws {@code IllegalArgumentException}.

Yes, but given a ByteBuffer it is not possible to determine if it “owns” the
memory, or not. So users of the API would have to have full knowledge of
the buffers they pass to it. Maybe this is ok?

-Chris.

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

[Chris Hegarty]

I think it best to keep whatever we do here simple and straight forward.
It is, after all, just a stop gap until a public API can be put in place
in a future release ( which I believe is a realistic possibility
given some of the discussions that I have heard about, but that is for
another day).

If we add a method to Unsafe, then we get the benefit of being 
protected by the security manager for free ( you need reflective access
to get "theUnsafe" field). Most of the code I've seen in this area delves
into Unsafe anyway.

How about: Unsafe::deallocate(ByteBuffer directBuffer)?
  http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/

We could attempt to limit this to the direct buffer that "owns" the
memory, i.e. not a duplicate or a slice, but I'm not sure it is worth
it.

Once we reach agreement on the technical solution, I will add appropriate 
wording to JEP 260 to cover this case.

-Chris.



> On 10 Dec 2016, at 13:08, Peter Levart  wrote:
> 
> Hi Uwe,
> 
> 
> On 12/10/2016 01:33 PM, Uwe Schindler wrote:
>> 
>> Hi Peter,
>> 
>> this would be a great fix! Thanks!!!
>> 
>> I also think the non-static method is superior to my original proposal, 
>> because it allows us to do the security check **once**, which is really 
>> needed for Lucene. I am still fine if the permission is still checked on 
>> every unmapping, but we need to do the check up-front. If you look at our 
>> current unmapping code (https://goo.gl/TfQWl6), you will the that the 
>> detector checks for the extra runtime permission upfront, so we can be sure 
>> that the actual unmapping will work for sure. This is also the reason why we 
>> use MethodHandles: As those are compiled on investigation of possible 
>> unmapping variants depending on the VM, we can “compile” the MethodHandle 
>> and later call it as often as we like, without the risk that it breaks for 
>> incompatibility reasons. The MethodHandle makes sure that all types are 
>> checked up front.
>> 
>> About MappedByteBuffer vs ByteBuffer (or maybe just java.nio.Buffer!?): I’d 
>> make it generic so it works with any direct buffer (maybe also non-byte 
>> ones). For Lucene it does not matter, but other projects (I know Cassandra 
>> or other off-Heap frameworks) do the same with buffers that were allocated 
>> direct (not only mmapped). The method signature in your proposal is also 
>> compatible to our requirements: We can create the DirectBufferDeallocator up 
>> front and then produce a MH which is bound to the allocator.
>> 
> 
> I choose to limit the method to ByteBuffer type because this is the public 
> static type used in programs for instances that are possibly "owning" the 
> underlying native memory. Other-typed buffers or even 2nd-level direct 
> ByteBuffers obtained by duplicating or slicing are just views and do not 
> "own" the underlying memory. While it would be possible to trigger 
> deallocation / unmapping via any buffer that references the owning buffer, I 
> think this might be prone to bugs. By limiting the method to 1st-level direct 
> ByteBuffer(s), the programmer is forced to think about ownership and lifetime 
> of derived buffers and consequently write better code.
> 
> So on 2nd thought, the API might be even better to reject non-direct and 
> 2nd-level direct ByteBuffer(s) by throwing an exception rather than silently 
> ignoring the deallocation request.
> 
>> I will make a pull request to Lucene using your current proposal so you have 
>> a “patch” to test this with Lucene before you commit something like this.
>> 
> 
> Let us first wait for a proposal from Oracle to see what they have in mind...
> 
> Regards, Peter
> 
>> Uwe
>> 
>> -
>> 
>> Uwe Schindler
>> 
>> uschind...@apache.org
>> 
>> ASF Member, Apache Lucene PMC / Committer
>> 
>> Bremen, Germany
>> 
>> http://lucene.apache.org/
>> 
>> *From:*Peter Levart [mailto:peter.lev...@gmail.com]
>> *Sent:* Saturday, December 10, 2016 12:10 PM
>> *To:* Alan Bateman ; Uwe Schindler 
>> ; jigsaw-dev@openjdk.java.net; Core-Libs-Dev 
>> 
>> *Subject:* Re: Java 9 build 148 causes trouble in Apache 
>> Lucene/Solr/Elasticsearch
>> 
>> Hi,
>> 
>> On 12/10/2016 06:14 AM, Alan Bateman wrote:
>> 
>>On 09/12/2016 22:32, Uwe Schindler wrote:
>> 
>> 
>>Hi,
>> 
>>I updated our Jenkins server for the JDK 9 preview testing to
>>use build 148. Previously we had build 140 and build 147,
>>which both worked without any issues. But after the update the
>>following stuff goes wrong:
>> 
>>(1) Unmapping of direct buffers no longer works, although this
>>API was marked as critical because there is no replacement up
>>to now, so code can unmap memory mapped files, which is one of
>>the most important things Apache Lucene needs to use to access
>>huge random access files while reading the index. Without
>>memory mapping, 

Re: RFR [9] 8170859 : Run time and tool support for ModuleResolution

[Chris Hegarty]

I'll work with Alan to get these changes re-based on top of
the refactoring in jake. Consider this review request withdrawn.

-Chris.

On 09/12/16 14:09, Remi Forax wrote:

Thanks Alan,
so I withdraw my snarky comment.

Rémi


On December 9, 2016 12:25:19 PM GMT+01:00, Alan Bateman 
 wrote:

On 08/12/2016 14:41, Remi Forax wrote:


Chris,
this patch is rather ugly.
Patching the ModuleDescriptor is not a good idea, maybe it's means

that we need a system of metadata associated with a ModuleDescriptor,

the hash of a module (which is not part of the module spec but the

OpenJDK implementation) can be also considered as metadata.



There is refactoring in flight that drops the JDK-specific meta data
from ModuleDescriptor. Once all the pieces are merged together then it
should look a lot better.

-Alan.

Re: RFR [9] 8166568 & 8169492 jmod extract and bug fix

[Chris Hegarty]

> On 8 Dec 2016, at 14:45, Andrey Nazarov <andrey.x.naza...@oracle.com> wrote:
> 
> Hi,
> 
> Still no tests when directory where files are extracted is not empty. It very 
> common case.

Consider this patch added: 

  diff --git a/test/tools/jmod/JmodTest.java b/test/tools/jmod/JmodTest.java
--- a/test/tools/jmod/JmodTest.java
+++ b/test/tools/jmod/JmodTest.java
@@ -177,6 +177,11 @@
 jmod("extract",
  "--dir", "extractTestDir",
  MODS_DIR.resolve("fooExtractDir.jmod").toString())
+.assertSuccess();
+
+jmod("extract",
+ "--dir", "extractTestDir",
+ MODS_DIR.resolve("fooExtractDir.jmod").toString())
 .assertSuccess()
 .resultChecker(r -> {
 // check a sample of the extracted files


When the dir is not empty, it just overwrites / adds.

-Chris.

> —Andrey 
>> On 8 Dec 2016, at 16:09, Chris Hegarty <chris.hega...@oracle.com> wrote:
>> 
>> 
>>> On 8 Dec 2016, at 00:44, Mandy Chung <mandy.ch...@oracle.com> wrote:
>>> 
>>> 
>>>> On Dec 6, 2016, at 2:46 AM, Chris Hegarty <chris.hega...@oracle.com> wrote:
>>>> 
>>>> This change adds a basic option to the jmod tool to extract all its 
>>>> contents to
>>>> the current working directory, 8166568 [1]. Additionally, there is a bug 
>>>> fix for
>>>> a public mutable static, 8169492 [2].
>>>> 
>>>> http://cr.openjdk.java.net/~chegar/8166568_8169492.00/
>>> 
>>> 
>>> Looks good.  I agree with Alan and it’d be good to take the destination 
>>> directory to which the contents are written.  FYI.  jimage extract command 
>>> takes —-dir option.
>> 
>> Updated webrev contain a target destination dir:
>> http://cr.openjdk.java.net/~chegar/8166568_8169492.01/
>> 
>> -Chris
>> 
> 

Re: RFR [9] 8170859 : Run time and tool support for ModuleResolution

[Chris Hegarty]

Remi,

> On 8 Dec 2016, at 14:41, Remi Forax <fo...@univ-mlv.fr> wrote:
> 
> Chris,
> this patch is rather ugly.

I agree that it is not pretty, but the changes are mostly mechanical.

> Patching the ModuleDescriptor is not a good idea, maybe it's means that we 
> need a system of metadata associated with a ModuleDescriptor,
> the hash of a module (which is not part of the module spec but the OpenJDK 
> implementation) can be also considered as metadata.

As you have pointed out, this is no different from how hashes are
already handled today.

-Chris.

> regards,
> Rémi
> 
> - Mail original -
>> De: "Chris Hegarty" <chris.hega...@oracle.com>
>> À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net>
>> Envoyé: Jeudi 8 Décembre 2016 14:49:38
>> Objet: RFR [9] 8170859 : Run time and tool support for ModuleResolution
> 
>> This is a review request for the link time and run time support for
>> the mechanism to support incubator modules [1]. More specifically,
>> the addition of options to the jmod and jar tools to pass through the
>> relevant values, as per JEP 11, and support for these in the form
>> of a new ModuleResolution attribute ( that will be documented in
>> JEP 261 ).
>> 
>> http://cr.openjdk.java.net/~chegar/8170859/00/
>> 
>> -Chris.
>> 
>> [1] http://openjdk.java.net/jeps/11

Fwd: RFR [9] 8166568 & 8169492 jmod extract and bug fix

[Chris Hegarty]

[ forwarding to a more appropriate list to review this change ]

> Begin forwarded message:
> 
> From: Chris Hegarty <chris.hega...@oracle.com>
> Subject: RFR [9] 8166568 & 8169492 jmod extract and bug fix
> Date: 6 December 2016 at 10:46:08 GMT
> To: core-libs-dev <core-libs-...@openjdk.java.net>
> 
> This change adds a basic option to the jmod tool to extract all its contents 
> to
> the current working directory, 8166568 [1]. Additionally, there is a bug fix 
> for
> a public mutable static, 8169492 [2].
> 
> http://cr.openjdk.java.net/~chegar/8166568_8169492.00/
> 
> -Chris.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8166568
> [2] https://bugs.openjdk.java.net/browse/JDK-8169492

Re: Code review for jigsaw/jake -> jdk9/dev sync up

[Chris Hegarty]

On 24 Nov 2016, at 15:25, Alan Bateman  wrote:
> 
> ...
> To get going, I've put the webrevs with a snapshot of the changes in jake 
> here:
>http://cr.openjdk.java.net/~alanb/8169069/0/

Overall this look very good. I ran through most of the changes in the jdk repo,
just a few small comments.

1) SuppressWarnings.java  typo element - > elementS

  38  * However, note that if a warning is suppressed in a {@code
  39  * module-info} file, the suppression applies to elementS within the
  40  * file and not to types contained within the module.

2) jartool Main.java
  Maybe concealedPackages should have a comment about its use ( it is
  used in the Validator, and not by Main at all ).

3) MethodHandles.java privateLookupIn
  It might be clearer if the third bullet used {@code lookup}, or 'caller 
lookup’, or ‘given lookup'?
 
  The CALLER lookup has the {@link Lookup#MODULE MODULE} lookup mode.

4) ServiceLoader
{@code ExtendedCodecsFactory}
  111  * will be treated as a provider factory and {@code
  112  * ExtendedCodecsFactory.provider()} will be invoked to INSTANTIATE the
  113  * provider.

  Is 'instantiate' strictly true here? Should it simply be ‘return'

  206  *  If a named module declares more than one provider then the 
providers
  207  * are located in the order that they appear in the {@code provides} 
table of
  208  * the {@code Module} class file attribute ({@code 
module-info.class}).   

  Wow. I assume the JLS, or otherwise, will specify that the order in which the 
  providers are listed in the module-info be preserved, no? Maybe this item 
could
  mention that. The class file reference can still be kept, but seems a bit 
low-level
  for developers.

-Chris.

hg: jigsaw/jake/jdk: Replace exported-private with open

[chris . hegarty]

Changeset: 3750898360d0
Author:chegar
Date:  2016-11-23 09:55 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3750898360d0

Replace exported-private with open

! src/java.base/share/classes/java/lang/Class.java

hg: jigsaw/jake/jdk: Import of 8168980: Reinstate sun.reflect.ReflectionFactory.newConstructorForSerialization(Class, Constructor)

[chris . hegarty]

Changeset: 7992a052c7fa
Author:chegar
Date:  2016-11-01 12:37 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7992a052c7fa

Import of 8168980: Reinstate 
sun.reflect.ReflectionFactory.newConstructorForSerialization(Class,Constructor)
Reviewed-by: alanb

! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java
! src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java
! test/sun/reflect/ReflectionFactory/ReflectionFactoryTest.java

Re: Ugly things done to support multiple ContentHandlerFactory and URLStreamHandlerFactory

[Chris Hegarty]

Alan, Tom,

On 13/10/16 19:59, Alan Bateman wrote:

..

Speaking of net-dev, then maybe this thread should move there as this
topic is really more of a URL issue rather than module system issue.


I have replied to this over on net-dev [1] ( I hope that is ok ).
We can continue the discussion there.

-Chris.

[]1 http://mail.openjdk.java.net/pipermail/net-dev/2016-October/010380.html

Re: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs

[Chris Hegarty]

> On 22 Aug 2016, at 19:24, Steve Drach  wrote:
>> ...
>>> It exists purely because another class in the same versioned directory 
>>> depends on it.  If we are creating a versionedStream for the version that 
>>> the non-public class is in, it will be in finalNames, otherwise it won’t 
>>> be.  I believe the code is correct here.
>>> 
>>> New concealed packages can be added in a versioned section of the jar file 
>>> created by jar tool.  Should classes in concealed packages be added to 
>>> finalNames or not?  Or stated differently, for jlink, should a 
>>> versionedStream contain entries in concealed packages?
>>> 
>> Er, I thought the plan was for the set of concealed packages to be the same. 
>> It's okay for the ConcealedPackages in the base section to include "empty" 
>> packages.
> 
> I wasn’t involved with that decision.  Chris wrote that code, perhaps he can 
> comment.

This surprises me, as I have the same recollection as Alan; no additional
concealed packages are allowable in the versioned section.

I just checked the jar tool, and it does NOT add any versioned specific
concealed packages.

-Chris.

Re: Concealed packages (was Re: Module API usage questions)

[Chris Hegarty]

> On 20 Jul 2016, at 20:13, Paul Benedict  wrote:
> 
> Yes, that's my concern, but it's really only secondary to something else. I
> am more concerned that specifying both seems redundant. The JVM should be
> able to infer at resolution time that what's not exported is concealed.
> There may be a grander design at play which I yet to understand, but I
> don't see how specifying what's concealed adds more information to the mix
> than you already have.

Concealed Packages are just a performance optimization, nothing more.

If the ConcealedPackages attribute is present then it should contain
all the non-exported packages of the module. The ConcealedPackages
attribute, if present, can be used by a class loader implementation to
quickly determine, along with the exports, what packages are contained
within a module. If the ConcealedPackages attribute is not present then
the module artifact will have to be scanned to determine the set of
packages it contains.

-Chris.

Re: 8159248: ModuleFinder.of spec + 8158456: ModuleDescriptor.read does not verify dependence on java.base

[Chris Hegarty]

> On 16 Jun 2016, at 16:33, Alan Bateman  wrote:
> 
> I need a Reviewer for a patch is to address two conformance issues.
> 
> One is that the ModuleFinder.of(Path...) javadoc doesn't make it clear that 
> an exception is thrown when a module descriptor cannot be created for an 
> automatic module. As part of this I've changed the implementation to not 
> silently skip services configuration files or contents that don't parse as 
> identifiers. Also a small change to ModuleDescriptor.Builder in preparation 
> for other changes.
> 
> The other issue is that the requires table in the Module attribute for 
> java.base should be empty and should have at least an entry for java.base for 
> other modules.
> 
> The changes are simple, most of the changes are extending the test coverage:
> 
> http://cr.openjdk.java.net/~alanb/8159248%2b8158456/webrev/

Both these changes look good to me Alan.

-Chris.

Re: RFR: JDK-8158402 - jlink: should use regex for all pattern operations (--order-resources or --exclude-resources)

[Chris Hegarty]

> On 9 Jun 2016, at 12:57, Jim Laskey (Oracle) <james.las...@oracle.com> wrote:
> 
> 
>> On Jun 9, 2016, at 8:52 AM, Chris Hegarty <chris.hega...@oracle.com> wrote:
>> 
>>> 
>>> On 9 Jun 2016, at 11:16, Alan Bateman <alan.bate...@oracle.com> wrote:
>>> 
>>> On 08/06/2016 20:45, Jim Laskey (Oracle) wrote:
>>> 
>>>> Consistent use of PathPatterns for jlink, jimage and jmod options.
>>>> 
>>>> —optionName=(regex:|glob:|) ?? where  => 
>>>> glob:
>>>> 
>>>> http://cr.openjdk.java.net/~jlaskey/8158402/webrev/index.html 
>>>> <http://cr.openjdk.java.net/~jlaskey/8158402/webrev/index.html>
>>>> https://bugs.openjdk.java.net/browse/JDK-8158402 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8158402>
>>>> 
>>> This look okay to me but two questions:
>>> 
>>> 1. Do any of the usage resources need to be updated?
>>> 
>>> 2. Does this introduce an inconsistency in the jmod tool in that 
>>> --hash-modules takes a regex whereas --exclude takes a pattern that is a 
>>> glob (at least by default, it could be a regex too if prefixed with 
>>> "regex:").
>> 
>> As things currently stand --hash-modules accepts a regex, and --exclude 
>> accepts a glob. So this change does not affect default behaviour.
>> 
>> It makes sense for --exclude to take a glob ( and optionally a regex ).
>> I don’t think it makes sense for --hash-modules to take anything other
>> than a regex.
>> 
>> Are there issues with this?
>> 
>> Jim,   can you please rename GlobConverter to PatternConverter or 
>> ExcludeConverter,
>> or similar.
> 
> diff -r 766e969fc3e0 src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java
> --- a/src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.javaThu Jun 
> 09 07:55:38 2016 -0300
> +++ b/src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.javaThu Jun 
> 09 08:56:46 2016 -0300
> @@ -1072,6 +1072,10 @@
> @Override
> public Pattern convert(String value) {
> try {
> +if (value.startsWith("regex:")) {
> +value = value.substring("regex:".length()).trim();
> +}
> +
> return Pattern.compile(value);
> } catch (PatternSyntaxException e) {
> throw new CommandException("err.bad.pattern", value);
> @@ -1083,7 +1087,7 @@
> @Override public String valuePattern() { return "pattern"; }
> }
> 
> -static class GlobConverter implements ValueConverter {
> +static class PathMatcherConverter implements ValueConverter 
> {
> @Override
> public PathMatcher convert(String pattern) {
> try {
> @@ -1199,7 +1203,7 @@
> OptionSpec excludes
> = parser.accepts("exclude", getMessage("main.opt.exclude"))
> .withRequiredArg()
> -.withValuesConvertedBy(new GlobConverter());
> +.withValuesConvertedBy(new PathMatcherConverter());
> 
> OptionSpec hashModules
> = parser.accepts("hash-modules", 
> getMessage("main.opt.hash-modules”))

That looks fine. Thanks.

-Chris.

Re: RFR: JDK-8158402 - jlink: should use regex for all pattern operations (--order-resources or --exclude-resources)

[Chris Hegarty]

> On 9 Jun 2016, at 11:16, Alan Bateman  wrote:
> 
> On 08/06/2016 20:45, Jim Laskey (Oracle) wrote:
> 
>> Consistent use of PathPatterns for jlink, jimage and jmod options.
>> 
>> —optionName=(regex:|glob:|) ?? where  => 
>> glob:
>> 
>> http://cr.openjdk.java.net/~jlaskey/8158402/webrev/index.html 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8158402 
>> 
>> 
> This look okay to me but two questions:
> 
> 1. Do any of the usage resources need to be updated?
> 
> 2. Does this introduce an inconsistency in the jmod tool in that 
> --hash-modules takes a regex whereas --exclude takes a pattern that is a glob 
> (at least by default, it could be a regex too if prefixed with "regex:").

As things currently stand --hash-modules accepts a regex, and --exclude 
accepts a glob. So this change does not affect default behaviour.

It makes sense for --exclude to take a glob ( and optionally a regex ).
I don’t think it makes sense for --hash-modules to take anything other
than a regex.

Are there issues with this?

Jim,   can you please rename GlobConverter to PatternConverter or 
ExcludeConverter,
or similar.

-Chris.

Re: 8150668: Layer.defineModulesXXX with a Configuration containing java.base throws undocumented exception

[Chris Hegarty]

> On 25 May 2016, at 12:09, Alan Bateman  wrote:
> 
> This is another small fix where the Layer javadoc doesn't make it clear that 
> there can only be one "java.base" module in the VM. The enforcement has been 
> there but it wasn't specified and there weren't tests for this scenario.
>http://cr.openjdk.java.net/~alanb/8150668/webrev/

This looks fine.

-Chris.

Re: 8156142: ModuleReader instances don't always throw NPE for passed null args

[Chris Hegarty]

> On 25 May 2016, at 12:49, Alan Bateman  wrote:
> 
> 
> Another trivial patch, this time it's the ModuleReader for the system modules 
> is missing a null check so that it doesn't throw the expected NPE. The patch 
> is to mostly just expand test coverage.
>  http://cr.openjdk.java.net/~alanb/8156142/webrev/

I think this is fine. Does the @implSpec on release(ByteBuffer) need
to be updated too?

-Chris.

Re: (9) RFR: 8157783: Fix module dependencies for /javax/* and /jdk/* tests

[Chris Hegarty]

> On 25 May 2016, at 07:44, John Jiang  wrote:
> 
> Hi,
> Please review this patch on fixing module dependencies for /javax/* and 
> /jdk/* tests.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8157783
> Webrev: http://cr.openjdk.java.net/~jjiang/8157783/webrev.00/

The changes to the non-javax tests look fine.

Just a question on scripts, GetCallerClassTest.sh in this case, but the
question is more general.

You have added '@modules java.base/jdk.internal.reflect’, but what 
does this actually do?  I can see the value of explicitly declaring that
the script requires a particular set of modules, which could be used
for test selection depending on the runtime. But the qualified export
appears meaningless.

Also, since the module is java.base, the dependency is implicit and
not required.

-Chris.

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

[Chris Hegarty]

On 20/05/16 22:24, Alan Bateman wrote:

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.


Yes, of course. done


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


Updated.


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.


That is certainly better. done.


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


D'oh. Fixed.

Updated webrev:
  http://cr.openjdk.java.net/~chegar/8156497.01/

-Chris.

Re: 8152650: ModuleFinder.compose should accept varargs

[Chris Hegarty]

> On 21 May 2016, at 00:13, Mandy Chung  wrote:
> 
> 
>> 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.

+1

-Chris.

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

[Chris Hegarty]

> On 20 May 2016, at 17:01, Jonathan Gibbons <jonathan.gibb...@oracle.com> 
> 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
> 

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

Re: 8148834: Update module-info reader/writer to 53.0

[Chris Hegarty]

On 19 May 2016, at 12:49, Alan Bateman  wrote:

> javac has been switched to generate v53.0 class files. ASM, pack200 and 
> several other areas have been updated too. We have two places in the 
> module-info reader/writing that needs to be updated so I need a Reviewer to 
> get this into jdk9/dev.
> 
> -Alan
> 
> diff --git a/src/java.base/share/classes/java/lang/module/ModuleInfo.java 
> b/src/java.base/share/classes/java/lang/module/ModuleInfo.java
> --- a/src/java.base/share/classes/java/lang/module/ModuleInfo.java
> +++ b/src/java.base/share/classes/java/lang/module/ModuleInfo.java
> @@ -154,7 +154,7 @@
> int minor_version = in.readUnsignedShort();
> int major_version = in.readUnsignedShort();
> if (major_version < 53) {
> -// throw invalidModuleDescriptor"Must be >= 53.0");
> +throw invalidModuleDescriptor("Must be >= 53.0");
> }
> 
> ConstantPool cpool = new ConstantPool(in);
> diff --git 
> a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java 
> b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
> --- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
> +++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
> @@ -54,7 +54,7 @@
> ClassWriter cw = new ClassWriter(0);
> 
> String name = md.name().replace('.', '/') + "/module-info";
> -cw.visit(Opcodes.V1_8, ACC_MODULE, name, null, null, null);
> +cw.visit(Opcodes.V1_9, ACC_MODULE, name, null, null, null);
> 
> cw.visitAttribute(new ModuleAttribute(md));
> cw.visitAttribute(new ConcealedPackagesAttribute(md.conceals()));

This looks good to me Alan.

-Chris.

Re: 8157290: jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java failing

[Chris Hegarty]

On 19 May 2016, at 11:26, Alan Bateman  wrote:

> 
> The jdk9/client -> jdk9/dev integration yesterday included the fix for 
> JDK-8154539 which breaks a test that has been assuming sun.misc is in 
> java.base. I suspect this test was missed in previous rounds that laid the 
> ground for jdk.unsupported. Trivial change to get the test back to use a 
> package that overlaps with a package in java.base.
> 
> http://cr.openjdk.java.net/~alanb/8157290/webrev/

This looks fine. Yes, it was missed in previous jdk.unsupported changes.

-Chris.

Re: RFR [9] 8153737: Unsupported Module

[Chris Hegarty]

On 9 May 2016, at 20:43, Richard Opalka <ropa...@redhat.com> wrote:

> Fixed in JBoss Marshalling upstream.

Thanks for fixing this, and getting back to us on the list.

I assume then that, at least, this part of JBoss is working on JDK 9 b115, 
right?

-Chris.

> Thanks,
> 
> Rio
> 
> On 04/27/2016 11:54 PM, Chris Hegarty wrote:
>> Hi Rio,
>> 
>> 
>>> We are missing sun/reflect/ReflectionFactory$GetReflectionFactoryAction 
>>> inner class
>>> 
>>> in jdk.unsupported module:
>>> 
>>> java.lang.NoClassDefFoundError: 
>>> sun/reflect/ReflectionFactory$GetReflectionFactoryAction
>>>at 
>>> jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9-internal/BuiltinClassLoader.java:366)
>>>at 
>>> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@9-internal/ClassLoaders.java:184)
>>>at 
>>> java.lang.ClassLoader.loadClass(java.base@9-internal/ClassLoader.java:419)
>>>at 
>>> org.jboss.marshalling.reflect.SerializableClass.(SerializableClass.java:47)
>> GetReflectionFactoryAction is a convenience class for acquiring
>> the capability to instantiate reflective objects.
>> 
>> As part of JEP 260, we retained the single getReflectionFactory
>> accessor. You can replace your usage with the following:
>> 
>>  PrivilegedAction pa = new 
>> PrivilegedAction() {
>>@Override
>>public ReflectionFactory run() {
>>return ReflectionFactory.getReflectionFactory();
>>}
>>};
>> 
>> -Chris.
>> 
> 

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

[Chris Hegarty]

On 05/05/16 19:42, Alexandre (Shura) Iline wrote:

Chris, could you please take another look:
http://cr.openjdk.java.net/~shurailine/8151914/webrev.02/


This looks ok to me Shura, maybe just 'mrjar' for the directory
name?

Since there are file moves can you please prepare the changeset,
and I will push it for you.

-Chris.



What I have discovered is that jdk.zipfs was used to access jars on the 
classpath, which were JTreg jars: jtreg.jar, testing.jar, etc. Cleaning the 
class path through the environment removed dependency on the zipfs.

Whether the java.tools API behavior is correct is a separate matter. I am 
planning to create a standalone test case and take it with javac ppl.

Thank you.

Shura


On May 4, 2016, at 8:30 AM, Chris Hegarty <chris.hega...@oracle.com> wrote:

On 4 May 2016, at 14:32, Alan Bateman <alan.bate...@oracle.com> wrote:


On 04/05/2016 11:24, Chris Hegarty wrote:

:
The tests cause compilation of test library classes, but only some tests
actually use the methods that provoke compilation. Similar to above, tests
that don’t actually compile anything could depend on just java.compiler.

This is all to fragile and may cause problems with future refactoring. I
think we should add the same set of @moduels to all these tests, rather
than an individual set determined by intimate knowledge of the inner
workings of the test.

@modules java.compiler
   jdk.compiler
   jdk.zipfs
   jdk.jartool

with the addition of jdk.httpserver for MultiReleaseJarHttpProperties.


or we could move the tests into their own MultiRelease sub-directory and create 
a TEST.properties with a module key. That would allow these tests to drop 
@modules, except the test that uses the HTTP server.


I think that would be better.

-Chris.

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

[Chris Hegarty]

On 3 May 2016, at 16:10, Chris Hegarty <chris.hega...@oracle.com> wrote:

>>> 
>>> Can you please take a look on:
>>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/

Taking another look over this before sponsoring….

The test library dependency seems to be on java.compiler, and not jdk.compiler,
right ?  Also, I see no reason for the addition of jdk.zipfs.

-Chris.

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

[Chris Hegarty]

On 2 May 2016, at 22:48, Steve Drach  wrote:

> Looks fine to me,

+1.

-Chris.

> although I am not an official reviewer.  Thanks for doing this.
> 
>> On May 2, 2016, at 1:03 PM, Alexandre (Shura) Iline 
>>  wrote:
>> 
>> Hi,
>> 
>> Can you please take a look on:
>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/
>> ?
>> 
>> Thank you
>> 
>> Shura
>> 
> 

hg: jigsaw/jake/jdk: Fix typo

[chris . hegarty]

Changeset: 42007c6589fc
Author:chegar
Date:  2016-05-03 11:07 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/42007c6589fc

Fix typo

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

Re: 8154956: Module system implementation refresh (4/2016)

[Chris Hegarty]

> On 29 Apr 2016, at 13:38, Alan Bateman  wrote:
> 
> The webrevs, all repos are here:
>  http://cr.openjdk.java.net/~alanb/8154956/1/

The updated changes look good to me.

-Chris.

Re: 8154956: Module system implementation refresh (4/2016)

[Chris Hegarty]

> On 30 Apr 2016, at 05:48, Mandy Chung  wrote:
> 
> 
>> On Apr 29, 2016, at 5:38 AM, Alan Bateman  wrote:
>> 
>> The webrevs, all repos are here:
>> http://cr.openjdk.java.net/~alanb/8154956/1/
> 
> I reviewed all repos except hotspot.  Looks good in general.  Minor comments:
> 
> Configuration.java
>   Nit: line 361-364 there is an extra space
> 
> sun/tools/jar/Main.java
>  In the printModuleDescriptor method, creating a List from a stream is not 
> necessary.
>  1668 md.requires().stream().sorted().collect(toList()).forEach(
> 
> sortExports can be replaced as well.
> 
> I have a patch to clean this up that I can push to jake:
>  http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/jar-jmod-cleanup/

Thank you Mandy,  I attempted to clean this up recently, but your further 
updates are much better.

-Chris.

hg: jigsaw/jake/jdk: Consistent module descriptor output for the jmod and jar tool

[chris . hegarty]

Changeset: 9aca35cb3b89
Author:chegar
Date:  2016-04-28 17:25 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9aca35cb3b89

Consistent module descriptor output for the jmod and jar tool

! src/java.base/share/classes/module-info.java
! src/jdk.jartool/share/classes/sun/tools/jar/Main.java
! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java
! test/tools/jar/modularJar/Basic.java

Re: RFR JDK-8151913: Fix module dependencies in java/net tests

[Chris Hegarty]

On 27 Apr 2016, at 08:08, John Jiang  wrote:

> Hi,
> Please review the fix for explicitly declaring module dependencies for java 
> net tests.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8151913
> Webrev: http://cr.openjdk.java.net/~jjiang/8151913/webrev.00

This looks ok to me.  Thanks,

-Chris.

Re: 8154707: java/util/ServiceLoader/modules/BasicTest.java failing

[Chris Hegarty]

> On 20 Apr 2016, at 16:37, Alan Bateman  wrote:
> 
> 
> The changes to for JDK-8077360 [1] broke one of our test so it's failing in 
> jdk9/dev now.
> 
> As it happens, the test isn't really that useful anyway because the code is 
> exercised by many other tests. So I think we can just make is miscellaneous 
> test for now and replace when we do the next phase of SL work. The webrev is 
> here:
>   http://cr.openjdk.java.net/~alanb/8154707/webrev/index.html

The change looks ok.

-Chris

Re: RFR 8153928, test/lib/share/classes/jdk/test/lib/Utils.java introduced dependency to java.base/jdk.internal.misc

[Chris Hegarty]

> On 11 Apr 2016, at 07:57, Felix Yang  wrote:
> 
> Hi Alan and Amy,
>thanks for figuring this out. Updated to suggested practice.
> 
> New webrev: http://cr.openjdk.java.net/~xiaofeya/8153928/webrev.01/

Thanks for jumping on this, Felix. +1

-Chris.

> Felix
> 
>> On 2016/4/11 14:46, Alan Bateman wrote:
>>> On 11/04/2016 06:04, Felix Yang wrote:
>>> Amy,
>>>thanks. I'm not sure which practices are suggested. By searching the 
>>> existing tests, I found lots of test with 2+ @modules, so I chose to add 
>>> another @modules. Personally, both ways look clear and transparent for me.
>> We've tried to use one @modules per test but there are inconsistencies. I 
>> think some of those inconsistencies arose when patches were brought into 
>> jdk9/dev early and then subsequently merged. At some point we should do a 
>> pass over the existing usages to get them consistent.
>> 
>> -Alan
> 

Re: Initial webrev with changes for JDK 9

[Chris Hegarty]

Mandy,

On 14 Mar 2016, at 20:37, Mandy Chung  wrote:

> 
>> On Mar 11, 2016, at 1:39 AM, Alan Bateman  wrote:
>> 
>> 
>> I've refreshed the webrevs here:
>>  http://cr.openjdk.java.net/~alanb/8142968/2
> 
> 
> I have reviewed the jmod tool and some comments:
> 
> 299 private boolean printModuleDescriptor(InputStream in)
> 
> jmod -p option prints the output in different sections.
> java -listmods: prints the module descriptor closer to 
> module-info.java declaration.  Also jmod -p does not do any 
> sorting and names are unordered.
> 
> It would be better for both options to use similar format.  I think
> closer to how it is declared in module-info.java would be preferred.
> The optional attributes will follow it - the existing format is fine.

Good idea. I updated the output as close as possible, where applicable,
to -listmods:.

> It’d help if the package names and uses are printed in alphabetical order.
> 
> 584 } catch (ZipException x) {
> 585 // Skip. Do nothing. No packages will be added
> 
> When ZipException is thrown?  Should it be handled in the same way as 
> IOException?

I do remember adding this explicit catch. I’m reluctant to remove it
until I can find my notes, as to why it was added. I’ll have to get back
to you on this.

> 603 .filter(pkg -> pkg.length() > 0)   // module-info
> 
> I think jmod should detect if there is any unnamed package and output an 
> error since unnamed package is not allowed in named module.  Currently any 
> classes in unnamed package are include in the jmod file.

Classes in the unnamed package are now disallowed.

> findPackages should filter module-info.class explicitly.
> 
> 396 Path tempTarget = target.resolveSibling(target.getFileName() + 
> ".tmp”);
> 
> When any error occurs, foo.mod.tmp is left behind.

Fixed.

> jmods.properties - some unused messages.
> 
> err.cp.must.be.specified:--class-path must be specified
> err.dir.not.empty=not empty: {0}
> err.invalid.arg.for.option=invalid argument for option: {0}
> err.option.after.class=option must be specified before classes: {0}

Removed.

Changeset with the above updates:
  http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7e5d2398a250

-Chris.

hg: jigsaw/jake/jdk: jartool: code review comments

[chris . hegarty]

Changeset: 507b98946557
Author:chegar
Date:  2016-03-15 12:14 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/507b98946557

jartool: code review comments

! src/jdk.jartool/share/classes/sun/tools/jar/Main.java
! test/tools/jar/modularJar/Basic.java

hg: jigsaw/jake: Update jmod tool options and subcommands as per JEP 261

[chris . hegarty]

Changeset: aee43f8fb92a
Author:chegar
Date:  2016-03-14 21:32 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/aee43f8fb92a

Update jmod tool options and subcommands as per JEP 261

! make/CreateJmods.gmk

hg: jigsaw/jake/jdk: Update jmod tool options and subcommands as per JEP 261

[chris . hegarty]

Changeset: f57cdcac
Author:chegar
Date:  2016-03-14 21:19 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f57cdcac

Update jmod tool options and subcommands as per JEP 261

! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java
! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties
! test/jdk/jigsaw/launcher/basic/BasicTest.java
! test/jdk/jigsaw/module/ModuleReader/ModuleReaderTest.java
! test/jdk/jigsaw/tools/jlink/basic/BasicTest.java
! test/jdk/jigsaw/tools/jmod/JmodNegativeTest.java
! test/jdk/jigsaw/tools/jmod/JmodTest.java
! test/jdk/jigsaw/tools/lib/tests/JImageGenerator.java
! test/tools/jar/compat/CLICompatibility.java

hg: jigsaw/jake/hotspot: 2 new changesets

[chris . hegarty]

Changeset: f4040e0ac7b1
Author:lana
Date:  2016-02-04 11:28 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f4040e0ac7b1

Added tag jdk-9+104 for changeset 534c50395957

! .hgtags

Changeset: 4f5be0820e7f
Author:chegar
Date:  2016-02-05 10:02 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4f5be0820e7f

Merge

! .hgtags

hg: jigsaw/jake/langtools: 2 new changesets

[chris . hegarty]

Changeset: d10e29115134
Author:lana
Date:  2016-02-04 11:28 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d10e29115134

Added tag jdk-9+104 for changeset 3f60a4808377

! .hgtags

Changeset: 311748f33d80
Author:chegar
Date:  2016-02-05 10:02 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/311748f33d80

Merge

! .hgtags

hg: jigsaw/jake/jdk: 2 new changesets

[chris . hegarty]

Changeset: b5f8a1045cbe
Author:lana
Date:  2016-02-04 11:28 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b5f8a1045cbe

Added tag jdk-9+104 for changeset 8faf1aec77a9

! .hgtags

Changeset: 17c57a90889d
Author:chegar
Date:  2016-02-05 10:02 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/17c57a90889d

Merge

! .hgtags

hg: jigsaw/jake/jaxp: 2 new changesets

[chris . hegarty]

Changeset: 81d08cfd9e11
Author:lana
Date:  2016-02-04 11:28 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/81d08cfd9e11

Added tag jdk-9+104 for changeset 58448465334e

! .hgtags

Changeset: 796d4c4b6204
Author:chegar
Date:  2016-02-05 10:02 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/796d4c4b6204

Merge

hg: jigsaw/jake/corba: 2 new changesets

[chris . hegarty]

Changeset: 64006ae915b3
Author:lana
Date:  2016-02-04 11:28 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/64006ae915b3

Added tag jdk-9+104 for changeset e385e95e6101

! .hgtags

Changeset: 7ac10f87caf0
Author:chegar
Date:  2016-02-05 10:02 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/7ac10f87caf0

Merge

hg: jigsaw/jake/hotspot: 3 new changesets

[chris . hegarty]

Changeset: 2725fdfbc8e5
Author:shade
Date:  2016-01-28 19:43 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2725fdfbc8e5

8148483: JEP 280: Indify String Concatenation
Reviewed-by: psandoz, mcimadamore, igerasim, forax, plevart, vlivanov, ihse
Contributed-by: Aleksey Shipilev , Remi Forax 
, Peter Levart 

! test/gc/metaspace/TestPerfCountersAndMemoryPools.java

Changeset: 534c50395957
Author:lana
Date:  2016-01-28 15:42 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/534c50395957

Merge


Changeset: c7e50901f0a6
Author:chegar
Date:  2016-02-04 11:01 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c7e50901f0a6

Merge

! test/gc/metaspace/TestPerfCountersAndMemoryPools.java

hg: jigsaw/jake/jdk: 30 new changesets

[chris . hegarty]

Changeset: 2d461cd667ba
Author:chegar
Date:  2016-01-26 09:18 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2d461cd667ba

8148154: Integrate JOpt Simple for internal usage by JDK tools
Reviewed-by: alanb, redestad, rriggs

+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/AbstractOptionSpec.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/AlternativeLongOptionSpec.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/ArgumentAcceptingOptionSpec.java
+ src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/ArgumentList.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/BuiltinHelpFormatter.java
+ src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/HelpFormatter.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/IllegalOptionSpecificationException.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/MissingRequiredOptionException.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/MultipleArgumentsForOptionException.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/NoArgumentOptionSpec.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/NonOptionArgumentSpec.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionArgumentConversionException.java
+ src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionDeclarer.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionDescriptor.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionException.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionMissingRequiredArgumentException.java
+ src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionParser.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionParserState.java
+ src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionSet.java
+ src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionSpec.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionSpecBuilder.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionSpecTokenizer.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionalArgumentOptionSpec.java
+ src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/ParserRules.java
+ src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/README
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/RequiredArgumentOptionSpec.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/UnacceptableNumberOfNonOptionsException.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/UnconfiguredOptionException.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/UnrecognizedOptionException.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/ValueConversionException.java
+ src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/ValueConverter.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/internal/AbbreviationMap.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/internal/Classes.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/internal/Columns.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/internal/ConstructorInvokingValueConverter.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/internal/MethodInvokingValueConverter.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/internal/Objects.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/internal/Reflection.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/internal/ReflectionException.java
+ src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/internal/Row.java
+ src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/internal/Rows.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/internal/Strings.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/util/DateConverter.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/util/InetAddressConverter.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/util/KeyValuePair.java
+ 
src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/util/RegexMatcher.java

Changeset: 674710f62d05
Author:chegar
Date:  2016-01-26 09:25 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/674710f62d05

8065076: java/net/SocketPermission/SocketPermissionTest.java fails 
intermittently
Reviewed-by: coffeys, xiaofeya

! test/java/net/SocketPermission/SocketPermissionTest.java
- test/java/net/SocketPermission/policy

Changeset: 88a7d9ea4ae2
Author:asmotrak
Date:  2016-01-26 13:32 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/88a7d9ea4ae2

8144539: Update PKCS11 tests to run with security manager
Reviewed-by: valeriep, ascarpino

! test/sun/security/pkcs11/Cipher/ReinitCipher.java
! 

hg: jigsaw/jake/hotspot: 6 new changesets

[chris . hegarty]

Changeset: c5550502a1f1
Author:chegar
Date:  2016-01-13 14:34 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c5550502a1f1

8146736: Move sun.misc performance counters to jdk.internal.perf
Reviewed-by: alanb, mchung, rriggs

! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/prims/perf.cpp

Changeset: d5239fc1b697
Author:lana
Date:  2016-01-14 12:03 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d5239fc1b697

Merge


Changeset: 2dce8e72f3ef
Author:chegar
Date:  2016-01-21 11:22 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2dce8e72f3ef

Merge


Changeset: 31e4d11eab11
Author:lana
Date:  2016-01-21 09:45 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/31e4d11eab11

Added tag jdk-9+102 for changeset d5239fc1b697

! .hgtags

Changeset: 310896caab0c
Author:chegar
Date:  2016-01-21 20:56 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/310896caab0c

Merge

! .hgtags

Changeset: 62d2a0ffb810
Author:chegar
Date:  2016-01-21 21:01 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/62d2a0ffb810

Merge

hg: jigsaw/jake/corba: 2 new changesets

[chris . hegarty]

Changeset: 68b4d7d59f16
Author:lana
Date:  2016-01-21 09:45 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/68b4d7d59f16

Added tag jdk-9+102 for changeset 9c4662334d93

! .hgtags

Changeset: 268666f27e51
Author:chegar
Date:  2016-01-21 20:56 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/268666f27e51

Merge

hg: jigsaw/jake/jaxws: 2 new changesets

[chris . hegarty]

Changeset: 1ce986ce18e3
Author:lana
Date:  2016-01-21 09:46 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/1ce986ce18e3

Added tag jdk-9+102 for changeset 0868b93587cc

! .hgtags

Changeset: 6f1a8b346869
Author:chegar
Date:  2016-01-21 20:56 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/6f1a8b346869

Merge

hg: jigsaw/jake/nashorn: 12 new changesets

[chris . hegarty]

Changeset: bb63b699c060
Author:hannesw
Date:  2016-01-12 15:38 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/bb63b699c060

8146888: Wrong license headers in test files
Reviewed-by: mhaupt, jlaskey

! test/script/nosecurity/treeapi/for.js
! test/script/nosecurity/treeapi/forin.js
! test/script/nosecurity/treeapi/functionCall.js
! test/script/nosecurity/treeapi/functionDeclaration.js
! test/script/nosecurity/treeapi/functionExpr.js
! test/script/nosecurity/treeapi/identifier.js
! test/script/nosecurity/treeapi/if.js
! test/script/nosecurity/treeapi/instanceof.js

Changeset: 8faab9cd4b95
Author:hannesw
Date:  2016-01-12 16:30 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/8faab9cd4b95

8143896: java.lang.Long is implicitly converted to double
Reviewed-by: mhaupt, jlaskey

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArray.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeDate.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeNumber.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExpExecResult.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeString.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/IntArrayData.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornGuards.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java
! test/script/basic/JDK-8030200.js
! test/script/basic/JDK-8079145.js.EXPECTED
+ test/script/basic/JDK-8143896.js
! test/script/nosecurity/parserapi.js
! test/script/nosecurity/parserapi.js.EXPECTED

Changeset: 9ab6b645c428
Author:hannesw
Date:  2016-01-13 19:34 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/9ab6b645c428

8147008: Nashorn primitive linker should handle ES6 symbols
Reviewed-by: attila, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeBoolean.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeSymbol.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java
! test/script/basic/es6/symbols.js

Changeset: 0f21903deef8
Author:mhaupt
Date:  2016-01-14 10:55 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0f21903deef8

8036977: Make process singleton options to be context wide
Summary: The bug was fixed in an earlier change. This change contributes a test.
Reviewed-by: hannesw, sundar

+ test/script/nosecurity/context-dependent-logging.js

Changeset: da61004610e3
Author:sundar
Date:  2016-01-14 15:35 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/da61004610e3

8147070: Dynalink GuardedInvocation must check the Class object passed
Reviewed-by: hannesw, mhaupt, attila

! src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardedInvocation.java

Changeset: 2247904a107c
Author:attila
Date:  2016-01-14 13:22 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/2247904a107c

8144917: Prepare AbstractJavaLinker/BeanLinker codebase for missing member 
implementation
Reviewed-by: mhaupt, sundar

! src/jdk.dynalink/share/classes/jdk/dynalink/beans/AbstractJavaLinker.java
! src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java
! src/jdk.dynalink/share/classes/jdk/dynalink/beans/StaticClassLinker.java

Changeset: 30c3bcdb762c
Author:attila
Date:  2016-01-14 13:24 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/30c3bcdb762c

8144919: Implement missing member handler for BeansLinker
Reviewed-by: lagergren, mhaupt, sundar

! src/jdk.dynalink/share/classes/jdk/dynalink/beans/AbstractJavaLinker.java
! src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java
! src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeansLinker.java
+ 
src/jdk.dynalink/share/classes/jdk/dynalink/beans/LinkerServicesWithMissingMemberHandlerFactory.java
+ 
src/jdk.dynalink/share/classes/jdk/dynalink/beans/MissingMemberHandlerFactory.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! 

hg: jigsaw/jake/langtools: 17 new changesets

[chris . hegarty]

Changeset: 88a874f33d6d
Author:alundblad
Date:  2016-01-08 17:14 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/88a874f33d6d

8144226: Sjavac's handling of include/exclude patterns is buggy, redundant and 
inconsistent
Summary: Rewrote sjavac include/exclude pattern handling.
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Util.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/OptionHelper.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Options.java
! 
src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/SourceLocation.java
! test/tools/sjavac/CompileExcludingDependency.java
! test/tools/sjavac/CompileWithAtFile.java
! test/tools/sjavac/CompileWithInvisibleSources.java
! test/tools/sjavac/CompileWithOverrideSources.java
- test/tools/sjavac/ExclPattern.java
+ test/tools/sjavac/HiddenFiles.java
+ test/tools/sjavac/IncludeExcludePatterns.java
! test/tools/sjavac/OptionDecoding.java
! test/tools/sjavac/Serialization.java
! test/tools/sjavac/util/OptionTestUtil.java

Changeset: f6740b308ee2
Author:dlsmith
Date:  2016-01-08 12:29 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f6740b308ee2

8037789: Surprising more-specific results for lambda bodies with no return 
expressions
Reviewed-by: mcimadamore, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java

Changeset: 9571d628ecf6
Author:vromero
Date:  2016-01-08 14:24 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9571d628ecf6

8146719: javac test BootClassPathPrepend.java should be deleted
Reviewed-by: jjg

- test/tools/javac/file/BootClassPathPrepend.java

Changeset: 5ab68e3a1096
Author:vromero
Date:  2016-01-08 15:15 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5ab68e3a1096

8146722: javac remove test T6430241.java as irrelevant in 9
Reviewed-by: jjg

- test/tools/javac/api/T6430241.java

Changeset: 3a6560c043d2
Author:dlsmith
Date:  2016-01-08 17:02 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3a6560c043d2

8143852: Implement type variable renaming for functional interface most 
specific test
Reviewed-by: mcimadamore, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/lambda/MostSpecific15.java
+ test/tools/javac/lambda/MostSpecific16.java
+ test/tools/javac/lambda/MostSpecific16.out
+ test/tools/javac/lambda/MostSpecific17.java
+ test/tools/javac/lambda/MostSpecific18.java
+ test/tools/javac/lambda/MostSpecific19.java
+ test/tools/javac/lambda/MostSpecific19.out
+ test/tools/javac/lambda/MostSpecific20.java
+ test/tools/javac/lambda/MostSpecific21.java
+ test/tools/javac/lambda/MostSpecific21.out
+ test/tools/javac/lambda/MostSpecific22.java
+ test/tools/javac/lambda/MostSpecific23.java
+ test/tools/javac/lambda/MostSpecific23.out
+ test/tools/javac/lambda/MostSpecific24.java
+ test/tools/javac/lambda/MostSpecific24.out
+ test/tools/javac/lambda/MostSpecific25.java
+ test/tools/javac/lambda/MostSpecific25.out
+ test/tools/javac/lambda/MostSpecific26.java
+ test/tools/javac/lambda/MostSpecific26.out
+ test/tools/javac/lambda/MostSpecific27.java
+ test/tools/javac/lambda/MostSpecific28.java
+ test/tools/javac/lambda/MostSpecific28.out

Changeset: 9f3a70d14025
Author:jjg
Date:  2016-01-08 22:24 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9f3a70d14025

8146727: test tools/sjavac/IncludeExcludePatterns.java fails on Windows
Reviewed-by: darcy

! test/tools/sjavac/IncludeExcludePatterns.java

Changeset: c3b040ed4122
Author:jlahoda
Date:  2016-01-11 11:21 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c3b040ed4122

8056897: Improve error recovery for empty binary and hexadecimal literals.
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! test/tools/javac/BadHexConstant.java
! test/tools/javac/BadHexConstant.out
! test/tools/javac/diags/examples/IdentifierExpected.java
+ test/tools/javac/lexer/JavaLexerTest.java
! test/tools/javac/literals/T6891079.java
! test/tools/javac/literals/T6891079.out

Changeset: a5066095d36e
Author:alundblad
Date:  2016-01-11 17:08 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a5066095d36e

8145944: sjavac client could not connect to server
Summary: Wait for port file to get deleted before returning from 
PortFile::delete
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/PortFile.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java

Changeset: 

hg: jigsaw/jake/jaxp: 7 new changesets

[chris . hegarty]

Changeset: 1e29ca011af4
Author:joehw
Date:  2016-01-08 10:51 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/1e29ca011af4

8144967: javax.xml.transform.Source and org.xml.sax.InputSource can be empty
Reviewed-by: darcy, rriggs

! src/java.xml/share/classes/javax/xml/transform/Source.java
! src/java.xml/share/classes/javax/xml/transform/dom/DOMSource.java
! src/java.xml/share/classes/javax/xml/transform/sax/SAXSource.java
! src/java.xml/share/classes/javax/xml/transform/stax/StAXSource.java
! src/java.xml/share/classes/javax/xml/transform/stream/StreamSource.java
! src/java.xml/share/classes/org/xml/sax/InputSource.java
+ test/javax/xml/jaxp/unittest/common/Sources.java

Changeset: b34427de0b08
Author:joehw
Date:  2016-01-12 15:29 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/b34427de0b08

8144966: Catalog API: Null handling and reference to Reader
Reviewed-by: mchung, rriggs

! src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java
! src/java.xml/share/classes/javax/xml/catalog/CatalogManager.java
! src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolver.java
! test/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java
! test/javax/xml/jaxp/libs/catalog/CatalogTestUtils.java
! test/javax/xml/jaxp/libs/jaxp/library/JAXPTestUtilities.java
! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java

Changeset: 56972d2827cb
Author:joehw
Date:  2016-01-13 10:12 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/56972d2827cb

8146606: Catalog.matchSystem() appends an extra '/' to the matched result
Reviewed-by: lancea

! src/java.xml/share/classes/javax/xml/catalog/RewriteSystem.java
! src/java.xml/share/classes/javax/xml/catalog/RewriteUri.java
! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java
+ test/javax/xml/jaxp/unittest/catalog/rewriteCatalog.xml

Changeset: 9dcf193c0b6c
Author:lana
Date:  2016-01-14 12:03 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/9dcf193c0b6c

Merge


Changeset: 62db4eb04781
Author:chegar
Date:  2016-01-21 11:19 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/62db4eb04781

Merge


Changeset: 09dcbee7948e
Author:lana
Date:  2016-01-21 09:46 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/09dcbee7948e

Added tag jdk-9+102 for changeset 9dcf193c0b6c

! .hgtags

Changeset: 99afcfda3af0
Author:chegar
Date:  2016-01-21 20:56 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/99afcfda3af0

Merge

hg: jigsaw/jake/hotspot: 5 new changesets

[chris . hegarty]

Changeset: dd2b7bf1c72e
Author:lana
Date:  2016-01-07 09:33 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dd2b7bf1c72e

Added tag jdk-9+100 for changeset bdb0acafc63c

! .hgtags

Changeset: 861652d2fc80
Author:chegar
Date:  2016-01-06 10:03 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/861652d2fc80

8145544: Move sun.misc.VM to jdk.internal.misc
Reviewed-by: alanb, dholmes, mullan, weijun

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

Changeset: 9f45d3d57d69
Author:lana
Date:  2016-01-07 15:15 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9f45d3d57d69

Merge


Changeset: b1e56c4a3024
Author:lana
Date:  2016-01-14 08:08 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b1e56c4a3024

Added tag jdk-9+101 for changeset 9f45d3d57d69

! .hgtags

Changeset: e443a6d17444
Author:chegar
Date:  2016-01-19 09:13 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e443a6d17444

Merge

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

hg: jigsaw/jake/corba: 3 new changesets

[chris . hegarty]

Changeset: 30dfb3bd3d06
Author:lana
Date:  2016-01-07 09:33 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/30dfb3bd3d06

Added tag jdk-9+100 for changeset 791d0d3ac013

! .hgtags

Changeset: 9c4662334d93
Author:lana
Date:  2016-01-14 08:08 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/9c4662334d93

Added tag jdk-9+101 for changeset 30dfb3bd3d06

! .hgtags

Changeset: 959d18056b1a
Author:chegar
Date:  2016-01-19 09:14 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/959d18056b1a

Merge

hg: jigsaw/jake/langtools: 14 new changesets

[chris . hegarty]

Changeset: bdbad16dd9ac
Author:sadayapalam
Date:  2015-12-22 16:37 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bdbad16dd9ac

8145466: javac: No line numbers in compilation error
Summary: Compiler should not use the syntax tree from enclosing contexts in 
diagnostics even when the enclosing contexts are consulted for method lookup.
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/diags/DiagnosticRewriterTest.java
+ test/tools/javac/diags/DiagnosticRewriterTest.out
+ test/tools/javac/diags/DiagnosticRewriterTest2.java
+ test/tools/javac/diags/DiagnosticRewriterTest2.out

Changeset: 5d73162435ba
Author:chegar
Date:  2015-12-22 12:19 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5d73162435ba

8145990: Move sun.misc math support classes to jdk.internal.math
Reviewed-by: bpb, darcy

! test/tools/javac/proprietary/WarnVariable.java
! test/tools/javac/proprietary/WarnVariable.out
! test/tools/javac/proprietary/WarnWildcard.java
! test/tools/javac/proprietary/WarnWildcard.out

Changeset: 33e28fa7fa17
Author:lana
Date:  2015-12-24 10:34 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/33e28fa7fa17

Merge


Changeset: 51136404ee5e
Author:rfield
Date:  2015-12-29 21:27 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/51136404ee5e

8145239: JShell: throws AssertionError when replace classes with some methods 
which depends on these classes
Reviewed-by: rfield
Contributed-by: bitterf...@gmail.com

! src/jdk.jshell/share/classes/jdk/jshell/Eval.java
! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java
! src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java
! src/jdk.jshell/share/classes/jdk/jshell/Unit.java
! src/jdk.jshell/share/classes/jdk/jshell/Util.java
! test/jdk/jshell/ClassesTest.java

Changeset: 1e4be39c1401
Author:lana
Date:  2016-01-07 09:34 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1e4be39c1401

Added tag jdk-9+100 for changeset 51136404ee5e

! .hgtags

Changeset: 512af6dd6a7c
Author:chegar
Date:  2016-01-06 10:01 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/512af6dd6a7c

8145544: Move sun.misc.VM to jdk.internal.misc
Reviewed-by: alanb, mullan, weijun

! test/tools/javac/proprietary/WarnImport.java
! test/tools/javac/proprietary/WarnImport.out
! test/tools/javac/proprietary/WarnMethod.java
! test/tools/javac/proprietary/WarnMethod.out
! test/tools/javac/proprietary/WarnStaticImport.java
! test/tools/javac/proprietary/WarnStaticImport.out

Changeset: 13f3bd8e4924
Author:vromero
Date:  2016-01-06 10:34 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/13f3bd8e4924

8146439: delete test T7021650.java as redundant
Reviewed-by: jjg

- test/tools/javac/util/context/T7021650.java

Changeset: 70ac078df098
Author:jjg
Date:  2016-01-06 13:31 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/70ac078df098

8146572: Update "@since 1.9" to "@since 9" to match java.version.specification 
[langtools]
Reviewed-by: darcy

! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
! 
src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor9.java
! 
src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java
! 
src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java
! 
src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor9.java
! 
src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java
! src/java.compiler/share/classes/javax/tools/FileManagerUtils.java
! src/java.compiler/share/classes/javax/tools/StandardJavaFileManager.java
! src/jdk.compiler/share/classes/com/sun/source/doctree/DocCommentTree.java
! src/jdk.compiler/share/classes/com/sun/source/doctree/IndexTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/CompilationUnitTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/PackageTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java
! src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java
! src/jdk.compiler/share/classes/com/sun/source/util/TaskEvent.java

Changeset: 22391da9418e
Author:alundblad
Date:  2016-01-07 11:41 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/22391da9418e

8143301: Sjavac does not close file given to --compare-found-sources
Summary: File is now closed after use.
Reviewed-by: jlahoda, jjg

hg: jigsaw/jake: 13 new changesets

[chris . hegarty]

Changeset: bb2b1548325d
Author:chegar
Date:  2015-12-22 12:17 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/bb2b1548325d

8145990: Move sun.misc math support classes to jdk.internal.math
Reviewed-by: bpb, darcy

! modules.xml

Changeset: ba256c014bff
Author:erikj
Date:  2015-12-23 10:00 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/ba256c014bff

8146002: Need to support mirrors for bootstrapping Jib
Reviewed-by: ihse, tbell

! common/bin/jib.sh

Changeset: 48b9f5c66837
Author:lana
Date:  2015-12-24 10:33 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/48b9f5c66837

Merge


Changeset: c1f30ac14db0
Author:sdrach
Date:  2015-12-30 16:15 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/c1f30ac14db0

8144355: JDK 9 changes to ZipFileSystem to support multi-release jar files
Summary: JEP 238 Multi-Release JarFileSystem implementation
Reviewed-by: alanb, psandoz, sherman

! modules.xml

Changeset: b0a80d214458
Author:lana
Date:  2016-01-07 09:33 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/b0a80d214458

Added tag jdk-9+100 for changeset c1f30ac14db0

! .hgtags

Changeset: 918e76f6ed2a
Author:chegar
Date:  2016-01-06 10:01 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/918e76f6ed2a

8145544: Move sun.misc.VM to jdk.internal.misc
Reviewed-by: alanb, mullan, weijun

! modules.xml

Changeset: c7fead77b7c6
Author:lana
Date:  2016-01-07 15:13 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/c7fead77b7c6

Merge


Changeset: f0117f6e5234
Author:simonis
Date:  2016-01-08 09:46 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/f0117f6e5234

8146638: Only use compiler option files if they are really supported by the 
toolchain
Reviewed-by: erikj

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! make/common/NativeCompilation.gmk

Changeset: f6f02029c56d
Author:simonis
Date:  2016-01-08 11:12 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/f6f02029c56d

8146639: Fix detection of Cups headers during configuration
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/lib-cups.m4

Changeset: 1bee5efa73e3
Author:alanb
Date:  2016-01-08 11:45 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/1bee5efa73e3

8049422: Remove @jdk.Exported
Reviewed-by: dfuchs, mchung, darcy, chegar

! make/common/NON_CORE_PKGS.gmk
! modules.xml

Changeset: c4d72a162083
Author:erikj
Date:  2016-01-08 15:05 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/c4d72a162083

8146091: Configure fails to configure icecc on OEL
Reviewed-by: ihse

! common/autoconf/build-performance.m4
! common/autoconf/generated-configure.sh

Changeset: def087f16668
Author:lana
Date:  2016-01-14 08:08 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/def087f16668

Added tag jdk-9+101 for changeset c4d72a162083

! .hgtags

Changeset: 2f434c396e49
Author:chegar
Date:  2016-01-19 14:09 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/2f434c396e49

Merge

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! make/common/NON_CORE_PKGS.gmk
! make/common/NativeCompilation.gmk

hg: jigsaw/jake/langtools: 2 new changesets

[chris . hegarty]

Changeset: 592453420cb8
Author:lana
Date:  2015-12-23 15:41 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/592453420cb8

Added tag jdk-9+99 for changeset cb73b474703e

! .hgtags

Changeset: c5c7605b72a5
Author:chegar
Date:  2016-01-11 15:45 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c5c7605b72a5

Merge

! .hgtags

hg: jigsaw/jake/jdk: Fix typos in DTLS test @module tags

[chris . hegarty]

Changeset: 0179576bca95
Author:chegar
Date:  2016-01-08 11:45 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0179576bca95

Fix typos in DTLS test @module tags

! test/javax/net/ssl/DTLS/CipherSuite.java
! test/javax/net/ssl/DTLS/ClientAuth.java
! test/javax/net/ssl/DTLS/InvalidCookie.java
! test/javax/net/ssl/DTLS/InvalidRecords.java
! test/javax/net/ssl/DTLS/NoMacInitialClientHello.java
! test/javax/net/ssl/DTLS/Reordered.java
! test/javax/net/ssl/DTLS/Retransmission.java
! test/javax/net/ssl/DTLS/WeakCipherSuite.java

hg: jigsaw/jake/corba: 4 new changesets

[chris . hegarty]

Changeset: ea285530245c
Author:lana
Date:  2015-12-17 19:39 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/ea285530245c

Added tag jdk-9+97 for changeset 10a482b86358

! .hgtags

Changeset: 180212ee1d87
Author:lana
Date:  2015-12-18 09:29 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/180212ee1d87

Added tag jdk-9+98 for changeset ea285530245c

! .hgtags

Changeset: 791d0d3ac013
Author:lana
Date:  2015-12-23 15:41 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/791d0d3ac013

Added tag jdk-9+99 for changeset 180212ee1d87

! .hgtags

Changeset: 20c851d5f3ec
Author:chegar
Date:  2016-01-06 11:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/20c851d5f3ec

Merge

hg: jigsaw/jake: 31 new changesets

[chris . hegarty]

Changeset: ec0e9c395cc0
Author:vlivanov
Date:  2015-11-30 13:39 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/ec0e9c395cc0

8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls
Reviewed-by: jrose, dlong, aph, forax

! test/lib/sun/hotspot/WhiteBox.java

Changeset: a178cfd8a297
Author:neliasso
Date:  2015-12-01 19:18 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a178cfd8a297

Merge

! test/lib/sun/hotspot/WhiteBox.java

Changeset: d2ec5fa5ef7a
Author:amurillo
Date:  2015-12-03 22:30 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/d2ec5fa5ef7a

Merge


Changeset: 19754c27a6a3
Author:sundar
Date:  2015-12-08 10:11 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/19754c27a6a3

8143404: Remove apple script engine code in jdk repository
Reviewed-by: alanb, mchung

! common/bin/unshuffle_list.txt
! modules.xml

Changeset: a151b3ec17a1
Author:erikj
Date:  2015-12-09 11:44 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a151b3ec17a1

8136782: Introduce a build/configure wrapper
Reviewed-by: ihse

! .hgignore
! common/autoconf/basics.m4
! common/autoconf/configure
! common/autoconf/configure.ac
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
+ common/bin/jab.sh
+ common/conf/jab-profiles.js
! make/Help.gmk
! make/InitSupport.gmk
! make/Main.gmk

Changeset: d86c771b7d54
Author:lana
Date:  2015-12-10 09:23 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/d86c771b7d54

Merge


Changeset: aa66642d2fff
Author:ysuenaga
Date:  2015-12-11 21:58 +0900
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/aa66642d2fff

8036003: Add --with-debug-symbols=[none|internal|external|zipped]
Reviewed-by: ihse, dholmes

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/autoconf/spec.gmk.in
! make/common/NativeCompilation.gmk

Changeset: feffe40d47e1
Author:erikj
Date:  2015-12-11 14:20 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/feffe40d47e1

8145115: make JAVAC_FLAGS=-g no longer works
Reviewed-by: ihse

! make/CompileJavaModules.gmk

Changeset: a208775dedf3
Author:erikj
Date:  2015-12-11 17:15 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a208775dedf3

8145206: Configure broken on Macosx
Reviewed-by: tbell

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

Changeset: 75c3897541ec
Author:erikj
Date:  2015-12-11 17:18 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/75c3897541ec

8145185: Rename JAB the build tool to JIB
Reviewed-by: ihse, tbell

! .hgignore
- common/bin/jab.sh
+ common/bin/jib.sh
- common/conf/jab-profiles.js
+ common/conf/jib-profiles.js

Changeset: 48987460c7d4
Author:lana
Date:  2015-12-17 19:39 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/48987460c7d4

Added tag jdk-9+97 for changeset 75c3897541ec

! .hgtags

Changeset: 27bdfaf601e3
Author:lana
Date:  2015-12-18 09:29 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/27bdfaf601e3

Added tag jdk-9+98 for changeset 48987460c7d4

! .hgtags

Changeset: 4763fa38faf9
Author:erikj
Date:  2015-12-14 11:51 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/4763fa38faf9

8145008: Add libelf package to Linux devkit
Reviewed-by: ihse

! make/devkit/Tools.gmk

Changeset: 9d2b28adb26f
Author:chegar
Date:  2015-12-14 20:32 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/9d2b28adb26f

8144995: Move sun.misc.HexDumpEncoder to sun.security.util
Reviewed-by: psandoz, mchung

! modules.xml

Changeset: e79b5043fd02
Author:ehelin
Date:  2015-12-15 11:04 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/e79b5043fd02

8139272: Add configure variable to set concurrency for jtreg tests
Reviewed-by: erikj, ihse

! common/autoconf/build-performance.m4
! common/autoconf/configure.ac
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! make/Help.gmk
! make/InitSupport.gmk
! make/MainSupport.gmk
! test/Makefile

Changeset: ca96c0c2104b
Author:erikj
Date:  2015-12-15 15:45 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/ca96c0c2104b

8145391: Updated jprt.properties, devtools, jib and readme with SS12u4
Reviewed-by: ihse, tbell

! README
! README-builds.html
! README-builds.md
! common/conf/jib-profiles.js
+ make/devkit/createSolarisDevkit.sh
+ make/devkit/solaris11.1-package-list.txt
! make/jprt.properties

Changeset: 5a7e1695ac8c
Author:ihse
Date:  2015-12-15 11:02 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/5a7e1695ac8c

8142907: Integration of minor fixes from the build-infra project
Reviewed-by: erikj, dholmes

! common/autoconf/configure.ac
! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
+ common/autoconf/hotspot.m4
! common/autoconf/jdk-options.m4
! common/autoconf/spec.gmk.in
! 

hg: jigsaw/jake/jaxp: 9 new changesets

[chris . hegarty]

Changeset: a549eb34d37e
Author:joehw
Date:  2015-12-09 21:40 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a549eb34d37e

8072081: Supplementary characters are rejected in comments
Reviewed-by: lancea

! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java
! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java
! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java
+ test/javax/xml/jaxp/unittest/parsers/SupplementaryChars.java

Changeset: 9c107c050335
Author:lana
Date:  2015-12-10 09:24 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/9c107c050335

Merge


Changeset: 52b01339235f
Author:lana
Date:  2015-12-17 19:39 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/52b01339235f

Added tag jdk-9+97 for changeset 9c107c050335

! .hgtags

Changeset: a7d62c74abb9
Author:lana
Date:  2015-12-18 09:29 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a7d62c74abb9

Added tag jdk-9+98 for changeset 52b01339235f

! .hgtags

Changeset: 97f4af132b2e
Author:joehw
Date:  2015-12-11 12:01 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/97f4af132b2e

8068839: newDuration(x) produces incorrect outputs for some values of x
Reviewed-by: rriggs, lancea

! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationImpl.java
+ test/javax/xml/jaxp/unittest/datatype/JDK8068839Test.java

Changeset: a01744f786df
Author:lana
Date:  2015-12-17 20:25 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a01744f786df

Merge


Changeset: 52774b544850
Author:lana
Date:  2015-12-18 09:57 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/52774b544850

Merge


Changeset: d45bcd374f60
Author:lana
Date:  2015-12-23 15:41 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/d45bcd374f60

Added tag jdk-9+99 for changeset 52774b544850

! .hgtags

Changeset: 42eb17d671fa
Author:chegar
Date:  2016-01-06 11:27 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/42eb17d671fa

Merge

hg: jigsaw/jake/hotspot: Manual import of 8142907: Integration of minor fixes from the build-infra project

[chris . hegarty]

Changeset: 48135fa262f8
Author:ihse
Date:  2015-12-15 11:02 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/48135fa262f8

Manual import of 8142907: Integration of minor fixes from the build-infra 
project
Reviewed-by: erikj, dholmes

! make/lib/Lib-jdk.hotspot.agent.gmk

hg: jigsaw/jake/jdk: Fix @modules in DTLS tests

[chris . hegarty]

Changeset: 278b3ce9d5d3
Author:chegar
Date:  2016-01-08 07:08 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/278b3ce9d5d3

Fix @modules in DTLS tests

! test/javax/net/ssl/DTLS/CipherSuite.java
! test/javax/net/ssl/DTLS/ClientAuth.java
! test/javax/net/ssl/DTLS/InvalidCookie.java
! test/javax/net/ssl/DTLS/InvalidRecords.java
! test/javax/net/ssl/DTLS/NoMacInitialClientHello.java
! test/javax/net/ssl/DTLS/Reordered.java
! test/javax/net/ssl/DTLS/Retransmission.java
! test/javax/net/ssl/DTLS/WeakCipherSuite.java