From mandy.chung at oracle.com  Sun Nov  1 04:55:58 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sun, 01 Nov 2015 04:55:58 +0000
Subject: hg: jigsaw/jake/jdk: Update
	java.util.spi.AbstractResourceBundleProvider javadoc per the
	fix for 8139067
Message-ID: <201511010455.tA14twMH016812@aojmv0008.oracle.com>

Changeset: 0b5cbd1f966e
Author:    mchung
Date:      2015-10-31 21:55 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0b5cbd1f966e

Update java.util.spi.AbstractResourceBundleProvider javadoc per the fix for 8139067

! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java


From alan.bateman at oracle.com  Sun Nov  1 18:34:19 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sun, 01 Nov 2015 18:34:19 +0000
Subject: hg: jigsaw/jake/jdk: Drop -Xoverride, replaced by -Xpatch
Message-ID: <201511011834.tA1IYJGC000918@aojmv0008.oracle.com>

Changeset: 34a20e1f0d8b
Author:    alanb
Date:      2015-11-01 18:30 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/34a20e1f0d8b

Drop -Xoverride, replaced by -Xpatch

! src/java.base/share/native/libjli/java.c


From mandy.chung at oracle.com  Mon Nov  2 04:05:59 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Mon, 02 Nov 2015 04:05:59 +0000
Subject: hg: jigsaw/jake/langtools: Update T6769027.java to use
	JavacMessages.add(ResourceBundleHelper)
Message-ID: <201511020405.tA245xrP018846@aojmv0008.oracle.com>

Changeset: 056daf65e292
Author:    mchung
Date:      2015-11-01 20:05 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/056daf65e292

Update T6769027.java to use JavacMessages.add(ResourceBundleHelper)

! test/tools/javac/Diagnostics/6769027/T6769027.java


From rory.odonnell at oracle.com  Mon Nov  2 08:51:32 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Mon, 2 Nov 2015 08:51:32 +0000
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <5634C884.6040302@oracle.com>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com>
Message-ID: <56372414.7010605@oracle.com>

I can't find a bug in Gradle's JIRA on this issue, Mani do you want to 
log an issue there ?

Rgds,Rory

On 31/10/2015 13:56, Alan Bateman wrote:
> On 31/10/2015 12:50, Mani Sarkar wrote:
>> Hi Rory,
>>
>> Do you know of a version of Gradle or a EA version which is JDK 9 
>> Jigsaw compatible, we get these failures when building:
>>
>> https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console 
>>
>>
> Caused by: java.lang.IllegalAccessException: class 
> org.gradle.internal.reflect.DirectInstantiator cannot access class 
> com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because 
> module jdk.compiler does not export package com.sun.tools.javac.api to 
> <unnamed module @b7f23d9>
>     at 
> org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49)
>     ... 86 more
>
> We should at least check if there is a bug in the Gradle JIRA for 
> this. It can be worked around by configuring the compileJava options 
> to fork javac but you might not want to do that.
>
> The other issue with Gradle that we know about is the 
> ClassCastException when attempting to run tests, this is tracked here:
>     https://issues.gradle.org/browse/GRADLE-3287
>
> -Alan.
>

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


From cedric.champeau at gmail.com  Mon Nov  2 08:56:39 2015
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Mon, 2 Nov 2015 09:56:39 +0100
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <56372414.7010605@oracle.com>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com> <56372414.7010605@oracle.com>
Message-ID: <CADQzvmmxb50=r63Ab_2g+z75GFK3eGOvp9XLjRtBCfoLetvQWA@mail.gmail.com>

BTW, Groovy itself is not compatible with Jigsaw, so my guess would be that
even if Gradle fixed this, you would have different errors because Gradle
uses Groovy. What is possible today is to run Gradle on Java 9 non jigsaw,
and compile using Java 9 Jigsaw.

Jochen sent an email on jigsaw-dev a few weeks ago ("Groovy with Jigsaw")
but as far as I understand, there's no clear understanding of the
problem/solutions so far.

2015-11-02 9:51 GMT+01:00 Rory O'Donnell <rory.odonnell at oracle.com>:

> I can't find a bug in Gradle's JIRA on this issue, Mani do you want to log
> an issue there ?
>
> Rgds,Rory
>
>
> On 31/10/2015 13:56, Alan Bateman wrote:
>
>> On 31/10/2015 12:50, Mani Sarkar wrote:
>>
>>> Hi Rory,
>>>
>>> Do you know of a version of Gradle or a EA version which is JDK 9 Jigsaw
>>> compatible, we get these failures when building:
>>>
>>>
>>> https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console
>>>
>>> Caused by: java.lang.IllegalAccessException: class
>> org.gradle.internal.reflect.DirectInstantiator cannot access class
>> com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because module
>> jdk.compiler does not export package com.sun.tools.javac.api to <unnamed
>> module @b7f23d9>
>>     at
>> org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49)
>>     ... 86 more
>>
>> We should at least check if there is a bug in the Gradle JIRA for this.
>> It can be worked around by configuring the compileJava options to fork
>> javac but you might not want to do that.
>>
>> The other issue with Gradle that we know about is the ClassCastException
>> when attempting to run tests, this is tracked here:
>>     https://issues.gradle.org/browse/GRADLE-3287
>>
>> -Alan.
>>
>>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>

From Alan.Bateman at oracle.com  Mon Nov  2 09:05:23 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 2 Nov 2015 09:05:23 +0000
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <CADQzvmmxb50=r63Ab_2g+z75GFK3eGOvp9XLjRtBCfoLetvQWA@mail.gmail.com>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com> <56372414.7010605@oracle.com>
	<CADQzvmmxb50=r63Ab_2g+z75GFK3eGOvp9XLjRtBCfoLetvQWA@mail.gmail.com>
Message-ID: <56372753.6010702@oracle.com>



On 02/11/2015 08:56, C?dric Champeau wrote:
> BTW, Groovy itself is not compatible with Jigsaw, so my guess would be 
> that even if Gradle fixed this, you would have different errors 
> because Gradle uses Groovy. What is possible today is to run Gradle on 
> Java 9 non jigsaw, and compile using Java 9 Jigsaw.
>
> Jochen sent an email on jigsaw-dev a few weeks ago ("Groovy with 
> Jigsaw") but as far as I understand, there's no clear understanding of 
> the problem/solutions so far.
There was one specific issue in that thread, it was a VerifyError that 
stemmed from Guava overriding 
java.lang.reflect.AccessibleObject.setAccessible. That issue was 
resolved at the time and I don't think there were any other specific 
issues on that thread. There was of course the general issue that Groovy 
seems to access or wrap types in non-exported packages but we don't have 
a solution to that except via the command-line -XaddExports.

-Alan.

From jarthana at in.ibm.com  Mon Nov  2 09:48:24 2015
From: jarthana at in.ibm.com (Jayaprakash Arthanareeswaran)
Date: Mon, 2 Nov 2015 15:18:24 +0530
Subject: Is Caching JrtFileSystem acceptable?
Message-ID: <OF9476A5E6.BCA93A45-ON65257EF1.003472C2-65257EF1.0035DF02@in.ibm.com>



Hello,

We recently changed our code in Eclipse to support JRE 8 when loading
classes from a Java 9 images (discussion at [1]). The change was to use a
JrtFileSystem with a class loader. The file system is then cached and
re-used for every request to get something from the JRE 9 images. The code
is something like this:

URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL();
URLClassLoader loader = new URLClassLoader(new URL[] { url });
FileSystem jrt = FileSystems.newFileSystem("jrt:/", env, loader);

After this change, we have started getting an NPE in the file system (We
are randomly hitting this and at this point no idea what is causing it):

Daemon Thread [Java indexing] (Suspended (exception NullPointerException))
	ByteArrayInputStream.<init>(byte[]) line: 106
	JrtFileSystem.newByteChannel(byte[], Set<OpenOption>,
FileAttribute<?>...) line: 600
	JrtPath.newByteChannel(Set<OpenOption>, FileAttribute<?>...) line:
732
	JrtFileSystemProvider.newByteChannel(Path, Set<OpenOption>,
FileAttribute<?>...) line: 218
	Files.newByteChannel(Path, Set<OpenOption>, FileAttribute<?>...)
line: 361
	Files.newByteChannel(Path, OpenOption...) line: 407
	Files.readAllBytes(Path) line: 3152

I have confirmed that the JrtFileSystem that is used in the above stack and
what we cached are the same objects. And the path that is being passed in
the beginning is a valid JrtPath. I would like to know if this is a bug in
the file system implementation or something to do with our code.

Of course, I don't have the source for JrtFileSystem, so unable to debug
this further. Thanks for any pointers in trouble-shooting this further.

Regards,
Jay

[1]
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-October/004857.html

From cedric.champeau at gmail.com  Mon Nov  2 09:58:06 2015
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Mon, 2 Nov 2015 10:58:06 +0100
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <56372753.6010702@oracle.com>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com> <56372414.7010605@oracle.com>
	<CADQzvmmxb50=r63Ab_2g+z75GFK3eGOvp9XLjRtBCfoLetvQWA@mail.gmail.com>
	<56372753.6010702@oracle.com>
Message-ID: <CADQzvmkCX9hQu1NFCdoPLaS4ZQZaJPq9+vWfB+h8DYXUHWaQHw@mail.gmail.com>

>
>  That issue was resolved at the time and I don't think there were any
> other specific issues on that thread. There was of course the general issue
> that Groovy seems to access or wrap types in non-exported packages but we
> don't have a solution to that except via the command-line -XaddExports.
>
> -Alan.
>

I think this is the particular issue Jochen is very worried about. We
should think about the consequences of it. What does it mean to be forced
to use -XaddExports. It is at least unclear to me. What would be
catastrophic is releasing Jigsaw and realizing that we killed Groovy
because it cannot use modules without, for example, disabling all kind of
security.

From Alan.Bateman at oracle.com  Mon Nov  2 10:24:50 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 2 Nov 2015 10:24:50 +0000
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <CADQzvmkCX9hQu1NFCdoPLaS4ZQZaJPq9+vWfB+h8DYXUHWaQHw@mail.gmail.com>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com> <56372414.7010605@oracle.com>
	<CADQzvmmxb50=r63Ab_2g+z75GFK3eGOvp9XLjRtBCfoLetvQWA@mail.gmail.com>
	<56372753.6010702@oracle.com>
	<CADQzvmkCX9hQu1NFCdoPLaS4ZQZaJPq9+vWfB+h8DYXUHWaQHw@mail.gmail.com>
Message-ID: <563739F2.2030002@oracle.com>


On 02/11/2015 09:58, C?dric Champeau wrote:
>
> I think this is the particular issue Jochen is very worried about. We 
> should think about the consequences of it. What does it mean to be 
> forced to use -XaddExports. It is at least unclear to me. What would 
> be catastrophic is releasing Jigsaw and realizing that we killed 
> Groovy because it cannot use modules without, for example, disabling 
> all kind of security.

Uwe Schindler has created a bug on this topic here:

   https://issues.apache.org/jira/browse/GROOVY-7587

It makes me wonder if Groovy has ever been used with a security manager 
as it seems to wrap or need access to all JDK-internal types.

-Alan.

From Alan.Bateman at oracle.com  Mon Nov  2 10:35:36 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 2 Nov 2015 10:35:36 +0000
Subject: Is Caching JrtFileSystem acceptable?
In-Reply-To: <OF9476A5E6.BCA93A45-ON65257EF1.003472C2-65257EF1.0035DF02@in.ibm.com>
References: <OF9476A5E6.BCA93A45-ON65257EF1.003472C2-65257EF1.0035DF02@in.ibm.com>
Message-ID: <56373C78.4090807@oracle.com>

On 02/11/2015 09:48, Jayaprakash Arthanareeswaran wrote:
>
> Hello,
>
> We recently changed our code in Eclipse to support JRE 8 when loading
> classes from a Java 9 images (discussion at [1]). The change was to use a
> JrtFileSystem with a class loader. The file system is then cached and
> re-used for every request to get something from the JRE 9 images. The code
> is something like this:
>
> URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL();
> URLClassLoader loader = new URLClassLoader(new URL[] { url });
> FileSystem jrt = FileSystems.newFileSystem("jrt:/", env, loader);
>
> After this change, we have started getting an NPE in the file system (We
> are randomly hitting this and at this point no idea what is causing it):
>
> Daemon Thread [Java indexing] (Suspended (exception NullPointerException))
> 	ByteArrayInputStream.<init>(byte[]) line: 106
> 	JrtFileSystem.newByteChannel(byte[], Set<OpenOption>,
> FileAttribute<?>...) line: 600
> 	JrtPath.newByteChannel(Set<OpenOption>, FileAttribute<?>...) line:
> 732
> 	JrtFileSystemProvider.newByteChannel(Path, Set<OpenOption>,
> FileAttribute<?>...) line: 218
> 	Files.newByteChannel(Path, Set<OpenOption>, FileAttribute<?>...)
> line: 361
> 	Files.newByteChannel(Path, OpenOption...) line: 407
> 	Files.readAllBytes(Path) line: 3152
>
> I have confirmed that the JrtFileSystem that is used in the above stack and
> what we cached are the same objects. And the path that is being passed in
> the beginning is a valid JrtPath. I would like to know if this is a bug in
> the file system implementation or something to do with our code.
>
> Of course, I don't have the source for JrtFileSystem, so unable to debug
> this further. Thanks for any pointers in trouble-shooting this further.
>
I'm not aware of any issues here and there shouldn't be an issue 
retaining the reference to the jrt FileSystem.

As the jrt FileSystem is in the stack trace then it means that 
Files.readAllBytes has been called with Path associated with the jrt 
file system. It's not obvious how a NPE could arise after that. The only 
thing that comes to mind is the file system being closed asynchronously, 
I can't recall how the jrt file system handles that (Sundar will know).

However, just to establish the environment - is this IBM JDK 8 or an 
Oracle/OpenJDK build of JDK 8? Also is the target image a regular JDK 9 
build or a Jigsaw build? There are changes to the jrt file system code 
in the Jigsaw forest but this is mostly to support exploded builds.

-Alan

From cedric.champeau at gmail.com  Mon Nov  2 10:49:35 2015
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Mon, 2 Nov 2015 11:49:35 +0100
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <563739F2.2030002@oracle.com>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com> <56372414.7010605@oracle.com>
	<CADQzvmmxb50=r63Ab_2g+z75GFK3eGOvp9XLjRtBCfoLetvQWA@mail.gmail.com>
	<56372753.6010702@oracle.com>
	<CADQzvmkCX9hQu1NFCdoPLaS4ZQZaJPq9+vWfB+h8DYXUHWaQHw@mail.gmail.com>
	<563739F2.2030002@oracle.com>
Message-ID: <CADQzvm=-7gH-QmRhP5bU8NHJZdeLJCVnAPHpRqvCaMYm=_oAmA@mail.gmail.com>

Surely Groovy is widely used with security managers, and it has never been
a problem so far. I'm not sure how this issue is relevant to the problem,
but Jochen expressed several times concerns about how Groovy would interact
with Jigsaw without getting clear answers, or at best "we don't know". I'm
unfortunately not in a position where I can investigate right now, but
Jigsaw is certainly critical for both Groovy and Gradle, so I'd like to
make sure we address all issues before Jigsaw is out. Basically my focus
today is making Gradle capable of building apps using Jigsaw, but not
running on Jigsaw. Just because those are competing priorities. But both
*have* to be fixed.

2015-11-02 11:24 GMT+01:00 Alan Bateman <Alan.Bateman at oracle.com>:

>
> On 02/11/2015 09:58, C?dric Champeau wrote:
>
>>
>> I think this is the particular issue Jochen is very worried about. We
>> should think about the consequences of it. What does it mean to be forced
>> to use -XaddExports. It is at least unclear to me. What would be
>> catastrophic is releasing Jigsaw and realizing that we killed Groovy
>> because it cannot use modules without, for example, disabling all kind of
>> security.
>>
>
> Uwe Schindler has created a bug on this topic here:
>
>   https://issues.apache.org/jira/browse/GROOVY-7587
>
> It makes me wonder if Groovy has ever been used with a security manager as
> it seems to wrap or need access to all JDK-internal types.
>
> -Alan.
>

From blackdrag at gmx.org  Mon Nov  2 12:55:45 2015
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Mon, 2 Nov 2015 13:55:45 +0100
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <563739F2.2030002@oracle.com>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com> <56372414.7010605@oracle.com>
	<CADQzvmmxb50=r63Ab_2g+z75GFK3eGOvp9XLjRtBCfoLetvQWA@mail.gmail.com>
	<56372753.6010702@oracle.com>
	<CADQzvmkCX9hQu1NFCdoPLaS4ZQZaJPq9+vWfB+h8DYXUHWaQHw@mail.gmail.com>
	<563739F2.2030002@oracle.com>
Message-ID: <56375D51.6020101@gmx.org>

On 02.11.2015 11:24, Alan Bateman wrote:
[...]
> Uwe Schindler has created a bug on this topic here:
>
>    https://issues.apache.org/jira/browse/GROOVY-7587
>
> It makes me wonder if Groovy has ever been used with a security manager
> as it seems to wrap or need access to all JDK-internal types.

This impression is wrong, Groovy does not need access to all 
JDK-internal types. But this is a dynamic language at heart. If you do 
not have a static type, then the runtime type is what counts, and that 
is the exact type, which is sometime an internal JDK type. It means 
Groovy has to do the same thing it has to do when a security manager 
doesn't like access to this class, which is to not use the specific 
class/method, but the super class information... or the information of 
that super class.. in worst case this will be Object, which means only 
method from Object can be called using Groovy in that case.

The current state is, that this issue is now fixed. The example scripts 
in the issue are working. That does not mean we can now run the build on 
jigsaw of course.

bye Jochen

From ali.ebrahimi1781 at gmail.com  Mon Nov  2 13:20:47 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Mon, 2 Nov 2015 16:50:47 +0330
Subject: Question on Implied readability
Message-ID: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>

Hi,
please clear situation for me:

I have two version of com.bar module
one com.baz that depends on com.bar
one com.foo that depends on both com.bar and com.baz

Two layer:
layer 1: com.baz and com.bar at 1
---------------------------

module com.bar {//version1
    exports com.bar;
}

------------------

//Bar.java

package com.bar;
public class Bar {
    public String bar(){ return "bar1";}
}

module com.baz {
        requires com.bar;
        exports com.baz;
}

-----------------

//Baz.java

package com.baz;

import com.bar.Bar;
public class Baz {
    public String baz(){ return new Bar().bar();}
    public Bar bar(){
        return new Bar();
    }
}

layer 2: com.foo and com.bar at 2
--------------------
 module com.bar {//version2

    exports com.bar;
}

-------------

//Bar.java

package com.bar;

public class Bar {
    public String bar(){ return "bar2";}
}

-------------

module com.foo {
        requires com.bar;
        requires com.baz;
}

-------------

Foo.java

package com.foo;

import com.bar.Bar;
import com.baz.Baz;

public class Main {
    public static void main(String[] args) {
        System.out.println(new Baz().baz());
        System.out.println(new Bar().bar());
    }
}

Result:

bar1
bar2

Good. So we can have different versions of same module.

But, my question arise from section "Implied readability" of

"The State of the Module System" document:
"The public modifiers mean that any module that depends upon the
java.sql module
will read not only the java.sql module but also the java.logging and
java.xml modules. "

Based on this paragraph we can edit module descriptors for modules com.foo
and com.baz as:
--------------------

module com.baz {
        requires public com.bar;
        exports com.baz;
}

--------------

module com.foo {
        requires com.baz;
}

But result is:

bar1
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0/Native
Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9.0
/NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9.0
/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(java.base at 9.0/Method.java:531)
        at jakeplus.minicontainer.Bootstrapper.main(java.base at 9.0
/Bootstrapper.java:67)
Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module:
com.foo)
 cannot access class com.bar.Bar (in module: com.bar), com.foo cannot read
com.bar
        at com.foo.Main.main(com.foo/Main.java:12)
        ... 5 more

The exception message says: com.foo cannot read com.bar. Why?
Is not two situation equivalent? (before Implied readability and after)
This is bug?

Best Regards,
Ali Ebrahimi

From artem.smotrakov at oracle.com  Mon Nov  2 13:30:39 2015
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Mon, 2 Nov 2015 16:30:39 +0300
Subject: [9] RFR: 8140649: imageFile should use delete[] with new[]
Message-ID: <5637657F.1060108@oracle.com>

Hello,

Please review this small fix for jdk9/dev repo.

It updates imageFile.cpp to use delete[] operator together with new[]. 
It also adds a check to ImageLocation::set_data(u1*) method to prevent a 
possible null-dereference.

Bug: https://bugs.openjdk.java.net/browse/JDK-8140649
Webrev: 
http://cr.openjdk.java.net/~asmotrak/image_file_new_delete/webrev.01/

Artem

From james.laskey at oracle.com  Mon Nov  2 14:59:18 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Mon, 2 Nov 2015 10:59:18 -0400
Subject: [9] RFR: 8140649: imageFile should use delete[] with new[]
In-Reply-To: <5637657F.1060108@oracle.com>
References: <5637657F.1060108@oracle.com>
Message-ID: <BC614203-1BA6-4C67-99D7-EAA5F03C50EB@oracle.com>

+1

> On Nov 2, 2015, at 9:30 AM, Artem Smotrakov <artem.smotrakov at oracle.com> wrote:
> 
> Hello,
> 
> Please review this small fix for jdk9/dev repo.
> 
> It updates imageFile.cpp to use delete[] operator together with new[]. It also adds a check to ImageLocation::set_data(u1*) method to prevent a possible null-dereference.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8140649
> Webrev: http://cr.openjdk.java.net/~asmotrak/image_file_new_delete/webrev.01/
> 
> Artem


From Alan.Bateman at oracle.com  Mon Nov  2 18:48:04 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 2 Nov 2015 18:48:04 +0000
Subject: Question on Implied readability
In-Reply-To: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>
Message-ID: <5637AFE4.8020000@oracle.com>

On 02/11/2015 13:20, Ali Ebrahimi wrote:
> :
>
> bar1
> Exception in thread "main" java.lang.reflect.InvocationTargetException
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0/Native
> Method)
>          at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9.0
> /NativeMethodAccessorImpl.java:62)
>          at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9.0
> /DelegatingMethodAccessorImpl.java:43)
>          at java.lang.reflect.Method.invoke(java.base at 9.0/Method.java:531)
>          at jakeplus.minicontainer.Bootstrapper.main(java.base at 9.0
> /Bootstrapper.java:67)
> Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module:
> com.foo)
>   cannot access class com.bar.Bar (in module: com.bar), com.foo cannot read
> com.bar
>          at com.foo.Main.main(com.foo/Main.java:12)
>          ... 5 more
>
> The exception message says: com.foo cannot read com.bar. Why?
> Is not two situation equivalent? (before Implied readability and after)
> This is bug?

I used the source from your mail to create a test case but I didn't 
duplicate what you were seeing. In my test then I created two layers L1 
and L2. In L1 then com.bar at 1 and com.baz are mapped to the same loader 
CL1. In L2 then com.bar at 2 and com.foo are mapped to the same loader CL2. 
The parent of L2 is L1. The parent of CL2 is CL1 with CL2 doing 
local-first rather than parent delegation so that it loads the local 
version of module com.bar's types.

The readability is setup as expected:

         Module foo = layer2.findModule("com.foo").get();
         Module bar2 = layer2.findModule("com.bar").get();
         assertTrue(foo.canRead(bar2));

         Module bar1 = layer1.findModule("com.bar").get();
         assertFalse(foo.canRead(bar1))

I can't rule out a bug of course but I would need to see an outline of 
what jakeplus.minicontainer.Bootstrapper is doing so that I can see how 
the layers and class loaders are arranged.

-Alan.

From pbenedict at apache.org  Mon Nov  2 19:13:42 2015
From: pbenedict at apache.org (Paul Benedict)
Date: Mon, 2 Nov 2015 13:13:42 -0600
Subject: Question on Implied readability
In-Reply-To: <5637AFE4.8020000@oracle.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>
	<5637AFE4.8020000@oracle.com>
Message-ID: <CABLGb9xpF+HiEwBrUE2CuS54RfbJzskzFn9sPcCV5_9oOW2Qzw@mail.gmail.com>

Alan, please correct me if wrong, but there is no enforced correlation
between the module name and the jar name it's packaged in, right? The name
is officially taken from the module-info.class? If so, I'd like to make a
suggestion. One thing that's been extremely useful to me with JBoss is the
ability to link back to the JAR path in the stack trace. Is there any
chance you would consider expanding the stack trace to something like this:

bar1
Exception in thread "main" java.lang.reflect.InvocationTargetException
         at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0
[c:\jdk\1.9\jre\modules\java.base.jar]/NativeMethod)

Paul


Cheers,
Paul

On Mon, Nov 2, 2015 at 12:48 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 02/11/2015 13:20, Ali Ebrahimi wrote:
>
>> :
>>
>> bar1
>> Exception in thread "main" java.lang.reflect.InvocationTargetException
>>          at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0
>> /Native
>> Method)
>>          at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9.0
>> /NativeMethodAccessorImpl.java:62)
>>          at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9.0
>> /DelegatingMethodAccessorImpl.java:43)
>>          at java.lang.reflect.Method.invoke(java.base at 9.0
>> /Method.java:531)
>>          at jakeplus.minicontainer.Bootstrapper.main(java.base at 9.0
>> /Bootstrapper.java:67)
>> Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module:
>> com.foo)
>>   cannot access class com.bar.Bar (in module: com.bar), com.foo cannot
>> read
>> com.bar
>>          at com.foo.Main.main(com.foo/Main.java:12)
>>          ... 5 more
>>
>> The exception message says: com.foo cannot read com.bar. Why?
>> Is not two situation equivalent? (before Implied readability and after)
>> This is bug?
>>
>
> I used the source from your mail to create a test case but I didn't
> duplicate what you were seeing. In my test then I created two layers L1 and
> L2. In L1 then com.bar at 1 and com.baz are mapped to the same loader CL1.
> In L2 then com.bar at 2 and com.foo are mapped to the same loader CL2. The
> parent of L2 is L1. The parent of CL2 is CL1 with CL2 doing local-first
> rather than parent delegation so that it loads the local version of module
> com.bar's types.
>
> The readability is setup as expected:
>
>         Module foo = layer2.findModule("com.foo").get();
>         Module bar2 = layer2.findModule("com.bar").get();
>         assertTrue(foo.canRead(bar2));
>
>         Module bar1 = layer1.findModule("com.bar").get();
>         assertFalse(foo.canRead(bar1))
>
> I can't rule out a bug of course but I would need to see an outline of
> what jakeplus.minicontainer.Bootstrapper is doing so that I can see how the
> layers and class loaders are arranged.
>
> -Alan.
>

From ali.ebrahimi1781 at gmail.com  Mon Nov  2 20:02:20 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Mon, 2 Nov 2015 23:32:20 +0330
Subject: Question on Implied readability
In-Reply-To: <5637AFE4.8020000@oracle.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>
	<5637AFE4.8020000@oracle.com>
Message-ID: <CAA0cW5A0ppeRohChzs9-RyNaGQ_r3dZ_jM5kARrb9eZQoJpGqw@mail.gmail.com>

Hi Alan,

I don't khow how you testing this.
But this is simple possible test case:

public class Test {
    public static void main(String[] args) throws Exception {
        ModuleFinder finder1 = ModuleFinder.of(Paths.get("mods1"));
        Configuration cfg1 = Configuration.resolve(finder1,
Layer.boot(),ModuleFinder.empty(),"com.bar","com.baz");

        ModuleClassLoader cl1 = new ModuleClassLoader(cfg1);
        Layer layer1 = Layer.create(cfg1, m -> cl1);

        ModuleFinder finder2 = ModuleFinder.of(Paths.get("mods2"));
        Configuration cfg2 = Configuration.resolve(finder2,
layer1,ModuleFinder.empty(),"com.bar","com.foo");

        ModuleClassLoader cl2 = new ModuleClassLoader(cl1,cfg2);
        Layer layer2 = Layer.create(cfg2, m -> cl2);

        System.out.println("layer2.modules()\n"+layer2.modules());
        System.out.println("layer1.modules()\n"+layer1.modules());

        Module foo = layer2.findModule("com.foo").get();
        Module bar2 = layer2.findModule("com.bar").get();
        System.out.println("foo.canRead(bar2) -> "+foo.canRead(bar2));

        Module bar1 = layer1.findModule("com.bar").get();
        System.out.println("foo.canRead(bar1) -> "+foo.canRead(bar1));

        ClassLoader fooModuleLoader = layer2.findLoader("com.foo");
        Class<?> mainClass = fooModuleLoader.loadClass("com.foo.Main");

        Test.class.getModule().addReads(mainClass.getModule());
        Method mainMethod = mainClass.getMethod("main", String[].class);

        mainMethod.invoke(null, (Object)new String[0]);
    }

And Result:

layer2.modules()
[module com.foo, module com.bar]
layer1.modules()
[module com.baz, module com.bar]
foo.canRead(bar2) -> false
foo.canRead(bar1) -> false
bar1
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0/Native
Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9.0/NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9.0/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(java.base at 9.0/Method.java:531)
        at com.test.Test.main(com.test/Test.java:48)
Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module: com.foo)
 cannot access class com.bar.Bar (in module: com.bar), com.foo cannot
read com.bar
        at com.foo.Main.main(com.foo/Main.java:12)
        ... 5 more


Note that I get above result if Implied readability used.


On Mon, Nov 2, 2015 at 10:18 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 02/11/2015 13:20, Ali Ebrahimi wrote:
>
>> :
>>
>>
> I can't rule out a bug of course but I would need to see an outline of
> what jakeplus.minicontainer.Bootstrapper is doing so that I can see how the
> layers and class loaders are arranged.


This is simple extension to jake that build layers based on config from
command line.
 Sample Input:

<layer mp="mods1">
    <module name="com.bar" standalone="true" root-module="false"/>
    <module name="com.baz" standalone="true" root-module="true"/>
    <layer mp="mods2">
        <module name="com.bar" standalone="true" root-module="true"/>
        <module name="com.foo" standalone="true" root-module="true"
main-class="com.foo.Main"/>
    </layer>
</layer>


>
> -Alan.
>



-- 

Best Regards,
Ali Ebrahimi

From alex.buckley at oracle.com  Mon Nov  2 21:03:17 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 02 Nov 2015 13:03:17 -0800
Subject: Avoiding same-package conflicts
In-Reply-To: <5633D52C.6050406@gmx.org>
References: <CABHMDwh+L=dmJ9oBRm=81okP2qLjT9uYaP0=7+MY_eVZ7UqpbQ@mail.gmail.com>	<563223CB.8060300@oracle.com>	<CACzrW9BPvfDOb1Wbgd6n4Rba1+0TyG3XnKWFFPfZS0Kr0kBmRA@mail.gmail.com>
	<5633D52C.6050406@gmx.org>
Message-ID: <5637CF95.9030800@oracle.com>

On 10/30/2015 1:38 PM, Jochen Theodorou wrote:
> I can second that by an example using Groovy. We have not yet taken
> steps to make jigsaw modules, but we quite some time ago we have split
> the code base in what would become eventually become modules in the
> future. Because of history this did mean to split packages. So we have a
> couple of jars (that want to be modules), with overlapping package names.
>
> Examples of package conflicts with the "base module":
>
> * The groovy-console has a conflict in groovy.ui
> * groovy-ant has a conflict in groovy.util
> * groovy-docgenerator in org.codehaus.groovy.tools
> * groovy-nio in org.codehaus.groovy.runtime
> * groovy-sql in org.codehaus.groovy.runtime
> * groovy-swing in org.codehaus.groovy.runtime
> * groovy-test in goovy.lang and groovy.util
> * groovy-xml in org.codehaus.groovy.runtime and goovy.util
>
> That's 7 "modules" with conflicts out of 19. One should remember here,
> that the codebase is like 10+ years old, and something that is now a
> "module" used to be fixed part of the language in the past. So some poor
> naming decision have been made. The org.codehaus.groovy.runtime
> conflicts could probably be solved, but the groovy.util ones are
> difficult, since this is a package imported by default (like java.lang
> in java), so moving classes to differing packages will break Groovy
> scripts... very elementary here for example GroovyTestCase in
> groovy-util, which is in the groovy-test "module"..

The initial modularization of JavaFX had a similar pattern: more split 
packages than you would think, due to a "horizontal" module wanting to 
share packages with numerous "vertical" domain modules. There, the 
"horizontal" module was a 'builder' module which hoped to add 
$COMPONENTBuilder classes to the packages of various 'component' 
modules; eventually the $COMPONENTBuilder classes were deemed 
unnecessary and the 'builder' module deleted. For Groovy, I suggest that 
your "base module" has the greatest claim to the 
org.codehaus.groovy.runtime package, and that the 
groovy-{nio,sql,swing,xml} modules should export 
org.codehaus.groovy.runtime.* subpackages to the base module only.

It doesn't seem great that the groovy-ant and groovy-test modules try to 
augment the important groovy.util package owned by your base module. 
Speaking generally, it makes no sense to allow a module to protect its 
internals if at the same time its API can be augmented by unrelated 
modules -- it can't be the "same" API because it doesn't have access to 
the same internals.

> also... there is a automated meta class lookup system, that is based on
> the package name with a prefix. So someone could provide a meta class
> for java.util.ArrayList, while another does this for LinkedList. If they
> are using modules, they cannot be loaded at the same time. Granted, I
> don't like this mechanism, and I am looking for ways to deprecate it in
> the near future, but it is another example of same-package conflicts.

Does this mean a Groovy meta class can currently be defined as a class 
in the java.* run-time package of the bootstrap loader?

Alex

From Alan.Bateman at oracle.com  Mon Nov  2 21:51:23 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 2 Nov 2015 21:51:23 +0000
Subject: Question on Implied readability
In-Reply-To: <CAA0cW5A0ppeRohChzs9-RyNaGQ_r3dZ_jM5kARrb9eZQoJpGqw@mail.gmail.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>
	<5637AFE4.8020000@oracle.com>
	<CAA0cW5A0ppeRohChzs9-RyNaGQ_r3dZ_jM5kARrb9eZQoJpGqw@mail.gmail.com>
Message-ID: <5637DADB.7000407@oracle.com>

On 02/11/2015 20:02, Ali Ebrahimi wrote:
> :
> layer2.modules() [module com.foo, module com.bar] layer1.modules() 
> [module com.baz, module com.bar] foo.canRead(bar2) -> false 
> foo.canRead(bar1) -> false
Thanks, I see the issue. The reason it didn't duplicate for me is 
because I hadn't dropped the requires com.bar.

So the bug is implied readability across layers when the same named 
module exists in multiple layers. In this case com.foo should read 
com.bar at 1. The com.bar (@2) is the same configuration as com.foo is 
confusing the code. We'll need to fix this.

-Alan

From sadhak001 at gmail.com  Mon Nov  2 22:23:38 2015
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Mon, 2 Nov 2015 22:23:38 +0000
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <56372414.7010605@oracle.com>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com> <56372414.7010605@oracle.com>
Message-ID: <CAGHtMWnmQQy9RspU0KP=_yWETm37Fsaath+HQgY5ma0Eon6ASw@mail.gmail.com>

Hi Rory,

TestNG has an alternative build system which we will try to use to build it
using the Jigsaw binary.

How do you report such bugs to Gradle / Groovy ? Is it simpler if you
reported to them on their mailing list ? Let me know what works best, this
is fairly important as other Gradle users might have similar issues.

Cheers,
Mani

On Mon, Nov 2, 2015 at 8:51 AM, Rory O'Donnell <rory.odonnell at oracle.com>
wrote:

> I can't find a bug in Gradle's JIRA on this issue, Mani do you want to log
> an issue there ?
>
> Rgds,Rory
>
>
> On 31/10/2015 13:56, Alan Bateman wrote:
>
>> On 31/10/2015 12:50, Mani Sarkar wrote:
>>
>>> Hi Rory,
>>>
>>> Do you know of a version of Gradle or a EA version which is JDK 9 Jigsaw
>>> compatible, we get these failures when building:
>>>
>>>
>>> https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console
>>>
>>> Caused by: java.lang.IllegalAccessException: class
>> org.gradle.internal.reflect.DirectInstantiator cannot access class
>> com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because module
>> jdk.compiler does not export package com.sun.tools.javac.api to <unnamed
>> module @b7f23d9>
>>     at
>> org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49)
>>     ... 86 more
>>
>> We should at least check if there is a bug in the Gradle JIRA for this.
>> It can be worked around by configuring the compileJava options to fork
>> javac but you might not want to do that.
>>
>> The other issue with Gradle that we know about is the ClassCastException
>> when attempting to run tests, this is tracked here:
>>     https://issues.gradle.org/browse/GRADLE-3287
>>
>> -Alan.
>>
>>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>


-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

From ali.ebrahimi1781 at gmail.com  Mon Nov  2 23:32:04 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Tue, 3 Nov 2015 03:02:04 +0330
Subject: Question on Implied readability
In-Reply-To: <5637DADB.7000407@oracle.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>
	<5637AFE4.8020000@oracle.com>
	<CAA0cW5A0ppeRohChzs9-RyNaGQ_r3dZ_jM5kARrb9eZQoJpGqw@mail.gmail.com>
	<5637DADB.7000407@oracle.com>
Message-ID: <CAA0cW5BjGKyJiR8ksQZgriOxMV-+fzWa+=7+4-a8hQS1M-uUsQ@mail.gmail.com>

Hi,


On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 02/11/2015 20:02, Ali Ebrahimi wrote:
> Thanks, I see the issue. The reason it didn't duplicate for me is because
> I hadn't dropped the requires com.bar.
>
> So the bug is implied readability across layers when the same named module
> exists in multiple layers. In this case com.foo should read com.bar at 1.
> The com.bar (@2) is the same configuration as com.foo is confusing the
> code. We'll need to fix this.
>
> So, you say com.foo can not read com.bar(@2) and why?
Based on implied readability module com.foo implicitly reads com.bar, in
other word have requires com.bar;
and because com.bar(@2) is co-layer with com.foo, so
module com.foo should reads com.bar(@2).
com.bar(@2) override com.bar(@1) for com.foo.
How this specified in spec?

> -Alan
>

-- 

Best Regards,
Ali Ebrahimi

From alex.buckley at oracle.com  Tue Nov  3 02:27:18 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 02 Nov 2015 18:27:18 -0800
Subject: Question on Implied readability
In-Reply-To: <CAA0cW5BjGKyJiR8ksQZgriOxMV-+fzWa+=7+4-a8hQS1M-uUsQ@mail.gmail.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>	<5637AFE4.8020000@oracle.com>	<CAA0cW5A0ppeRohChzs9-RyNaGQ_r3dZ_jM5kARrb9eZQoJpGqw@mail.gmail.com>	<5637DADB.7000407@oracle.com>
	<CAA0cW5BjGKyJiR8ksQZgriOxMV-+fzWa+=7+4-a8hQS1M-uUsQ@mail.gmail.com>
Message-ID: <56381B86.4010705@oracle.com>

On 11/2/2015 3:32 PM, Ali Ebrahimi wrote:
> On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 02/11/2015 20:02, Ali Ebrahimi wrote:
>> Thanks, I see the issue. The reason it didn't duplicate for me is because
>> I hadn't dropped the requires com.bar.
>>
>> So the bug is implied readability across layers when the same named module
>> exists in multiple layers. In this case com.foo should read com.bar at 1.
>> The com.bar (@2) is the same configuration as com.foo is confusing the
>> code. We'll need to fix this.
>>
>> So, you say com.foo can not read com.bar(@2) and why?
> Based on implied readability module com.foo implicitly reads com.bar, in
> other word have requires com.bar;
> and because com.bar(@2) is co-layer with com.foo, so
> module com.foo should reads com.bar(@2).
> com.bar(@2) override com.bar(@1) for com.foo.
> How this specified in spec?

It's currently underspecified in Configuration::resolve as "A 
readability graph is then constructed to take account of implicitly 
declared dependences (requires public)."

We'll have to think about the implication of com.baz in layer1 sometimes 
offering a 'requires public' on com.bar in layer1, and sometimes 
offering a 'requires public' on com.bar in layer2, depending on who is 
reading com.baz in layer1.

Alex

From frank.yuan at oracle.com  Tue Nov  3 04:07:34 2015
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 3 Nov 2015 12:07:34 +0800
Subject: Question on Implied readability
In-Reply-To: <56381B86.4010705@oracle.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>	<5637AFE4.8020000@oracle.com>	<CAA0cW5A0ppeRohChzs9-RyNaGQ_r3dZ_jM5kARrb9eZQoJpGqw@mail.gmail.com>	<5637DADB.7000407@oracle.com>	<CAA0cW5BjGKyJiR8ksQZgriOxMV-+fzWa+=7+4-a8hQS1M-uUsQ@mail.gmail.com>
	<56381B86.4010705@oracle.com>
Message-ID: <016501d115ed$3037a2c0$90a6e840$@oracle.com>



> -----Original Message-----
> From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of Alex Buckley
> Sent: Tuesday, November 03, 2015 10:27 AM
> To: jigsaw-dev <jigsaw-dev at openjdk.java.net>
> Subject: Re: Question on Implied readability
> 
> On 11/2/2015 3:32 PM, Ali Ebrahimi wrote:
> > On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman <Alan.Bateman at oracle.com>
> > wrote:
> >
> >> On 02/11/2015 20:02, Ali Ebrahimi wrote:
> >> Thanks, I see the issue. The reason it didn't duplicate for me is
> >> because I hadn't dropped the requires com.bar.
> >>
> >> So the bug is implied readability across layers when the same named
> >> module exists in multiple layers. In this case com.foo should read com.bar at 1.
> >> The com.bar (@2) is the same configuration as com.foo is confusing
> >> the code. We'll need to fix this.
> >>
> >> So, you say com.foo can not read com.bar(@2) and why?
> > Based on implied readability module com.foo implicitly reads com.bar,
> > in other word have requires com.bar; and because com.bar(@2) is
> > co-layer with com.foo, so module com.foo should reads com.bar(@2).
> > com.bar(@2) override com.bar(@1) for com.foo.
> > How this specified in spec?
> 
> It's currently underspecified in Configuration::resolve as "A readability graph is then constructed to take account of implicitly declared
> dependences (requires public)."
> 
> We'll have to think about the implication of com.baz in layer1 sometimes offering a 'requires public' on com.bar in layer1, and
> sometimes offering a 'requires public' on com.bar in layer2, depending on who is reading com.baz in layer1.

Hi Alex

I don't think so. com.baz declares "requires public com.bar", so com.baz decide which com.bar is readable, in this case, decide which com.bar is used by com.foo
Consider the following scenario, which is the common usage of implied readability
com.baz provides the following service:
public Object1 getObject();
Object1 is a class defined in com.bar, please not com.bar at 2 is not visible to com.baz(indeed to avoid conflict, only one com.bar can be visible/readable to com.baz), so com.baz construct an Object1 of com.bar at 1 during getObject() is invoked, and then com.foo get this Object1 instance, now com.foo can only use type Object1 of com.bar at 1 to interpret it, who guarantee what Object1 of com.bar at 2 is?! So here the type must be definite, M2 requires public M1,  M3 requires M2, then which M1 is read by M2, which M1 must be readable to M3. It's not related to Layer actually.

Frank


> 
> Alex


From sundararajan.athijegannathan at oracle.com  Tue Nov  3 06:00:10 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 3 Nov 2015 11:30:10 +0530
Subject: Is Caching JrtFileSystem acceptable?
In-Reply-To: <56373C78.4090807@oracle.com>
References: <OF9476A5E6.BCA93A45-ON65257EF1.003472C2-65257EF1.0035DF02@in.ibm.com>
	<56373C78.4090807@oracle.com>
Message-ID: <56384D6A.5010507@oracle.com>

As Alan said, other thing async. closing of the file system, nothing 
really comes to mind. There is checkResource call in code to check that 
the resource exists before opening channel on it.. Is it possible to 
reproduce this on a smaller app?

-Sundar

On 11/2/2015 4:05 PM, Alan Bateman wrote:
> On 02/11/2015 09:48, Jayaprakash Arthanareeswaran wrote:
>>
>> Hello,
>>
>> We recently changed our code in Eclipse to support JRE 8 when loading
>> classes from a Java 9 images (discussion at [1]). The change was to 
>> use a
>> JrtFileSystem with a class loader. The file system is then cached and
>> re-used for every request to get something from the JRE 9 images. The 
>> code
>> is something like this:
>>
>> URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL();
>> URLClassLoader loader = new URLClassLoader(new URL[] { url });
>> FileSystem jrt = FileSystems.newFileSystem("jrt:/", env, loader);
>>
>> After this change, we have started getting an NPE in the file system (We
>> are randomly hitting this and at this point no idea what is causing it):
>>
>> Daemon Thread [Java indexing] (Suspended (exception 
>> NullPointerException))
>>     ByteArrayInputStream.<init>(byte[]) line: 106
>>     JrtFileSystem.newByteChannel(byte[], Set<OpenOption>,
>> FileAttribute<?>...) line: 600
>>     JrtPath.newByteChannel(Set<OpenOption>, FileAttribute<?>...) line:
>> 732
>>     JrtFileSystemProvider.newByteChannel(Path, Set<OpenOption>,
>> FileAttribute<?>...) line: 218
>>     Files.newByteChannel(Path, Set<OpenOption>, FileAttribute<?>...)
>> line: 361
>>     Files.newByteChannel(Path, OpenOption...) line: 407
>>     Files.readAllBytes(Path) line: 3152
>>
>> I have confirmed that the JrtFileSystem that is used in the above 
>> stack and
>> what we cached are the same objects. And the path that is being 
>> passed in
>> the beginning is a valid JrtPath. I would like to know if this is a 
>> bug in
>> the file system implementation or something to do with our code.
>>
>> Of course, I don't have the source for JrtFileSystem, so unable to debug
>> this further. Thanks for any pointers in trouble-shooting this further.
>>
> I'm not aware of any issues here and there shouldn't be an issue 
> retaining the reference to the jrt FileSystem.
>
> As the jrt FileSystem is in the stack trace then it means that 
> Files.readAllBytes has been called with Path associated with the jrt 
> file system. It's not obvious how a NPE could arise after that. The 
> only thing that comes to mind is the file system being closed 
> asynchronously, I can't recall how the jrt file system handles that 
> (Sundar will know).
>
> However, just to establish the environment - is this IBM JDK 8 or an 
> Oracle/OpenJDK build of JDK 8? Also is the target image a regular JDK 
> 9 build or a Jigsaw build? There are changes to the jrt file system 
> code in the Jigsaw forest but this is mostly to support exploded builds.
>
> -Alan


From ali.ebrahimi1781 at gmail.com  Tue Nov  3 08:14:49 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Tue, 3 Nov 2015 11:44:49 +0330
Subject: Question on Implied readability
In-Reply-To: <016501d115ed$3037a2c0$90a6e840$@oracle.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>
	<5637AFE4.8020000@oracle.com>
	<CAA0cW5A0ppeRohChzs9-RyNaGQ_r3dZ_jM5kARrb9eZQoJpGqw@mail.gmail.com>
	<5637DADB.7000407@oracle.com>
	<CAA0cW5BjGKyJiR8ksQZgriOxMV-+fzWa+=7+4-a8hQS1M-uUsQ@mail.gmail.com>
	<56381B86.4010705@oracle.com>
	<016501d115ed$3037a2c0$90a6e840$@oracle.com>
Message-ID: <CAA0cW5ApS0o8AJt58A71GbLjaHbC8rMWQ0yf-6j4w8Hj8W1G+A@mail.gmail.com>

Hi Frank,
*I think Alex's interpretation of *implied readability is consistent with
current definition of concept and expected behavior.
Based on your intention public modifier should mean:
com.baz embeds com.bar in itself and exports com.bar packages for com.baz's
readers and com.foo does not reads module com.bar.
If this is expected behavior (that I don't think so) why we use:
 'require public com.bar' instead of 'includes com.bar'?

On Tue, Nov 3, 2015 at 7:37 AM, Frank Yuan <frank.yuan at oracle.com> wrote:

>
> >
>
> Hi Alex
>
> I don't think so. com.baz declares "requires public com.bar", so com.baz
> decide which com.bar is readable, in this case, decide which com.bar is
> used by com.foo
> Consider the following scenario, which is the common usage of implied
> readability
> com.baz provides the following service:
> public Object1 getObject();
> Object1 is a class defined in com.bar, please not com.bar at 2 is not
> visible to com.baz(indeed to avoid conflict, only one com.bar can be
> visible/readable to com.baz), so com.baz construct an Object1 of com.bar at 1
> during getObject() is invoked, and then com.foo get this Object1 instance,
> now com.foo can only use type Object1 of com.bar at 1 to interpret it, who
> guarantee what Object1 of com.bar at 2 is?! So here the type must be
> definite, M2 requires public M1,  M3 requires M2, then which M1 is read by
> M2, which M1 must be readable to M3. It's not related to Layer actually.

This would arise error as of pre-jigsaw with multiple classloaders and
expected.
I think completed related to layer. Intention of Layers is to handle such
scenarios.


> Frank
>
>
-- 

Best Regards,
Ali Ebrahimi

From ali.ebrahimi1781 at gmail.com  Tue Nov  3 08:22:34 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Tue, 3 Nov 2015 11:52:34 +0330
Subject: Question on Implied readability
In-Reply-To: <56381B86.4010705@oracle.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>
	<5637AFE4.8020000@oracle.com>
	<CAA0cW5A0ppeRohChzs9-RyNaGQ_r3dZ_jM5kARrb9eZQoJpGqw@mail.gmail.com>
	<5637DADB.7000407@oracle.com>
	<CAA0cW5BjGKyJiR8ksQZgriOxMV-+fzWa+=7+4-a8hQS1M-uUsQ@mail.gmail.com>
	<56381B86.4010705@oracle.com>
Message-ID: <CAA0cW5BwnpXBmk1Uyaqjo1RAbWEWP6ouJf5x8d1xqPXW-UOMVA@mail.gmail.com>

Thanks Alex,
So this is currently not fully implemented.
I think this would have many use cases in EE land where we would need
override some modules.

On Tue, Nov 3, 2015 at 5:57 AM, Alex Buckley <alex.buckley at oracle.com>
wrote:

> On 11/2/2015 3:32 PM, Ali Ebrahimi wrote:
>
>> On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>
>> On 02/11/2015 20:02, Ali Ebrahimi wrote:
>>> Thanks, I see the issue. The reason it didn't duplicate for me is because
>>> I hadn't dropped the requires com.bar.
>>>
>>> So the bug is implied readability across layers when the same named
>>> module
>>> exists in multiple layers. In this case com.foo should read com.bar at 1.
>>> The com.bar (@2) is the same configuration as com.foo is confusing the
>>> code. We'll need to fix this.
>>>
>>> So, you say com.foo can not read com.bar(@2) and why?
>>>
>> Based on implied readability module com.foo implicitly reads com.bar, in
>> other word have requires com.bar;
>> and because com.bar(@2) is co-layer with com.foo, so
>> module com.foo should reads com.bar(@2).
>> com.bar(@2) override com.bar(@1) for com.foo.
>> How this specified in spec?
>>
>
> It's currently underspecified in Configuration::resolve as "A readability
> graph is then constructed to take account of implicitly declared
> dependences (requires public)."
>
> We'll have to think about the implication of com.baz in layer1 sometimes
> offering a 'requires public' on com.bar in layer1, and sometimes offering a
> 'requires public' on com.bar in layer2, depending on who is reading com.baz
> in layer1.
>
> Alex
>



-- 

Best Regards,
Ali Ebrahimi

From philippe.marschall at netcetera.ch  Tue Nov  3 08:25:09 2015
From: philippe.marschall at netcetera.ch (Philippe Marschall)
Date: Tue, 3 Nov 2015 09:25:09 +0100
Subject: Possible jrt filesystem bug
Message-ID: <56386F65.2030909@netcetera.ch>

Hi

I have encountered something with I believe may be a bug in the jrt 
filesystem.

The children/directory entries of
/packages/com.oracle/java.xml.ws/com are
/modules/java.xml.ws/com/sun
/modules/java.xml.ws/com/oracle
when I believe they should be:
/packages/com.oracle/java.xml.ws/com/sun
/packages/com.oracle/java.xml.ws/com/oracle

You can use the following code to reproduce the issue:

FileSystem fileSystem = FileSystems.getFileSystem(URI.create("jrt:/"));
Path parent = fileSystem.getPath("/packages/com.oracle/java.xml.ws/com");
try (DirectoryStream<Path> directoryStream = 
Files.newDirectoryStream(parent)) {
   for (Path each : directoryStream) {
     System.out.println(" parent: " + parent + " child: " + each + "
startsWith: " + each.startsWith(parent));
   }
}

The output I get is:

  parent: /packages/com.oracle/java.xml.ws/com child:
/modules/java.xml.ws/com/oracle startsWith: false

  parent: /packages/com.oracle/java.xml.ws/com child:
/modules/java.xml.ws/com/sun startsWith: false

This is based on b86 with Jigsaw on Mac OS.

Cheers
Philippe

From Alan.Bateman at oracle.com  Tue Nov  3 08:49:46 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 3 Nov 2015 08:49:46 +0000
Subject: Is Caching JrtFileSystem acceptable?
In-Reply-To: <56384D6A.5010507@oracle.com>
References: <OF9476A5E6.BCA93A45-ON65257EF1.003472C2-65257EF1.0035DF02@in.ibm.com>
	<56373C78.4090807@oracle.com> <56384D6A.5010507@oracle.com>
Message-ID: <5638752A.1070304@oracle.com>



On 03/11/2015 06:00, Sundararajan Athijegannathan wrote:
> As Alan said, other thing async. closing of the file system, nothing 
> really comes to mind. There is checkResource call in code to check 
> that the resource exists before opening channel on it.. Is it possible 
> to reproduce this on a smaller app?
Speaking of, I assume jrtfs needs to be more robust in the face of 
asynchronous close, maybe a RW lock.

Jayaprakash - are you able to establish if the file system is open or 
closed when you get the NPE?

From Alan.Bateman at oracle.com  Tue Nov  3 09:30:55 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 3 Nov 2015 09:30:55 +0000
Subject: Question on Implied readability
In-Reply-To: <CABLGb9xpF+HiEwBrUE2CuS54RfbJzskzFn9sPcCV5_9oOW2Qzw@mail.gmail.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>
	<5637AFE4.8020000@oracle.com>
	<CABLGb9xpF+HiEwBrUE2CuS54RfbJzskzFn9sPcCV5_9oOW2Qzw@mail.gmail.com>
Message-ID: <56387ECF.4030906@oracle.com>

On 02/11/2015 19:13, Paul Benedict wrote:
> Alan, please correct me if wrong, but there is no enforced correlation 
> between the module name and the jar name it's packaged in, right? The 
> name is officially taken from the module-info.class?
For explicit modules (meaning those with a module-info.class) then that 
is correct.


> If so, I'd like to make a suggestion. One thing that's been extremely 
> useful to me with JBoss is the ability to link back to the JAR path in 
> the stack trace. Is there any chance you would consider expanding the 
> stack trace to something like this:
>
> bar1
> Exception in thread "main" java.lang.reflect.InvocationTargetException
>          at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0[c:\jdk\1.9\jre\modules\java.base.jar]/NativeMethod)
On the surface then this might look appealing but I've no doubt it would 
be highly problematic too. For starters, disclosing file paths in 
exceptions will lead to security concerns. The other thing is that file 
paths or code sources can be quite long so it will make stack traces 
harder to read. We are also not quite over the consequences of adding 
the module name and version to the stack trace as there are always 
consequences to changing something that is serialization. In this case, 
there is still work to do in JMX.

BTW: With -verbose:class and -listmods then we already have a few ways 
to tell where a module is loaded from.

-Alan

From ali.ebrahimi1781 at gmail.com  Tue Nov  3 09:39:51 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Tue, 3 Nov 2015 13:09:51 +0330
Subject: Simple typo in ModuleInfo
Message-ID: <CAA0cW5CM0kKYoWZZ5zvxaF4HRJxPqmNgdv2sd6YtUgvo4=AZ_Q@mail.gmail.com>

Hi,


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
@@ -186,7 +186,7 @@

         int methods_count = in.readUnsignedShort();
         if (methods_count > 0)
-            throw invalidModuleDescriptor("Bad #fields");
+            throw invalidModuleDescriptor("Bad #methods");

         int attributes_count = in.readUnsignedShort();


-- 

Best Regards,
Ali Ebrahimi

From blackdrag at gmx.org  Tue Nov  3 09:56:56 2015
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Tue, 3 Nov 2015 10:56:56 +0100
Subject: Avoiding same-package conflicts
In-Reply-To: <5637CF95.9030800@oracle.com>
References: <CABHMDwh+L=dmJ9oBRm=81okP2qLjT9uYaP0=7+MY_eVZ7UqpbQ@mail.gmail.com>
	<563223CB.8060300@oracle.com>
	<CACzrW9BPvfDOb1Wbgd6n4Rba1+0TyG3XnKWFFPfZS0Kr0kBmRA@mail.gmail.com>
	<5633D52C.6050406@gmx.org> <5637CF95.9030800@oracle.com>
Message-ID: <563884E8.4060505@gmx.org>

On 02.11.2015 22:03, Alex Buckley wrote:
[...]
> The initial modularization of JavaFX had a similar pattern: more split
> packages than you would think, due to a "horizontal" module wanting to
> share packages with numerous "vertical" domain modules. There, the
> "horizontal" module was a 'builder' module which hoped to add
> $COMPONENTBuilder classes to the packages of various 'component'
> modules; eventually the $COMPONENTBuilder classes were deemed
> unnecessary and the 'builder' module deleted. For Groovy, I suggest that
> your "base module" has the greatest claim to the
> org.codehaus.groovy.runtime package, and that the
> groovy-{nio,sql,swing,xml} modules should export
> org.codehaus.groovy.runtime.* subpackages to the base module only.
>
> It doesn't seem great that the groovy-ant and groovy-test modules try to
> augment the important groovy.util package owned by your base module.
> Speaking generally, it makes no sense to allow a module to protect its
> internals if at the same time its API can be augmented by unrelated
> modules -- it can't be the "same" API because it doesn't have access to
> the same internals.

Oh, I am not talking about internal API here.

The conflicts in org.codehaus.groovy.runtime are due to historic 
reasons. They are mostly extension methods, which could be in any 
package. But traditionally they had been part of DefaultGroovyMethods, 
from which we factored out a lot of methods over time to modularize the 
codebase more. And they tended to stay in the same package, since there 
was in the past no reason to choose a different one... looks strange to 
put a single class in a package that could be somewhere else perfectly 
fine after all. If we move those classes to new packages, then we will 
get into trouble with static compiled code. After all we did that 
modularization before Groovy had an optional static compiler, and we did 
a major version change for that (from 1.8 to 2.0) as well.

For groovy.util the case is more problematic. Moving GroovyTestCase into 
a new package would for example break an estimated 95% of our test 
cases. What will most likely happen is, that the test module merges with 
the base module thus pulling in "optional" dependencies like JUnit 3... 
which is in conflict with us trying to slim down the base runtime even 
more, to for example give the android version an easier standing. We 
have been thinking about for example moving the compiler into a separate 
jar. But splitting something something as tightly coupled as that will 
cause numerous same-package conflicts... Just to give an example... Eval 
is a class in groovy.util and used for example like this:

  assert 10 == Eval.me(' 2 * 4 + 2')
  assert 10 == Eval.x(2, ' x * 4 + 2')

Of course this will call the compiler.. but what use is there to make a 
groovy-base and a groovy compiler jigsaw style module, if they strongly 
depend on each other anyway?

Anyway... my intension was to give an example of how some people divide 
a broad library into "modules" and how it does not fit the "one module 
per jar, no exported name space duplication" idea. And you just 
confirmed it with the initial modularization of JavaFX.

Just to clarify... hiding parts of API is out of scope for groovy 
modules atm. A first step for us would be to get some kind of mapping of 
our current multi jar system to jigsaw modules that fits our needs.

>> also... there is a automated meta class lookup system, that is based on
>> the package name with a prefix. So someone could provide a meta class
>> for java.util.ArrayList, while another does this for LinkedList. If they
>> are using modules, they cannot be loaded at the same time. Granted, I
>> don't like this mechanism, and I am looking for ways to deprecate it in
>> the near future, but it is another example of same-package conflicts.
>
> Does this mean a Groovy meta class can currently be defined as a class
> in the java.* run-time package of the bootstrap loader?

The class would be groovy.runtime.metaclass.java.util.ArrayListMetaClass 
and doesn't have need the bootsrap loader for this of course. We 
actually always avoided implementing logic that depends on being in the 
bootstrap loader.

bye Jochen

From blackdrag at gmx.org  Tue Nov  3 10:01:12 2015
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Tue, 3 Nov 2015 11:01:12 +0100
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <CAGHtMWnmQQy9RspU0KP=_yWETm37Fsaath+HQgY5ma0Eon6ASw@mail.gmail.com>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com> <56372414.7010605@oracle.com>
	<CAGHtMWnmQQy9RspU0KP=_yWETm37Fsaath+HQgY5ma0Eon6ASw@mail.gmail.com>
Message-ID: <563885E8.80101@gmx.org>

Hi,

Jochen here, not Rory, but Groovy maintainer ;) So for Groovy reporting 
on the mailing list is good, if you also want to discuss the bug a bit 
there. If you really only want to report it, then you can just write it 
in the bug tracker. Of course Gradle is Gradle and Groovy is Groovy

bye Jochen

On 02.11.2015 23:23, Mani Sarkar wrote:
> Hi Rory,
>
> TestNG has an alternative build system which we will try to use to build
> it using the Jigsaw binary.
>
> How do you report such bugs to Gradle / Groovy ? Is it simpler if you
> reported to them on their mailing list ? Let me know what works best,
> this is fairly important as other Gradle users might have similar issues.
>
> Cheers,
> Mani
>
> On Mon, Nov 2, 2015 at 8:51 AM, Rory O'Donnell <rory.odonnell at oracle.com
> <mailto:rory.odonnell at oracle.com>> wrote:
>
>     I can't find a bug in Gradle's JIRA on this issue, Mani do you want
>     to log an issue there ?
>
>     Rgds,Rory
>
>
>     On 31/10/2015 13:56, Alan Bateman wrote:
>
>         On 31/10/2015 12:50, Mani Sarkar wrote:
>
>             Hi Rory,
>
>             Do you know of a version of Gradle or a EA version which is
>             JDK 9 Jigsaw compatible, we get these failures when building:
>
>             https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console
>
>
>         Caused by: java.lang.IllegalAccessException: class
>         org.gradle.internal.reflect.DirectInstantiator cannot access
>         class com.sun.tools.javac.api.JavacTool (in module jdk.compiler)
>         because module jdk.compiler does not export package
>         com.sun.tools.javac.api to <unnamed module @b7f23d9>
>              at
>         org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49)
>              ... 86 more
>
>         We should at least check if there is a bug in the Gradle JIRA
>         for this. It can be worked around by configuring the compileJava
>         options to fork javac but you might not want to do that.
>
>         The other issue with Gradle that we know about is the
>         ClassCastException when attempting to run tests, this is tracked
>         here:
>         https://issues.gradle.org/browse/GRADLE-3287
>
>         -Alan.
>
>
>     --
>     Rgds,Rory O'Donnell
>     Quality Engineering Manager
>     Oracle EMEA , Dublin, Ireland
>
>
>
>
> --
> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  | **Blog
> <http://neomatrix369.wordpress.com>**  | *LJC Associate & LJC Advocate
> (@adoptopenjdk & @adoptajsr programs)
> *Meet-a-Project - *MutabilityDetector
> <https://github.com/MutabilityDetector>*  | **Bitbucket
> <https://bitbucket.org/neomatrix369>* * | **Github
> <https://github.com/neomatrix369>** | **LinkedIn
> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/
>
> */Don't chase success, rather aim for "Excellence", and success will
> come chasing after you!/*


From frank.yuan at oracle.com  Tue Nov  3 10:00:50 2015
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 3 Nov 2015 18:00:50 +0800
Subject: Question on Implied readability
In-Reply-To: <CAA0cW5ApS0o8AJt58A71GbLjaHbC8rMWQ0yf-6j4w8Hj8W1G+A@mail.gmail.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>	<5637AFE4.8020000@oracle.com>	<CAA0cW5A0ppeRohChzs9-RyNaGQ_r3dZ_jM5kARrb9eZQoJpGqw@mail.gmail.com>	<5637DADB.7000407@oracle.com>	<CAA0cW5BjGKyJiR8ksQZgriOxMV-+fzWa+=7+4-a8hQS1M-uUsQ@mail.gmail.com>	<56381B86.4010705@oracle.com>	<016501d115ed$3037a2c0$90a6e840$@oracle.com>
	<CAA0cW5ApS0o8AJt58A71GbLjaHbC8rMWQ0yf-6j4w8Hj8W1G+A@mail.gmail.com>
Message-ID: <020501d1161e$8a0d4350$9e27c9f0$@oracle.com>

 

Hi Frank,

I think Alex's interpretation of implied readability is consistent with current definition of concept and expected behavior.

Based on your intention public modifier should mean:

com.baz embeds com.bar in itself and exports com.bar packages for com.baz's readers and com.foo does not reads module com.bar.

 

Up to the point, yes, this is my view even though I don't mean com.baz embeds com.bar physically. But if com.foo intends to read com.bar, it should declare "requires com.bar" explicitly. Article http://openjdk.java.net/projects/jigsaw/spec/sotms/ states the purpose of implied readability as well as the common use case. The key of this design is at that the module, which provides some service, take the responsibility to make some other necessary modules readable to the consumer module. Or it can encapsulate the interface in the necessary modules, that it won't declare "requires" with "public". If the consumer module doesn't demand the producer module, consumer also won't need to read those "necessary modules".

 

Besides the conceptual aspect, it doesn't work if consumer uses any instance returned from producer but consumer interprets it to be the type in any different module with which the producer reads, as the example I gave in my pervious mail.

 

If this is expected behavior (that I don't think so) why we use:

 'require public com.bar' instead of 'includes com.bar'?

 

 

On Tue, Nov 3, 2015 at 7:37 AM, Frank Yuan <frank.yuan at oracle.com <mailto:frank.yuan at oracle.com> > wrote:


>

Hi Alex

I don't think so. com.baz declares "requires public com.bar", so com.baz decide which com.bar is readable, in this case, decide which com.bar is used by com.foo
Consider the following scenario, which is the common usage of implied readability
com.baz provides the following service:
public Object1 getObject();
Object1 is a class defined in com.bar, please not com.bar at 2 <mailto:com.bar at 2>  is note visible to com.baz(indeed to avoid conflict, only one com.bar can be visible/readable to com.baz), so com.baz construct an Object1 of com.bar at 1 <mailto:com.bar at 1>  during getObject() is invoked, and then com.foo get this Object1 instance, now com.foo can only use type Object1 of com.bar at 1 <mailto:com.bar at 1>  to interpret it, who guarantee what Object1 of com.bar at 2 <mailto:com.bar at 2>  is?! So here the type must be definite, M2 requires public M1,  M3 requires M2, then which M1 is read by M2, which M1 must be readable to M3. It's not related to Layer actually.

This would arise error as of pre-jigsaw with multiple classloaders and expected.

I think completed related to layer. Intention of Layers is to handle such scenarios.

 

Our gap may be you think com.baz should construct Object1 with the type in com.bar at 2 <mailto:com.bar at 2> , but in your code, com.baz does read com.bar at 1 <mailto:com.bar at 1>  according to its static module descriptors and your layer's configuration, and then in com.baz, the hard code will construct Object1 with the type in com.bar at 1 <mailto:com.bar at 1> , you can use reflection to addReads(com.bar at 2 <mailto:com.bar at 2> ) inside com.baz but I guess it should fail because of duplicate module name, further, package name and qualified class name should not be duplicate in same one scope.

 

I said it's not related to Layer because I wanted to emphasize it's related to Layer properties. Anyway we don't need to struggle on the words.

 

Frank

 

-- 


Best Regards,

Ali Ebrahimi


From Alan.Bateman at oracle.com  Tue Nov  3 10:01:56 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 3 Nov 2015 10:01:56 +0000
Subject: Simple typo in ModuleInfo
In-Reply-To: <CAA0cW5CM0kKYoWZZ5zvxaF4HRJxPqmNgdv2sd6YtUgvo4=AZ_Q@mail.gmail.com>
References: <CAA0cW5CM0kKYoWZZ5zvxaF4HRJxPqmNgdv2sd6YtUgvo4=AZ_Q@mail.gmail.com>
Message-ID: <56388614.5000904@oracle.com>



On 03/11/2015 09:39, Ali Ebrahimi wrote:
> Hi,
>
>
> 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
> @@ -186,7 +186,7 @@
>
>           int methods_count = in.readUnsignedShort();
>           if (methods_count > 0)
> -            throw invalidModuleDescriptor("Bad #fields");
> +            throw invalidModuleDescriptor("Bad #methods");
>
>
Thanks, we'll get that typo fixed.

-Alan

From ali.ebrahimi1781 at gmail.com  Tue Nov  3 10:38:14 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Tue, 3 Nov 2015 14:08:14 +0330
Subject: Question on Implied readability
In-Reply-To: <020501d1161e$8a0d4350$9e27c9f0$@oracle.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>
	<5637AFE4.8020000@oracle.com>
	<CAA0cW5A0ppeRohChzs9-RyNaGQ_r3dZ_jM5kARrb9eZQoJpGqw@mail.gmail.com>
	<5637DADB.7000407@oracle.com>
	<CAA0cW5BjGKyJiR8ksQZgriOxMV-+fzWa+=7+4-a8hQS1M-uUsQ@mail.gmail.com>
	<56381B86.4010705@oracle.com>
	<016501d115ed$3037a2c0$90a6e840$@oracle.com>
	<CAA0cW5ApS0o8AJt58A71GbLjaHbC8rMWQ0yf-6j4w8Hj8W1G+A@mail.gmail.com>
	<020501d1161e$8a0d4350$9e27c9f0$@oracle.com>
Message-ID: <CAA0cW5CarpJ1Dtg2j_t1_gZVfRS1EZ3mV=5ND6F7d1FKn4evnw@mail.gmail.com>

Hi Frank,

On Tue, Nov 3, 2015 at 1:30 PM, Frank Yuan <frank.yuan at oracle.com> wrote:

>
>
>
> This would arise error as of pre-jigsaw with multiple classloaders and
> expected.
>
> I think completed related to layer. Intention of Layers is to handle such
> scenarios.
>
>
>
> Our gap may be you think com.baz should construct Object1 with the type in
> com.bar at 2, but in your code, com.baz does read com.bar at 1 according to its
> static module descriptors and your layer's configuration, and then in
> com.baz,
>

Not at all. I think com.baz should construct Object1 with the type in
com.bar at 1 <com.bar at 2>(com.baz can not read com.bar at 2 from upper layer
'layer2') and if that object passed to com.foo in layer2 as said before,
error should occur.


-- 

Best Regards,
Ali Ebrahimi

From Alan.Bateman at oracle.com  Tue Nov  3 11:28:01 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 3 Nov 2015 11:28:01 +0000
Subject: Compilation feedback and version question
In-Reply-To: <CACzrW9CEyAHTmNWkptKDM=jnPtCECKB0maMJ0xo2Yb9PJ6cXsg@mail.gmail.com>
References: <CACzrW9CQftaESzqtK87WkTYxfPjYXGHzVVt+uK57S-HO_sVaug@mail.gmail.com>
	<CACzrW9A58tss_WRuUyVpHvkB66hNdacwqJOcxj67EPJFRoTJfg@mail.gmail.com>
	<5631616D.6080707@oracle.com>
	<CACzrW9CEyAHTmNWkptKDM=jnPtCECKB0maMJ0xo2Yb9PJ6cXsg@mail.gmail.com>
Message-ID: <56389A41.1010103@oracle.com>



On 29/10/2015 11:25, Stephen Colebourne wrote:
> :
>
> However, my feedback is that the -listmods option is confusing. An
> option called "list" is something I expect to list all things, not to
> be clever and only show some subset. At the very least, I consider it
> vital for there to be a tool (preferably java.exe) that can list *all*
> available modules given a module path. Maybe the current -listmods
> should be renamed to -applicationmods or -initialmods, or split to
> -listmods:app and -listmods:all ?  (Being able to list everything
> available feels like module 101).
>
I think you have a point. The -listmods option lists the modules in the 
boot layer when it might more understandable if it simply listed all 
observable modules and just exited like java -version. We'll need to 
think about this.

-Alan

From sundararajan.athijegannathan at oracle.com  Tue Nov  3 11:28:02 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 3 Nov 2015 16:58:02 +0530
Subject: Possible jrt filesystem bug
In-Reply-To: <56386F65.2030909@netcetera.ch>
References: <56386F65.2030909@netcetera.ch>
Message-ID: <56389A42.40700@oracle.com>

This appears to be a bug. I'll check with the latest code in jigsaw 
forest and file a bug if needed.

Thanks,
-Sundar

On 11/3/2015 1:55 PM, Philippe Marschall wrote:
> Hi
>
> I have encountered something with I believe may be a bug in the jrt 
> filesystem.
>
> The children/directory entries of
> /packages/com.oracle/java.xml.ws/com are
> /modules/java.xml.ws/com/sun
> /modules/java.xml.ws/com/oracle
> when I believe they should be:
> /packages/com.oracle/java.xml.ws/com/sun
> /packages/com.oracle/java.xml.ws/com/oracle
>
> You can use the following code to reproduce the issue:
>
> FileSystem fileSystem = FileSystems.getFileSystem(URI.create("jrt:/"));
> Path parent = fileSystem.getPath("/packages/com.oracle/java.xml.ws/com");
> try (DirectoryStream<Path> directoryStream = 
> Files.newDirectoryStream(parent)) {
>   for (Path each : directoryStream) {
>     System.out.println(" parent: " + parent + " child: " + each + "
> startsWith: " + each.startsWith(parent));
>   }
> }
>
> The output I get is:
>
>  parent: /packages/com.oracle/java.xml.ws/com child:
> /modules/java.xml.ws/com/oracle startsWith: false
>
>  parent: /packages/com.oracle/java.xml.ws/com child:
> /modules/java.xml.ws/com/sun startsWith: false
>
> This is based on b86 with Jigsaw on Mac OS.
>
> Cheers
> Philippe


From jborgers at jpinpoint.com  Tue Nov  3 11:37:54 2015
From: jborgers at jpinpoint.com (Jeroen Borgers)
Date: Tue, 3 Nov 2015 12:37:54 +0100
Subject: Java 9 performance optimizations
In-Reply-To: <CAHjP37ECRFCoUtRVn1fYENENdvNTzYyiCqsHH0ZzvkVxw3syNg@mail.gmail.com>
References: <CAP3hAEkqrg-7Td-uA8sqTKUGZY2x51JZV=VbNPtKhDvr-4whRQ@mail.gmail.com>
	<CAHjP37ECRFCoUtRVn1fYENENdvNTzYyiCqsHH0ZzvkVxw3syNg@mail.gmail.com>
Message-ID: <CAP3hAE=Kj7AfE99_ach5tj-9TZJ+maV3uRxaW2W9rBTiebp+NQ@mail.gmail.com>

I found this interesting presentation "Java goes AOT" from JVM Language
Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc

As presented by Christiaan Thalinger from HS compiler team, AOT is used
with Graal to reduce startup time and quicker peak performance (tiered).
Currently they don't do any inlining in AOT yet because compilation time
blows up by inlining everything since no profiling information is available
yet. I guess modules and knowing dependencies can help here to reduce this.
Besides test running to generate profiling data.

Regards, Jeroen

2015-10-27 1:39 GMT+01:00 Vitaly Davidovich <vitalyd at gmail.com>:

> Is there more info on aggressive lambda inlining? If it's what I think it
> is, it would be very useful performance wise.
>
> sent from my phone
> On Oct 25, 2015 12:51 PM, "Jeroen Borgers" <jborgers at jpinpoint.com> wrote:
>
>> Hi,
>>
>> One of the goals of Jigsaw I read here:
>>
>> http://openjdk.java.net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
>> is:
>> *Enable ahead-of-time, whole-program optimization techniques*  -
>> [..]
>> The optimization techniques envisioned here include, but are not limited
>> to: Fast lookup of both JDK and application classes; early bytecode
>> verification; aggressive inlining of, *e.g.*, lambda expressions, and
>> other
>> standard compiler optimizations; construction of JVM-specific memory
>> images
>> that can be loaded more efficiently than class files; ahead-of-time
>> compilation of method bodies to native code; and the removal of unused
>> fields, methods, and classes. These kinds of techniques tend to work best
>> when JDK and application code is analyzed together, prior to run time.
>> [..]
>>
>>    -
>>
>>    *Optimize existing code as-is* ? It must be possible to apply the
>>    optimizer tool to existing code already packaged in traditional jar
>> files,
>>    without changing those files.
>>    -
>>
>>    *Actual optimizations* ? As a proof of concept, provide at least two
>>    optimizations that deliver nontrivial performance benefits.
>>
>> My questions are:
>> * What is the current state? Which techniques/optimizations are already
>> implemented and available from the current ea JDK 9 or will be?
>> * Are there any new insights/developments in this area?
>> * I noticed in my JMH microbenchmark with parallelstream and lambda's that
>> it runs slightly faster on 9_b85 compared to 8_u66. Could this be caused
>> by
>> more aggressive inlining of lambda's?
>> * It seems to me that some compilation and optimization work is moved from
>> runtime to link time, this will only be beneficial in limited cases,
>> right?
>> Are there obvious cases?
>> * I don't really see why aggressive inlining and std optimizations can now
>> be more effective. Because there will be less de-optimization events
>> needed
>> because of better predictability? Can in-lining now take place in two
>> ways,
>> between platform modules and application? Through interfaces?
>>
>> Thanks!
>>
>> -Jeroen
>>
>

From Alan.Bateman at oracle.com  Tue Nov  3 11:53:23 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 3 Nov 2015 11:53:23 +0000
Subject: Question on Implied readability
In-Reply-To: <56381B86.4010705@oracle.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>
	<5637AFE4.8020000@oracle.com>
	<CAA0cW5A0ppeRohChzs9-RyNaGQ_r3dZ_jM5kARrb9eZQoJpGqw@mail.gmail.com>
	<5637DADB.7000407@oracle.com>
	<CAA0cW5BjGKyJiR8ksQZgriOxMV-+fzWa+=7+4-a8hQS1M-uUsQ@mail.gmail.com>
	<56381B86.4010705@oracle.com>
Message-ID: <5638A033.6000205@oracle.com>

On 03/11/2015 02:27, Alex Buckley wrote:
>
> It's currently underspecified in Configuration::resolve as "A 
> readability graph is then constructed to take account of implicitly 
> declared dependences (requires public)."
Yes, the javadoc does indeed need more work.

>
> We'll have to think about the implication of com.baz in layer1 
> sometimes offering a 'requires public' on com.bar in layer1, and 
> sometimes offering a 'requires public' on com.bar in layer2, depending 
> on who is reading com.baz in layer1.
Yes, although for the configuration then the read edges are always to 
modules in same configuration or to modules in parent layers. So in 
Ali's example then the configuration for layer2 should have have com.foo 
reading both com.baz and com.bar in layer1. At runtime then com.foo 
might decide to also read com.bar at 2 but it's playing with fire at that 
point.

In any case, the issue that Ali ran into turns out to be a small 
oversight in the implementation, easily fixed. There is however another 
case that will need yet more thought and that is where an 
indistinguishable com.bar is in both layers. If they are different 
(meaning not equal) then the implementation will be correct. This is 
somewhat of a corner case but will need to be handled too.

-Alan.

From Alan.Bateman at oracle.com  Tue Nov  3 12:02:24 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 3 Nov 2015 12:02:24 +0000
Subject: Possible jrt filesystem bug
In-Reply-To: <56389A42.40700@oracle.com>
References: <56386F65.2030909@netcetera.ch> <56389A42.40700@oracle.com>
Message-ID: <5638A250.1030505@oracle.com>

On 03/11/2015 11:28, Sundararajan Athijegannathan wrote:
> This appears to be a bug. I'll check with the latest code in jigsaw 
> forest and file a bug if needed.
Is this solely that the jrt implementation of DirectoryStream is 
resolving entries in the directory when they are sym links or is there 
more to this?

-Alan.

From Alan.Bateman at oracle.com  Tue Nov  3 12:06:31 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 3 Nov 2015 12:06:31 +0000
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <56375D51.6020101@gmx.org>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com> <56372414.7010605@oracle.com>
	<CADQzvmmxb50=r63Ab_2g+z75GFK3eGOvp9XLjRtBCfoLetvQWA@mail.gmail.com>
	<56372753.6010702@oracle.com>
	<CADQzvmkCX9hQu1NFCdoPLaS4ZQZaJPq9+vWfB+h8DYXUHWaQHw@mail.gmail.com>
	<563739F2.2030002@oracle.com> <56375D51.6020101@gmx.org>
Message-ID: <5638A347.3000907@oracle.com>


On 02/11/2015 12:55, Jochen Theodorou wrote:
>
> This impression is wrong, Groovy does not need access to all 
> JDK-internal types.
Okay, I should have said "potentially all" as there are many cases were 
the implementation type is not in an exported package.

> But this is a dynamic language at heart. If you do not have a static 
> type, then the runtime type is what counts, and that is the exact 
> type, which is sometime an internal JDK type. It means Groovy has to 
> do the same thing it has to do when a security manager doesn't like 
> access to this class, which is to not use the specific class/method, 
> but the super class information... or the information of that super 
> class.. in worst case this will be Object, which means only method 
> from Object can be called using Groovy in that case.
>
> The current state is, that this issue is now fixed. The example 
> scripts in the issue are working. That does not mean we can now run 
> the build on jigsaw of course.
Good to hear, so I'm guess you have to talk the hierarchy of the runtime 
time to find the type that is part of the API. With modules then could 
this look at the exportness?

-Alan

From vitalyd at gmail.com  Tue Nov  3 12:09:04 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 3 Nov 2015 07:09:04 -0500
Subject: Java 9 performance optimizations
In-Reply-To: <CAP3hAE=Kj7AfE99_ach5tj-9TZJ+maV3uRxaW2W9rBTiebp+NQ@mail.gmail.com>
References: <CAP3hAEkqrg-7Td-uA8sqTKUGZY2x51JZV=VbNPtKhDvr-4whRQ@mail.gmail.com>
	<CAHjP37ECRFCoUtRVn1fYENENdvNTzYyiCqsHH0ZzvkVxw3syNg@mail.gmail.com>
	<CAP3hAE=Kj7AfE99_ach5tj-9TZJ+maV3uRxaW2W9rBTiebp+NQ@mail.gmail.com>
Message-ID: <CAHjP37HHamYoY=kRKoJBZF9h5DiVRA9Wnx2VT4MwYhGjPBmNkg@mail.gmail.com>

Yes, I had seen Chris' presentation as well.  Certainly modularization will
help AOT in many ways.  But, I'm particularly interested on the JIT side.
What was meant by aggressive lambda inlining, for example? Can anyone point
at some additional info?

Thanks

sent from my phone
On Nov 3, 2015 6:37 AM, "Jeroen Borgers" <jborgers at jpinpoint.com> wrote:

> I found this interesting presentation "Java goes AOT" from JVM Language
> Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc
>
> As presented by Christiaan Thalinger from HS compiler team, AOT is used
> with Graal to reduce startup time and quicker peak performance (tiered).
> Currently they don't do any inlining in AOT yet because compilation time
> blows up by inlining everything since no profiling information is available
> yet. I guess modules and knowing dependencies can help here to reduce this.
> Besides test running to generate profiling data.
>
> Regards, Jeroen
>
> 2015-10-27 1:39 GMT+01:00 Vitaly Davidovich <vitalyd at gmail.com>:
>
>> Is there more info on aggressive lambda inlining? If it's what I think it
>> is, it would be very useful performance wise.
>>
>> sent from my phone
>> On Oct 25, 2015 12:51 PM, "Jeroen Borgers" <jborgers at jpinpoint.com>
>> wrote:
>>
>>> Hi,
>>>
>>> One of the goals of Jigsaw I read here:
>>>
>>> http://openjdk.java.net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
>>> is:
>>> *Enable ahead-of-time, whole-program optimization techniques*  -
>>> [..]
>>> The optimization techniques envisioned here include, but are not limited
>>> to: Fast lookup of both JDK and application classes; early bytecode
>>> verification; aggressive inlining of, *e.g.*, lambda expressions, and
>>> other
>>> standard compiler optimizations; construction of JVM-specific memory
>>> images
>>> that can be loaded more efficiently than class files; ahead-of-time
>>> compilation of method bodies to native code; and the removal of unused
>>> fields, methods, and classes. These kinds of techniques tend to work best
>>> when JDK and application code is analyzed together, prior to run time.
>>> [..]
>>>
>>>    -
>>>
>>>    *Optimize existing code as-is* ? It must be possible to apply the
>>>    optimizer tool to existing code already packaged in traditional jar
>>> files,
>>>    without changing those files.
>>>    -
>>>
>>>    *Actual optimizations* ? As a proof of concept, provide at least two
>>>    optimizations that deliver nontrivial performance benefits.
>>>
>>> My questions are:
>>> * What is the current state? Which techniques/optimizations are already
>>> implemented and available from the current ea JDK 9 or will be?
>>> * Are there any new insights/developments in this area?
>>> * I noticed in my JMH microbenchmark with parallelstream and lambda's
>>> that
>>> it runs slightly faster on 9_b85 compared to 8_u66. Could this be caused
>>> by
>>> more aggressive inlining of lambda's?
>>> * It seems to me that some compilation and optimization work is moved
>>> from
>>> runtime to link time, this will only be beneficial in limited cases,
>>> right?
>>> Are there obvious cases?
>>> * I don't really see why aggressive inlining and std optimizations can
>>> now
>>> be more effective. Because there will be less de-optimization events
>>> needed
>>> because of better predictability? Can in-lining now take place in two
>>> ways,
>>> between platform modules and application? Through interfaces?
>>>
>>> Thanks!
>>>
>>> -Jeroen
>>>
>>
>

From ali.ebrahimi1781 at gmail.com  Tue Nov  3 12:21:11 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Tue, 3 Nov 2015 15:51:11 +0330
Subject: Question on Implied readability
In-Reply-To: <5638A033.6000205@oracle.com>
References: <CAA0cW5BzaAF6za6j-YYzX4zLbPtea9TwqFVHutWzwwfOLUTz+A@mail.gmail.com>
	<5637AFE4.8020000@oracle.com>
	<CAA0cW5A0ppeRohChzs9-RyNaGQ_r3dZ_jM5kARrb9eZQoJpGqw@mail.gmail.com>
	<5637DADB.7000407@oracle.com>
	<CAA0cW5BjGKyJiR8ksQZgriOxMV-+fzWa+=7+4-a8hQS1M-uUsQ@mail.gmail.com>
	<56381B86.4010705@oracle.com> <5638A033.6000205@oracle.com>
Message-ID: <CAA0cW5BOSfuFq_RaDjffJbJxZbESvxYb2AiB6Mv0Y-oUSQYgRQ@mail.gmail.com>

Hi,
This patch works for me:

diff --git a/src/java.base/share/classes/java/lang/module/Resolver.java
b/src/java.base/share/classes/java/lang/module/Resolver.java
--- a/src/java.base/share/classes/java/lang/module/Resolver.java
+++ b/src/java.base/share/classes/java/lang/module/Resolver.java
@@ -263,6 +263,34 @@

                 // already defined to the runtime
                 if (mref == null && layer.findModule(dn).isPresent()) {
+                    //Implied readability wrt to layers
+                    ModuleDescriptor parentLayerModuleDescriptor =
layer.findModule(dn).get().getDescriptor();
+                    for (ModuleDescriptor.Requires
parentLayerModuleRequires : parentLayerModuleDescriptor.requires()) {
+
 if(parentLayerModuleRequires.modifiers().contains(Requires.Modifier.PUBLIC))
+                        {
+                            String dn2 = parentLayerModuleRequires.name();
+                            //Search for implicitly required module in
current layer
+                            ModuleReference mref2 = find(beforeFinder,
dn2);
+                            if(mref2 != null){//module dn2 overrided in
current layer
+                                // check if module descriptor has already
been seen
+                                ModuleDescriptor other2 =
mref2.descriptor();
+                                if (!selected.contains(other2) &&
!newlySelected.contains(other2)) {
+                                    if (nameToReference.put(dn2, mref2) ==
null) {
+                                        if (TRACE) {
+                                            trace("Module %s located,
required by %s",
+                                                    dn2, descriptor.name
());
+                                            if
(mref2.location().isPresent())
+                                                trace("  (%s)",
mref2.location().get());
+                                        }
+                                    }
+
+                                    newlySelected.add(other2);
+
+                                    q.offer(other2);
+                                }
+                            }
+                        }
+                    }
                     trace("Module %s found in parent Layer", dn);
                     continue;
                 }
@@ -508,10 +536,14 @@
                     g2.put(descriptor, requiresPublic);
                     for (Requires d: descriptor.requires()) {
                         String dn = d.name();
-                        if (nameToDescriptor.get(dn) == null
-                            &&
d.modifiers().contains(Requires.Modifier.PUBLIC))
+                        if
(d.modifiers().contains(Requires.Modifier.PUBLIC))
                         {
-                            ModuleReference mref = findInLayer(l, dn);
+                            ModuleReference mref;
+                            if(nameToDescriptor.get(dn)== null){
+                                mref = findInLayer(l, dn);
+                            }else {
+                                mref = find(beforeFinder,dn);
+                            }
                             if (mref == null)
                                 throw new InternalError(dn + " not found");
                             requiresPublic.add(mref.descriptor());


On Tue, Nov 3, 2015 at 3:23 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 03/11/2015 02:27, Alex Buckley wrote:
>
>>
>> It's currently underspecified in Configuration::resolve as "A readability
>> graph is then constructed to take account of implicitly declared
>> dependences (requires public)."
>>
> Yes, the javadoc does indeed need more work.
>
>
>> We'll have to think about the implication of com.baz in layer1 sometimes
>> offering a 'requires public' on com.bar in layer1, and sometimes offering a
>> 'requires public' on com.bar in layer2, depending on who is reading com.baz
>> in layer1.
>>
> Yes, although for the configuration then the read edges are always to
> modules in same configuration or to modules in parent layers. So in Ali's
> example then the configuration for layer2 should have have com.foo reading
> both com.baz and com.bar in layer1. At runtime then com.foo might decide to
> also read com.bar at 2 but it's playing with fire at that point.
>
> In any case, the issue that Ali ran into turns out to be a small oversight
> in the implementation, easily fixed. There is however another case that
> will need yet more thought and that is where an indistinguishable com.bar
> is in both layers. If they are different (meaning not equal) then the
> implementation will be correct. This is somewhat of a corner case but will
> need to be handled too.
>
> -Alan.
>



-- 

Best Regards,
Ali Ebrahimi

From paul.sandoz at oracle.com  Tue Nov  3 12:32:51 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Nov 2015 13:32:51 +0100
Subject: Java 9 performance optimizations
In-Reply-To: <CAHjP37HHamYoY=kRKoJBZF9h5DiVRA9Wnx2VT4MwYhGjPBmNkg@mail.gmail.com>
References: <CAP3hAEkqrg-7Td-uA8sqTKUGZY2x51JZV=VbNPtKhDvr-4whRQ@mail.gmail.com>
	<CAHjP37ECRFCoUtRVn1fYENENdvNTzYyiCqsHH0ZzvkVxw3syNg@mail.gmail.com>
	<CAP3hAE=Kj7AfE99_ach5tj-9TZJ+maV3uRxaW2W9rBTiebp+NQ@mail.gmail.com>
	<CAHjP37HHamYoY=kRKoJBZF9h5DiVRA9Wnx2VT4MwYhGjPBmNkg@mail.gmail.com>
Message-ID: <3C5587C3-32D3-4B21-BFC0-40CA27732878@oracle.com>

Hi Vitaly,

Probably worth sending an email to the hotspot-dev at openjdk.java.net <mailto:hotspot-dev at openjdk.java.net>

> On 3 Nov 2015, at 13:09, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> Yes, I had seen Chris' presentation as well.  Certainly modularization will
> help AOT in many ways.  But, I'm particularly interested on the JIT side.
> What was meant by aggressive lambda inlining, for example? Can anyone point
> at some additional info?
> 

I presume it in part might relate to cracking open the lambda ?box? implementing the targeted functional interface to obtain the underlying method containing the lambda body, generated by javac, that the box defers to, then subsituting the indy call to an invocation of that underlying method. Cue lots of hand waving?

Maybe more clues in Oleg Pliss?s Closures on Embedded JVM presentation at JVMLS 2014:

  http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf <http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf>

Paul.


From vitalyd at gmail.com  Tue Nov  3 13:07:00 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 3 Nov 2015 08:07:00 -0500
Subject: Java 9 performance optimizations
In-Reply-To: <3C5587C3-32D3-4B21-BFC0-40CA27732878@oracle.com>
References: <CAP3hAEkqrg-7Td-uA8sqTKUGZY2x51JZV=VbNPtKhDvr-4whRQ@mail.gmail.com>
	<CAHjP37ECRFCoUtRVn1fYENENdvNTzYyiCqsHH0ZzvkVxw3syNg@mail.gmail.com>
	<CAP3hAE=Kj7AfE99_ach5tj-9TZJ+maV3uRxaW2W9rBTiebp+NQ@mail.gmail.com>
	<CAHjP37HHamYoY=kRKoJBZF9h5DiVRA9Wnx2VT4MwYhGjPBmNkg@mail.gmail.com>
	<3C5587C3-32D3-4B21-BFC0-40CA27732878@oracle.com>
Message-ID: <CAHjP37EYZpn2ET0mGoPqXvx3qSJgN3OtHg5=qpTrvkBVGA-Ogg@mail.gmail.com>

Hi Paul,

Thanks for the response and the link -- will look at it later.

I presume it in part might relate to cracking open the lambda ?box?
> implementing the targeted functional interface to obtain the underlying
> method containing the lambda body, generated by javac, that the box defers
> to, then subsituting the indy call to an invocation of that underlying
> method. Cue lots of hand waving?


 Yes, that's sort of what I assumed it referred to.  That would be great!

Thanks

On Tue, Nov 3, 2015 at 7:32 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Vitaly,
>
> Probably worth sending an email to the hotspot-dev at openjdk.java.net
> <mailto:hotspot-dev at openjdk.java.net>
>
> > On 3 Nov 2015, at 13:09, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> >
> > Yes, I had seen Chris' presentation as well.  Certainly modularization
> will
> > help AOT in many ways.  But, I'm particularly interested on the JIT side.
> > What was meant by aggressive lambda inlining, for example? Can anyone
> point
> > at some additional info?
> >
>
> I presume it in part might relate to cracking open the lambda ?box?
> implementing the targeted functional interface to obtain the underlying
> method containing the lambda body, generated by javac, that the box defers
> to, then subsituting the indy call to an invocation of that underlying
> method. Cue lots of hand waving?
>
> Maybe more clues in Oleg Pliss?s Closures on Embedded JVM presentation at
> JVMLS 2014:
>
>   http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf <
> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf>
>
> Paul.
>
>

From blackdrag at gmx.org  Tue Nov  3 13:41:10 2015
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Tue, 3 Nov 2015 14:41:10 +0100
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <5638A347.3000907@oracle.com>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com> <56372414.7010605@oracle.com>
	<CADQzvmmxb50=r63Ab_2g+z75GFK3eGOvp9XLjRtBCfoLetvQWA@mail.gmail.com>
	<56372753.6010702@oracle.com>
	<CADQzvmkCX9hQu1NFCdoPLaS4ZQZaJPq9+vWfB+h8DYXUHWaQHw@mail.gmail.com>
	<563739F2.2030002@oracle.com> <56375D51.6020101@gmx.org>
	<5638A347.3000907@oracle.com>
Message-ID: <5638B976.7000600@gmx.org>

On 03.11.2015 13:06, Alan Bateman wrote:
[...]
> Good to hear, so I'm guess you have to talk the hierarchy of the runtime
> time to find the type that is part of the API. With modules then could
> this look at the exportness?

Well, what we currently do is fill a ClassInfo class (a kind of 
reflection cache from which we generate our meta class) with the all the 
members we can access. This is the non-private members from the parents 
and all declared members of the current class. If the current class is 
blocked, it will automatically consist only of the not blocked 
information from the parent.

We don't try to find the module and its exports at runtime. Maybe we 
will do such things later to improve performance.

bye Jochen



From alan.bateman at oracle.com  Tue Nov  3 14:59:10 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 03 Nov 2015 14:59:10 +0000
Subject: hg: jigsaw/jake/jdk: 2 new changesets
Message-ID: <201511031459.tA3ExAGi025260@aojmv0008.oracle.com>

Changeset: c63cc080ff93
Author:    alanb
Date:      2015-11-03 14:21 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c63cc080ff93

Exception message incorrect when InvalidModuleDescriptorException thrown
because module-info.class has non-empty method table
Contributed-by: ali.ebrahimi1781 at gmail.com

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

Changeset: d770953d20e5
Author:    alanb
Date:      2015-11-03 14:50 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d770953d20e5

requires public not handled correctly when same named module in current
configuration and parent layer

! src/java.base/share/classes/java/lang/module/Resolver.java
! test/jdk/jigsaw/module/ConfigurationTest.java


From Alan.Bateman at oracle.com  Tue Nov  3 15:03:12 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 3 Nov 2015 15:03:12 +0000
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <5638B976.7000600@gmx.org>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com> <56372414.7010605@oracle.com>
	<CADQzvmmxb50=r63Ab_2g+z75GFK3eGOvp9XLjRtBCfoLetvQWA@mail.gmail.com>
	<56372753.6010702@oracle.com>
	<CADQzvmkCX9hQu1NFCdoPLaS4ZQZaJPq9+vWfB+h8DYXUHWaQHw@mail.gmail.com>
	<563739F2.2030002@oracle.com> <56375D51.6020101@gmx.org>
	<5638A347.3000907@oracle.com> <5638B976.7000600@gmx.org>
Message-ID: <5638CCB0.7010706@oracle.com>

On 03/11/2015 13:41, Jochen Theodorou wrote:
>
> Well, what we currently do is fill a ClassInfo class (a kind of 
> reflection cache from which we generate our meta class) with the all 
> the members we can access. This is the non-private members from the 
> parents and all declared members of the current class. If the current 
> class is blocked, it will automatically consist only of the not 
> blocked information from the parent.
By "blocked" then do you mean setAccessible(true) fails or specific 
exceptions like IllegalAccess*, InaccessibleObjectException or maybe 
SecurityException?

Does it meant that Groovy will work with strong encapsulation? I realize 
there are issues with support for dynamic code generation that aren't 
currently exposed in the API.

-Alan

From alan.bateman at oracle.com  Tue Nov  3 15:36:50 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 03 Nov 2015 15:36:50 +0000
Subject: hg: jigsaw/jake/jdk: 8139587: ThreadMXBean.dumpAllThreads() may fail
	with "java.io.InvalidObjectException: Failed to invoke
	from(CompositeData)"
Message-ID: <201511031536.tA3FaogQ007130@aojmv0008.oracle.com>

Changeset: 8103705ebe2f
Author:    jbachorik
Date:      2015-11-03 15:36 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8103705ebe2f

8139587: ThreadMXBean.dumpAllThreads() may fail with "java.io.InvalidObjectException: Failed to invoke from(CompositeData)"

! src/java.management/share/classes/sun/management/StackTraceElementCompositeData.java
! src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java
+ src/java.management/share/classes/sun/management/TypeVersionMapper.java
! src/java.management/share/classes/sun/management/Util.java
+ test/sun/management/StackTraceElementCompositeData/CompatibilityTest.java


From alan.bateman at oracle.com  Tue Nov  3 16:25:34 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 03 Nov 2015 16:25:34 +0000
Subject: hg: jigsaw/jake/jdk: Fix up header/comments on TypeVersionMapper
Message-ID: <201511031625.tA3GPYp3020455@aojmv0008.oracle.com>

Changeset: 4601ebe760f8
Author:    jbachorik
Date:      2015-11-03 16:24 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4601ebe760f8

Fix up header/comments on TypeVersionMapper

! src/java.management/share/classes/sun/management/TypeVersionMapper.java


From blackdrag at gmx.org  Tue Nov  3 18:02:04 2015
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Tue, 3 Nov 2015 19:02:04 +0100
Subject: TestNG build failing with JDK9 Jigsaw due to Gradle
In-Reply-To: <5638CCB0.7010706@oracle.com>
References: <CAGHtMWn0GiogRgkBAak1AFGiwgAbzTqGpXg1yGDbRmLe7bou2Q@mail.gmail.com>
	<5634C884.6040302@oracle.com> <56372414.7010605@oracle.com>
	<CADQzvmmxb50=r63Ab_2g+z75GFK3eGOvp9XLjRtBCfoLetvQWA@mail.gmail.com>
	<56372753.6010702@oracle.com>
	<CADQzvmkCX9hQu1NFCdoPLaS4ZQZaJPq9+vWfB+h8DYXUHWaQHw@mail.gmail.com>
	<563739F2.2030002@oracle.com> <56375D51.6020101@gmx.org>
	<5638A347.3000907@oracle.com> <5638B976.7000600@gmx.org>
	<5638CCB0.7010706@oracle.com>
Message-ID: <5638F69C.3040808@gmx.org>

On 03.11.2015 16:03, Alan Bateman wrote:
> On 03/11/2015 13:41, Jochen Theodorou wrote:
>>
>> Well, what we currently do is fill a ClassInfo class (a kind of
>> reflection cache from which we generate our meta class) with the all
>> the members we can access. This is the non-private members from the
>> parents and all declared members of the current class. If the current
>> class is blocked, it will automatically consist only of the not
>> blocked information from the parent.
> By "blocked" then do you mean setAccessible(true) fails or specific
> exceptions like IllegalAccess*, InaccessibleObjectException or maybe
> SecurityException?

I mean SecurityException and InaccessibleObjectException.

> Does it meant that Groovy will work with strong encapsulation? I realize
> there are issues with support for dynamic code generation that aren't
> currently exposed in the API.

IllegalAccessException is a different story, Groovy does not do strong 
encapsulation in the Java sense. Well, it is more that the access 
modifiers have a slightly different meaning, but it goes probably too 
far to explain details.

bye Jochen



From harold.seigel at oracle.com  Tue Nov  3 19:42:16 2015
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Tue, 03 Nov 2015 19:42:16 +0000
Subject: hg: jigsaw/jake/hotspot: Fix Observability tests
Message-ID: <201511031942.tA3JgGBs005377@aojmv0008.oracle.com>

Changeset: 7e972ba1fe32
Author:    gtriantafill
Date:      2015-11-03 11:14 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7e972ba1fe32

Fix Observability tests
Reviewed-by: lfoltan, hseigel

+ test/runtime/modules/Visibility/XbootcpNoVisibility.java
- test/runtime/modules/observability3/Observability3.sh
- test/runtime/modules/observability3/Observability3_A.java
- test/runtime/modules/observability3/java/util/Observability3_B.java


From alex.buckley at oracle.com  Tue Nov  3 21:28:29 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 03 Nov 2015 13:28:29 -0800
Subject: Avoiding same-package conflicts
In-Reply-To: <563884E8.4060505@gmx.org>
References: <CABHMDwh+L=dmJ9oBRm=81okP2qLjT9uYaP0=7+MY_eVZ7UqpbQ@mail.gmail.com>
	<563223CB.8060300@oracle.com>
	<CACzrW9BPvfDOb1Wbgd6n4Rba1+0TyG3XnKWFFPfZS0Kr0kBmRA@mail.gmail.com>
	<5633D52C.6050406@gmx.org> <5637CF95.9030800@oracle.com>
	<563884E8.4060505@gmx.org>
Message-ID: <563926FD.1090805@oracle.com>

On 11/3/2015 1:56 AM, Jochen Theodorou wrote:
> On 02.11.2015 22:03, Alex Buckley wrote:
> For groovy.util the case is more problematic. Moving GroovyTestCase into
> a new package would for example break an estimated 95% of our test
> cases. What will most likely happen is, that the test module merges with
> the base module thus pulling in "optional" dependencies like JUnit 3...
> which is in conflict with us trying to slim down the base runtime even
> more, to for example give the android version an easier standing. We
> have been thinking about for example moving the compiler into a separate
> jar. But splitting something something as tightly coupled as that will
> cause numerous same-package conflicts... Just to give an example... Eval
> is a class in groovy.util and used for example like this:
>
>   assert 10 == Eval.me(' 2 * 4 + 2')
>   assert 10 == Eval.x(2, ' x * 4 + 2')
>
> Of course this will call the compiler.. but what use is there to make a
> groovy-base and a groovy compiler jigsaw style module, if they strongly
> depend on each other anyway?

groovy-compiler will obviously have a hard dependency on groovy-base, 
but you can avoid groovy-base having a hard dependency on 
groovy-compiler by using services. Of course this assumes a suitable 
split between the interface of your compiler and its implementation.

Even the java.base module is very open to external providers -- see the 
Services column of 
http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html#java.base 
-- for example, "uses java.net.ContentHandlerFactory" can be provided by 
java.desktop, and "uses java.security.Provider" can be provided by 
java.naming, java.security.jgss, et al.

> Anyway... my intension was to give an example of how some people divide
> a broad library into "modules" and how it does not fit the "one module
> per jar, no exported name space duplication" idea. And you just
> confirmed it with the initial modularization of JavaFX.

Yes. We were clear at JavaOne that 1:1 migration -- one module per JAR 
-- is just one possibility among many. I actually expect the main 
obstacle to 1:1 migration to be not duplication of exported packages but 
rather cycles between classes in the JARs.

>>> also... there is a automated meta class lookup system, that is based on
>>> the package name with a prefix. So someone could provide a meta class
>>> for java.util.ArrayList, while another does this for LinkedList. If they
>>> are using modules, they cannot be loaded at the same time. Granted, I
>>> don't like this mechanism, and I am looking for ways to deprecate it in
>>> the near future, but it is another example of same-package conflicts.
>>
>> Does this mean a Groovy meta class can currently be defined as a class
>> in the java.* run-time package of the bootstrap loader?
>
> The class would be groovy.runtime.metaclass.java.util.ArrayListMetaClass
> and doesn't have need the bootsrap loader for this of course. We
> actually always avoided implementing logic that depends on being in the
> bootstrap loader.

That's good. Still, as you said, the meta classes for java.util.{A,B} 
might live in different modules, so each of those modules will try to 
export g.r.m.java.util to the same consumer.

One option for the Groovy runtime is to special case its meta class 
package hierarchy by arranging for g.r.m.** classes to be defined by, 
and exported from, a special module that the runtime generates; the 
runtime would set up readability between this module and the user 
modules that "thought" they were defining and exporting g.r.m.**.

You can see a flavor of this technique in the "dynamic module" created 
by Java's Core Reflection when you proxy certain interfaces -- see 
"Package and Module Membership of Proxy Class" in 
http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/reflect/Proxy.html.

Alex

From wolfgang.weigend at oracle.com  Wed Nov  4 00:24:28 2015
From: wolfgang.weigend at oracle.com (Wolfgang Weigend)
Date: Tue, 3 Nov 2015 16:24:28 -0800 (PST)
Subject: An exception has occurred in jlink
In-Reply-To: <562BB3B0.3000903@oracle.com>
References: <6591de18-6eb3-4476-ac37-d651f13e044e@default>
	<562BB3B0.3000903@oracle.com>
Message-ID: <fda5c48c-f225-4526-b8af-f921b72a62a6@default>

Alan,

with ";" jlink works perfect with jdk9-jigsaw-b83 :-)

Thanks

Wolfgang

-----Original Message-----
From: Alan Bateman 
Sent: Samstag, 24. Oktober 2015 18:37
To: Wolfgang Weigend; jigsaw-dev at openjdk.java.net
Subject: Re: An exception has occurred in jlink

On 24/10/2015 17:32, Wolfgang Weigend wrote:
> Dear folks,
>
>   
>
> I tried the jdk 9 EA jigsaw b83 with the quick start example as below.
>
>   
>
> C:\>jlink --modulepath C:\projects\jdk1.9.0\jmods:mlib --addmods 
> C:\src\com.greetings --output greetingsapp
The path separator on Windows is ";" so replace this with "C:\projects\jdk1.9.0\jmods;mlib" and I expect it should be work. Also you might want to grab the latest download (based on jdk9-b86) to get the latest jlink.

-Alan



From jeroen at sumatra.nl  Wed Nov  4 07:45:45 2015
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Wed, 4 Nov 2015 07:45:45 +0000
Subject: Avoiding same-package conflicts
In-Reply-To: <563926FD.1090805@oracle.com>
References: <CABHMDwh+L=dmJ9oBRm=81okP2qLjT9uYaP0=7+MY_eVZ7UqpbQ@mail.gmail.com>
	<563223CB.8060300@oracle.com>
	<CACzrW9BPvfDOb1Wbgd6n4Rba1+0TyG3XnKWFFPfZS0Kr0kBmRA@mail.gmail.com>
	<5633D52C.6050406@gmx.org> <5637CF95.9030800@oracle.com>
	<563884E8.4060505@gmx.org> <563926FD.1090805@oracle.com>
Message-ID: <eaeb0b5ef5ee41938579773d81c9a14c@mane.sumatrasoftware.com>

Alex Buckley wrote:
> Yes. We were clear at JavaOne that 1:1 migration -- one module per JAR
> -- is just one possibility among many. I actually expect the main
> obstacle to 1:1 migration to be not duplication of exported packages but
> rather cycles between classes in the JARs.

In your JavaOne talk you also mentioned "[no] duplication of exported packages", but the real restriction (at least in the current builds) seems to be "no duplication of packages (in the same layer)".

Can you confirm this?

Thanks,
Jeroen


From ali.ebrahimi1781 at gmail.com  Wed Nov  4 08:00:14 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Wed, 4 Nov 2015 11:30:14 +0330
Subject: Some API Change Suggessions
Message-ID: <CAA0cW5BWV0CcNAF2b4G8NfM+ZiErwAWhHBTLN3zOyB3kM5G3gw@mail.gmail.com>

Hi,
I think some renaming can improves API and avoid some illegible future
confusions.

Candidates:

1)
Configuration ===> LayerConfiguration or LayerConfig

2)

Configuration.layer() ===> Configuration.parentLayer()

This was confusing when I tried this:

Configuration cfg = Configuration.resolve(...

Layer layer = Layer
        .create(cfg, m -> cl);

assertTrue(layer.equals(cfg.layer()));   //

After change:

assertTrue(layer.parent().equals(cfg.parentLayer()));



-- 

Best Regards,
Ali Ebrahimi

From Alan.Bateman at oracle.com  Wed Nov  4 08:10:41 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 4 Nov 2015 08:10:41 +0000
Subject: Avoiding same-package conflicts
In-Reply-To: <eaeb0b5ef5ee41938579773d81c9a14c@mane.sumatrasoftware.com>
References: <CABHMDwh+L=dmJ9oBRm=81okP2qLjT9uYaP0=7+MY_eVZ7UqpbQ@mail.gmail.com>
	<563223CB.8060300@oracle.com>
	<CACzrW9BPvfDOb1Wbgd6n4Rba1+0TyG3XnKWFFPfZS0Kr0kBmRA@mail.gmail.com>
	<5633D52C.6050406@gmx.org> <5637CF95.9030800@oracle.com>
	<563884E8.4060505@gmx.org> <563926FD.1090805@oracle.com>
	<eaeb0b5ef5ee41938579773d81c9a14c@mane.sumatrasoftware.com>
Message-ID: <5639BD81.9050402@oracle.com>


On 04/11/2015 07:45, Jeroen Frijters wrote:
> :
> In your JavaOne talk you also mentioned "[no] duplication of exported packages", but the real restriction (at least in the current builds) seems to be "no duplication of packages (in the same layer)".
>
> Can you confirm this?
>
Not quite, the requirement is that a module M cannot read two or modules 
that export the same package to M. This is one of the checks when 
creating a configuration:

http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/module/Configuration.html#resolve-java.lang.module.ModuleFinder-java.lang.reflect.Layer-java.lang.module.ModuleFinder-java.util.Collection-

Instantiating a configuration as a Layer requires that you don't map two 
modules with the same package to the same class loader. More on this here:

http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/reflect/Layer.html#create-java.lang.module.Configuration-java.lang.reflect.Layer.ClassLoaderFinder-

I think some of the chatter here has been specific to the boot layer 
where all modules on the application module path are mapped to the 
application class loader.

-Alan

From dalibor.topic at oracle.com  Wed Nov  4 13:58:44 2015
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 4 Nov 2015 14:58:44 +0100
Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA
In-Reply-To: <CABBycTQf2g99bam+vq-oG0bWOzB3gAJsNtg6anmhdXuNN3OBQA@mail.gmail.com>
References: <CABBycTQf2g99bam+vq-oG0bWOzB3gAJsNtg6anmhdXuNN3OBQA@mail.gmail.com>
Message-ID: <563A0F14.9070205@oracle.com>

On 30.10.2015 16:29, Vincent Privat wrote:
> Hi,
> - Is it expected to allow external people to have the possibility to
> subscribe to JDK issues?

See http://robilad.livejournal.com/139637.html

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

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

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

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

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From alan.bateman at oracle.com  Wed Nov  4 14:04:05 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 04 Nov 2015 14:04:05 +0000
Subject: hg: jigsaw/jake/jdk: 2 new changesets
Message-ID: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>

Changeset: 8e0eb0540634
Author:    alanb
Date:      2015-11-04 13:45 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e0eb0540634

JT_HOME in test/Makefile out of date

! test/Makefile

Changeset: fd7cc28c24c7
Author:    alanb
Date:      2015-11-04 13:59 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7

Improve finding source module when creating a layer
Expand test coverage for implied readability + layers

! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
! src/java.base/share/classes/java/lang/reflect/Module.java
! test/jdk/jigsaw/module/ConfigurationTest.java
! test/jdk/jigsaw/reflect/Layer/LayerTest.java


From ali.ebrahimi1781 at gmail.com  Wed Nov  4 15:55:06 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Wed, 4 Nov 2015 19:25:06 +0330
Subject: hg: jigsaw/jake/jdk: 2 new changesets
In-Reply-To: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>
Message-ID: <CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>

Hi,

On Wed, Nov 4, 2015 at 5:34 PM, <alan.bateman at oracle.com> wrote:
>
>
> Changeset: fd7cc28c24c7
> Author:    alanb
> Date:      2015-11-04 13:59 +0000
> URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7
>
> Improve finding source module when creating a layer
> Expand test coverage for implied readability + layers
>
> ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
> ! src/java.base/share/classes/java/lang/reflect/Module.java
> ! test/jdk/jigsaw/module/ConfigurationTest.java
> ! test/jdk/jigsaw/reflect/Layer/LayerTest.java
>
>
In recent change to Module.java:

+++ b/src/java.base/share/classes/java/lang/reflect/Module.java	Wed
Nov 04 13:59:58 2015 +0000
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.2>@@
-40,6 +40,7 @@ <http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.3>
import java.util.HashSet;
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.4>
import java.util.Map;
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.5>
import java.util.Objects;
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.6>+import
java.util.Optional;
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.7>
import java.util.Set;
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.8>
import java.util.WeakHashMap;
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.9>
import java.util.concurrent.locks.Lock;
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.10>@@
-891,12 +892,32 @@
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.11>
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.12>
         // reads
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.13>
         Set<Module> reads = new HashSet<>();
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.14>-
         for (ModuleDescriptor other: cf.reads(descriptor)) {
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.15>+
         for (ModuleDescriptor other : cf.reads(descriptor)) {
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.16>+
             Module m2 = null;
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.17>+
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.18>+
             // Search the configuration and parent layers for the
module <http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.19>+
               // descriptor. This is temporary until Configuration
defines <http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.20>+
               // an API to return the layer + name of the source
rather than <http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.21>+
               // the module descriptor.
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.22>
             String dn = other.name();
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.23>-
             Module m2 = modules.get(dn);
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.24>-
             Layer parent = cf.layer();
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.25>-
             if (m2 == null && parent != null)
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.26>-
                 m2 = parent.findModule(other.name()).orElse(null);
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.27>+
             Module candidate = modules.get(dn);
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.28>+
             if (candidate != null &&
other.equals(candidate.getDescriptor())) {
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.29>+
                 m2 = candidate;
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.30>+
             } else {
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.31>+
                 Layer parent = cf.layer();
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.32>+
                 while (parent != null) {
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.33>+
                     Optional<Module> om = parent.findModule(dn);
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.34>+
                     if (om.isPresent()) {
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.35>+
                         candidate = om.get();
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.36>+
                         if (other.equals(candidate.getDescriptor()))
{ <http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.37>+
                               m2 = candidate;
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.38>+
                             break;
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.39>+
                         }
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.40>+
                     }
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.41>+
                     parent = parent.parent().orElse(null);
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.42>+
                 }
<http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7#l2.43>+
             }


Layer.findModule already do recursive search for modules in parent layers



-- 

Best Regards,
Ali Ebrahimi

From Alan.Bateman at oracle.com  Wed Nov  4 16:01:32 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 4 Nov 2015 16:01:32 +0000
Subject: hg: jigsaw/jake/jdk: 2 new changesets
In-Reply-To: <CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>
	<CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>
Message-ID: <563A2BDC.9030202@oracle.com>


On 04/11/2015 15:55, Ali Ebrahimi wrote:
>
>
> Layer.findModule already do recursive search for modules in parent layers
That is by name and so does not uniquely identify the module. The module 
descriptor is also not unique which is why further work is required to 
have the layer of the source module.

-Alan

From ali.ebrahimi1781 at gmail.com  Wed Nov  4 16:26:14 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Wed, 4 Nov 2015 19:56:14 +0330
Subject: hg: jigsaw/jake/jdk: 2 new changesets
In-Reply-To: <563A2BDC.9030202@oracle.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>
	<CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>
	<563A2BDC.9030202@oracle.com>
Message-ID: <CAA0cW5Cw2Lcgf765BHE4vhcYd6XGqu0+yOstsHFBHOoMEyLnjQ@mail.gmail.com>

Hi,

On Wed, Nov 4, 2015 at 7:31 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
> On 04/11/2015 15:55, Ali Ebrahimi wrote:
>
>
>
> Layer.findModule already do recursive search for modules in parent layers
>
> That is by name and so does not uniquely identify the module. The module
> descriptor is also not unique which is why further work is required to have
> the layer of the source module.
>
> Yes, I got it. But should not upper level descriptors win over lower
descriptors regards to current configuration.
What I missed here?



-- 

Best Regards,
Ali Ebrahimi

From christian.tornqvist at oracle.com  Wed Nov  4 20:28:47 2015
From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com)
Date: Wed, 04 Nov 2015 20:28:47 +0000
Subject: hg: jigsaw/jake/hotspot: Fixed sun.misc issues in
	hotspot/test/testlibrary_tests/ctw
Message-ID: <201511042028.tA4KSlDx020153@aojmv0008.oracle.com>

Changeset: e1b2092789e5
Author:    ctornqvi
Date:      2015-11-04 12:28 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e1b2092789e5

Fixed sun.misc issues in hotspot/test/testlibrary_tests/ctw

! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java
! test/testlibrary_tests/ctw/ClassesDirTest.java
! test/testlibrary_tests/ctw/JarDirTest.java
! test/testlibrary_tests/ctw/JarsTest.java


From Alan.Bateman at oracle.com  Wed Nov  4 22:03:11 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 4 Nov 2015 22:03:11 +0000
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5Cw2Lcgf765BHE4vhcYd6XGqu0+yOstsHFBHOoMEyLnjQ@mail.gmail.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>
	<CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>
	<563A2BDC.9030202@oracle.com>
	<CAA0cW5Cw2Lcgf765BHE4vhcYd6XGqu0+yOstsHFBHOoMEyLnjQ@mail.gmail.com>
Message-ID: <563A809F.9020402@oracle.com>



On 04/11/2015 16:26, Ali Ebrahimi wrote:
> :
>
> Yes, I got it. But should not upper level descriptors win over lower 
> descriptors regards to current configuration.
> What I missed here?
>
(Changing the subject line so that it's clearer what this discussion is 
about).

In your implied readability mail then I think you have:

configuration1/layer1:
   com.bar at 1
   com.baz requires public com.bar

configuration2:
   com.bar at 2
   com.foo requires com.baz

The readability graph for configuration2 is:

   com.bar at 2 requires java.base
   com.foo reads java.base
   com.foo reads com.baz
   com.foo reads com.bar at 1

Instantiating this configuration (as a layer) means locating the 
jlr.Module for com.bar at 1. For now, and it's temporary, it is found by 
matching the ModuleDescriptor starting in the configuration and working 
through the stack of layers. I say temporary because we need an API 
change to expose the layer of the source module. That will eliminate the 
search and will fix the corner case that arises when modules in 
different layers have equal ModuleDescriptor objects. We'll get to this 
soon.

-Alan.





From ali.ebrahimi1781 at gmail.com  Wed Nov  4 22:45:24 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Thu, 5 Nov 2015 02:15:24 +0330
Subject: Implied readability + layers
In-Reply-To: <563A809F.9020402@oracle.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>
	<CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>
	<563A2BDC.9030202@oracle.com>
	<CAA0cW5Cw2Lcgf765BHE4vhcYd6XGqu0+yOstsHFBHOoMEyLnjQ@mail.gmail.com>
	<563A809F.9020402@oracle.com>
Message-ID: <CAA0cW5DATqYdbTSUieJSACEU3f4w45mzV4ZKHjc7v=AHwAzb7A@mail.gmail.com>

Hi,

On Thu, Nov 5, 2015 at 1:33 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 04/11/2015 16:26, Ali Ebrahimi wrote:
>
> :
>
> Yes, I got it. But should not upper level descriptors win over lower
> descriptors regards to current configuration.
> What I missed here?
>
> (Changing the subject line so that it's clearer what this discussion is
> about).
>
> In your implied readability mail then I think you have:
>
> configuration1/layer1:
>   com.bar at 1
>   com.baz requires public com.bar
>
> configuration2:
>   com.bar at 2
>   com.foo requires com.baz
>
> The readability graph for configuration2 is:
>
>   com.bar at 2 requires java.base
>   com.foo reads java.base
>   com.foo reads com.baz
>   com.foo reads com.bar at 1
>
> Instantiating this configuration (as a layer) means locating the
> jlr.Module for com.bar at 1. For now, and it's temporary, it is found by
> matching the ModuleDescriptor starting in the configuration and working
> through the stack of layers. I say temporary because we need an API change
> to expose the layer of the source module. That will eliminate the search
> and will fix the corner case that arises when modules in different layers
> have equal ModuleDescriptor objects. We'll get to this soon.
>

So you say com.bar at 2 does not override com.bar at 1 in layer2 and types will
be loaded from com.bar at 1 in layer2 for com.foo?
This is changed from yesterday?
I now get
bar1
bar1
instead of
bar1
bar2
for my yesterday sample code. quite supersizing!

Second, what can you say for this test case:

public static void testLayerWithRequiresPublic4() {

    // cf1: m1 and m2 at 1, m1 requires public m2

    ModuleDescriptor descriptor1
            = new ModuleDescriptor.Builder("m1")
            .requires(ModuleDescriptor.Requires.Modifier.PUBLIC, "m2")
            .build();

    ModuleDescriptor descriptor2_v1
            = new ModuleDescriptor.Builder("m2")
            .version("1")
            .build();

    ModuleFinder finder1 = ModuleUtils.finderOf(descriptor1, descriptor2_v1);

    Configuration cf1
            = Configuration.resolve(finder1, boot(),
ModuleFinder.empty(), "m1");

    ClassLoader cl1 = new ClassLoader() { };
    Layer layer1 = Layer.create(cf1, mn -> cl1);


    // cf2: m3 and m2 at 2, m3 requires m1

    ModuleDescriptor descriptor2_v2
            = new ModuleDescriptor.Builder("m2")
            .version("2")
            .build();

    ModuleDescriptor descriptor3
            = new ModuleDescriptor.Builder("m3")
            .requires("m1")
            .build();

    ModuleFinder finder2 = ModuleUtils.finderOf(descriptor2_v2, descriptor3);

    Configuration cf2
            = Configuration.resolve(finder2, layer1,
ModuleFinder.empty(), "m3");

    ClassLoader cl2 = new ClassLoader() { };
    Layer layer2 = Layer.create(cf2, mn -> cl2);


    Module m1 = layer1.findModule("m1").get();
    Module m2_v1 = layer1.findModule("m2").get();
    Module m2_v2 = layer2.findModule("m2").get();
    Module m3 = layer2.findModule("m3").get();

    assertTrue(m2_v2.getLayer() == layer2);
    assertFalse(m1.canRead(m2_v2));
    assertFalse(m2_v1.canRead(m2_v2));
    assertFalse(m2_v2.canRead(m2_v1));
    assertFalse(m3.canRead(m2_v2));
}




-- 

Best Regards,
Ali Ebrahimi

From weijun.wang at oracle.com  Thu Nov  5 02:07:45 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 5 Nov 2015 10:07:45 +0800
Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA
In-Reply-To: <F51572CC-7F86-45AD-9C82-F64902AC03F4@oracle.com>
References: <CABBycTQf2g99bam+vq-oG0bWOzB3gAJsNtg6anmhdXuNN3OBQA@mail.gmail.com>
	<F51572CC-7F86-45AD-9C82-F64902AC03F4@oracle.com>
Message-ID: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com>

I was talking with Vincent off the list, but it seems better to be back.

Here is Vincent's mail on how he thinks of the new API we are about to provide in JDK-8058778.

> The new API is interesting but if it's not available in Java SE I'm afraid it does not fit our use case. We cannot make JOSM depend on a JDK at runtime just for this feature :(

There might be some confusion on what "JDK" means. It used to be the developer's toolkit versus JRE the runtime, but as for module names, a jdk.* module contains APIs defined by OpenJDK instead of Java SE. In fact, most of them are not especially designed for developers.

That said, I am not exactly sure what kind of images we will release after jigsaw. If there is still a JRE, I think it will include not only the java.* modules but also some jdk.* ones. I hope jdk.security.cert is one of them.

Personally I am not afraid of using jdk.* modules, since almost every JDK distribution is based on OpenJDK. At least it is now a supported API of OpenJDK instead of old sun.* classes that were never claimed to be supported by anyone.

In fact, keytool was not defined in Java SE either. It was in JRE though.

Thanks
Max

> On Oct 31, 2015, at 12:34 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
>> 
>> - We'd like to know if it can be expected to see the
>> package sun.security.x509 become a public JDK API, for example in
>> javax.security.cert? We currently use it to generate a self-signed
>> certificate in order to create a local https server. That's our only use of
>> private JDK API.
> 
> There are two RFEs related to signing and certificates
>  8058778: New APIs for some keytool functions
>  8056174: New APIs for jar signing
> 
> I have added this comment in 8058778 for the security team to look into.  You can subscribe to security-dev at openjdk.java.net  where the discussion for these RFEs will be.
> 
> Mandy
> 


From Alan.Bateman at oracle.com  Thu Nov  5 08:50:34 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 5 Nov 2015 08:50:34 +0000
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5DATqYdbTSUieJSACEU3f4w45mzV4ZKHjc7v=AHwAzb7A@mail.gmail.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>
	<CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>
	<563A2BDC.9030202@oracle.com>
	<CAA0cW5Cw2Lcgf765BHE4vhcYd6XGqu0+yOstsHFBHOoMEyLnjQ@mail.gmail.com>
	<563A809F.9020402@oracle.com>
	<CAA0cW5DATqYdbTSUieJSACEU3f4w45mzV4ZKHjc7v=AHwAzb7A@mail.gmail.com>
Message-ID: <563B185A.8020409@oracle.com>



On 04/11/2015 22:45, Ali Ebrahimi wrote:
> :
> So you say com.bar at 2 does not override com.bar at 1 in layer2 and types 
> will be loaded from com.bar at 1 in layer2 for com.foo?
The configuration for layer2 doesn't contain any modules that require 
com.bar.

If you expand the scenario to com.bax requires com.bar and if com.bax is 
in configuration2 then you would have com.bax reads com.bar at 2 in the 
readability graph (and layer2).


> This is changed from yesterday?
> I now get
> bar1
> bar1
> instead of
> bar1
> bar2
> for my yesterday sample code. quite supersizing!
It will take time to shake out issues and it's great that you are trying 
things and finding issues. At this time the only issue I'm aware of is 
where there are equal ModuleDescriptors in multiple layers. That one 
requires an API change as I mentioned, we'll get that sorted out soon.


>
> Second, what can you say for this test case:
>
> :
>
>
>      Module m1 = layer1.findModule("m1").get();
>      Module m2_v1 = layer1.findModule("m2").get();
>      Module m2_v2 = layer2.findModule("m2").get();
>      Module m3 = layer2.findModule("m3").get();
>
>      assertTrue(m2_v2.getLayer() == layer2);
>      assertFalse(m1.canRead(m2_v2));
>      assertFalse(m2_v1.canRead(m2_v2));
>      assertFalse(m2_v2.canRead(m2_v1));
>      assertFalse(m3.canRead(m2_v2));
In this example then m3 is the only module in layer2 and so 
layer2.findModule("m2") will find m2 in its parent (hence m2_v2 == m2_v1).

If you adjust the example so that m3 requires m2 then layer2 will 
contain m3 and m2 at 2.

It's also possible for m3 require both m1 and m2. The result may be a 
surprising as m3 will read m2 at 1 and m2 at 2. Clearly if both versions of m2 
were to export the same package then it would fail but there are no 
exports in this test case.

-Alan.

From sundararajan.athijegannathan at oracle.com  Thu Nov  5 08:52:41 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 5 Nov 2015 14:22:41 +0530
Subject: Possible jrt filesystem bug
In-Reply-To: <56386F65.2030909@netcetera.ch>
References: <56386F65.2030909@netcetera.ch>
Message-ID: <563B18D9.4060201@oracle.com>

Hi,

I filed a bug : https://bugs.openjdk.java.net/browse/JDK-8141521

Thanks for reporting this issue,
-Sundar

On 11/3/2015 1:55 PM, Philippe Marschall wrote:
> Hi
>
> I have encountered something with I believe may be a bug in the jrt 
> filesystem.
>
> The children/directory entries of
> /packages/com.oracle/java.xml.ws/com are
> /modules/java.xml.ws/com/sun
> /modules/java.xml.ws/com/oracle
> when I believe they should be:
> /packages/com.oracle/java.xml.ws/com/sun
> /packages/com.oracle/java.xml.ws/com/oracle
>
> You can use the following code to reproduce the issue:
>
> FileSystem fileSystem = FileSystems.getFileSystem(URI.create("jrt:/"));
> Path parent = fileSystem.getPath("/packages/com.oracle/java.xml.ws/com");
> try (DirectoryStream<Path> directoryStream = 
> Files.newDirectoryStream(parent)) {
>   for (Path each : directoryStream) {
>     System.out.println(" parent: " + parent + " child: " + each + "
> startsWith: " + each.startsWith(parent));
>   }
> }
>
> The output I get is:
>
>  parent: /packages/com.oracle/java.xml.ws/com child:
> /modules/java.xml.ws/com/oracle startsWith: false
>
>  parent: /packages/com.oracle/java.xml.ws/com child:
> /modules/java.xml.ws/com/sun startsWith: false
>
> This is based on b86 with Jigsaw on Mac OS.
>
> Cheers
> Philippe


From sundararajan.athijegannathan at oracle.com  Thu Nov  5 08:54:08 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 5 Nov 2015 14:24:08 +0530
Subject: Possible jrt filesystem bug
In-Reply-To: <5638A250.1030505@oracle.com>
References: <56386F65.2030909@netcetera.ch> <56389A42.40700@oracle.com>
	<5638A250.1030505@oracle.com>
Message-ID: <563B1930.1080501@oracle.com>

Appears to be only localized to jrt fs DirectoryStream's handling of 
symlink paths under /packages

-Sundar

On 11/3/2015 5:32 PM, Alan Bateman wrote:
> On 03/11/2015 11:28, Sundararajan Athijegannathan wrote:
>> This appears to be a bug. I'll check with the latest code in jigsaw 
>> forest and file a bug if needed.
> Is this solely that the jrt implementation of DirectoryStream is 
> resolving entries in the directory when they are sym links or is there 
> more to this?
>
> -Alan.


From ali.ebrahimi1781 at gmail.com  Thu Nov  5 09:30:33 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Thu, 5 Nov 2015 13:00:33 +0330
Subject: Implied readability + layers
In-Reply-To: <563B185A.8020409@oracle.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>
	<CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>
	<563A2BDC.9030202@oracle.com>
	<CAA0cW5Cw2Lcgf765BHE4vhcYd6XGqu0+yOstsHFBHOoMEyLnjQ@mail.gmail.com>
	<563A809F.9020402@oracle.com>
	<CAA0cW5DATqYdbTSUieJSACEU3f4w45mzV4ZKHjc7v=AHwAzb7A@mail.gmail.com>
	<563B185A.8020409@oracle.com>
Message-ID: <CAA0cW5ChHpORsH3Z72Yzk98cn5Mutopyjoo8LTdetAQyP3G__Q@mail.gmail.com>

Hi alan,
So far quite disappointing!

But I think Alex's last response on this topic says opposite of this:

"We'll have to think about the implication of com.baz in layer1 sometimes
offering a 'requires public' on com.bar in layer1, and sometimes offering a
'requires public' on com.bar in layer2, depending on who is reading com.baz
in layer1."

In this case adding  'requires public' on com.bar in layer2 does not mean
we should pick com.bar at 2 for com,foo?

This scenario would have many usages in future when world would filled with
modules and developers would have to use newer versions of modules to fix
bugs.
What if com.foo compiled against com.bar at 2? adding redundant requires com.bar
in com.foo does not help and my app will fail.
So what is advantage of multiple layers?


On Thu, Nov 5, 2015 at 12:20 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 04/11/2015 22:45, Ali Ebrahimi wrote:
>
> :
>
> So you say com.bar at 2 does not override com.bar at 1 in layer2 and types will
> be loaded from com.bar at 1 in layer2 for com.foo?
>
> The configuration for layer2 doesn't contain any modules that require
> com.bar.
>
> If you expand the scenario to com.bax requires com.bar and if com.bax is
> in configuration2 then you would have com.bax reads com.bar at 2 in the
> readability graph (and layer2).
>
>
> This is changed from yesterday?
> I now get
> bar1
> bar1
> instead of
> bar1
> bar2
> for my yesterday sample code. quite supersizing!
>
> It will take time to shake out issues and it's great that you are trying
> things and finding issues. At this time the only issue I'm aware of is
> where there are equal ModuleDescriptors in multiple layers. That one
> requires an API change as I mentioned, we'll get that sorted out soon.
>
>
>
> Second, what can you say for this test case:
>
> :
>
>
>     Module m1 = layer1.findModule("m1").get();
>     Module m2_v1 = layer1.findModule("m2").get();
>     Module m2_v2 = layer2.findModule("m2").get();
>     Module m3 = layer2.findModule("m3").get();
>
>     assertTrue(m2_v2.getLayer() == layer2);
>     assertFalse(m1.canRead(m2_v2));
>     assertFalse(m2_v1.canRead(m2_v2));
>     assertFalse(m2_v2.canRead(m2_v1));
>     assertFalse(m3.canRead(m2_v2));
>
> In this example then m3 is the only module in layer2 and so
> layer2.findModule("m2") will find m2 in its parent (hence m2_v2 == m2_v1).
>
> If you adjust the example so that m3 requires m2 then layer2 will contain
> m3 and m2 at 2.
>
> It's also possible for m3 require both m1 and m2. The result may be a
> surprising as m3 will read m2 at 1 and m2 at 2. Clearly if both versions of m2
> were to export the same package then it would fail but there are no exports
> in this test case.
>
> -Alan.
>



-- 

Best Regards,
Ali Ebrahimi

From sundararajan.athijegannathan at oracle.com  Thu Nov  5 09:45:46 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 5 Nov 2015 15:15:46 +0530
Subject: RFR 8141521: jrt file system's DirectoryStream reports child paths
	with wrong paths for directories under /packages
Message-ID: <563B254A.7090001@oracle.com>

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

Thanks
-Sundar

From frank.yuan at oracle.com  Thu Nov  5 10:49:53 2015
From: frank.yuan at oracle.com (Frank Yuan)
Date: Thu, 5 Nov 2015 18:49:53 +0800
Subject: Implied readability + layers
In-Reply-To: <563B185A.8020409@oracle.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>	<CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>	<563A2BDC.9030202@oracle.com>	<CAA0cW5Cw2Lcgf765BHE4vhcYd6XGqu0+yOstsHFBHOoMEyLnjQ@mail.gmail.com>	<563A809F.9020402@oracle.com>	<CAA0cW5DATqYdbTSUieJSACEU3f4w45mzV4ZKHjc7v=AHwAzb7A@mail.gmail.com>
	<563B185A.8020409@oracle.com>
Message-ID: <010b01d117b7$bf075d80$3d161880$@oracle.com>



> -----Original Message-----
> From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of Alan Bateman
> Sent: Thursday, November 05, 2015 4:51 PM
> To: Ali Ebrahimi <ali.ebrahimi1781 at gmail.com>
> Cc: jigsaw-dev <jigsaw-dev at openjdk.java.net>
> Subject: Re: Implied readability + layers
> 
> 
> 
> On 04/11/2015 22:45, Ali Ebrahimi wrote:
> > :
> > So you say com.bar at 2 does not override com.bar at 1 in layer2 and types
> > will be loaded from com.bar at 1 in layer2 for com.foo?
> The configuration for layer2 doesn't contain any modules that require com.bar.
> 
> If you expand the scenario to com.bax requires com.bar and if com.bax is in configuration2 then you would have com.bax reads
> com.bar at 2 in the readability graph (and layer2).
> 
> 
> > This is changed from yesterday?
> > I now get
> > bar1
> > bar1
> > instead of
> > bar1
> > bar2
> > for my yesterday sample code. quite supersizing!
> It will take time to shake out issues and it's great that you are trying things and finding issues. At this time the only issue I'm aware of is
> where there are equal ModuleDescriptors in multiple layers. That one requires an API change as I mentioned, we'll get that sorted out
> soon.
> 
> 
> >
> > Second, what can you say for this test case:
> >
> > :
> >
> >
> >      Module m1 = layer1.findModule("m1").get();
> >      Module m2_v1 = layer1.findModule("m2").get();
> >      Module m2_v2 = layer2.findModule("m2").get();
> >      Module m3 = layer2.findModule("m3").get();
> >
> >      assertTrue(m2_v2.getLayer() == layer2);
> >      assertFalse(m1.canRead(m2_v2));
> >      assertFalse(m2_v1.canRead(m2_v2));
> >      assertFalse(m2_v2.canRead(m2_v1));
> >      assertFalse(m3.canRead(m2_v2));
> In this example then m3 is the only module in layer2 and so
> layer2.findModule("m2") will find m2 in its parent (hence m2_v2 == m2_v1).
> 
> If you adjust the example so that m3 requires m2 then layer2 will contain m3 and m2 at 2.
> 
> It's also possible for m3 require both m1 and m2. The result may be a surprising as m3 will read m2 at 1 and m2 at 2. Clearly if both
> versions of m2 were to export the same package then it would fail but there are no exports in this test case.

Generally, m2 at 1 and m2 at 2 are different versions of a same component. So essentially a module M cannot read duplicate types/modules, except only use reflection to access, right?


> 
> -Alan.


From ali.ebrahimi1781 at gmail.com  Thu Nov  5 11:05:19 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Thu, 5 Nov 2015 14:35:19 +0330
Subject: Implied readability + layers
In-Reply-To: <010b01d117b7$bf075d80$3d161880$@oracle.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>
	<CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>
	<563A2BDC.9030202@oracle.com>
	<CAA0cW5Cw2Lcgf765BHE4vhcYd6XGqu0+yOstsHFBHOoMEyLnjQ@mail.gmail.com>
	<563A809F.9020402@oracle.com>
	<CAA0cW5DATqYdbTSUieJSACEU3f4w45mzV4ZKHjc7v=AHwAzb7A@mail.gmail.com>
	<563B185A.8020409@oracle.com>
	<010b01d117b7$bf075d80$3d161880$@oracle.com>
Message-ID: <CAA0cW5CMHsqcnapxCZvab39sWB2Mt4c2qXLiuMg5Qo44JEHDBA@mail.gmail.com>

Hi,

On Thu, Nov 5, 2015 at 2:19 PM, Frank Yuan <frank.yuan at oracle.com> wrote:

>
>
>
> Generally, m2 at 1 and m2 at 2 are different versions of a same component. So
> essentially a module M cannot read duplicate types/modules, except only use
> reflection to access, right?
>
I think this should be true with flat classpath days not now!

I think we should assume sublayers and parent layers somewhat as subclasses
and supper classes and think about method overriding vs module overriding.


-- 

Best Regards,
Ali Ebrahimi

From Alan.Bateman at oracle.com  Thu Nov  5 11:38:19 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 5 Nov 2015 11:38:19 +0000
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5ChHpORsH3Z72Yzk98cn5Mutopyjoo8LTdetAQyP3G__Q@mail.gmail.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>
	<CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>
	<563A2BDC.9030202@oracle.com>
	<CAA0cW5Cw2Lcgf765BHE4vhcYd6XGqu0+yOstsHFBHOoMEyLnjQ@mail.gmail.com>
	<563A809F.9020402@oracle.com>
	<CAA0cW5DATqYdbTSUieJSACEU3f4w45mzV4ZKHjc7v=AHwAzb7A@mail.gmail.com>
	<563B185A.8020409@oracle.com>
	<CAA0cW5ChHpORsH3Z72Yzk98cn5Mutopyjoo8LTdetAQyP3G__Q@mail.gmail.com>
Message-ID: <563B3FAB.7050809@oracle.com>

On 05/11/2015 09:30, Ali Ebrahimi wrote:
> Hi alan,
> So far quite disappointing!
>
> But I think Alex's last response on this topic says opposite of this:
>
> "We'll have to think about the implication of com.baz in layer1 
> sometimes offering a 'requires public' on com.bar in layer1, and 
> sometimes offering a 'requires public' on com.bar in layer2, depending 
> on who is reading com.baz in layer1."
>
> In this case adding 'requires public' on com.bar in layer2 does not 
> mean we should pick com.bar at 2 for com,foo?

In this example then com.baz in layer1 doesn't know anything about 
com.bar at 2 or other modules that comes into existence in future "child" 
layers, at least not statically.

com.baz does read com.bar at 1 and as it declares "requires public com.bar" 
then I assume com.baz's exported API must have com.bar at 1 types in its 
method signatories. This will usually be good for other modules in 
layer1 or modules in descendants of layer1 that use the com.baz API.

Creating a new layer2 does not change modules in other layers. This 
means that creating layer2 will not change com.baz (in layer1) to read 
com.bar at 2 (in layer2). It is of course possible for com.baz to opt-in 
and reflectively to read com.bar at 2 but great care is required (static 
references in code in com.baz will presumably resolve to types in 
com.bar at 1).

>
> This scenario would have many usages in future when world would filled 
> with modules and developers would have to use newer versions of 
> modules to fix bugs.
> What if com.foo compiled against com.bar at 2? adding redundant 
> requirescom.bar in com.foo does not help and my app will fail.
Assuming com.bar at 1 and com.bar at 2 export the same packages then it should 
fail when you attempt to create the Configuration for layer2 as com.foo 
cannot read both.

In this example then you might consider a new instance of module com.baz 
in layer2. That way, layer2 would have com.foo, com.baz and com.bar at 2.

-Alan.



From Alan.Bateman at oracle.com  Thu Nov  5 11:44:30 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 5 Nov 2015 11:44:30 +0000
Subject: Implied readability + layers
In-Reply-To: <010b01d117b7$bf075d80$3d161880$@oracle.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>
	<CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>
	<563A2BDC.9030202@oracle.com>
	<CAA0cW5Cw2Lcgf765BHE4vhcYd6XGqu0+yOstsHFBHOoMEyLnjQ@mail.gmail.com>
	<563A809F.9020402@oracle.com>
	<CAA0cW5DATqYdbTSUieJSACEU3f4w45mzV4ZKHjc7v=AHwAzb7A@mail.gmail.com>
	<563B185A.8020409@oracle.com>
	<010b01d117b7$bf075d80$3d161880$@oracle.com>
Message-ID: <563B411E.6050503@oracle.com>



On 05/11/2015 10:49, Frank Yuan wrote:
> :
> Generally, m2 at 1 and m2 at 2 are different versions of a same component. So essentially a module M cannot read duplicate types/modules, except only use reflection to access, right?
>
Yes, assuming m2 at 1 and m2 at 2 export the same package to M then it should 
be caught when attempting to create the Configuration. And yes, M can 
use the reflection API to read any other module at run-time.

-Alan.

From christian.tornqvist at oracle.com  Thu Nov  5 12:56:50 2015
From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com)
Date: Thu, 05 Nov 2015 12:56:50 +0000
Subject: hg: jigsaw/jake/hotspot: Fixed exports for another of the CTW tests
Message-ID: <201511051256.tA5Cuo0T021551@aojmv0008.oracle.com>

Changeset: e2caae19bed6
Author:    ctornqvi
Date:      2015-11-05 04:56 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e2caae19bed6

Fixed exports for another of the CTW tests

! test/testlibrary_tests/ctw/ClassesListTest.java


From ali.ebrahimi1781 at gmail.com  Thu Nov  5 13:17:19 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Thu, 5 Nov 2015 16:47:19 +0330
Subject: Implied readability + layers
Message-ID: <CAA0cW5BbQzO7Gh-K_R4Nf07-oRUrxnhSx1=uQQwMsZLZ=NPymQ@mail.gmail.com>

Hi,

On Thu, Nov 5, 2015 at 3:08 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 05/11/2015 09:30, Ali Ebrahimi wrote:
>
> Hi alan,
> So far quite disappointing!
>
>
> In this example then com.baz in layer1 doesn't know anything about
> com.bar at 2 or other modules that comes into existence in future "child"
> layers, at least not statically.
>

I know that and may be even com.baz not compatible with com.bar at 2. So I
don't expect sublayers's modules propagated in parent layers.
However, in current design we don't involve module version in declaration
of dependence and I think that is good decision.
So my assumption is:

The readability graph for configuration1 is:
  com.bar at 1 reads java.base
  com.baz reads com.bar at 1
The readability graph for configuration2 is:
  com.bar at 2 requires java.base
  com.foo reads java.base
  com.foo reads com.baz
  com.foo reads com.bar at 2


> com.baz does read com.bar at 1 and as it declares "requires public com.bar"
> then I assume com.baz's exported API must have com.bar at 1 types in its
> method signatories. This will usually be good for other modules in layer1
> or modules in descendants of layer1 that use the com.baz API.
>
This does not affect modules belong layerx < layer2 so can be happy.
If API usage of com.baz in com.foo does not contain any type of com.bar you
wouldn't have any issue, otherwise com.foo must live on layer1.


> Creating a new layer2 does not change modules in other layers. This means
> that creating layer2 will not change com.baz (in layer1) to read com.bar at 2
> (in layer2). It is of course possible for com.baz to opt-in and
> reflectively to read com.bar at 2 but great care is required (static
> references in code in com.baz will presumably resolve to types in com.bar at 1
> ).
>
See above.


>
>
>
> This scenario would have many usages in future when world would filled
> with modules and developers would have to use newer versions of modules to
> fix bugs.
> What if com.foo compiled against com.bar at 2? adding redundant requires com.bar
> in com.foo does not help and my app will fail.
>
> Assuming com.bar at 1 and com.bar at 2 export the same packages then it should
> fail when you attempt to create the Configuration for layer2 as com.foo
> cannot read both.
>

I think this is reasonable that when executing bytecode belong to layer2
(com.foo or com.poo) that request for types of module com.foo we pick from
com.bar at 2.


> In this example then you might consider a new instance of module com.baz
> in layer2. That way, layer2 would have com.foo, com.baz and com.bar at 2.
>

If I'm not owner of com.baz or what do for com.baz dependent modules

I think we have tree possible choices:
1) pick com.bar at 1 for layer1 and layer2
2) pick com.bar at 1 for layer1 and com.bar at 1 for layer2
3) pick com.bar at 2 for layer1 and layer2

I think 2 would be best and flexible choice.


Best Regards,
Ali Ebrahimi

From ali.ebrahimi1781 at gmail.com  Thu Nov  5 13:24:33 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Thu, 5 Nov 2015 16:54:33 +0330
Subject: Implied readability + layers
In-Reply-To: <563B411E.6050503@oracle.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>
	<CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>
	<563A2BDC.9030202@oracle.com>
	<CAA0cW5Cw2Lcgf765BHE4vhcYd6XGqu0+yOstsHFBHOoMEyLnjQ@mail.gmail.com>
	<563A809F.9020402@oracle.com>
	<CAA0cW5DATqYdbTSUieJSACEU3f4w45mzV4ZKHjc7v=AHwAzb7A@mail.gmail.com>
	<563B185A.8020409@oracle.com>
	<010b01d117b7$bf075d80$3d161880$@oracle.com>
	<563B411E.6050503@oracle.com>
Message-ID: <CAA0cW5AcbkER-n5CxsW8Y-pG5tgUUFGZybxex=A_TUX_qVh9uA@mail.gmail.com>

Hi,

On Thu, Nov 5, 2015 at 3:14 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 05/11/2015 10:49, Frank Yuan wrote:
>
>> :
>> Generally, m2 at 1 and m2 at 2 are different versions of a same component. So
>> essentially a module M cannot read duplicate types/modules, except only use
>> reflection to access, right?
>>
>> Yes, assuming m2 at 1 and m2 at 2 export the same package to M then it should
> be caught when attempting to create the Configuration. And yes, M can use
> the reflection API to read any other module at run-time.


If m2 at 2 can hide(override) m2 at 1 for M then you don't have duplicates.


-- 

Best Regards,
Ali Ebrahimi

From james.laskey at oracle.com  Thu Nov  5 13:27:24 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Thu, 5 Nov 2015 09:27:24 -0400
Subject: RFR 8141521: jrt file system's DirectoryStream reports child
	paths with wrong paths for directories under /packages
In-Reply-To: <563B254A.7090001@oracle.com>
References: <563B254A.7090001@oracle.com>
Message-ID: <561B12CD-D642-43CF-A444-80BCEAAFDA42@oracle.com>

+1

> On Nov 5, 2015, at 5:45 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8141521/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8141521
> 
> Thanks
> -Sundar


From Alan.Bateman at oracle.com  Thu Nov  5 14:02:47 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 5 Nov 2015 14:02:47 +0000
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5BbQzO7Gh-K_R4Nf07-oRUrxnhSx1=uQQwMsZLZ=NPymQ@mail.gmail.com>
References: <CAA0cW5BbQzO7Gh-K_R4Nf07-oRUrxnhSx1=uQQwMsZLZ=NPymQ@mail.gmail.com>
Message-ID: <563B6187.4030108@oracle.com>



On 05/11/2015 13:17, Ali Ebrahimi wrote:
>
> If API usage of com.baz in com.foo does not contain any type of 
> com.bar you wouldn't have any issue, otherwise com.foo must live on 
> layer1.

Are there com.bar types in com.baz's API? If not then users of com.baz 
need to vigorously lobby the maintainer of com.baz to stop using 
requires public. If com.baz agrees then com.foo will not read com.bar at 1 
and this frees up com.foo to use another version of com.bar in layer2.

On the other hand, if there are com.bar types in com.baz's API then 
com.foo will be exposed to com.bar at 1 types.

-Alan.

From ali.ebrahimi1781 at gmail.com  Thu Nov  5 15:06:11 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Thu, 5 Nov 2015 18:36:11 +0330
Subject: Implied readability + layers
In-Reply-To: <563B6187.4030108@oracle.com>
References: <CAA0cW5BbQzO7Gh-K_R4Nf07-oRUrxnhSx1=uQQwMsZLZ=NPymQ@mail.gmail.com>
	<563B6187.4030108@oracle.com>
Message-ID: <CAA0cW5B6=hRUOHZN0H1dmbToa8UDT7H+wTCxAPDgtwOfwdMJEA@mail.gmail.com>

Hi,

On Thu, Nov 5, 2015 at 5:32 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 05/11/2015 13:17, Ali Ebrahimi wrote:
>
>>
>> If API usage of com.baz in com.foo does not contain any type of com.bar
>> you wouldn't have any issue, otherwise com.foo must live on layer1.
>>
>
> Are there com.bar types in com.baz's API? If not then users of com.baz
> need to vigorously lobby the maintainer of com.baz to stop using requires
> public. If com.baz agrees then com.foo will not read com.bar at 1 and this
> frees up com.foo to use another version of com.bar in layer2.
>
> On the other hand, if there are com.bar types in com.baz's API then
> com.foo will be exposed to com.bar at 1 types.


If com.foo does not use any com.baz's com.bar depend API or com.bar depend
API added latter or requires public in com.baz added later or removed
latter any com.foo may be not aware that, estimating what version of
com.bar for com.foo module that depend on com.bar at 2 would be quite puzzling
and this would be a good candidate for next edition of java puzzlers book.

But with one simple rule "Always current layer's version of module win over
parent layer's one. you don't have unexpected result as in this example
com.bar at 2 may be ignored while com.foo not being aware.

-- 

Best Regards,
Ali Ebrahimi

From jean-francois.denise at oracle.com  Thu Nov  5 15:21:23 2015
From: jean-francois.denise at oracle.com (Jean-Francois Denise)
Date: Thu, 5 Nov 2015 16:21:23 +0100
Subject: RFR 8141521: jrt file system's DirectoryStream reports child
	paths with wrong paths for directories under /packages
In-Reply-To: <561B12CD-D642-43CF-A444-80BCEAAFDA42@oracle.com>
References: <563B254A.7090001@oracle.com>
	<561B12CD-D642-43CF-A444-80BCEAAFDA42@oracle.com>
Message-ID: <0E86B110-DBC4-480D-9A02-3A211DD672EB@oracle.com>

+1, in the test, could you make sure that childCount is not zero?

On 5 Nov 2015, at 14:27, Jim Laskey (Oracle) <james.laskey at oracle.com> wrote:

> +1
> 
>> On Nov 5, 2015, at 5:45 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>> 
>> Please review http://cr.openjdk.java.net/~sundar/8141521/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8141521
>> 
>> Thanks
>> -Sundar
> 


From Alan.Bateman at oracle.com  Thu Nov  5 15:34:19 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 5 Nov 2015 15:34:19 +0000
Subject: RFR 8141521: jrt file system's DirectoryStream reports child
	paths with wrong paths for directories under /packages
In-Reply-To: <563B254A.7090001@oracle.com>
References: <563B254A.7090001@oracle.com>
Message-ID: <563B76FB.4020709@oracle.com>



On 05/11/2015 09:45, Sundararajan Athijegannathan wrote:
> Please review http://cr.openjdk.java.net/~sundar/8141521/webrev.00/ 
> for https://bugs.openjdk.java.net/browse/JDK-8141521
The NodeAndImage.symLink field looks very strange as a DirectoryStream 
just needs the names of the entries where each is resolved against the 
Path that newDirectoryStream is called on. I just wonder how it works 
with a combination of "." and ".." and other interesting paths.

In the test then shouldn't L608 be child.startsWith(path) as this should 
not be a String comparison. I also wonder having a much more expanded 
test for newDirectoryStream as this should have been caught by unit tests.

BTW: A small request but would it be possible to reduce the length of 
the some of the really long lines. It makes it a bit easier to do 
side-by-side reviews when there isn't horizontal scrolling.

-Alan

From Alan.Bateman at oracle.com  Thu Nov  5 15:45:19 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 5 Nov 2015 15:45:19 +0000
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5B6=hRUOHZN0H1dmbToa8UDT7H+wTCxAPDgtwOfwdMJEA@mail.gmail.com>
References: <CAA0cW5BbQzO7Gh-K_R4Nf07-oRUrxnhSx1=uQQwMsZLZ=NPymQ@mail.gmail.com>
	<563B6187.4030108@oracle.com>
	<CAA0cW5B6=hRUOHZN0H1dmbToa8UDT7H+wTCxAPDgtwOfwdMJEA@mail.gmail.com>
Message-ID: <563B798F.2090703@oracle.com>

On 05/11/2015 15:06, Ali Ebrahimi wrote:
> :
> If com.foo does not use any com.baz's com.bar depend API or com.bar 
> depend API added latter or requires public in com.baz added later or 
> removed latter any com.foo may be not aware that, estimating what 
> version of com.bar for com.foo module that depend on com.bar at 2 would 
> be quite puzzling and this would be a good candidate for next edition 
> of java puzzlers book.

Right, module maintainers will need to consider the compatibility impact 
of dropping requires public. If the motivation is that they are removing 
APIs then they are likely breaking users of the API anyway.

-Alan

From rahman.usta.88 at gmail.com  Thu Nov  5 18:28:33 2015
From: rahman.usta.88 at gmail.com (Rahman USTA)
Date: Thu, 5 Nov 2015 20:28:33 +0200
Subject: Accessing JavaFX' StageHelper and ContextMenuContent in Jigsaw
Message-ID: <CAGe7fv1rN9qPGzA64ZvPGJv243tnVHFyF9sVfKS+=OzmrUwf7g@mail.gmail.com>

Hi all;

I'm trying Jigsaw build with my JavaFX project, everything is fine but with
two exception.

javac could not find/access
com.sun.javafx.scene.control.skin.ContextMenuContent
and com.sun.javafx.stage.StageHelper classes.

Is it possible to use them or are there any alternatives for these classes.

Thanks.

-- 
Rahman USTA
Istanbul JUG
https://github.com/rahmanusta <http://www.kodcu.com/>

From ali.ebrahimi1781 at gmail.com  Thu Nov  5 18:39:51 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Thu, 5 Nov 2015 22:09:51 +0330
Subject: Implied readability + layers
In-Reply-To: <563B798F.2090703@oracle.com>
References: <CAA0cW5BbQzO7Gh-K_R4Nf07-oRUrxnhSx1=uQQwMsZLZ=NPymQ@mail.gmail.com>
	<563B6187.4030108@oracle.com>
	<CAA0cW5B6=hRUOHZN0H1dmbToa8UDT7H+wTCxAPDgtwOfwdMJEA@mail.gmail.com>
	<563B798F.2090703@oracle.com>
Message-ID: <CAA0cW5BA7kG9udcciCO725CMhfPZw4Ecdydg5xh=jqumwEWQ9Q@mail.gmail.com>

Hi,
So with current implementation of Implied readability w.r.t. layers and
unexpected consequences of its remove or addition, I strongly propose to
drop it from current design.

On Thu, Nov 5, 2015 at 7:15 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 05/11/2015 15:06, Ali Ebrahimi wrote:
>
>> :
>> If com.foo does not use any com.baz's com.bar depend API or com.bar
>> depend API added latter or requires public in com.baz added later or
>> removed latter any com.foo may be not aware that, estimating what version
>> of com.bar for com.foo module that depend on com.bar at 2 would be quite
>> puzzling and this would be a good candidate for next edition of java
>> puzzlers book.
>>
>
> Right, module maintainers will need to consider the compatibility impact
> of dropping requires public. If the motivation is that they are removing
> APIs then they are likely breaking users of the API anyway.

 How about adding requires public to M2 and can you say how many modules
may fail.

I don't understand this strict rule that all consumers of M2 and consumers
of consumers of M2 should lock to same version of com.bar.

-- 

Best Regards,
Ali Ebrahimi

From alex.buckley at oracle.com  Thu Nov  5 18:44:36 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 05 Nov 2015 10:44:36 -0800
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5ChHpORsH3Z72Yzk98cn5Mutopyjoo8LTdetAQyP3G__Q@mail.gmail.com>
References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com>	<CAA0cW5DTMTkj+_paM3YbNm9FNQRxA=X6wdzJkQsGhuvxJ37YJw@mail.gmail.com>	<563A2BDC.9030202@oracle.com>	<CAA0cW5Cw2Lcgf765BHE4vhcYd6XGqu0+yOstsHFBHOoMEyLnjQ@mail.gmail.com>	<563A809F.9020402@oracle.com>	<CAA0cW5DATqYdbTSUieJSACEU3f4w45mzV4ZKHjc7v=AHwAzb7A@mail.gmail.com>	<563B185A.8020409@oracle.com>
	<CAA0cW5ChHpORsH3Z72Yzk98cn5Mutopyjoo8LTdetAQyP3G__Q@mail.gmail.com>
Message-ID: <563BA394.80201@oracle.com>

On 11/5/2015 1:30 AM, Ali Ebrahimi wrote:
> Hi alan,
> So far quite disappointing!
>
> But I think Alex's last response on this topic says opposite of this:
>
> "We'll have to think about the implication of com.baz in layer1 sometimes
> offering a 'requires public' on com.bar in layer1, and sometimes offering a
> 'requires public' on com.bar in layer2, depending on who is reading com.baz
> in layer1."

Alan and I have discussed this. It's not possible for com.baz in layer1 
to "switch" which com.bar it depends on. There are two reasons.

First, in some loader of layer1, code in com.baz refers to a type 
exported by com.bar at 1, and thus triggers class loading of that type from 
whichever class loader in layer1 is responsible for loading com.bar at 1. 
The loader for com.baz will be marked by the JVM as an "initiating 
loader" for the type -- see JVMS8 5.3.2 -- so any further execution of 
code in com.baz that refers to the type will get the same class as 
initially loaded (from com.bar at 1). There is no way around this.

Second, when code in com.foo calls code in com.baz, the callee has no 
idea who the caller is. The bytecodes for method invocation don't pass 
that information. Since code in com.baz doesn't know the caller is 
com.foo in layer2, there is no possibility of com.baz "switching" to 
invoke code in com.bar at 2 in layer2 rather than com.bar at 1 in layer1.

It would be possible to write code in com.baz that reflectively detects 
its caller, then reflectively invokes code in either com.bar at 2 or 
com.bar at 1, never referring to exported types of any com.bar module via 
the constant pool. If you do this, good luck with all the mental 
accounting -- it's not a sane technique to build into the module system. 
Since layers can come and go, it makes sense for the module system to 
isolate code in a parent layer (com.baz in layer1) from the comings and 
goings of code in a child layer (com.bar in layer2).

> In this case adding  'requires public' on com.bar in layer2 does not mean
> we should pick com.bar at 2 for com,foo?
> This scenario would have many usages in future when world would filled with
> modules and developers would have to use newer versions of modules to fix
> bugs.
> What if com.foo compiled against com.bar at 2? adding redundant requires com.bar
> in com.foo does not help and my app will fail.
> So what is advantage of multiple layers?

Inconsistent separate compilation has caused problems at run time since 
1995. I was very clear in "Project Jigsaw: Under The Hood" that mixing 
multiple versions of a module must not be done casually.

What layers give to a managed runtime (e.g. an app server) is i) freedom 
to map modules to loaders (not only 1:1 but also n:1 and n:m), and ii) 
freedom to isolate different versions of modules from each other (see 
slide 55 in 
http://openjdk.java.net/projects/jigsaw/j1/jigsaw-under-the-hood-j1-2015.pdf).

Alex



From jonathan.gibbons at oracle.com  Thu Nov  5 18:50:15 2015
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 05 Nov 2015 18:50:15 +0000
Subject: hg: jigsaw/jake/langtools: 2 new changesets
Message-ID: <201511051850.tA5IoFOa024735@aojmv0008.oracle.com>

Changeset: 755579d808dc
Author:    alundblad
Date:      2015-11-05 10:49 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/755579d808dc

add missing methods in ForwardingFileManager

! src/java.compiler/share/classes/javax/tools/ForwardingJavaFileManager.java

Changeset: 76aeac001089
Author:    jjg
Date:      2015-11-05 10:49 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/76aeac001089

allow for new jtreg naming convention for patches

! test/tools/lib/ToolBox.java


From kevin.rushforth at oracle.com  Thu Nov  5 19:51:15 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 05 Nov 2015 11:51:15 -0800
Subject: Accessing JavaFX' StageHelper and ContextMenuContent in Jigsaw
In-Reply-To: <CAGe7fv1rN9qPGzA64ZvPGJv243tnVHFyF9sVfKS+=OzmrUwf7g@mail.gmail.com>
References: <CAGe7fv1rN9qPGzA64ZvPGJv243tnVHFyF9sVfKS+=OzmrUwf7g@mail.gmail.com>
Message-ID: <563BB333.3050606@oracle.com>

The StageHelper class is deliberately not exposed for good reasons, 
since it's purpose is to provide internal access to non-public state.

We moved most of the skin classes to a publicly exported 
javafx.scene.control.skin package as part of JEP 253, but that didn't 
include ContextMenuContent.

Can you explain what you are trying to do with these classes? Perhaps 
there is an alternative? If this is a detailed JavaFX question, then I 
suggest asking it on openjfx-dev rather than jigsaw-dev.

-- Kevin


Rahman USTA wrote:
> Hi all;
>
> I'm trying Jigsaw build with my JavaFX project, everything is fine but with
> two exception.
>
> javac could not find/access
> com.sun.javafx.scene.control.skin.ContextMenuContent
> and com.sun.javafx.stage.StageHelper classes.
>
> Is it possible to use them or are there any alternatives for these classes.
>
> Thanks.
>
>   

From peter.levart at gmail.com  Thu Nov  5 20:13:16 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 5 Nov 2015 21:13:16 +0100
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5BA7kG9udcciCO725CMhfPZw4Ecdydg5xh=jqumwEWQ9Q@mail.gmail.com>
References: <CAA0cW5BbQzO7Gh-K_R4Nf07-oRUrxnhSx1=uQQwMsZLZ=NPymQ@mail.gmail.com>
	<563B6187.4030108@oracle.com>
	<CAA0cW5B6=hRUOHZN0H1dmbToa8UDT7H+wTCxAPDgtwOfwdMJEA@mail.gmail.com>
	<563B798F.2090703@oracle.com>
	<CAA0cW5BA7kG9udcciCO725CMhfPZw4Ecdydg5xh=jqumwEWQ9Q@mail.gmail.com>
Message-ID: <563BB85C.3030407@gmail.com>



On 11/05/2015 07:39 PM, Ali Ebrahimi wrote:
> Hi,
> So with current implementation of Implied readability w.r.t. layers and
> unexpected consequences of its remove or addition, I strongly propose to
> drop it from current design.

Unless the rule is very simple. The implied readability should be no 
different than explicit readability. The following situation:

module foo {
     requires public bar;
     ...
}

module baz {
     requires foo;
     ...
}

Should behave exactly like the following:

module foo {
     requires bar;
     ...
}

module baz {
     requires foo;
     requires bar;
     ...
}


...in all possible configurations of layers and classloaders.

If implied readability is taken "symbolically", the same caveats apply 
to one or the other form - they are just different forms of expressing 
the same thing.

Regards, Peter

> On Thu, Nov 5, 2015 at 7:15 PM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 05/11/2015 15:06, Ali Ebrahimi wrote:
>>
>>> :
>>> If com.foo does not use any com.baz's com.bar depend API or com.bar
>>> depend API added latter or requires public in com.baz added later or
>>> removed latter any com.foo may be not aware that, estimating what version
>>> of com.bar for com.foo module that depend on com.bar at 2 would be quite
>>> puzzling and this would be a good candidate for next edition of java
>>> puzzlers book.
>>>
>> Right, module maintainers will need to consider the compatibility impact
>> of dropping requires public. If the motivation is that they are removing
>> APIs then they are likely breaking users of the API anyway.
>   How about adding requires public to M2 and can you say how many modules
> may fail.
>
> I don't understand this strict rule that all consumers of M2 and consumers
> of consumers of M2 should lock to same version of com.bar.
>


From ali.ebrahimi1781 at gmail.com  Thu Nov  5 20:42:43 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Fri, 6 Nov 2015 00:12:43 +0330
Subject: Implied readability + layers
Message-ID: <CAA0cW5Dr5SmrnXkFuQuKmBkoKJcw5uvtQhhn-Yrkg_HJ-pLBqw@mail.gmail.com>

Hi,

On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart <peter.levart at gmail.com>
wrote:

>
>
> On 11/05/2015 07:39 PM, Ali Ebrahimi wrote:
>
> Hi,
> So with current implementation of Implied readability w.r.t. layers and
> unexpected consequences of its remove or addition, I strongly propose to
> drop it from current design.
>
>
> Unless the rule is very simple. The implied readability should be no
> different than explicit readability.
>
> ...in all possible configurations of layers and classloaders.
>

Exactly. I agree.
Now suppose we have foo, bar at 1 in layer1 and baz and bar at 2 in layer2.

situation1:

module foo {
    requires public bar;
    ...
}

module baz {
    requires foo;
    ...
}

The readability graph for configuration1/layer1 is:
  bar at 1 reads java.base
  foo reads java.base
  foo reads bar at 1

The readability graph for configuration2/layer2 is:
 bar at 2 reads java.base
 baz reads foo
 baz reads bar at 1==================

But situation2:
module foo {
    requires bar;
    ...
}

module baz {
    requires foo;
    requires bar;
    ...
}

The readability graph for configuration1/layer1 is:
  bar at 1 reads java.base
  foo reads java.base
  foo reads bar at 1

The readability graph for configuration2/layer2 is:
 bar at 2 reads java.base
 baz reads foo
 baz reads bar at 2==================



> If implied readability is taken "symbolically", the same caveats apply to
> one or the other form - they are just different forms of expressing the
> same thing.
>
As you can see this is currently is not case.

But with one simple rule "Always current layer's version of module win over
parent layer's one" we would have same readability graphs for both
situations.



-- 

Best Regards,
Ali Ebrahimi

From rahman.usta.88 at gmail.com  Thu Nov  5 20:59:14 2015
From: rahman.usta.88 at gmail.com (Rahman USTA)
Date: Thu, 5 Nov 2015 22:59:14 +0200
Subject: Accessing JavaFX' StageHelper and ContextMenuContent in Jigsaw
In-Reply-To: <563BB333.3050606@oracle.com>
References: <CAGe7fv1rN9qPGzA64ZvPGJv243tnVHFyF9sVfKS+=OzmrUwf7g@mail.gmail.com>
	<563BB333.3050606@oracle.com>
Message-ID: <CAGe7fv16G1pGU=TSSMrfK=q-CtAjbDJbVUAUcVYdY6KjVpBQpw@mail.gmail.com>

I'm using ContextMenuContent to add new menu items to webview's default
context menu. I can set a new ContextMenu for Webviews but, I want to use
actions of default menuitems as well. Code
<https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu/component/ViewPanel.java#L95-L127>

I'm doing something when application focus-out, but when an JavaFX Alert is
shown, it acts as focus-out, to avoid this circumstances I'm using
StageHelper Code
<https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu/controller/ApplicationController.java#L1037-L1043>

Note: I can also ask the question to openjfx-dev

2015-11-05 21:51 GMT+02:00 Kevin Rushforth <kevin.rushforth at oracle.com>:

> The StageHelper class is deliberately not exposed for good reasons, since
> it's purpose is to provide internal access to non-public state.
>
> We moved most of the skin classes to a publicly exported
> javafx.scene.control.skin package as part of JEP 253, but that didn't
> include ContextMenuContent.
>
> Can you explain what you are trying to do with these classes? Perhaps
> there is an alternative? If this is a detailed JavaFX question, then I
> suggest asking it on openjfx-dev rather than jigsaw-dev.
>
> -- Kevin
>
>
>
> Rahman USTA wrote:
>
>> Hi all;
>>
>> I'm trying Jigsaw build with my JavaFX project, everything is fine but
>> with
>> two exception.
>>
>> javac could not find/access
>> com.sun.javafx.scene.control.skin.ContextMenuContent
>> and com.sun.javafx.stage.StageHelper classes.
>>
>> Is it possible to use them or are there any alternatives for these
>> classes.
>>
>> Thanks.
>>
>>
>>
>


-- 
Rahman USTA
Istanbul JUG
https://github.com/rahmanusta <http://www.kodcu.com/>

From peter.levart at gmail.com  Thu Nov  5 21:15:15 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 5 Nov 2015 22:15:15 +0100
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5Dr5SmrnXkFuQuKmBkoKJcw5uvtQhhn-Yrkg_HJ-pLBqw@mail.gmail.com>
References: <CAA0cW5Dr5SmrnXkFuQuKmBkoKJcw5uvtQhhn-Yrkg_HJ-pLBqw@mail.gmail.com>
Message-ID: <563BC6E3.1090903@gmail.com>



On 11/05/2015 09:42 PM, Ali Ebrahimi wrote:
> Hi,
>
> On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>> wrote:
>
>
>
>     On 11/05/2015 07:39 PM, Ali Ebrahimi wrote:
>>     Hi,
>>     So with current implementation of Implied readability w.r.t. layers and
>>     unexpected consequences of its remove or addition, I strongly propose to
>>     drop it from current design.
>
>     Unless the rule is very simple. The implied readability should be
>     no different than explicit readability.
>
>     ...in all possible configurations of layers and classloaders.
>
> Exactly. I agree.
> Now suppose we have foo, bar at 1 in layer1 and baz and bar at 2 in layer2.
>
> situation1:
>
> module foo {
>     requires public bar;
>     ...
> }
>
> module baz {
>     requires foo;
>     ...
> }
>
> The readability graph for configuration1/layer1 is:
>   bar at 1 reads java.base
>   foo reads java.base
>   foo reads bar at 1
>
> The readability graph for configuration2/layer2 is:
>  bar at 2 reads java.base
>  baz reads foo
>  baz reads bar at 1==================
>
> But situation2:
> module foo {
> requires bar;
>     ...
> }
>
> module baz {
> requires foo;
> requires bar;
>     ...
> }
>
> The readability graph for configuration1/layer1 is:
>   bar at 1 reads java.base
>   foo reads java.base
>   foo reads bar at 1
>
> The readability graph for configuration2/layer2 is:
>  bar at 2 reads java.base
>  baz reads foo
>  baz reads bar at 2==================
>
>
>
>     If implied readability is taken "symbolically", the same caveats
>     apply to one or the other form - they are just different forms of
>     expressing the same thing.
>
> As you can see this is currently is not case.

What I'm trying to say is that it should be the same. situation1 should 
construct the same readability graph as situation2 (which is the right one).

>
> But with one simple rule "Always current layer's version of module win 
> over parent layer's one" we would have same readability graphs for 
> both situations.

Right. I would say it even simpler: take the implicitly and explicitly 
required module names "symbolically" and evaluate them in the context of 
each module.

This way adding a "public" keyword is always safe and the existence of 
"public" keyword can not harm anybody. Removing it is of course not safe 
and can not be made safe.

Regards, Peter

>
>
>
> -- 
>
> Best Regards,
> Ali Ebrahimi


From alex.buckley at oracle.com  Thu Nov  5 21:21:19 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 05 Nov 2015 13:21:19 -0800
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5Dr5SmrnXkFuQuKmBkoKJcw5uvtQhhn-Yrkg_HJ-pLBqw@mail.gmail.com>
References: <CAA0cW5Dr5SmrnXkFuQuKmBkoKJcw5uvtQhhn-Yrkg_HJ-pLBqw@mail.gmail.com>
Message-ID: <563BC84F.2070503@oracle.com>

On 11/5/2015 12:42 PM, Ali Ebrahimi wrote:
> On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart <peter.levart at gmail.com>
> wrote:
>> On 11/05/2015 07:39 PM, Ali Ebrahimi wrote:
>> So with current implementation of Implied readability w.r.t. layers and
>> unexpected consequences of its remove or addition, I strongly propose to
>> drop it from current design.
>>
>> Unless the rule is very simple. The implied readability should be no
>> different than explicit readability.
>>
>> ...in all possible configurations of layers and classloaders.
>>
>
> Exactly. I agree.
> Now suppose we have foo, bar at 1 in layer1 and baz and bar at 2 in layer2.
>
> situation1:
>
> module foo {
>      requires public bar;
>      ...
> }
>
> module baz {
>      requires foo;
>      ...
> }
>
> The readability graph for configuration1/layer1 is:
>    bar at 1 reads java.base
>    foo reads java.base
>    foo reads bar at 1
>
> The readability graph for configuration2/layer2 is:
>   bar at 2 reads java.base
>   baz reads foo
>   baz reads bar at 1==================
>
> But situation2:
> module foo {
>      requires bar;
>      ...
> }
>
> module baz {
>      requires foo;
>      requires bar;
>      ...
> }
>
> The readability graph for configuration1/layer1 is:
>    bar at 1 reads java.base
>    foo reads java.base
>    foo reads bar at 1
>
> The readability graph for configuration2/layer2 is:
>   bar at 2 reads java.base
>   baz reads foo
>   baz reads bar at 2==================
>
>> If implied readability is taken "symbolically", the same caveats apply to
>> one or the other form - they are just different forms of expressing the
>> same thing.
>>
> As you can see this is currently is not case.

It is the case for modules in the same layer. For modules in different 
layers, the fundamental design of class loading (initiating loader v. 
defining loader) means that explicit readability within a layer 
"dominates" implicit readability across layers. A redesign of class 
loading is not on the table, so anyone creating layers has to carefully 
track the cross-layer dependencies, just like they have to carefully 
manage the module->loader mapping.

Alex

From alex.buckley at oracle.com  Thu Nov  5 21:39:24 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 05 Nov 2015 13:39:24 -0800
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5BA7kG9udcciCO725CMhfPZw4Ecdydg5xh=jqumwEWQ9Q@mail.gmail.com>
References: <CAA0cW5BbQzO7Gh-K_R4Nf07-oRUrxnhSx1=uQQwMsZLZ=NPymQ@mail.gmail.com>	<563B6187.4030108@oracle.com>	<CAA0cW5B6=hRUOHZN0H1dmbToa8UDT7H+wTCxAPDgtwOfwdMJEA@mail.gmail.com>	<563B798F.2090703@oracle.com>
	<CAA0cW5BA7kG9udcciCO725CMhfPZw4Ecdydg5xh=jqumwEWQ9Q@mail.gmail.com>
Message-ID: <563BCC8C.1000004@oracle.com>

On 11/5/2015 10:39 AM, Ali Ebrahimi wrote:
> Hi,
> So with current implementation of Implied readability w.r.t. layers and
> unexpected consequences of its remove or addition, I strongly propose to
> drop it from current design.
>
> On Thu, Nov 5, 2015 at 7:15 PM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 05/11/2015 15:06, Ali Ebrahimi wrote:
>>
>>> :
>>> If com.foo does not use any com.baz's com.bar depend API or com.bar
>>> depend API added latter or requires public in com.baz added later or
>>> removed latter any com.foo may be not aware that, estimating what version
>>> of com.bar for com.foo module that depend on com.bar at 2 would be quite
>>> puzzling and this would be a good candidate for next edition of java
>>> puzzlers book.
>>>
>>
>> Right, module maintainers will need to consider the compatibility impact
>> of dropping requires public. If the motivation is that they are removing
>> APIs then they are likely breaking users of the API anyway.
>
>   How about adding requires public to M2 and can you say how many modules
> may fail.
>
> I don't understand this strict rule that all consumers of M2 and consumers
> of consumers of M2 should lock to same version of com.bar.

A single version of com.bar in a program is strongly presumed to be 
better than multiple versions of com.bar in a program.

I showed elsewhere that explicit readability within a parent layer 
causes class loading to behave in such a way that modules in a child 
layer cannot override modules in the parent layer. That's just how the 
JVM works. Sometimes that will rear its head as "consumers of M2 are 
locked to the same com.bar as consumers of consumers of M2", sometimes 
it won't, depending on which layers have which modules. But unlimited 
support for multiple versions in all possible layer arrangements is not 
a goal.

Alex

From kevin.rushforth at oracle.com  Thu Nov  5 21:41:12 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 05 Nov 2015 13:41:12 -0800
Subject: Accessing JavaFX' StageHelper and ContextMenuContent in Jigsaw
In-Reply-To: <CAGe7fv16G1pGU=TSSMrfK=q-CtAjbDJbVUAUcVYdY6KjVpBQpw@mail.gmail.com>
References: <CAGe7fv1rN9qPGzA64ZvPGJv243tnVHFyF9sVfKS+=OzmrUwf7g@mail.gmail.com>
	<563BB333.3050606@oracle.com>
	<CAGe7fv16G1pGU=TSSMrfK=q-CtAjbDJbVUAUcVYdY6KjVpBQpw@mail.gmail.com>
Message-ID: <563BCCF8.5010906@oracle.com>

Yes, this is case of your using internal classes and unsupported 
methods, so let's discuss on openjfx-dev to see if there is another way 
to do what you want to do. I note that in addition to the two internal 
classes, you are also accessing a non-supported (and not documented) 
impl_* method which may or may not continue to work.

-- Kevin


Rahman USTA wrote:
> I'm using ContextMenuContent to add new menu items to webview's 
> default context menu. I can set a new ContextMenu for Webviews but, I 
> want to use actions of default menuitems as well. Code 
> <https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu/component/ViewPanel.java#L95-L127> 
>
>
> I'm doing something when application focus-out, but when an JavaFX 
> Alert is shown, it acts as focus-out, to avoid this circumstances I'm 
> using StageHelper Code 
> <https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu/controller/ApplicationController.java#L1037-L1043>
>
> Note: I can also ask the question to openjfx-dev
>
> 2015-11-05 21:51 GMT+02:00 Kevin Rushforth <kevin.rushforth at oracle.com 
> <mailto:kevin.rushforth at oracle.com>>:
>
>     The StageHelper class is deliberately not exposed for good
>     reasons, since it's purpose is to provide internal access to
>     non-public state.
>
>     We moved most of the skin classes to a publicly exported
>     javafx.scene.control.skin package as part of JEP 253, but that
>     didn't include ContextMenuContent.
>
>     Can you explain what you are trying to do with these classes?
>     Perhaps there is an alternative? If this is a detailed JavaFX
>     question, then I suggest asking it on openjfx-dev rather than
>     jigsaw-dev.
>
>     -- Kevin
>
>
>
>     Rahman USTA wrote:
>
>         Hi all;
>
>         I'm trying Jigsaw build with my JavaFX project, everything is
>         fine but with
>         two exception.
>
>         javac could not find/access
>         com.sun.javafx.scene.control.skin.ContextMenuContent
>         and com.sun.javafx.stage.StageHelper classes.
>
>         Is it possible to use them or are there any alternatives for
>         these classes.
>
>         Thanks.
>
>          
>
>
>
>
> -- 
> Rahman USTA
> Istanbul JUG
> https://github.com/rahmanusta <http://www.kodcu.com/>

From ali.ebrahimi1781 at gmail.com  Thu Nov  5 22:02:00 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Fri, 6 Nov 2015 01:32:00 +0330
Subject: Implied readability + layers
Message-ID: <CAA0cW5DonH361gN6MXR84P+S9w8jv-4pgdF6uWo6jcd+YkNbnA@mail.gmail.com>

Hi,

On Thu, Nov 5, 2015 at 10:14 PM, Alex Buckley <alex.buckley at oracle.com>
wrote:

> On 11/5/2015 1:30 AM, Ali Ebrahimi wrote:
>
>> Hi alan,
>> So far quite disappointing!
>>
>> But I think Alex's last response on this topic says opposite of this:
>>
>> "We'll have to think about the implication of com.baz in layer1 sometimes
>> offering a 'requires public' on com.bar in layer1, and sometimes offering
>> a
>> 'requires public' on com.bar in layer2, depending on who is reading
>> com.baz
>> in layer1."
>>
>
> Alan and I have discussed this. It's not possible for com.baz in layer1 to
> "switch" which com.bar it depends on.


I never said we do version switch for com.bar in com.baz in layer1 depend
on its consumer module.
I just say we use com.bar at 1 for layer1's modules and com.bar at 2 for layer2's
modules.
You may say it is possible (not always) com.bar at 1 passed to layer2 and we
what we can do.
This is simple: Or transfer com.foo to layer1 or refactor that to 2 module
com.foobaz and com.foobar2 and transfer com.foobaz to layer1.

See my previous posts for current implementation unexpected results.

This is simple for all module system and module developers module and
module consumers  and there would not be any puzzle.

-- 

Best Regards,
Ali Ebrahimi

From harold.seigel at oracle.com  Thu Nov  5 22:19:42 2015
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Thu, 05 Nov 2015 22:19:42 +0000
Subject: hg: jigsaw/jake/hotspot: Make ModuleEntry hashtable lookup more
	efficient.
Message-ID: <201511052219.tA5MJgWf011362@aojmv0008.oracle.com>

Changeset: e2f40992e003
Author:    hseigel
Date:      2015-11-05 16:58 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e2f40992e003

Make ModuleEntry hashtable lookup more efficient.

! src/share/vm/classfile/moduleEntry.cpp


From peter.levart at gmail.com  Thu Nov  5 22:28:10 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 5 Nov 2015 23:28:10 +0100
Subject: Implied readability + layers
In-Reply-To: <563BC84F.2070503@oracle.com>
References: <CAA0cW5Dr5SmrnXkFuQuKmBkoKJcw5uvtQhhn-Yrkg_HJ-pLBqw@mail.gmail.com>
	<563BC84F.2070503@oracle.com>
Message-ID: <563BD7FA.3010602@gmail.com>



On 11/05/2015 10:21 PM, Alex Buckley wrote:
> On 11/5/2015 12:42 PM, Ali Ebrahimi wrote:
>> On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart <peter.levart at gmail.com>
>> wrote:
>>> On 11/05/2015 07:39 PM, Ali Ebrahimi wrote:
>>> So with current implementation of Implied readability w.r.t. layers and
>>> unexpected consequences of its remove or addition, I strongly 
>>> propose to
>>> drop it from current design.
>>>
>>> Unless the rule is very simple. The implied readability should be no
>>> different than explicit readability.
>>>
>>> ...in all possible configurations of layers and classloaders.
>>>
>>
>> Exactly. I agree.
>> Now suppose we have foo, bar at 1 in layer1 and baz and bar at 2 in layer2.
>>
>> situation1:
>>
>> module foo {
>>      requires public bar;
>>      ...
>> }
>>
>> module baz {
>>      requires foo;
>>      ...
>> }
>>
>> The readability graph for configuration1/layer1 is:
>>    bar at 1 reads java.base
>>    foo reads java.base
>>    foo reads bar at 1
>>
>> The readability graph for configuration2/layer2 is:
>>   bar at 2 reads java.base
>>   baz reads foo
>>   baz reads bar at 1==================
>>
>> But situation2:
>> module foo {
>>      requires bar;
>>      ...
>> }
>>
>> module baz {
>>      requires foo;
>>      requires bar;
>>      ...
>> }
>>
>> The readability graph for configuration1/layer1 is:
>>    bar at 1 reads java.base
>>    foo reads java.base
>>    foo reads bar at 1
>>
>> The readability graph for configuration2/layer2 is:
>>   bar at 2 reads java.base
>>   baz reads foo
>>   baz reads bar at 2==================
>>
>>> If implied readability is taken "symbolically", the same caveats 
>>> apply to
>>> one or the other form - they are just different forms of expressing the
>>> same thing.
>>>
>> As you can see this is currently is not case.
>
> It is the case for modules in the same layer. For modules in different 
> layers, the fundamental design of class loading (initiating loader v. 
> defining loader) means that explicit readability within a layer 
> "dominates" implicit readability across layers. 

You mean explicit readability within a layer must dominate implicit 
readability across layers unless we want the possibility of strange 
ClassCastExceptions like "com.bar.Type can not be cast to com.bar.Type"  
and similar?

So what is written in javadoc for:

     public static Configuration resolve(ModuleFinder beforeFinder,
                                         Layer parent,
                                         ModuleFinder afterFinder,
                                         Collection<String> roots)

      * <p> Each root module is located using the given {@code beforeFinder}
      * and if not found, using the given {@code afterFinder}. Their 
transitive
      * dependences are located using the given {@code beforeFinder}, or 
if not
      * found then the parent {@code Layer}, or if not found then the given
      * {@code afterFinder}. Dependences located in the parent {@code Layer}
      * are resolved no further. </p>

...is true only for explicit dependencies? If "transitive" dependency is 
implicit, then the order is: parent Layer, beforeFinder, afterFinder ?

Or is it just so that the module definition is searched in the specified 
order, but classes are always loaded according to ClassLoader hierarchy 
and their delegation strategy, regardless of Layer configurations that 
just sit above them and must be aligned with them?

So we can achieve the desired effect if we construct our own 
ClassLoader(s) that delegate according to 
beforeFinder/parentLayer/afterFinder ?

Regards, Peter

> A redesign of class loading is not on the table, so anyone creating 
> layers has to carefully track the cross-layer dependencies, just like 
> they have to carefully manage the module->loader mapping.
>
> Alex


From ali.ebrahimi1781 at gmail.com  Thu Nov  5 22:30:18 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Fri, 6 Nov 2015 02:00:18 +0330
Subject: Implied readability + layers
In-Reply-To: <563BCC8C.1000004@oracle.com>
References: <CAA0cW5BbQzO7Gh-K_R4Nf07-oRUrxnhSx1=uQQwMsZLZ=NPymQ@mail.gmail.com>
	<563B6187.4030108@oracle.com>
	<CAA0cW5B6=hRUOHZN0H1dmbToa8UDT7H+wTCxAPDgtwOfwdMJEA@mail.gmail.com>
	<563B798F.2090703@oracle.com>
	<CAA0cW5BA7kG9udcciCO725CMhfPZw4Ecdydg5xh=jqumwEWQ9Q@mail.gmail.com>
	<563BCC8C.1000004@oracle.com>
Message-ID: <CAA0cW5AfcmOHXzCaZFXZT2e-s7auR=kBuvvsn65AeJjb5NU4MQ@mail.gmail.com>

Hi,

On Fri, Nov 6, 2015 at 1:09 AM, Alex Buckley <alex.buckley at oracle.com>
wrote:

>
>>
> A single version of com.bar in a program is strongly presumed to be better
> than multiple versions of com.bar in a program.
>
In Ideal world this would be perfect.

But, If you use many modules from different third-parties with different
release cycles, things may change and finding this single version may be
impossible.


> I showed elsewhere that explicit readability within a parent layer causes
> class loading to behave in such a way that modules in a child layer cannot
> override modules in the parent layer. That's just how the JVM works.
> Sometimes that will rear its head as "consumers of M2 are locked to the
> same com.bar as consumers of consumers of M2", sometimes it won't,
> depending on which layers have which modules. But unlimited support for
> multiple versions in all possible layer arrangements is not a goal.

If goal is prevent from overriding as for methods in clesses why not use
'final': require final com.bar?


-- 

Best Regards,
Ali Ebrahimi

From alex.buckley at oracle.com  Fri Nov  6 00:39:47 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 05 Nov 2015 16:39:47 -0800
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5DonH361gN6MXR84P+S9w8jv-4pgdF6uWo6jcd+YkNbnA@mail.gmail.com>
References: <CAA0cW5DonH361gN6MXR84P+S9w8jv-4pgdF6uWo6jcd+YkNbnA@mail.gmail.com>
Message-ID: <563BF6D3.3000702@oracle.com>

On 11/5/2015 2:02 PM, Ali Ebrahimi wrote:
> Hi,
>
> On Thu, Nov 5, 2015 at 10:14 PM, Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>
>     On 11/5/2015 1:30 AM, Ali Ebrahimi wrote:
>
>         Hi alan,
>         So far quite disappointing!
>
>         But I think Alex's last response on this topic says opposite of
>         this:
>
>         "We'll have to think about the implication of com.baz in layer1
>         sometimes
>         offering a 'requires public' on com.bar in layer1, and sometimes
>         offering a
>         'requires public' on com.bar in layer2, depending on who is
>         reading com.baz
>         in layer1."
>
>
>     Alan and I have discussed this. It's not possible for com.baz in
>     layer1 to "switch" which com.bar it depends on.
>
> I never said we do version switch for com.bar in com.baz in layer1
> depend on its consumer module.
> I just say we use com.bar at 1 for layer1's modules and com.bar at 2 for
> layer2's modules.

com.foo in layer2 requires com.baz in layer1, right? Yes.

com.baz in layer1 uses types from com.bar in layer1, and NOT from 
com.bar in layer2, right? Yes.

Therefore, com.foo uses types from com.bar in layer1 (as required by 
com.baz in layer1), right? Yes.

I don't know what it means to say "we use com.bar at 2 for layer2's 
modules". com.foo is in layer2, and you can make it read com.bar at 2 via 
reflection, but otherwise com.bar at 2 is not read by com.foo because 
com.baz doesn't know about it.

> You may say it is possible (not always) com.bar at 1 passed to layer2 and
> we what we can do.
> This is simple: Or transfer com.foo to layer1 or refactor that to 2
> module com.foobaz and com.foobar2 and transfer com.foobaz to layer1.

I can't follow the "simple" solution, sorry.

Alex


From alex.buckley at oracle.com  Fri Nov  6 00:53:03 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 05 Nov 2015 16:53:03 -0800
Subject: Implied readability + layers
In-Reply-To: <563BD7FA.3010602@gmail.com>
References: <CAA0cW5Dr5SmrnXkFuQuKmBkoKJcw5uvtQhhn-Yrkg_HJ-pLBqw@mail.gmail.com>
	<563BC84F.2070503@oracle.com> <563BD7FA.3010602@gmail.com>
Message-ID: <563BF9EF.1080605@oracle.com>

On 11/5/2015 2:28 PM, Peter Levart wrote:
> On 11/05/2015 10:21 PM, Alex Buckley wrote:
>>>> If implied readability is taken "symbolically", the same
>>>> caveats apply to one or the other form - they are just
>>>> different forms of expressing the same thing.
>>>>
>>> As you can see this is currently is not case.
>>
>> It is the case for modules in the same layer. For modules in different
>> layers, the fundamental design of class loading (initiating loader v.
>> defining loader) means that explicit readability within a layer
>> "dominates" implicit readability across layers.
>
> You mean explicit readability within a layer must dominate implicit
> readability across layers unless we want the possibility of strange
> ClassCastExceptions like "com.bar.Type can not be cast to com.bar.Type"
> and similar?

Yes.

> So what is written in javadoc for:
>
>      public static Configuration resolve(ModuleFinder beforeFinder,
>                                          Layer parent,
>                                          ModuleFinder afterFinder,
>                                          Collection<String> roots)
>
>       * <p> Each root module is located using the given {@code beforeFinder}
>       * and if not found, using the given {@code afterFinder}. Their
> transitive
>       * dependences are located using the given {@code beforeFinder}, or
> if not
>       * found then the parent {@code Layer}, or if not found then the given
>       * {@code afterFinder}. Dependences located in the parent {@code Layer}
>       * are resolved no further. </p>
>
> ...is true only for explicit dependencies? If "transitive" dependency is
> implicit, then the order is: parent Layer, beforeFinder, afterFinder ?

I believe that "transitive" dependencies means "the set of explicit 
dependencies mentioned by 'requires' clauses all the way down to 
java.base". Implicitly read dependencies appear later, and are dominated 
by the explicit dependencies that have already been resolved.

> Or is it just so that the module definition is searched in the specified
> order, but classes are always loaded according to ClassLoader hierarchy
> and their delegation strategy, regardless of Layer configurations that
> just sit above them and must be aligned with them?

It goes without saying that classes are always loaded according to the 
class loaders' delegation strategy (e.g. "a hierarchy") and the JVM's 
loaded class cache (where the "initiating loader" info I mentioned 
earlier is stored). Layers don't change that, so they need to align with 
loader delegation rather than the other way around.

> So we can achieve the desired effect if we construct our own
> ClassLoader(s) that delegate according to
> beforeFinder/parentLayer/afterFinder ?

I'm not really sure what the desired effect is at this point, but yes 
the loaders passed to a layer should delegate in accordance with the 
resolved graph, and yes the graph would have been resolved on the basis 
of beforeFinder-then-parentLayer-then-afterFinder.

Alex

From alex.buckley at oracle.com  Fri Nov  6 01:10:34 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 05 Nov 2015 17:10:34 -0800
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5AfcmOHXzCaZFXZT2e-s7auR=kBuvvsn65AeJjb5NU4MQ@mail.gmail.com>
References: <CAA0cW5BbQzO7Gh-K_R4Nf07-oRUrxnhSx1=uQQwMsZLZ=NPymQ@mail.gmail.com>	<563B6187.4030108@oracle.com>	<CAA0cW5B6=hRUOHZN0H1dmbToa8UDT7H+wTCxAPDgtwOfwdMJEA@mail.gmail.com>	<563B798F.2090703@oracle.com>	<CAA0cW5BA7kG9udcciCO725CMhfPZw4Ecdydg5xh=jqumwEWQ9Q@mail.gmail.com>	<563BCC8C.1000004@oracle.com>
	<CAA0cW5AfcmOHXzCaZFXZT2e-s7auR=kBuvvsn65AeJjb5NU4MQ@mail.gmail.com>
Message-ID: <563BFE0A.5020505@oracle.com>

On 11/5/2015 2:30 PM, Ali Ebrahimi wrote:
> On Fri, Nov 6, 2015 at 1:09 AM, Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>
>     A single version of com.bar in a program is strongly presumed to be
>     better than multiple versions of com.bar in a program.
>
> In Ideal world this would be perfect.
>
> But, If you use many modules from different third-parties with different
> release cycles, things may change and finding this single version may be
> impossible.

Disagree. Since JDK 1.0, people have been finding this single version by 
putting it earlier on the classpath than other versions. And if other 
versions have been shaded so as to co-exist on the classpath with the 
primary version, then that technique will still work in modules.

There is a requirement to support modules from different third parties: 
http://openjdk.java.net/projects/jigsaw/spec/reqs/#alternate-module-versions-in-dynamic-configurations 
-- but that doesn't mean arbitrary combinations like a module in a child 
layer overriding a module in a parent layer.

Alex

From rahman.usta.88 at gmail.com  Fri Nov  6 10:43:52 2015
From: rahman.usta.88 at gmail.com (Rahman USTA)
Date: Fri, 6 Nov 2015 12:43:52 +0200
Subject: Accessing JavaFX' StageHelper and ContextMenuContent in Jigsaw
In-Reply-To: <563BCCF8.5010906@oracle.com>
References: <CAGe7fv1rN9qPGzA64ZvPGJv243tnVHFyF9sVfKS+=OzmrUwf7g@mail.gmail.com>
	<563BB333.3050606@oracle.com>
	<CAGe7fv16G1pGU=TSSMrfK=q-CtAjbDJbVUAUcVYdY6KjVpBQpw@mail.gmail.com>
	<563BCCF8.5010906@oracle.com>
Message-ID: <CAGe7fv2hDh_2aAtu-xTmwEYkQ5FCwH54dKPmcovAeU44yPyPAQ@mail.gmail.com>

Thank you Kevin, I'll move on openjfx-dev.

2015-11-05 23:41 GMT+02:00 Kevin Rushforth <kevin.rushforth at oracle.com>:

> Yes, this is case of your using internal classes and unsupported methods,
> so let's discuss on openjfx-dev to see if there is another way to do what
> you want to do. I note that in addition to the two internal classes, you
> are also accessing a non-supported (and not documented) impl_* method which
> may or may not continue to work.
>
> -- Kevin
>
>
> Rahman USTA wrote:
>
> I'm using ContextMenuContent to add new menu items to webview's default
> context menu. I can set a new ContextMenu for Webviews but, I want to use
> actions of default menuitems as well. Code
> <https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu/component/ViewPanel.java#L95-L127>
>
> I'm doing something when application focus-out, but when an JavaFX Alert
> is shown, it acts as focus-out, to avoid this circumstances I'm using
> StageHelper Code
> <https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu/controller/ApplicationController.java#L1037-L1043>
>
> Note: I can also ask the question to openjfx-dev
>
> 2015-11-05 21:51 GMT+02:00 Kevin Rushforth <kevin.rushforth at oracle.com>:
>
>> The StageHelper class is deliberately not exposed for good reasons, since
>> it's purpose is to provide internal access to non-public state.
>>
>> We moved most of the skin classes to a publicly exported
>> javafx.scene.control.skin package as part of JEP 253, but that didn't
>> include ContextMenuContent.
>>
>> Can you explain what you are trying to do with these classes? Perhaps
>> there is an alternative? If this is a detailed JavaFX question, then I
>> suggest asking it on openjfx-dev rather than jigsaw-dev.
>>
>> -- Kevin
>>
>>
>>
>> Rahman USTA wrote:
>>
>>> Hi all;
>>>
>>> I'm trying Jigsaw build with my JavaFX project, everything is fine but
>>> with
>>> two exception.
>>>
>>> javac could not find/access
>>> com.sun.javafx.scene.control.skin.ContextMenuContent
>>> and com.sun.javafx.stage.StageHelper classes.
>>>
>>> Is it possible to use them or are there any alternatives for these
>>> classes.
>>>
>>> Thanks.
>>>
>>>
>>>
>>
>
>
> --
> Rahman USTA
> Istanbul JUG
> https://github.com/rahmanusta <http://www.kodcu.com/>
>
>


-- 
Rahman USTA
Istanbul JUG
https://github.com/rahmanusta <http://www.kodcu.com/>

From ali.ebrahimi1781 at gmail.com  Fri Nov  6 10:59:17 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Fri, 6 Nov 2015 14:29:17 +0330
Subject: Implied readability + layers
Message-ID: <CAA0cW5Ch=KRd21h8qko4JB9V0YX2fwXk_OWokcKibC6jhEzpxA@mail.gmail.com>

Hi,

On Fri, Nov 6, 2015 at 4:09 AM, Alex Buckley <alex.buckley at oracle.com>
wrote:
>
>
> com.foo in layer2 requires com.baz in layer1, right? Yes.
>
> com.baz in layer1 uses types from com.bar in layer1, and NOT from com.bar
> in layer2, right? Yes.
>
> Therefore, com.foo uses types from com.bar in layer1 (as required by
> com.baz in layer1), right? Yes.
>
> I don't know what it means to say "we use com.bar at 2 for layer2's
> modules". com.foo is in layer2, and you can make it read com.bar at 2 via
> reflection, but otherwise com.bar at 2 is not read by com.foo because
> com.baz doesn't know about it.

There is no need for reflection:
Please follow this sample and test it:

layer 1: com.baz and com.bar at 1
---------------------------

module com.bar {//version1
    exports com.bar;
}

------------------

//Bar.java

package com.bar;
public class Bar {
    public String bar(){ return "bar1";}
}

module com.baz {
        requires com.bar;
        exports com.baz;
}

-----------------

//Baz.java

package com.baz;

import com.bar.Bar;
public class Baz {
    public String baz(){ return new Bar().bar();}
    public Bar bar(){
        return new Bar();
    }
}

layer 2: com.foo and com.bar at 2
--------------------
 module com.bar {//version2

    exports com.bar;
}

-------------

//Bar.java

package com.bar;

public class Bar {
    public String bar(){ return "bar2";}
}

-------------

module com.foo {
        requires com.baz;

        exports com.foo;

}

-------------

Foo.java

package com.foo;

import com.bar.Bar;
import com.baz.Baz;

public class Main {
    public static void main(String[] args) {
        System.out.println(new Baz().baz());
        System.out.println(new Bar().bar());
    }
}


-------------------------

test code

public class Test {
    public static void main(String[] args) throws Exception {
        ModuleFinder finder1 = ModuleFinder.of(Paths.get("mods1"));
        Configuration cfg1 = Configuration.resolve(finder1,
Layer.boot(),ModuleFinder.empty(),"com.bar","com.baz");

        ModuleClassLoader cl1 = new ModuleClassLoader(cfg1);
        Layer layer1 = Layer.create(cfg1, m -> cl1);

        ModuleFinder finder2 = ModuleFinder.of(Paths.get("mods2"));
        Configuration cfg2 = Configuration.resolve(finder2,
layer1,ModuleFinder.empty(),"com.bar","com.foo");

        ModuleClassLoader cl2 = new ModuleClassLoader(cl1,cfg2);
        Layer layer2 = Layer.create(cfg2, m -> cl2);



        Module foo = layer2.findModule("com.foo").get();
        Module bar2 = layer2.findModule("com.bar").get();

        Module bar1 = layer1.findModule("com.bar").get();

        ClassLoader fooModuleLoader = layer2.findLoader("com.foo");
        Class<?> mainClass = fooModuleLoader.loadClass("com.foo.Main");

        Test.class.getModule().addReads(mainClass.getModule());
        Method mainMethod = mainClass.getMethod("main", String[].class);

        mainMethod.invoke(null, (Object)new String[0]);
    }

}

Result:

bar1
bar2

As you can see com.foo reads com.bar at 2 without reflection.

I say this is puzzling since with almost the equivalent code I get
another result. If you want I can show for you in another post.

If you want I can send all test files to your mail?


-- 

Best Regards,
Ali Ebrahimi

From Alan.Bateman at oracle.com  Fri Nov  6 16:48:12 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 6 Nov 2015 16:48:12 +0000
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5Ch=KRd21h8qko4JB9V0YX2fwXk_OWokcKibC6jhEzpxA@mail.gmail.com>
References: <CAA0cW5Ch=KRd21h8qko4JB9V0YX2fwXk_OWokcKibC6jhEzpxA@mail.gmail.com>
Message-ID: <563CD9CC.8080109@oracle.com>



On 06/11/2015 10:59, Ali Ebrahimi wrote:
> :
>
> module com.foo {
>          requires com.baz;
>
>          exports com.foo;
>
> }
In this example then com.foo will also need to require com.bar as 
otherwise com.foo will not compile (I assume you've deliberately removed 
the requires public for this example).

In any case, I think what you have here is:

layer1:
     com.bar at 1
     com.baz reads com.bar at 1

The (library) module com.baz has com.bar types in its API.

layer2
     com.bar at 2
     com.foo reads com.baz
     com.foo reads com.bar at 2


> :
>
>
> Result:
>
> bar1
> bar2
>
> As you can see com.foo reads com.bar at 2 without reflection.
Yes, because when creating the configuration for this layer then you are 
resolving com.bar and have arranged that it be found with the 
before-finder. You would get the same thing if you just resolved com.foo 
because resolving com.foo's dependences would require finding com.bar.

In any case, I think you will start to see some of the issues that Alex 
warns about when you change com.foo.Main to do more than invoke 
toString.  If you change it to create Bar and Baz objects for example 
then it's easy to provoke this example to fail with a loader constraint 
violation.

-Alan

From alex.buckley at oracle.com  Fri Nov  6 17:50:49 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 06 Nov 2015 09:50:49 -0800
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5Ch=KRd21h8qko4JB9V0YX2fwXk_OWokcKibC6jhEzpxA@mail.gmail.com>
References: <CAA0cW5Ch=KRd21h8qko4JB9V0YX2fwXk_OWokcKibC6jhEzpxA@mail.gmail.com>
Message-ID: <563CE879.3050409@oracle.com>

On 11/6/2015 2:59 AM, Ali Ebrahimi wrote:
> On Fri, Nov 6, 2015 at 4:09 AM, Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>
>     com.foo in layer2 requires com.baz in layer1, right? Yes.
>
>     com.baz in layer1 uses types from com.bar in layer1, and NOT from
>     com.bar in layer2, right? Yes.
>
>     Therefore, com.foo uses types from com.bar in layer1 (as required by
>     com.baz in layer1), right? Yes.
>
>     I don't know what it means to say "we use com.bar at 2 for layer2's
>     modules". com.foo is in layer2, and you can make it read com.bar at 2
>     via reflection, but otherwise com.bar at 2 is not read by com.foo
>     because com.baz doesn't know about it.
>
> There is no need for reflection:
> Please follow this sample and test it:
>
> layer 1: com.baz and com.bar at 1
> ---------------------------
>
> module com.bar {//version1
>      exports com.bar;
> }
>
> ------------------
>
> //Bar.java
>
> packagecom.bar;
> public classBar {
>      publicString bar(){return"bar1";}
> }
>
> module com.baz {
>          requires com.bar;
>          exports com.baz;
> }
>
> -----------------
>
> //Baz.java
>
> packagecom.baz;
>
> importcom.bar.Bar;
> public classBaz {
>      publicString baz(){return newBar().bar();}
>      publicBar bar(){
>          return newBar();
>      }
> }

I expect javac will warn about the bar() method of class Baz. As a 
public method in a public type in an exported package, its return type 
is from another module (com.bar), yet module com.baz doesn't set up 
implied readability to that other module. Anyway, moving on.

> layer 2: com.foo and com.bar at 2
> --------------------
> module com.bar {//version2
>
>      exports com.bar;
> }
>
> -------------
>
> //Bar.java
>
> packagecom.bar;
>
> public classBar {
>      publicString bar(){return"bar2";}
> }
>
> -------------
>
> module com.foo {
>          requires com.baz;
>
>          exports com.foo;
>
> }
>
> -------------
>
> Foo.java
>
> packagecom.foo;
>
> importcom.bar.Bar;
> importcom.baz.Baz;
>
> public classMain {
>      public static voidmain(String[] args) {
>          System.out.println(newBaz().baz());
>          System.out.println(newBar().bar());
>      }
> }

Foo.java should not compile. 'import com.bar.Bar' names a type that is 
inaccessible from module foo. This makes the rest of the scenario moot.

> public classTest {
>      public static voidmain(String[] args)throwsException {
>          ModuleFinder finder1 = ModuleFinder.of(Paths.get("mods1"));
>          Configuration cfg1 = Configuration.resolve(finder1, Layer.boot(),ModuleFinder.empty(),"com.bar","com.baz");
>
>          ModuleClassLoader cl1 =newModuleClassLoader(cfg1);
>          Layer layer1 = Layer.create(cfg1, m -> cl1);
>
>          ModuleFinder finder2 = ModuleFinder.of(Paths.get("mods2"));
>          Configuration cfg2 = Configuration.resolve(finder2, layer1,ModuleFinder.empty(),"com.bar","com.foo");
>
>          ModuleClassLoader cl2 =newModuleClassLoader(cl1,cfg2);
>          Layer layer2 = Layer.create(cfg2, m -> cl2);
>
>
>
>          Module foo = layer2.findModule("com.foo").get();
>          Module bar2 = layer2.findModule("com.bar").get();
>
>          Module bar1 = layer1.findModule("com.bar").get();
>
>          ClassLoader fooModuleLoader = layer2.findLoader("com.foo");
>          Class<?> mainClass = fooModuleLoader.loadClass("com.foo.Main");
>
>          Test.class.getModule().addReads(mainClass.getModule());
>          Method mainMethod = mainClass.getMethod("main", String[].class);
>
>          mainMethod.invoke(null, (Object)newString[0]);
>      }
>
> }
>
> Result:
>
> bar1
> bar2
>
> As you can see com.fooreads com.bar at 2 without reflection.
>
> I say this is puzzling since with almost the equivalent code I get another result. If you want I can show for you in another post.

It is puzzling. By specifying com.bar at 2 as one of the root modules in 
cfg2, you have managed to get layer2's loader to load the class 
com.bar.Bar from com.bar at 2. And code in module foo can access that 
class, despite module foo not reading any com.bar module.

Even though the main class in Foo.java should not have compiled, it 
would have been possible to produce class com.foo.Main by other means, 
and the module system should be more resilient in the face of such 
inconsistent separate compilation. We'll have to debug this.

Alex

From ali.ebrahimi1781 at gmail.com  Fri Nov  6 19:18:49 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Fri, 6 Nov 2015 22:48:49 +0330
Subject: Implied readability + layers
In-Reply-To: <563CD9CC.8080109@oracle.com>
References: <CAA0cW5Ch=KRd21h8qko4JB9V0YX2fwXk_OWokcKibC6jhEzpxA@mail.gmail.com>
	<563CD9CC.8080109@oracle.com>
Message-ID: <CAA0cW5AopQLWB7sP5oL7041UysP=Dj8Hf0vcCcT7b_eOpLySzA@mail.gmail.com>

Hi,

On Fri, Nov 6, 2015 at 8:18 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 06/11/2015 10:59, Ali Ebrahimi wrote:
>
>> :
>>
>> module com.foo {
>>          requires com.baz;
>>
>>          exports com.foo;
>>
>> }
>>
> In this example then com.foo will also need to require com.bar as
> otherwise com.foo will not compile (I assume you've deliberately removed
> the requires public for this example).
>
This is my bad, I emitted requires public when typing mail.
The is correct version:

module com.baz{
          requires public  com.baz;
          exports com.bar;
}

Stil result is:

foo.canRead(bar2) -> true
foo.canRead(bar1) -> false
baz.canRead(bar1) -> true
baz.canRead(bar2) -> false
bar1
bar2


But:
I figure out what is problem here:
If you try this sample once with exploded modules and then with modular
jars you will found.

Also, if you remove com.bar from root module list for cfg2 final result
will change:

 Configuration cfg2 = Configuration
                .resolve(finder2, layer1,ModuleFinder.empty(),"com.foo")
                .bind();

So all of this can not cause hard to find bugs in user applications.




-- 

Best Regards,
Ali Ebrahimi

From blackdrag at gmx.org  Fri Nov  6 20:07:44 2015
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 6 Nov 2015 21:07:44 +0100
Subject: Avoiding same-package conflicts
In-Reply-To: <563926FD.1090805@oracle.com>
References: <CABHMDwh+L=dmJ9oBRm=81okP2qLjT9uYaP0=7+MY_eVZ7UqpbQ@mail.gmail.com>
	<563223CB.8060300@oracle.com>
	<CACzrW9BPvfDOb1Wbgd6n4Rba1+0TyG3XnKWFFPfZS0Kr0kBmRA@mail.gmail.com>
	<5633D52C.6050406@gmx.org> <5637CF95.9030800@oracle.com>
	<563884E8.4060505@gmx.org> <563926FD.1090805@oracle.com>
Message-ID: <563D0890.3020807@gmx.org>

On 03.11.2015 22:28, Alex Buckley wrote:
[...]
> groovy-compiler will obviously have a hard dependency on groovy-base,
> but you can avoid groovy-base having a hard dependency on
> groovy-compiler by using services. Of course this assumes a suitable
> split between the interface of your compiler and its implementation.

and of course that split does not exist ;) It is a difference of not 
including something and referring to it by reflection, to have it 
optional; and to have it as a service. The first we can do without 
bigger changes, the later requires the definition of a whole "new" API.

[...]
> One option for the Groovy runtime is to special case its meta class
> package hierarchy by arranging for g.r.m.** classes to be defined by,
> and exported from, a special module that the runtime generates; the
> runtime would set up readability between this module and the user
> modules that "thought" they were defining and exporting g.r.m.**.
>
> You can see a flavor of this technique in the "dynamic module" created
> by Java's Core Reflection when you proxy certain interfaces -- see
> "Package and Module Membership of Proxy Class" in
> http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/reflect/Proxy.html.

will have a look soon, thanks.

bye Jochen


From Alan.Bateman at oracle.com  Fri Nov  6 20:12:04 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 6 Nov 2015 20:12:04 +0000
Subject: Implied readability + layers
In-Reply-To: <CAA0cW5AopQLWB7sP5oL7041UysP=Dj8Hf0vcCcT7b_eOpLySzA@mail.gmail.com>
References: <CAA0cW5Ch=KRd21h8qko4JB9V0YX2fwXk_OWokcKibC6jhEzpxA@mail.gmail.com>
	<563CD9CC.8080109@oracle.com>
	<CAA0cW5AopQLWB7sP5oL7041UysP=Dj8Hf0vcCcT7b_eOpLySzA@mail.gmail.com>
Message-ID: <563D0994.3020002@oracle.com>



On 06/11/2015 19:18, Ali Ebrahimi wrote:
>
> This is my bad, I emitted requires public when typing mail.
> The is correct version:
>
> module com.baz{
>           requires public  com.baz;
>           exports com.bar;
> }
>
> Stil result is:
>
> foo.canRead(bar2) -> true
> foo.canRead(bar1) -> false
> baz.canRead(bar1) -> true
> baz.canRead(bar2) -> false
> bar1
> bar2
>
>
> But:
> I figure out what is problem here:
> If you try this sample once with exploded modules and then with 
> modular jars you will found.

Right, I think you are running into issue again where the two versions 
of com.bar have equal ModuleDescriptors. When you create modular JAR 
then I'm guessing you add a module version and this makes them non-equal.

For the exploded module case then you could changing one of them to 
"export com.bar.extra" to make them non-equal. This is just temporary 
until we get the API changed as I mentioned in some of the other mails.

>
> Also, if you remove com.bar from root module list for cfg2 final 
> result will change:
>
>  Configuration cfg2 = Configuration
>                 .resolve(finder2, layer1,ModuleFinder.empty(),"com.foo")
>                 .bind();
>
> So all of this can not cause hard to find bugs in user applications.
>
Yes, nobody requires com.bar in the configuration for layer2 and so 
com.bar at 2 is ignored.

-Alan

From ali.ebrahimi1781 at gmail.com  Fri Nov  6 20:21:26 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Fri, 6 Nov 2015 23:51:26 +0330
Subject: Implied readability + layers
In-Reply-To: <563D0994.3020002@oracle.com>
References: <CAA0cW5Ch=KRd21h8qko4JB9V0YX2fwXk_OWokcKibC6jhEzpxA@mail.gmail.com>
	<563CD9CC.8080109@oracle.com>
	<CAA0cW5AopQLWB7sP5oL7041UysP=Dj8Hf0vcCcT7b_eOpLySzA@mail.gmail.com>
	<563D0994.3020002@oracle.com>
Message-ID: <CAA0cW5Cv_X4i5wLHhG2O2SkRZ1_6cU6VNwLUNM-PQBbiXWdhLA@mail.gmail.com>

Hi,

On Fri, Nov 6, 2015 at 9:20 PM, Alex Buckley <alex.buckley at oracle.com>
wrote:

>
>>
>> importcom.bar.Bar;
>> public classBaz {
>>      publicString baz(){return newBar().bar();}
>>      publicBar bar(){
>>          return newBar();
>>      }
>> }
>>
>
> I expect javac will warn about the bar() method of class Baz. As a public
> method in a public type in an exported package, its return type is from
> another module (com.bar), yet module com.baz doesn't set up implied
> readability to that other module. Anyway, moving on.
>
As said in Alan's response this is my bad and I missed requires public.


>
> layer 2: com.foo and com.bar at 2
>> --------------------
>> module com.bar {//version2
>>
>>      exports com.bar;
>> }
>>
>> -------------
>>
>> //Bar.java
>>
>> packagecom.bar;
>>
>> public classBar {
>>      publicString bar(){return"bar2";}
>> }
>>
>> -------------
>>
>> module com.foo {
>>          requires com.baz;
>>
>>          exports com.foo;
>>
>> }
>>
>> -------------
>>
>> Foo.java
>>
>> packagecom.foo;
>>
>> importcom.bar.Bar;
>> importcom.baz.Baz;
>>
>> public classMain {
>>      public static voidmain(String[] args) {
>>          System.out.println(newBaz().baz());
>>          System.out.println(newBar().bar());
>>      }
>> }
>>
>
> Foo.java should not compile. 'import com.bar.Bar' names a type that is
> inaccessible from module foo. This makes the rest of the scenario moot.
>
>>
>>
>> I say this is puzzling since with almost the equivalent code I get
>> another result. If you want I can show for you in another post.
>>
>
> It is puzzling. By specifying com.bar at 2 as one of the root modules in
> cfg2, you have managed to get layer2's loader to load the class com.bar.Bar
> from com.bar at 2. And code in module foo can access that class, despite
> module foo not reading any com.bar module.
>

I sent test files directly to your mail.


-- 

Best Regards,
Ali Ebrahimi

From ali.ebrahimi1781 at gmail.com  Fri Nov  6 20:37:22 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Sat, 7 Nov 2015 00:07:22 +0330
Subject: Implied readability + layers
In-Reply-To: <563D0994.3020002@oracle.com>
References: <CAA0cW5Ch=KRd21h8qko4JB9V0YX2fwXk_OWokcKibC6jhEzpxA@mail.gmail.com>
	<563CD9CC.8080109@oracle.com>
	<CAA0cW5AopQLWB7sP5oL7041UysP=Dj8Hf0vcCcT7b_eOpLySzA@mail.gmail.com>
	<563D0994.3020002@oracle.com>
Message-ID: <CAA0cW5CNH8SL-2qaTD6dUiHgdW7Y0-5hEyRarAv8wCfJ1eLhvw@mail.gmail.com>

Hi,

On Fri, Nov 6, 2015 at 11:42 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 06/11/2015 19:18, Ali Ebrahimi wrote:
>
>>
>>
> Right, I think you are running into issue again where the two versions of
> com.bar have equal ModuleDescriptors. When you create modular JAR then I'm
> guessing you add a module version and this makes them non-equal.
>
> For the exploded module case then you could changing one of them to
> "export com.bar.extra" to make them non-equal. This is just temporary until
> we get the API changed as I mentioned in some of the other mails.


Is not better we allow compiler support for module version in module
descriptor?

>
>
>> Also, if you remove com.bar from root module list for cfg2 final result
>> will change:
>>
>>  Configuration cfg2 = Configuration
>>                 .resolve(finder2, layer1,ModuleFinder.empty(),"com.foo")
>>                 .bind();
>>
>> So all of this can not cause hard to find bugs in user applications.
>>
>> Yes, nobody requires com.bar in the configuration for layer2 and so
> com.bar at 2 is ignored.

But don't you think with special handing of implied readability all of this
occurs and maybe some non-discovered ones.

May be user or IDE think adding 'requires com.bar' to com.foo is redundant
and removed.


-- 

Best Regards,
Ali Ebrahimi

From vincent.x.ryan at oracle.com  Sat Nov  7 00:10:21 2015
From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com)
Date: Sat, 07 Nov 2015 00:10:21 +0000
Subject: hg: jigsaw/jake/jdk: 8078813: Test JAAS with modules
Message-ID: <201511070010.tA70ALko012407@aojmv0008.oracle.com>

Changeset: 9418361408f3
Author:    vinnie
Date:      2015-11-07 00:15 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9418361408f3

8078813: Test JAAS with modules
Summary: Test JAAS LoginContext with different combination of module type.
Reviewed-by: weijun
Contributed-by: sibabrata.sahoo at oracle.com

+ test/java/security/modules/JigsawSecurityUtils.java
+ test/javax/security/auth/login/modules/JaasModularClientTest.java
+ test/javax/security/auth/login/modules/TEST.properties
+ test/javax/security/auth/login/modules/src/jaasclientmodule/client/JaasClient.java
+ test/javax/security/auth/login/modules/src/jaasclientmodule/client/jaas.conf
+ test/javax/security/auth/login/modules/src/jaasloginmodule/login/TestLoginModule.java
! test/jdk/jigsaw/lib/JarUtils.java


From mandy.chung at oracle.com  Sat Nov  7 06:37:22 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 07 Nov 2015 06:37:22 +0000
Subject: hg: jigsaw/jake/jdk: Class.forName(Module,
	String) supports for unnamed module
Message-ID: <201511070637.tA76bMJc009401@aojmv0008.oracle.com>

Changeset: a87d4be5e220
Author:    mchung
Date:      2015-11-06 22:37 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a87d4be5e220

Class.forName(Module, String) supports for unnamed module

! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/ModuleClassLoader.java
! src/java.base/share/classes/java/lang/Package.java
! src/java.base/share/classes/jdk/internal/misc/BuiltinClassLoader.java
+ test/java/lang/Class/forName/modules/TestDriver.java
+ test/java/lang/Class/forName/modules/TestMain.java
+ test/java/lang/Class/forName/modules/src/m1/module-info.java
+ test/java/lang/Class/forName/modules/src/m1/p1/A.java
+ test/java/lang/Class/forName/modules/src/m1/p1/Initializer.java
+ test/java/lang/Class/forName/modules/src/m1/p1/internal/B.java
+ test/java/lang/Class/forName/modules/src/m2/module-info.java
+ test/java/lang/Class/forName/modules/src/m2/p2/C.java
+ test/java/lang/Class/forName/modules/src/m2/p2/test/Main.java


From florian.trossbach at codecentric.de  Sat Nov  7 10:15:01 2015
From: florian.trossbach at codecentric.de (=?UTF-8?Q?Florian_Tro=C3=9Fbach?=)
Date: Sat, 7 Nov 2015 11:15:01 +0100
Subject: Unable to compile modules with references to automatic modules -
	"cannot find module: jdk.management.resource"
In-Reply-To: <CAPD9FEfA2fbE6yp4WAazjvXQra+eiVtMvfqQY0gAJdyKSUi0jQ@mail.gmail.com>
References: <CAPD9FEfA2fbE6yp4WAazjvXQra+eiVtMvfqQY0gAJdyKSUi0jQ@mail.gmail.com>
Message-ID: <CAPD9FEe8s8iMBww8KH8c8fQstsAsct5M0h95TvXGetdw7K40LA@mail.gmail.com>

Hi,

Following the sessions at JavaOne i started playing around with Jigsaw. I
am using Build 86 64-bit on OSX.

I have trouble compiling a multicompilation project that uses commons-lang3
as an automatic module on the modulepath.
The code is available at https://github.com/ftrossbach/IntroToJigsaw, this
specifically is the example 6 folder (1-5 work fine, 5 should be the same
as 6 but without the reference to the automatic module).

When I compile my modules with

javac -d . -mp ../jars -modulesourcepath . -verbose   $(find . -name
"*.java")

I get the attached output. The raised error is "error: cannot find module:
jdk.management.resource?.

I do not understand what that means or why this module is read. When I
compile the module without the reference to commons-lang3, it does not
occur. When I look at the commonslang3 jar  with jdeps, i only get a
dependency on java.base:

$ jdeps -s ../jars/commonslang3.jar
commonslang3.jar -> java.base

Any help with this problem is greatly appreciated.

Best regards,
Florian

-- 
Florian Tro?bach | IT-Consultant | Agile Software Factory  | Consulting
codecentric AG | Zeppelinstr 2 | 76185 Karlsruhe | Deutschland
tel: +49 (0) 721.9595-681 | fax: +49 (0) 721.9595-666 | mobil: +49 (0)
173.6700743
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de |
www.more4fi.de

Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
Vorstand: Michael Hochg?rtel . Mirko Novakovic . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus J?ger . J?rgen Sch?tz

Diese E-Mail einschlie?lich evtl. beigef?gter Dateien enth?lt vertrauliche
und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige
Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie
bitte sofort den Absender und l?schen Sie diese E-Mail und evtl.
beigef?gter Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder ?ffnen
evtl. beigef?gter Dateien sowie die unbefugte Weitergabe dieser E-Mail ist
nicht gestattet



-- 
Florian Tro?bach | IT-Consultant | Agile Software Factory  | Consulting
codecentric AG | Zeppelinstr 2 | 76185 Karlsruhe | Deutschland
tel: +49 (0) 721.9595-681 | fax: +49 (0) 721.9595-666 | mobil: +49 (0)
173.6700743
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de |
www.more4fi.de

Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
Vorstand: Michael Hochg?rtel . Mirko Novakovic . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus J?ger . J?rgen Sch?tz

Diese E-Mail einschlie?lich evtl. beigef?gter Dateien enth?lt vertrauliche
und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige
Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie
bitte sofort den Absender und l?schen Sie diese E-Mail und evtl.
beigef?gter Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder ?ffnen
evtl. beigef?gter Dateien sowie die unbefugte Weitergabe dieser E-Mail ist
nicht gestattet
-------------- next part --------------
[parsing started RegularFileObject[./de.codecentric.addresschecker/de/codecentric/addresschecker/api/AddressChecker.java]]
[parsing completed 18ms]
[parsing started RegularFileObject[./de.codecentric.addresschecker/de/codecentric/addresschecker/api/Run.java]]
[parsing completed 3ms]
[parsing started RegularFileObject[./de.codecentric.addresschecker/de/codecentric/addresschecker/internal/AddressCheckerImpl.java]]
[parsing completed 1ms]
[parsing started RegularFileObject[./de.codecentric.addresschecker/module-info.java]]
[parsing completed 0ms]
[parsing started RegularFileObject[./de.codecentric.zipvalidator/de/codecentric/zipvalidator/api/ZipCodeValidator.java]]
[parsing completed 1ms]
[parsing started RegularFileObject[./de.codecentric.zipvalidator/de/codecentric/zipvalidator/api/ZipCodeValidatorFactory.java]]
[parsing completed 0ms]
[parsing started RegularFileObject[./de.codecentric.zipvalidator/de/codecentric/zipvalidator/internal/ZipCodeValidatorImpl.java]]
[parsing completed 1ms]
[parsing started RegularFileObject[./de.codecentric.zipvalidator/module-info.java]]
[parsing completed 1ms]
[parsing started RegularFileObject[./de.codecentric.zipvalidator.model/de/codecentric/zipvalidator/model/api/ZipCodeValidationResult.java]]
[parsing completed 0ms]
[parsing started RegularFileObject[./de.codecentric.zipvalidator.model/module-info.java]]
[parsing completed 3ms]
[loading /modules/java.base/module-info.class]
error: cannot find module: jdk.management.resource
[loading /modules/jdk.zipfs/module-info.class]
[loading /modules/jdk.xml.ws/module-info.class]
[loading /modules/java.xml.ws/module-info.class]
[loading /modules/java.logging/module-info.class]
[loading /modules/java.xml.bind/module-info.class]
[loading /modules/java.compiler/module-info.class]
[loading /modules/java.desktop/module-info.class]
[loading /modules/java.prefs/module-info.class]
[loading /modules/java.xml/module-info.class]
[loading /modules/java.datatransfer/module-info.class]
[loading /modules/java.activation/module-info.class]
[loading /modules/java.management/module-info.class]
[loading /modules/java.rmi/module-info.class]
[loading /modules/java.naming/module-info.class]
[loading /modules/java.security.sasl/module-info.class]
[loading /modules/jdk.httpserver/module-info.class]
[loading /modules/java.annotations.common/module-info.class]
[loading /modules/jdk.xml.bind/module-info.class]
[loading /modules/jdk.compiler/module-info.class]
[loading /modules/jdk.xml.dom/module-info.class]
[loading /modules/jdk.snmp/module-info.class]
[loading /modules/jdk.security.jgss/module-info.class]
[loading /modules/java.security.jgss/module-info.class]
[loading /modules/jdk.security.auth/module-info.class]
[loading /modules/jdk.sctp/module-info.class]
[loading /modules/jdk.scripting.nashorn.shell/module-info.class]
[loading /modules/jdk.scripting.nashorn/module-info.class]
[loading /modules/java.scripting/module-info.class]
[loading /modules/jdk.internal.le/module-info.class]
[loading /modules/jdk.rmic/module-info.class]
[loading /modules/jdk.javadoc/module-info.class]
[loading /modules/java.corba/module-info.class]
[loading /modules/java.transaction/module-info.class]
[loading /modules/jdk.policytool/module-info.class]
[loading /modules/java.sql/module-info.class]
[loading /modules/jdk.plugin.dom/module-info.class]
[loading /modules/jdk.deploy/module-info.class]
[loading /modules/jdk.plugin/module-info.class]
[loading /modules/jdk.javaws/module-info.class]
[loading /modules/jdk.pack200/module-info.class]
[loading /modules/jdk.naming.rmi/module-info.class]
[loading /modules/jdk.naming.dns/module-info.class]
[loading /modules/jdk.management/module-info.class]
[loading /modules/jdk.localedata/module-info.class]
[loading /modules/jdk.jvmstat/module-info.class]
[loading /modules/jdk.jlink/module-info.class]
[loading /modules/jdk.jdeps/module-info.class]
[loading /modules/jdk.internal.opt/module-info.class]
[loading /modules/jdk.jfr/module-info.class]
[loading /modules/java.instrument/module-info.class]
[loading /modules/jdk.jdwp.agent/module-info.class]
[loading /modules/jdk.jdi/module-info.class]
[loading /modules/jdk.attach/module-info.class]
[loading /modules/jdk.jconsole/module-info.class]
[loading /modules/jdk.jcmd/module-info.class]
[loading /modules/jdk.hotspot.agent/module-info.class]
[loading /modules/jdk.jartool/module-info.class]
[loading /modules/jdk.deploy.osx/module-info.class]
[loading /modules/jdk.crypto.pkcs11/module-info.class]
[loading /modules/jdk.crypto.ec/module-info.class]
[loading /modules/jdk.charsets/module-info.class]
[loading /modules/jdk.accessibility/module-info.class]
[loading /modules/javafx.web/module-info.class]
[loading /modules/javafx.graphics/module-info.class]
[loading /modules/javafx.base/module-info.class]
[loading /modules/javafx.controls/module-info.class]
[loading /modules/javafx.media/module-info.class]
[loading /modules/javafx.swing/module-info.class]
[loading /modules/javafx.fxml/module-info.class]
[loading /modules/javafx.deploy/module-info.class]
[loading /modules/java.xml.crypto/module-info.class]
[loading /modules/java.sql.rowset/module-info.class]
[loading /modules/java.smartcardio/module-info.class]
[loading /modules/java.se/module-info.class]
[loading /modules/java.compact3/module-info.class]
[loading /modules/java.compact2/module-info.class]
[loading /modules/java.compact1/module-info.class]
[total 218ms]
1 error

From Alan.Bateman at oracle.com  Sat Nov  7 14:34:07 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 7 Nov 2015 14:34:07 +0000
Subject: Unable to compile modules with references to automatic modules -
	"cannot find module: jdk.management.resource"
In-Reply-To: <CAPD9FEe8s8iMBww8KH8c8fQstsAsct5M0h95TvXGetdw7K40LA@mail.gmail.com>
References: <CAPD9FEfA2fbE6yp4WAazjvXQra+eiVtMvfqQY0gAJdyKSUi0jQ@mail.gmail.com>
	<CAPD9FEe8s8iMBww8KH8c8fQstsAsct5M0h95TvXGetdw7K40LA@mail.gmail.com>
Message-ID: <563E0BDF.9040907@oracle.com>

On 07/11/2015 10:15, Florian Tro?bach wrote:
> :
>
> When I compile my modules with
>
> javac -d . -mp ../jars -modulesourcepath . -verbose   $(find . -name
> "*.java")
>
> I get the attached output. The raised error is "error: cannot find module:
> jdk.management.resource?.
>
>
This is a bug in the EA build where they are qualified exports to 
jdk.management.resource but this module is not in the builds. So it's a 
build issue, I'll create a bug to track this.  If you build the JDK 
yourself, from the jigsaw/jake sources, then you won't run into this 
issue, it is specified to how the EA builds are created.

That said, I'm not 100% sure why javac runs into it here, I'm sure Jon 
or Jan can explain that.

-Alan.

From alan.bateman at oracle.com  Sat Nov  7 16:48:33 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 07 Nov 2015 16:48:33 +0000
Subject: hg: jigsaw/jake/jdk: jdk/jigsaw tests failing due to recent changes
	to JarUtils
Message-ID: <201511071648.tA7GmY2A020640@aojmv0008.oracle.com>

Changeset: 1c37b2067e4d
Author:    alanb
Date:      2015-11-07 16:48 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c37b2067e4d

jdk/jigsaw tests failing due to recent changes to JarUtils

! test/javax/security/auth/login/modules/JaasModularClientTest.java
! test/jdk/jigsaw/lib/JarUtils.java


From alan.bateman at oracle.com  Sat Nov  7 17:41:44 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 07 Nov 2015 17:41:44 +0000
Subject: hg: jigsaw/jake/jdk: Move tests for Class getResource to
	java/lang/Class
Message-ID: <201511071741.tA7Hfi2o028732@aojmv0008.oracle.com>

Changeset: bb94cd0c9910
Author:    alanb
Date:      2015-11-07 17:41 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bb94cd0c9910

Move tests for Class getResource to java/lang/Class

+ test/java/lang/Class/getResource/Main.java
+ test/java/lang/Class/getResource/ResourcesTest.java
+ test/java/lang/Class/getResource/src/m1/module-info.java
+ test/java/lang/Class/getResource/src/m1/p1/Main.java
+ test/java/lang/Class/getResource/src/m2/module-info.java
+ test/java/lang/Class/getResource/src/m2/p2/Main.java
+ test/java/lang/Class/getResource/src/m3/module-info.java
+ test/java/lang/Class/getResource/src/m3/p3/Main.java
- test/jdk/jigsaw/etc/resources/Main.java
- test/jdk/jigsaw/etc/resources/ResourcesTest.java
- test/jdk/jigsaw/etc/resources/src/m1/module-info.java
- test/jdk/jigsaw/etc/resources/src/m1/p1/Main.java
- test/jdk/jigsaw/etc/resources/src/m2/module-info.java
- test/jdk/jigsaw/etc/resources/src/m2/p2/Main.java
- test/jdk/jigsaw/etc/resources/src/m3/module-info.java
- test/jdk/jigsaw/etc/resources/src/m3/p3/Main.java


From mandy.chung at oracle.com  Sat Nov  7 21:27:16 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 07 Nov 2015 21:27:16 +0000
Subject: hg: jigsaw/jake/jdk: Enable jlink gen-installed-modules plugin by
	default
Message-ID: <201511072127.tA7LRGPK008490@aojmv0008.oracle.com>

Changeset: 3f859f4a29bf
Author:    mchung
Date:      2015-11-07 13:02 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3f859f4a29bf

Enable jlink gen-installed-modules plugin by default

! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/InstalledModuleDescriptorPlugin.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/InstalledModuleDescriptorProvider.java


From florian.trossbach at codecentric.de  Sun Nov  8 09:56:59 2015
From: florian.trossbach at codecentric.de (=?UTF-8?Q?Florian_Tro=C3=9Fbach?=)
Date: Sun, 8 Nov 2015 10:56:59 +0100
Subject: Unable to compile modules with references to automatic modules -
	"cannot find module: jdk.management.resource"
In-Reply-To: <563E0BDF.9040907@oracle.com>
References: <CAPD9FEfA2fbE6yp4WAazjvXQra+eiVtMvfqQY0gAJdyKSUi0jQ@mail.gmail.com>
	<CAPD9FEe8s8iMBww8KH8c8fQstsAsct5M0h95TvXGetdw7K40LA@mail.gmail.com>
	<563E0BDF.9040907@oracle.com>
Message-ID: <CAPD9FEfuvyYnb-ojm3MmxvMJoTgBygLBY6+M7Qbv9sSBkGVqAQ@mail.gmail.com>

Hi Alan,

Thank you for your answer, building the JDK myself this error goes away.
Building my own JDK was not without challenges on OSX Mavericks though:

I first mistakenly cloned the wrong repository (the JDK9 without Jigsaw. It
compiled just fine, but I of course discovered my error when javac
complained about the -modulepath switch.
Then I cloned the right repo, but it failed to compile with an ?error 2?.
As I don?t know much about make, I proceeded to creating an Ubuntu VM and
after installing a load of dependencies (which the configure.sh script
tells you about very nicely!), I got it working.

I did some more ?research" about the OSX build though, and i found this:
https://www.mail-archive.com/build-dev at openjdk.java.net/msg15343.html. This
prompted me to replace the offending sections
from /hotspot/make/bsd/makefiles/gcc.make (around line 324) with the
equivalent from the non-jigsaw sources that I managed to compile
successfully. Lo and behold, this worked like a charm.

Best regards,
Florian

2015-11-07 15:34 GMT+01:00 Alan Bateman <Alan.Bateman at oracle.com>:

> On 07/11/2015 10:15, Florian Tro?bach wrote:
>
>> :
>>
>> When I compile my modules with
>>
>> javac -d . -mp ../jars -modulesourcepath . -verbose   $(find . -name
>> "*.java")
>>
>> I get the attached output. The raised error is "error: cannot find module:
>> jdk.management.resource?.
>>
>>
>> This is a bug in the EA build where they are qualified exports to
> jdk.management.resource but this module is not in the builds. So it's a
> build issue, I'll create a bug to track this.  If you build the JDK
> yourself, from the jigsaw/jake sources, then you won't run into this issue,
> it is specified to how the EA builds are created.
>
> That said, I'm not 100% sure why javac runs into it here, I'm sure Jon or
> Jan can explain that.
>
> -Alan.
>

From Alan.Bateman at oracle.com  Sun Nov  8 10:42:10 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 8 Nov 2015 10:42:10 +0000
Subject: Unable to compile modules with references to automatic modules -
	"cannot find module: jdk.management.resource"
In-Reply-To: <CAPD9FEfuvyYnb-ojm3MmxvMJoTgBygLBY6+M7Qbv9sSBkGVqAQ@mail.gmail.com>
References: <CAPD9FEfA2fbE6yp4WAazjvXQra+eiVtMvfqQY0gAJdyKSUi0jQ@mail.gmail.com>
	<CAPD9FEe8s8iMBww8KH8c8fQstsAsct5M0h95TvXGetdw7K40LA@mail.gmail.com>
	<563E0BDF.9040907@oracle.com>
	<CAPD9FEfuvyYnb-ojm3MmxvMJoTgBygLBY6+M7Qbv9sSBkGVqAQ@mail.gmail.com>
Message-ID: <563F2702.3010201@oracle.com>

On 08/11/2015 09:56, Florian Tro?bach wrote:
> :
>
> I did some more ?research" about the OSX build though, and i found 
> this: 
> https://www.mail-archive.com/build-dev at openjdk.java.net/msg15343.html. 
> This prompted me to replace the offending sections 
> from /hotspot/make/bsd/makefiles/gcc.make (around line 324) with the 
> equivalent from the non-jigsaw sources that I managed to compile 
> successfully. Lo and behold, this worked like a charm.
>
Good to hear you got it building on both Linux and OS X.

On the Xcode/clang issue then this has been fixed in JDK 9 in jdk9-b89 
via JDK-8138820 [1]. The jigsaw/jake forest and EA builds currently 
based on jdk9-b86 so a bit behind. We were sync'ing up jigsaw/jake 
weekly but most of us have been too busy recently and this is why 
jigsaw/jake is a bit behind. There is quite a bit of merging needed to 
do these syncs up but we will get jigsaw/jake sync'ed up soon.

-Alan

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

From jan.lahoda at oracle.com  Sun Nov  8 17:51:53 2015
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Sun, 08 Nov 2015 18:51:53 +0100
Subject: Unable to compile modules with references to automatic modules
	- "cannot find module: jdk.management.resource"
In-Reply-To: <563E0BDF.9040907@oracle.com>
References: <CAPD9FEfA2fbE6yp4WAazjvXQra+eiVtMvfqQY0gAJdyKSUi0jQ@mail.gmail.com>	<CAPD9FEe8s8iMBww8KH8c8fQstsAsct5M0h95TvXGetdw7K40LA@mail.gmail.com>
	<563E0BDF.9040907@oracle.com>
Message-ID: <563F8BB9.1070702@oracle.com>

On 7.11.2015 15:34, Alan Bateman wrote:
> On 07/11/2015 10:15, Florian Tro?bach wrote:
>> :
>>
>> When I compile my modules with
>>
>> javac -d . -mp ../jars -modulesourcepath . -verbose   $(find . -name
>> "*.java")
>>
>> I get the attached output. The raised error is "error: cannot find
>> module:
>> jdk.management.resource?.
>>
>>
> This is a bug in the EA build where they are qualified exports to
> jdk.management.resource but this module is not in the builds. So it's a
> build issue, I'll create a bug to track this.  If you build the JDK
> yourself, from the jigsaw/jake sources, then you won't run into this
> issue, it is specified to how the EA builds are created.
>
> That said, I'm not 100% sure why javac runs into it here, I'm sure Jon
> or Jan can explain that.

Automatic modules depend on all other named modules, and javac currently 
uses all modules it knows about, which includes those it found while 
analyzing other module-infos. I think it could be changed to only 
include modules found on the module paths.

Jan

>
> -Alan.

From Alan.Bateman at oracle.com  Mon Nov  9 08:55:09 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 9 Nov 2015 08:55:09 +0000
Subject: Unable to compile modules with references to automatic modules -
	"cannot find module: jdk.management.resource"
In-Reply-To: <563F8BB9.1070702@oracle.com>
References: <CAPD9FEfA2fbE6yp4WAazjvXQra+eiVtMvfqQY0gAJdyKSUi0jQ@mail.gmail.com>
	<CAPD9FEe8s8iMBww8KH8c8fQstsAsct5M0h95TvXGetdw7K40LA@mail.gmail.com>
	<563E0BDF.9040907@oracle.com> <563F8BB9.1070702@oracle.com>
Message-ID: <56405F6D.80003@oracle.com>


On 08/11/2015 17:51, Jan Lahoda wrote:
>
> Automatic modules depend on all other named modules, and javac 
> currently uses all modules it knows about, which includes those it 
> found while analyzing other module-infos. I think it could be changed 
> to only include modules found on the module paths.

I assume this will need to re-visited. If javac gets -limitmods then it 
will limit the set of observable modules and so qualified exports to 
modules that aren't in that set will need to be ignored. It's also tied 
to -addmods and getting javac consistent with run-time where automatic 
only require java.base for the purposes of resolution but read all other 
modules.

In any case, it won't be possible to compile code that references to 
types in the "missing" modules and so I assume shouldn't change javac 
behavior to not use the qualified exports.

-Alan

From harold.seigel at oracle.com  Mon Nov  9 16:55:42 2015
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Mon, 09 Nov 2015 16:55:42 +0000
Subject: hg: jigsaw/jake/hotspot: 8139095: AppCDS will load application
	archive classes that conflict with modules in the jimage
Message-ID: <201511091655.tA9GthgX026461@aojmv0008.oracle.com>

Changeset: 87a0cdda6d9e
Author:    jiangli
Date:      2015-11-06 19:47 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/87a0cdda6d9e

8139095: AppCDS will load application archive classes that conflict with modules in the jimage
Summary: More fine-grained shared class runtime visibility check.
Reviewed-by: lfoltan, acorn, ccheung
Contributed-by: jiangli.zhou at oracle.com, calvin.cheung at oracle.com, ioi.lam at oracle.com

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/systemDictionaryShared.hpp


From alexandre.iline at oracle.com  Mon Nov  9 17:54:05 2015
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Mon, 9 Nov 2015 20:54:05 +0300
Subject: RFR: 8139430
Message-ID: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>

Hi,

This is one of the ways to fix 8139430: http://cr.openjdk.java.net/~shurailine/8139430/webrev.03

Could you please take a look on it?

A few comments. 

The biggest dependency on java.management was in jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method to use the new process API, which helped to avoid updating a lot of code.

I am moving the rest library code which depended on java.management and jdk.management  to a new ?management" subpackage of the jdk library: jdk.testlibrary.management. Another possibility I have considered is ?ext? or ?extended? subpackage, which would have all the classes which depend on anything but java.base. With ?ext? there would be no way to keep the desired granularity with the test modules dependencies.

The methods which worth moving fit well into two classes: 
jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method which previously belonged to the TestThread utility methods.
jdk.testlibrary.management.RuntimeMXBeanTool - previously named as jdk.testlibrary.InputArguments

None of moved/renamed test library methods were used anywhere in tests, so no test updates needed:
jdk.testlibrary.InputArguments is not used, instead every test which needs that functionality directly calls RuntimeMXBean.getInputArguments()
jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not used as there is a similar class outside of the test library:
./closed/com/oracle/jfr/common/jrockit/TestThread.java

Please let me know what you think.

Shura

From alexandre.iline at oracle.com  Mon Nov  9 18:12:11 2015
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Mon, 9 Nov 2015 21:12:11 +0300
Subject: RFR: 8139430
In-Reply-To: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
Message-ID: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>

Hi

I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also:
http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/

Shura

> On Nov 9, 2015, at 8:54 PM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
> 
> Hi,
> 
> This is one of the ways to fix 8139430: http://cr.openjdk.java.net/~shurailine/8139430/webrev.03
> 
> Could you please take a look on it?
> 
> A few comments. 
> 
> The biggest dependency on java.management was in jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method to use the new process API, which helped to avoid updating a lot of code.
> 
> I am moving the rest library code which depended on java.management and jdk.management  to a new ?management" subpackage of the jdk library: jdk.testlibrary.management. Another possibility I have considered is ?ext? or ?extended? subpackage, which would have all the classes which depend on anything but java.base. With ?ext? there would be no way to keep the desired granularity with the test modules dependencies.
> 
> The methods which worth moving fit well into two classes: 
> jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method which previously belonged to the TestThread utility methods.
> jdk.testlibrary.management.RuntimeMXBeanTool - previously named as jdk.testlibrary.InputArguments
> 
> None of moved/renamed test library methods were used anywhere in tests, so no test updates needed:
> jdk.testlibrary.InputArguments is not used, instead every test which needs that functionality directly calls RuntimeMXBean.getInputArguments()
> jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not used as there is a similar class outside of the test library:
> ./closed/com/oracle/jfr/common/jrockit/TestThread.java
> 
> Please let me know what you think.
> 
> Shura


From jonathan.gibbons at oracle.com  Mon Nov  9 18:44:31 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 09 Nov 2015 10:44:31 -0800
Subject: Unable to compile modules with references to automatic modules
	- "cannot find module: jdk.management.resource"
In-Reply-To: <56405F6D.80003@oracle.com>
References: <CAPD9FEfA2fbE6yp4WAazjvXQra+eiVtMvfqQY0gAJdyKSUi0jQ@mail.gmail.com>	<CAPD9FEe8s8iMBww8KH8c8fQstsAsct5M0h95TvXGetdw7K40LA@mail.gmail.com>	<563E0BDF.9040907@oracle.com>
	<563F8BB9.1070702@oracle.com> <56405F6D.80003@oracle.com>
Message-ID: <5640E98F.1010702@oracle.com>



On 11/09/2015 12:55 AM, Alan Bateman wrote:
>
> On 08/11/2015 17:51, Jan Lahoda wrote:
>>
>> Automatic modules depend on all other named modules, and javac 
>> currently uses all modules it knows about, which includes those it 
>> found while analyzing other module-infos. I think it could be changed 
>> to only include modules found on the module paths.
>
> I assume this will need to re-visited. If javac gets -limitmods then 
> it will limit the set of observable modules and so qualified exports 
> to modules that aren't in that set will need to be ignored. It's also 
> tied to -addmods and getting javac consistent with run-time where 
> automatic only require java.base for the purposes of resolution but 
> read all other modules.
>
> In any case, it won't be possible to compile code that references to 
> types in the "missing" modules and so I assume shouldn't change javac 
> behavior to not use the qualified exports.
>
> -Alan 

Yes, this all needs to be fixed.

javac's ModuleFinder currently scans all modules on the aggregate module 
path; it needs to be updated to match the runtime behavior, which is to 
scan system modules, plus any modules in and reachable from the root 
set, plus any modules requested with -addmods.

-- Jon

From richard at lucentsky.com  Tue Nov 10 05:26:55 2015
From: richard at lucentsky.com (Richard Callahan)
Date: Tue, 10 Nov 2015 05:26:55 +0000
Subject: Technical question about the Java Dependency Analysis Tool
Message-ID: <BLUPR0501MB173046AB1576BF50F3C4AD21B6140@BLUPR0501MB1730.namprd05.prod.outlook.com>

Hi,

I have a specific question about the output from the Java Dependency Analysis Tool (JDeps), released with Open JDK 8. Thank you very much for such a marvelous tool!

I am parsing the output from JDeps with the "-v" flag set, such that a call to JDeps produces all class-level dependencies among and within a set of JAR files in a directory specified by the user. Consider a directed graph G constructed from the JDeps output, with the vertices representing nodes in the graph and the edges representing dependencies among the classes as specified in the JDeps output.  My question is, if a specific JAR file in the directory (call it A.jar) can compile using OpenJDK with the other JAR files in the directory designated as dependencies, then does there always exist at least one subgraph G' of G that corresponds to the dependency relationships that would be actually used by a Java compiler to compile A.jar? If the answer is "yes," then I believe I should be able to recover that graph by starting with the set of classes in A.jar and then constructing the subgraph G' in a manner similar to that used by a depth-first search.

Thank you for your time, I recognize it is valuable.

Best,

Richard

From jean-francois.denise at oracle.com  Tue Nov 10 10:17:40 2015
From: jean-francois.denise at oracle.com (jean-francois.denise at oracle.com)
Date: Tue, 10 Nov 2015 10:17:40 +0000
Subject: hg: jigsaw/jake/jdk: 2 new changesets
Message-ID: <201511101017.tAAAHeYu017280@aojmv0008.oracle.com>

Changeset: 1148a05d184a
Author:    jfdenise
Date:      2015-11-10 10:28 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1148a05d184a

Fix for 8135077, 8134944, 8139296
Reviewed-by: jlaskey

! src/jdk.jlink/share/classes/jdk/tools/jlink/JlinkTask.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/TaskHelper.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginProviderRepository.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JmodArchive.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/plugins/DefaultImageBuilderProvider.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties
! test/jdk/jigsaw/tools/jlink/CustomImageBuilderTest.java
! test/jdk/jigsaw/tools/jlink/JLinkNegativeTest.java
! test/jdk/jigsaw/tools/jlink/customplugin/plugin/CustomImageBuilderProvider.java

Changeset: 8daa6a6c8657
Author:    jfdenise
Date:      2015-11-10 11:06 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8daa6a6c8657

Fix compressed resource header length to be a u8. Handle endianness of compressed resource header.
Reviewed-by: jlaskey

! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java
! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java
! src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java
! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java
! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp
! src/java.base/share/native/libjimage/imageDecompressor.cpp
! src/java.base/share/native/libjimage/imageDecompressor.hpp
! src/java.base/share/native/libjimage/imageFile.cpp


From jaroslav.bachorik at oracle.com  Tue Nov 10 12:21:13 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 10 Nov 2015 13:21:13 +0100
Subject: RFR: 8139430
In-Reply-To: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
Message-ID: <5641E139.9000209@oracle.com>

Hi,

On 9.11.2015 19:12, Alexandre (Shura) Iline wrote:
> Hi
>
> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also:
> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/

As for the original (03) webrev - I wouldn't rename InputArguments into 
RuntimeMXBeanTool. The new name really does not reflect the 
functionality the class actually provides. IMO, you can keep the 
original class name and still move it to jdk.testlibrary.management.

As for the last (04) webrev - this change doesn't seem to be related to 
the issue. It is just a cleanup of a potential NPE. I would suggest 
either updating the issue summary to be more generic or address the NPE 
in a separate changeset.

-JB-

>
> Shura
>
>> On Nov 9, 2015, at 8:54 PM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>>
>> Hi,
>>
>> This is one of the ways to fix 8139430: http://cr.openjdk.java.net/~shurailine/8139430/webrev.03
>>
>> Could you please take a look on it?
>>
>> A few comments.
>>
>> The biggest dependency on java.management was in jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method to use the new process API, which helped to avoid updating a lot of code.
>>
>> I am moving the rest library code which depended on java.management and jdk.management  to a new ?management" subpackage of the jdk library: jdk.testlibrary.management. Another possibility I have considered is ?ext? or ?extended? subpackage, which would have all the classes which depend on anything but java.base. With ?ext? there would be no way to keep the desired granularity with the test modules dependencies.
>>
>> The methods which worth moving fit well into two classes:
>> jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method which previously belonged to the TestThread utility methods.
>> jdk.testlibrary.management.RuntimeMXBeanTool - previously named as jdk.testlibrary.InputArguments
>>
>> None of moved/renamed test library methods were used anywhere in tests, so no test updates needed:
>> jdk.testlibrary.InputArguments is not used, instead every test which needs that functionality directly calls RuntimeMXBean.getInputArguments()
>> jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not used as there is a similar class outside of the test library:
>> ./closed/com/oracle/jfr/common/jrockit/TestThread.java
>>
>> Please let me know what you think.
>>
>> Shura
>


From jean-francois.denise at oracle.com  Tue Nov 10 13:43:15 2015
From: jean-francois.denise at oracle.com (jean-francois.denise at oracle.com)
Date: Tue, 10 Nov 2015 13:43:15 +0000
Subject: hg: jigsaw/jake/jdk: Fix for 81422389. Close archives in all cases.
Message-ID: <201511101343.tAADhFk6012660@aojmv0008.oracle.com>

Changeset: 1943b3022700
Author:    jfdenise
Date:      2015-11-10 14:43 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1943b3022700

Fix for 81422389. Close archives in all cases.
Reviewed-by: jlaskey

! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java


From mandy.chung at oracle.com  Tue Nov 10 15:53:34 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Nov 2015 07:53:34 -0800
Subject: Technical question about the Java Dependency Analysis Tool
In-Reply-To: <BLUPR0501MB173046AB1576BF50F3C4AD21B6140@BLUPR0501MB1730.namprd05.prod.outlook.com>
References: <BLUPR0501MB173046AB1576BF50F3C4AD21B6140@BLUPR0501MB1730.namprd05.prod.outlook.com>
Message-ID: <B03C44CA-9CA4-44F5-B9C8-6FDC1CBC1121@oracle.com>

jdeps already has the option finding the JAR files needed to compile A.jar.

There is a new jdeps option added to Jigsaw EA build [1] to make this easier:

$ jdeps -s -ct -R -cp lib/* A.jar

This will transitively find all dependencies from the references in A.jar and shows the summary of the JAR-level dependencies.  jdeps -dotoutput option outputs the dependencies in a DOT file that you can generate the DOT graph.

You can use idk 9  jdeps ?include option which analyzes all JAR files in lib directory
$ jdeps ?dotoutput dotfiles ?include ?.*? -cp lib/* A.jar

Mandy
[1] http://openjdk.java.net/projects/jigsaw/ea

> On Nov 9, 2015, at 9:26 PM, Richard Callahan <richard at lucentsky.com> wrote:
> 
> Hi,
> 
> I have a specific question about the output from the Java Dependency Analysis Tool (JDeps), released with Open JDK 8. Thank you very much for such a marvelous tool!
> 
> I am parsing the output from JDeps with the "-v" flag set, such that a call to JDeps produces all class-level dependencies among and within a set of JAR files in a directory specified by the user. Consider a directed graph G constructed from the JDeps output, with the vertices representing nodes in the graph and the edges representing dependencies among the classes as specified in the JDeps output.  My question is, if a specific JAR file in the directory (call it A.jar) can compile using OpenJDK with the other JAR files in the directory designated as dependencies, then does there always exist at least one subgraph G' of G that corresponds to the dependency relationships that would be actually used by a Java compiler to compile A.jar? If the answer is "yes," then I believe I should be able to recover that graph by starting with the set of classes in A.jar and then constructing the subgraph G' in a manner similar to that used by a depth-first search.
> 
> Thank you for your time, I recognize it is valuable.
> 
> Best,
> 
> Richard


From mandy.chung at oracle.com  Tue Nov 10 18:04:55 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Nov 2015 10:04:55 -0800
Subject: RFR: 8139430
In-Reply-To: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
Message-ID: <27608F2A-6450-4F85-9F38-97D450B8FB23@oracle.com>

Hi Shura,

Thanks for doing it and it?s good to see the unnecessary dependency to java.management eliminated.

The new jdk.testlibrary.management package name is fine.  It?s okay to keep the class name InputArguments as Jaroslav suggests and it?s easier to tell what this class is about.

There is a copy of ProcessTools and InputArguments in the hotspot repository under
   hotspot/test/testlibrary/jdk/test/lib/

Are we planning to remove this duplicated copy?  If not, same patch should be applied to those copy.  It?s fine to separate this and push the hotspot test library change via hotspot-rt repo.  Christian can probably sponsor the patch for you.

I?ll sponsor the jdk change and push it to jdk9/dev once you send me an updated patch.

Mandy


> On Nov 9, 2015, at 10:12 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
> 
> Hi
> 
> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also:
> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/
> 
> Shura
> 
>> On Nov 9, 2015, at 8:54 PM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>> 
>> Hi,
>> 
>> This is one of the ways to fix 8139430: http://cr.openjdk.java.net/~shurailine/8139430/webrev.03
>> 
>> Could you please take a look on it?
>> 
>> A few comments. 
>> 
>> The biggest dependency on java.management was in jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method to use the new process API, which helped to avoid updating a lot of code.
>> 
>> I am moving the rest library code which depended on java.management and jdk.management  to a new ?management" subpackage of the jdk library: jdk.testlibrary.management. Another possibility I have considered is ?ext? or ?extended? subpackage, which would have all the classes which depend on anything but java.base. With ?ext? there would be no way to keep the desired granularity with the test modules dependencies.
>> 
>> The methods which worth moving fit well into two classes: 
>> jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method which previously belonged to the TestThread utility methods.
>> jdk.testlibrary.management.RuntimeMXBeanTool - previously named as jdk.testlibrary.InputArguments
>> 
>> None of moved/renamed test library methods were used anywhere in tests, so no test updates needed:
>> jdk.testlibrary.InputArguments is not used, instead every test which needs that functionality directly calls RuntimeMXBean.getInputArguments()
>> jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not used as there is a similar class outside of the test library:
>> ./closed/com/oracle/jfr/common/jrockit/TestThread.java
>> 
>> Please let me know what you think.
>> 
>> Shura
> 


From alexandre.iline at oracle.com  Tue Nov 10 18:11:30 2015
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Tue, 10 Nov 2015 21:11:30 +0300
Subject: RFR: 8139430
In-Reply-To: <27608F2A-6450-4F85-9F38-97D450B8FB23@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<27608F2A-6450-4F85-9F38-97D450B8FB23@oracle.com>
Message-ID: <90149651-7797-41FE-9B42-F913C8385A72@oracle.com>


> On Nov 10, 2015, at 9:04 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Hi Shura,
> 
> Thanks for doing it and it?s good to see the unnecessary dependency to java.management eliminated.
> 
> The new jdk.testlibrary.management package name is fine.  It?s okay to keep the class name InputArguments as Jaroslav suggests and it?s easier to tell what this class is about.
> 
> There is a copy of ProcessTools and InputArguments in the hotspot repository under
>   hotspot/test/testlibrary/jdk/test/lib/
> 
> Are we planning to remove this duplicated copy?  If not, same patch should be applied to those copy.  It?s fine to separate this and push the hotspot test library change via hotspot-rt repo.  Christian can probably sponsor the patch for you.

This is the bug to track the library merge:
https://bugs.openjdk.java.net/browse/JDK-8075327

It is there for a long time for discussion, so I would not suggest to wait for it. If a parallel fix is needed, I would rather just do it. 

> 
> I?ll sponsor the jdk change and push it to jdk9/dev once you send me an updated patch.

Yes, thank you.

Shura

> 
> Mandy
> 
> 
>> On Nov 9, 2015, at 10:12 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>> 
>> Hi
>> 
>> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also:
>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/
>> 
>> Shura
>> 
>>> On Nov 9, 2015, at 8:54 PM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> This is one of the ways to fix 8139430: http://cr.openjdk.java.net/~shurailine/8139430/webrev.03
>>> 
>>> Could you please take a look on it?
>>> 
>>> A few comments. 
>>> 
>>> The biggest dependency on java.management was in jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method to use the new process API, which helped to avoid updating a lot of code.
>>> 
>>> I am moving the rest library code which depended on java.management and jdk.management  to a new ?management" subpackage of the jdk library: jdk.testlibrary.management. Another possibility I have considered is ?ext? or ?extended? subpackage, which would have all the classes which depend on anything but java.base. With ?ext? there would be no way to keep the desired granularity with the test modules dependencies.
>>> 
>>> The methods which worth moving fit well into two classes: 
>>> jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method which previously belonged to the TestThread utility methods.
>>> jdk.testlibrary.management.RuntimeMXBeanTool - previously named as jdk.testlibrary.InputArguments
>>> 
>>> None of moved/renamed test library methods were used anywhere in tests, so no test updates needed:
>>> jdk.testlibrary.InputArguments is not used, instead every test which needs that functionality directly calls RuntimeMXBean.getInputArguments()
>>> jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not used as there is a similar class outside of the test library:
>>> ./closed/com/oracle/jfr/common/jrockit/TestThread.java
>>> 
>>> Please let me know what you think.
>>> 
>>> Shura
>> 
> 


From mandy.chung at oracle.com  Tue Nov 10 18:15:34 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Nov 2015 10:15:34 -0800
Subject: RFR: 8139430
In-Reply-To: <90149651-7797-41FE-9B42-F913C8385A72@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<27608F2A-6450-4F85-9F38-97D450B8FB23@oracle.com>
	<90149651-7797-41FE-9B42-F913C8385A72@oracle.com>
Message-ID: <118C0811-745B-424F-8DFE-45CB71A40213@oracle.com>


> On Nov 10, 2015, at 10:11 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
> 
>> 
>> On Nov 10, 2015, at 9:04 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 
>> Hi Shura,
>> 
>> Thanks for doing it and it?s good to see the unnecessary dependency to java.management eliminated.
>> 
>> The new jdk.testlibrary.management package name is fine.  It?s okay to keep the class name InputArguments as Jaroslav suggests and it?s easier to tell what this class is about.
>> 
>> There is a copy of ProcessTools and InputArguments in the hotspot repository under
>>  hotspot/test/testlibrary/jdk/test/lib/
>> 
>> Are we planning to remove this duplicated copy?  If not, same patch should be applied to those copy. It?s fine to separate this and push the hotspot test library change via hotspot-rt repo.  Christian can probably sponsor the patch for you.
> 
> This is the bug to track the library merge:
> https://bugs.openjdk.java.net/browse/JDK-8075327
> 
> It is there for a long time for discussion, so I would not suggest to wait for it. If a parallel fix is needed, I would rather just do it. 
> 

I agree.  I suggest to file a bug and apply this fix in the hotspot test library as a separate patch.

Mandy

From Alan.Bateman at oracle.com  Tue Nov 10 20:42:47 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Nov 2015 21:42:47 +0100
Subject: RFR: 8139430
In-Reply-To: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
Message-ID: <564256C7.60905@oracle.com>



On 09/11/2015 19:12, Alexandre (Shura) Iline wrote:
> Hi
>
> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also:
> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/
>
> Shura
>
I skimmed through the webrev and it looks okay. Assuming InputArguments 
is not renamed then you could rename containsPrefix to something like 
hasArgStartingWith or something that makes it clear what this method does.

Would it break many tests if getProcessId were changed to return long to 
match ProcessHandle::getPid?

When this is pushed then can we drop @modules java.management from any 
tests or were those changes held back assuming the dependency would be 
dropped?

-Alan.




From jonathan.gibbons at oracle.com  Tue Nov 10 22:19:49 2015
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 10 Nov 2015 22:19:49 +0000
Subject: hg: jigsaw/jake/langtools: 8140767: adding -XaddReads option to javac
Message-ID: <201511102219.tAAMJnUO007235@aojmv0008.oracle.com>

Changeset: 2c1838c6e03c
Author:    jlahoda
Date:      2015-11-10 14:19 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2c1838c6e03c

8140767: adding -XaddReads option to javac

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ModuleFinder.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
+ test/tools/javac/modules/AddReadsTest.java


From mandy.chung at oracle.com  Wed Nov 11 00:45:47 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Nov 2015 16:45:47 -0800
Subject: RFR: 8139430
In-Reply-To: <564256C7.60905@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<564256C7.60905@oracle.com>
Message-ID: <A04ECB77-F0B1-44E7-9777-8FA3FE962B99@oracle.com>


> On Nov 10, 2015, at 12:42 PM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> Would it break many tests if getProcessId were changed to return long to match ProcessHandle::getPid?

There are not small number of tests doing 
   Integer.toString(ProcessTools.getProcessId()));

Most of them are in hotspot and there are about 10 in jdk repo.   Perhaps the tests should simply be changed to call:
   ProcessHandle.current().getPid();

> 
> When this is pushed then can we drop @modules java.management from any tests or were those changes held back assuming the dependency would be dropped?

I think Shura prefers to do this patch on ProcessTools and update the dependency in another bulk update.   It?d be good if this can be done together.

Mandy


From weijun.wang at oracle.com  Wed Nov 11 02:20:43 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 11 Nov 2015 10:20:43 +0800
Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA
In-Reply-To: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com>
References: <CABBycTQf2g99bam+vq-oG0bWOzB3gAJsNtg6anmhdXuNN3OBQA@mail.gmail.com>
	<F51572CC-7F86-45AD-9C82-F64902AC03F4@oracle.com>
	<31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com>
Message-ID: <50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com>

Ping again.

Will the future JRE only include java.se? In other words, what will the java.com download for non-developers contain?

Thanks
Max

> On Nov 5, 2015, at 10:07 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
> I was talking with Vincent off the list, but it seems better to be back.
> 
> Here is Vincent's mail on how he thinks of the new API we are about to provide in JDK-8058778.
> 
>> The new API is interesting but if it's not available in Java SE I'm afraid it does not fit our use case. We cannot make JOSM depend on a JDK at runtime just for this feature :(
> 
> There might be some confusion on what "JDK" means. It used to be the developer's toolkit versus JRE the runtime, but as for module names, a jdk.* module contains APIs defined by OpenJDK instead of Java SE. In fact, most of them are not especially designed for developers.
> 
> That said, I am not exactly sure what kind of images we will release after jigsaw. If there is still a JRE, I think it will include not only the java.* modules but also some jdk.* ones. I hope jdk.security.cert is one of them.
> 
> Personally I am not afraid of using jdk.* modules, since almost every JDK distribution is based on OpenJDK. At least it is now a supported API of OpenJDK instead of old sun.* classes that were never claimed to be supported by anyone.
> 
> In fact, keytool was not defined in Java SE either. It was in JRE though.
> 
> Thanks
> Max


From Alan.Bateman at oracle.com  Wed Nov 11 07:24:05 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Nov 2015 08:24:05 +0100
Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA
In-Reply-To: <50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com>
References: <CABBycTQf2g99bam+vq-oG0bWOzB3gAJsNtg6anmhdXuNN3OBQA@mail.gmail.com>
	<F51572CC-7F86-45AD-9C82-F64902AC03F4@oracle.com>
	<31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com>
	<50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com>
Message-ID: <5642ED15.2050308@oracle.com>


On 11/11/2015 03:20, Wang Weijun wrote:
> Ping again.
>
> Will the future JRE only include java.se? In other words, what will the java.com download for non-developers contain?
>
This isn't really a quick for here. However, in your build environment 
then use jre/bin/java -listmods to see the full list of modules that are 
currently linked in. In the makes files then <top>/make/Images.gmk is 
the make file to check out, specifically the MAIN_MODULES and 
PROVIDER_MODULES as these are the set of root modules that will be 
resolved when creating the "jre" image.

-Alan.

From weijun.wang at oracle.com  Wed Nov 11 08:54:35 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 11 Nov 2015 16:54:35 +0800
Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA
In-Reply-To: <5642ED15.2050308@oracle.com>
References: <CABBycTQf2g99bam+vq-oG0bWOzB3gAJsNtg6anmhdXuNN3OBQA@mail.gmail.com>
	<F51572CC-7F86-45AD-9C82-F64902AC03F4@oracle.com>
	<31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com>
	<50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com>
	<5642ED15.2050308@oracle.com>
Message-ID: <D17CD418-D392-455F-AA8D-E8F04EE88074@oracle.com>


> On Nov 11, 2015, at 3:24 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> On 11/11/2015 03:20, Wang Weijun wrote:
>> Ping again.
>> 
>> Will the future JRE only include java.se? In other words, what will the java.com download for non-developers contain?
>> 
> This isn't really a quick for here. However, in your build environment then use jre/bin/java -listmods to see the full list of modules that are currently linked in. In the makes files then <top>/make/Images.gmk is the make file to check out, specifically the MAIN_MODULES and PROVIDER_MODULES as these are the set of root modules that will be resolved when creating the "jre" image.

Great, I see MAIN_MODULES contains quite some jdk.* modules.

Here comes the question: How do I request a new module to be included in it? The CCC for the new module/API?

Thanks
Max

> 
> -Alan.


From Alan.Bateman at oracle.com  Wed Nov 11 09:03:11 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Nov 2015 10:03:11 +0100
Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA
In-Reply-To: <D17CD418-D392-455F-AA8D-E8F04EE88074@oracle.com>
References: <CABBycTQf2g99bam+vq-oG0bWOzB3gAJsNtg6anmhdXuNN3OBQA@mail.gmail.com>
	<F51572CC-7F86-45AD-9C82-F64902AC03F4@oracle.com>
	<31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com>
	<50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com>
	<5642ED15.2050308@oracle.com>
	<D17CD418-D392-455F-AA8D-E8F04EE88074@oracle.com>
Message-ID: <5643044F.3030306@oracle.com>



On 11/11/2015 09:54, Wang Weijun wrote:
> :
>
> Here comes the question: How do I request a new module to be included in it? The CCC for the new module/API?
>
Can you cc jigsaw-dev on the changes to modules.xml? modules.xml is the 
temporary document that we have in JDK 9 to define the modular structure 
until the module system goes into the main line.

-Alan

From chris.hegarty at oracle.com  Wed Nov 11 09:13:36 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 11 Nov 2015 09:13:36 +0000
Subject: RFR: 8139430
In-Reply-To: <5641E139.9000209@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<5641E139.9000209@oracle.com>
Message-ID: <CA9BF65D-6D02-451C-88C4-142CA3069559@oracle.com>

On 10 Nov 2015, at 12:21, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:

> Hi,
> 
> On 9.11.2015 19:12, Alexandre (Shura) Iline wrote:
>> Hi
>> 
>> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also:
>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/

Looks good Shura, and it will be nice when the @modules in the tests
are cleaned up too.

Trivially, space missing in ProcessTools.java
   256         if[SPACE](pid == (int)pid) {

-Chris.

From erik.joelsson at oracle.com  Wed Nov 11 09:34:44 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 11 Nov 2015 09:34:44 +0000
Subject: hg: jigsaw/jake: 2 new changesets
Message-ID: <201511110934.tAB9YiJD018281@aojmv0008.oracle.com>

Changeset: 471d26171bcf
Author:    erikj
Date:      2015-11-11 10:24 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/471d26171bcf

Removing dead code

- make/CompileModuleInfos.gmk

Changeset: 887db7246c21
Author:    erikj
Date:      2015-11-11 10:24 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/887db7246c21

Fixed filtering of excluded modules

! make/GensrcModuleInfo.gmk
! make/Images.gmk


From weijun.wang at oracle.com  Wed Nov 11 10:07:50 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 11 Nov 2015 18:07:50 +0800
Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA
In-Reply-To: <5643044F.3030306@oracle.com>
References: <CABBycTQf2g99bam+vq-oG0bWOzB3gAJsNtg6anmhdXuNN3OBQA@mail.gmail.com>
	<F51572CC-7F86-45AD-9C82-F64902AC03F4@oracle.com>
	<31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com>
	<50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com>
	<5642ED15.2050308@oracle.com>
	<D17CD418-D392-455F-AA8D-E8F04EE88074@oracle.com>
	<5643044F.3030306@oracle.com>
Message-ID: <60BCE223-2D0C-4C0B-B49F-4B4FBB9AB1EA@oracle.com>


> On Nov 11, 2015, at 5:03 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 11/11/2015 09:54, Wang Weijun wrote:
>> :
>> 
>> Here comes the question: How do I request a new module to be included in it? The CCC for the new module/API?
>> 
> Can you cc jigsaw-dev on the changes to modules.xml? modules.xml is the temporary document that we have in JDK 9 to define the modular structure until the module system goes into the main line.

I'm prototyping in jake and the change is

src/java.base/share/classes/module-info.java:

     exports sun.security.util to
+        jdk.security.cert,
     exports sun.security.x509 to
+        jdk.security.cert,

src/jdk.security.cert/share/classes/module-info.java:

+module jdk.security.cert {
+    exports jdk.security.cert;
+}

--Max

> 
> -Alan


From Alan.Bateman at oracle.com  Wed Nov 11 11:01:55 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Nov 2015 12:01:55 +0100
Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA
In-Reply-To: <60BCE223-2D0C-4C0B-B49F-4B4FBB9AB1EA@oracle.com>
References: <CABBycTQf2g99bam+vq-oG0bWOzB3gAJsNtg6anmhdXuNN3OBQA@mail.gmail.com>
	<F51572CC-7F86-45AD-9C82-F64902AC03F4@oracle.com>
	<31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com>
	<50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com>
	<5642ED15.2050308@oracle.com>
	<D17CD418-D392-455F-AA8D-E8F04EE88074@oracle.com>
	<5643044F.3030306@oracle.com>
	<60BCE223-2D0C-4C0B-B49F-4B4FBB9AB1EA@oracle.com>
Message-ID: <56432023.2000102@oracle.com>



On 11/11/2015 11:07, Wang Weijun wrote:
> :
> I'm prototyping in jake and the change is
>
> src/java.base/share/classes/module-info.java:
>
>       exports sun.security.util to
> +        jdk.security.cert,
>       exports sun.security.x509 to
> +        jdk.security.cert,
>
> src/jdk.security.cert/share/classes/module-info.java:
>
> +module jdk.security.cert {
> +    exports jdk.security.cert;
> +}
>
>
Okay but is the jdk.security.cert API really tied to modules? If not 
then I assume this can be pushed via jdk9/dev and we can create the 
module declaration as part of sync'ing up the jake forest.

-Alan

From weijun.wang at oracle.com  Wed Nov 11 13:39:45 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 11 Nov 2015 21:39:45 +0800
Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA
In-Reply-To: <56432023.2000102@oracle.com>
References: <CABBycTQf2g99bam+vq-oG0bWOzB3gAJsNtg6anmhdXuNN3OBQA@mail.gmail.com>
	<F51572CC-7F86-45AD-9C82-F64902AC03F4@oracle.com>
	<31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com>
	<50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com>
	<5642ED15.2050308@oracle.com>
	<D17CD418-D392-455F-AA8D-E8F04EE88074@oracle.com>
	<5643044F.3030306@oracle.com>
	<60BCE223-2D0C-4C0B-B49F-4B4FBB9AB1EA@oracle.com>
	<56432023.2000102@oracle.com>
Message-ID: <3CDD8BBB-00F3-4797-9D34-8D1D2C2162B9@oracle.com>


> On Nov 11, 2015, at 7:01 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 11/11/2015 11:07, Wang Weijun wrote:
>> :
>> I'm prototyping in jake and the change is
>> 
>> src/java.base/share/classes/module-info.java:
>> 
>>      exports sun.security.util to
>> +        jdk.security.cert,
>>      exports sun.security.x509 to
>> +        jdk.security.cert,
>> 
>> src/jdk.security.cert/share/classes/module-info.java:
>> 
>> +module jdk.security.cert {
>> +    exports jdk.security.cert;
>> +}
>> 
>> 
> Okay but is the jdk.security.cert API really tied to modules?

No. I develop it in jake to make sure the API separation is clear and every test has correct @modules tags.

> If not then I assume this can be pushed via jdk9/dev and we can create the module declaration as part of sync'ing up the jake forest.

Sure, that is my plan.

--Max

> 
> -Alan


From alexandre.iline at oracle.com  Wed Nov 11 13:47:01 2015
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Wed, 11 Nov 2015 16:47:01 +0300
Subject: RFR: 8139430
In-Reply-To: <27608F2A-6450-4F85-9F38-97D450B8FB23@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<27608F2A-6450-4F85-9F38-97D450B8FB23@oracle.com>
Message-ID: <0927B2F7-E91C-4580-B8A5-F086508DF113@oracle.com>


> On Nov 10, 2015, at 9:04 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Hi Shura,
> 
> Thanks for doing it and it?s good to see the unnecessary dependency to java.management eliminated.
> 
> The new jdk.testlibrary.management package name is fine.  It?s okay to keep the class name InputArguments as Jaroslav suggests and it?s easier to tell what this class is about.

The reason I have refactored this is because there is more useful methods in RuntimeMXBean than just the getInputArguments(). If we are ever in a need in another library method dealing with RuntimeMXBean, then, a class RuntimeMXBeanTool, or similar, is a natural enough place to add them. Since also there is the ThreadMXBeanTool, it looks homogenous.

We can, of course, have the InputArguments class the way it is and still have other classes wrapping RuntimeMXBean calls.

http://cr.openjdk.java.net/~shurailine/8139430/webrev.05/

Shura

> 
> There is a copy of ProcessTools and InputArguments in the hotspot repository under
>   hotspot/test/testlibrary/jdk/test/lib/
> 
> Are we planning to remove this duplicated copy?  If not, same patch should be applied to those copy.  It?s fine to separate this and push the hotspot test library change via hotspot-rt repo.  Christian can probably sponsor the patch for you.
> 
> I?ll sponsor the jdk change and push it to jdk9/dev once you send me an updated patch.
> 
> Mandy
> 
> 
>> On Nov 9, 2015, at 10:12 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>> 
>> Hi
>> 
>> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also:
>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/
>> 
>> Shura
>> 
>>> On Nov 9, 2015, at 8:54 PM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> This is one of the ways to fix 8139430: http://cr.openjdk.java.net/~shurailine/8139430/webrev.03
>>> 
>>> Could you please take a look on it?
>>> 
>>> A few comments. 
>>> 
>>> The biggest dependency on java.management was in jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method to use the new process API, which helped to avoid updating a lot of code.
>>> 
>>> I am moving the rest library code which depended on java.management and jdk.management  to a new ?management" subpackage of the jdk library: jdk.testlibrary.management. Another possibility I have considered is ?ext? or ?extended? subpackage, which would have all the classes which depend on anything but java.base. With ?ext? there would be no way to keep the desired granularity with the test modules dependencies.
>>> 
>>> The methods which worth moving fit well into two classes: 
>>> jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method which previously belonged to the TestThread utility methods.
>>> jdk.testlibrary.management.RuntimeMXBeanTool - previously named as jdk.testlibrary.InputArguments
>>> 
>>> None of moved/renamed test library methods were used anywhere in tests, so no test updates needed:
>>> jdk.testlibrary.InputArguments is not used, instead every test which needs that functionality directly calls RuntimeMXBean.getInputArguments()
>>> jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not used as there is a similar class outside of the test library:
>>> ./closed/com/oracle/jfr/common/jrockit/TestThread.java
>>> 
>>> Please let me know what you think.
>>> 
>>> Shura
>> 
> 


From sundararajan.athijegannathan at oracle.com  Wed Nov 11 15:46:00 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 11 Nov 2015 21:16:00 +0530
Subject: RFR 8141521: jrt file system's DirectoryStream reports child
	paths with wrong paths for directories under /packages
In-Reply-To: <563B76FB.4020709@oracle.com>
References: <563B254A.7090001@oracle.com> <563B76FB.4020709@oracle.com>
Message-ID: <564362B8.5050708@oracle.com>

Hi,

Please find the updated webrev @ 
http://cr.openjdk.java.net/~sundar/8141521/webrev.01/

* Removed NodeAndImage and related stuff. Using just Node always. Using 
resolve in DirectoryStream - just "file" names of child Nodes appended 
to parent dir now.

* Using AbstractJrtPath in many places instead of byte[] and converting 
to getResolvedPath whereever jimage Node lookup has to be done.

* Expanded Basic.java /packages tests with "..", "." in the path etc. 
All cases pass now.

* Reduced long line length in places.

PS. Got distracted by another bug in UTF8String.toString - which I'm 
fixing as part of the new webrev! That caused the delay in debugging 
test issues [apart from holidays in between]

Thanks,
-Sundar

On 11/5/2015 9:04 PM, Alan Bateman wrote:
>
>
> On 05/11/2015 09:45, Sundararajan Athijegannathan wrote:
>> Please review http://cr.openjdk.java.net/~sundar/8141521/webrev.00/ 
>> for https://bugs.openjdk.java.net/browse/JDK-8141521
> The NodeAndImage.symLink field looks very strange as a DirectoryStream 
> just needs the names of the entries where each is resolved against the 
> Path that newDirectoryStream is called on. I just wonder how it works 
> with a combination of "." and ".." and other interesting paths.
>
> In the test then shouldn't L608 be child.startsWith(path) as this 
> should not be a String comparison. I also wonder having a much more 
> expanded test for newDirectoryStream as this should have been caught 
> by unit tests.
>
> BTW: A small request but would it be possible to reduce the length of 
> the some of the really long lines. It makes it a bit easier to do 
> side-by-side reviews when there isn't horizontal scrolling.
>
> -Alan


From alexandre.iline at oracle.com  Wed Nov 11 16:41:44 2015
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Wed, 11 Nov 2015 19:41:44 +0300
Subject: RFR: 8139430
In-Reply-To: <564256C7.60905@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<564256C7.60905@oracle.com>
Message-ID: <CBB16E61-EB4B-4BF1-9696-0D2A4DADEBA9@oracle.com>


> On Nov 10, 2015, at 11:42 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 09/11/2015 19:12, Alexandre (Shura) Iline wrote:
>> Hi
>> 
>> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also:
>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/
>> 
>> Shura
>> 
> I skimmed through the webrev and it looks okay. Assuming InputArguments is not renamed then you could rename containsPrefix to something like hasArgStartingWith or something that makes it clear what this method does.
> 
> Would it break many tests if getProcessId were changed to return long to match ProcessHandle::getPid?

Yes, there are a few places only, actually. Let me also fix those.

Shura

> 
> When this is pushed then can we drop @modules java.management from any tests or were those changes held back assuming the dependency would be dropped?
> 
> -Alan.
> 
> 
> 


From jonathan.gibbons at oracle.com  Wed Nov 11 23:29:13 2015
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 11 Nov 2015 23:29:13 +0000
Subject: hg: jigsaw/jake/langtools: Setting UsesProviderCompleter to
	ModuleSymbol.usesProvidersCompleter, to avoid running it too soon.
Message-ID: <201511112329.tABNTDat026610@aojmv0008.oracle.com>

Changeset: 7c66438d4d8a
Author:    jlahoda
Date:      2015-11-11 15:27 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7c66438d4d8a

Setting UsesProviderCompleter to ModuleSymbol.usesProvidersCompleter, to avoid running it too soon.

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! test/tools/javac/modules/AddReadsTest.java


From patrick at reini.net  Thu Nov 12 10:39:09 2015
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 12 Nov 2015 11:39:09 +0100
Subject: Proposal to enhance jdeps tool to search split packages/add some kind
	of general API
Message-ID: <BB261C69-BBB6-49E0-B3B2-153AA965AA85@reini.net>

Hi there,

I like to do some early adoption tests with software using the new module system. Now we got an unknown amount of split packages in our system, the we will need to fix in order to migrate our codebase.

I could imagine, that there are other potential users of the JDK, that have the same problem to solve. So I think it would be a good thing to have some detection within the jdeps tool or even have some kind of an API that could be used otherwise (as of in a IDE).

Now I wanted to know what you think about this? I would also be prepared to do some work in that area.

? Patrick

From weijun.wang at oracle.com  Thu Nov 12 13:41:16 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 12 Nov 2015 21:41:16 +0800
Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA
In-Reply-To: <3CDD8BBB-00F3-4797-9D34-8D1D2C2162B9@oracle.com>
References: <CABBycTQf2g99bam+vq-oG0bWOzB3gAJsNtg6anmhdXuNN3OBQA@mail.gmail.com>
	<F51572CC-7F86-45AD-9C82-F64902AC03F4@oracle.com>
	<31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com>
	<50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com>
	<5642ED15.2050308@oracle.com>
	<D17CD418-D392-455F-AA8D-E8F04EE88074@oracle.com>
	<5643044F.3030306@oracle.com>
	<60BCE223-2D0C-4C0B-B49F-4B4FBB9AB1EA@oracle.com>
	<56432023.2000102@oracle.com>
	<3CDD8BBB-00F3-4797-9D34-8D1D2C2162B9@oracle.com>
Message-ID: <609A0AD3-DA4F-44CE-93F5-00A001079FEC@oracle.com>

make/Images.gmk uses both JDK_COMPACTn and JRE_COMPACTn. Should it be only JRE_COMPACTn?

--Max


From scolebourne at joda.org  Thu Nov 12 13:50:49 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 12 Nov 2015 13:50:49 +0000
Subject: Annotations across modules
Message-ID: <CACzrW9CvQu0O=eVsuEb9PQRgoB+Zk2+p+idmgFgcQpSPqL+N5Q@mail.gmail.com>

My understanding of annotations today is that annotations are not
required at runtime. ie. if an annotation is placed into a class at
compile time but the .class file for the annotation is not available
on the runtime classpath. then there is no error.

Does this change in any way with modules?

My specific case is wrt @ConstructorProperties which is in java.beans.
In 9, a user may run my software without the java.beans module. Can I
safely assume that if the annotation is available on the compile
module path but not the runtime module path, everything will be OK
(ie. no error)?

thanks
Stephen

From jean-francois.denise at oracle.com  Thu Nov 12 14:10:25 2015
From: jean-francois.denise at oracle.com (jean-francois.denise at oracle.com)
Date: Thu, 12 Nov 2015 14:10:25 +0000
Subject: hg: jigsaw/jake/jdk: Fix for 8142485. Jake doesn't build on Windows
	after recent change to libjimage
Message-ID: <201511121410.tACEAPqx001282@aojmv0008.oracle.com>

Changeset: 1b50ccfd6f27
Author:    jfdenise
Date:      2015-11-12 15:00 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1b50ccfd6f27

Fix for 8142485. Jake doesn't build on Windows after recent change to libjimage
Reviewed-by: jlaskey

! src/java.base/share/native/libjimage/imageDecompressor.cpp


From Roger.Riggs at Oracle.com  Thu Nov 12 15:20:02 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Nov 2015 10:20:02 -0500
Subject: RFR 9: 8141571 : jdk/internal/jimage/JImageReadTest.java crashing in
	msvcr120.dll
Message-ID: <5644AE22.4030803@Oracle.com>

Please review additions to jimageFile to diagnose an intermittent failure.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-jimage-segv-8141571/

Issue:
   https://bugs.openjdk.java.net/browse/JDK-8141571

Thanks, Roger



From alex.buckley at oracle.com  Thu Nov 12 19:53:10 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 12 Nov 2015 11:53:10 -0800
Subject: Annotations across modules
In-Reply-To: <CACzrW9CvQu0O=eVsuEb9PQRgoB+Zk2+p+idmgFgcQpSPqL+N5Q@mail.gmail.com>
References: <CACzrW9CvQu0O=eVsuEb9PQRgoB+Zk2+p+idmgFgcQpSPqL+N5Q@mail.gmail.com>
Message-ID: <5644EE26.7060107@oracle.com>

On 11/12/2015 5:50 AM, Stephen Colebourne wrote:
> My understanding of annotations today is that annotations are not
> required at runtime. ie. if an annotation is placed into a class at
> compile time but the .class file for the annotation is not available
> on the runtime classpath. then there is no error.
>
> Does this change in any way with modules?

No.

> My specific case is wrt @ConstructorProperties which is in java.beans.
> In 9, a user may run my software without the java.beans module. Can I
> safely assume that if the annotation is available on the compile
> module path but not the runtime module path, everything will be OK
> (ie. no error)?

Yes, subject to assumptions that your software doesn't crash if it can't 
get a Class object for the java.beans.ConstructorProperties annotation type.

The fact that the java.beans package is part of the huge java.desktop 
module (due to unfortunate use of AWT types in Beans signatures) is the 
reason why JMX recently introduced its own annotation type for 
constructor properties (javax.management.ConstructorParameters). With an 
eye on behavioral compatibility, some JMX spec work was needed to 
account for when the @java.beans.ConstructorProperties annotation is 
present but the java.beans.ConstructorProperties annotation type is not 
available. See the discussion around JDK-7199353 at 
http://mail.openjdk.java.net/pipermail/jmx-dev/2015-October/thread.html.

Alex

From sundararajan.athijegannathan at oracle.com  Fri Nov 13 01:33:02 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 13 Nov 2015 07:03:02 +0530
Subject: RFR 8141521: jrt file system's DirectoryStream reports child
	paths with wrong paths for directories under /packages
In-Reply-To: <564362B8.5050708@oracle.com>
References: <563B254A.7090001@oracle.com> <563B76FB.4020709@oracle.com>
	<564362B8.5050708@oracle.com>
Message-ID: <56453DCE.9010901@oracle.com>

May I get review(s) on the updated webrev please?

http://cr.openjdk.java.net/~sundar/8141521/webrev.01/

Thanks,
-Sundar

On 11/11/2015 9:16 PM, Sundararajan Athijegannathan wrote:
> Hi,
>
> Please find the updated webrev @ 
> http://cr.openjdk.java.net/~sundar/8141521/webrev.01/
>
> * Removed NodeAndImage and related stuff. Using just Node always. 
> Using resolve in DirectoryStream - just "file" names of child Nodes 
> appended to parent dir now.
>
> * Using AbstractJrtPath in many places instead of byte[] and 
> converting to getResolvedPath whereever jimage Node lookup has to be 
> done.
>
> * Expanded Basic.java /packages tests with "..", "." in the path etc. 
> All cases pass now.
>
> * Reduced long line length in places.
>
> PS. Got distracted by another bug in UTF8String.toString - which I'm 
> fixing as part of the new webrev! That caused the delay in debugging 
> test issues [apart from holidays in between]
>
> Thanks,
> -Sundar
>
> On 11/5/2015 9:04 PM, Alan Bateman wrote:
>>
>>
>> On 05/11/2015 09:45, Sundararajan Athijegannathan wrote:
>>> Please review http://cr.openjdk.java.net/~sundar/8141521/webrev.00/ 
>>> for https://bugs.openjdk.java.net/browse/JDK-8141521
>> The NodeAndImage.symLink field looks very strange as a 
>> DirectoryStream just needs the names of the entries where each is 
>> resolved against the Path that newDirectoryStream is called on. I 
>> just wonder how it works with a combination of "." and ".." and other 
>> interesting paths.
>>
>> In the test then shouldn't L608 be child.startsWith(path) as this 
>> should not be a String comparison. I also wonder having a much more 
>> expanded test for newDirectoryStream as this should have been caught 
>> by unit tests.
>>
>> BTW: A small request but would it be possible to reduce the length of 
>> the some of the really long lines. It makes it a bit easier to do 
>> side-by-side reviews when there isn't horizontal scrolling.
>>
>> -Alan
>


From mandy.chung at oracle.com  Fri Nov 13 02:49:43 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 12 Nov 2015 18:49:43 -0800
Subject: Proposal to enhance jdeps tool to search split packages/add some
	kind of general API
In-Reply-To: <BB261C69-BBB6-49E0-B3B2-153AA965AA85@reini.net>
References: <BB261C69-BBB6-49E0-B3B2-153AA965AA85@reini.net>
Message-ID: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com>


> On Nov 12, 2015, at 2:39 AM, Patrick Reinhart <patrick at reini.net> wrote:
> 
> Hi there,
> 
> I like to do some early adoption tests with software using the new module system. Now we got an unknown amount of split packages in our system, the we will need to fix in order to migrate our codebase.
> 
> I could imagine, that there are other potential users of the JDK, that have the same problem to solve. So I think it would be a good thing to have some detection within the jdeps tool or even have some kind of an API that could be used otherwise (as of in a IDE).
> 
> Now I wanted to know what you think about this? I would also be prepared to do some work in that area.

A tool to detect split packages and some other characteristics to aid migration to modules would be useful.   I tend to think that belongs to a different tool that can build other additional analysis in it.

For split packages, it?d be useful to differentiate if the split package contains overlapping classes vs partitioned classes.   For partitioned classes, renaming the package would likely be one solution if it doesn?t need to live in a specific namespace.  For overlapping classes, one possibility is that the class path contains multiple copies of the same version or different version or patched version of a library, or redistribution.

Mandy

From mandy.chung at oracle.com  Fri Nov 13 02:55:22 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Fri, 13 Nov 2015 02:55:22 +0000
Subject: hg: jigsaw/jake/jdk: Backout compressed resource header length change
	that breaks windows build
Message-ID: <201511130255.tAD2tME8020503@aojmv0008.oracle.com>

Changeset: 103e023995ba
Author:    mchung
Date:      2015-11-12 18:51 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/103e023995ba

Backout compressed resource header length change that breaks windows build

! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java
! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java
! src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java
! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java
! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp
! src/java.base/share/native/libjimage/imageDecompressor.cpp
! src/java.base/share/native/libjimage/imageDecompressor.hpp
! src/java.base/share/native/libjimage/imageFile.cpp


From jonathan.gibbons at oracle.com  Fri Nov 13 03:30:50 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 12 Nov 2015 19:30:50 -0800
Subject: Proposal to enhance jdeps tool to search split packages/add some
	kind of general API
In-Reply-To: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com>
References: <BB261C69-BBB6-49E0-B3B2-153AA965AA85@reini.net>
	<156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com>
Message-ID: <5645596A.80907@oracle.com>



On 11/12/2015 06:49 PM, Mandy Chung wrote:
>> On Nov 12, 2015, at 2:39 AM, Patrick Reinhart <patrick at reini.net> wrote:
>>
>> Hi there,
>>
>> I like to do some early adoption tests with software using the new module system. Now we got an unknown amount of split packages in our system, the we will need to fix in order to migrate our codebase.
>>
>> I could imagine, that there are other potential users of the JDK, that have the same problem to solve. So I think it would be a good thing to have some detection within the jdeps tool or even have some kind of an API that could be used otherwise (as of in a IDE).
>>
>> Now I wanted to know what you think about this? I would also be prepared to do some work in that area.
> A tool to detect split packages and some other characteristics to aid migration to modules would be useful.   I tend to think that belongs to a different tool that can build other additional analysis in it.
>
> For split packages, it?d be useful to differentiate if the split package contains overlapping classes vs partitioned classes.   For partitioned classes, renaming the package would likely be one solution if it doesn?t need to live in a specific namespace.  For overlapping classes, one possibility is that the class path contains multiple copies of the same version or different version or patched version of a library, or redistribution.
>
> Mandy

I think it would be good to have a "class path analysis tool" that can 
take a classpath, and report which packages are found in which entries 
on the classpath, and whether any packages are split between multiple 
entries, or whether any packages are completely by hidden by earlier 
entries.

-- Jon


From Alan.Bateman at oracle.com  Fri Nov 13 06:49:06 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Nov 2015 07:49:06 +0100
Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA
In-Reply-To: <609A0AD3-DA4F-44CE-93F5-00A001079FEC@oracle.com>
References: <CABBycTQf2g99bam+vq-oG0bWOzB3gAJsNtg6anmhdXuNN3OBQA@mail.gmail.com>
	<F51572CC-7F86-45AD-9C82-F64902AC03F4@oracle.com>
	<31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com>
	<50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com>
	<5642ED15.2050308@oracle.com>
	<D17CD418-D392-455F-AA8D-E8F04EE88074@oracle.com>
	<5643044F.3030306@oracle.com>
	<60BCE223-2D0C-4C0B-B49F-4B4FBB9AB1EA@oracle.com>
	<56432023.2000102@oracle.com>
	<3CDD8BBB-00F3-4797-9D34-8D1D2C2162B9@oracle.com>
	<609A0AD3-DA4F-44CE-93F5-00A001079FEC@oracle.com>
Message-ID: <564587E2.1030007@oracle.com>

On 12/11/2015 14:41, Wang Weijun wrote:
> make/Images.gmk uses both JDK_COMPACTn and JRE_COMPACTn. Should it be only JRE_COMPACTn?
>
Yes, Images.gmk should be more consistent in the naming of its variables.

-Alan

From Alan.Bateman at oracle.com  Fri Nov 13 08:20:15 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Nov 2015 09:20:15 +0100
Subject: Proposal to enhance jdeps tool to search split packages/add some
	kind of general API
In-Reply-To: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com>
References: <BB261C69-BBB6-49E0-B3B2-153AA965AA85@reini.net>
	<156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com>
Message-ID: <56459D3F.6040408@oracle.com>

On 13/11/2015 03:49, Mandy Chung wrote:
> :
> A tool to detect split packages and some other characteristics to aid 
> migration to modules would be useful. I tend to think that belongs to 
> a different tool that can build other additional analysis in it.
I was chatting briefly with Patrick about this at Devoxx. For detecting 
split packages on a class path then I agree, it feels like another tool 
because it doesn't have to do any static analysis of the classes. More 
generally, I expect there will be many ideas and suggestions for things 
that jdeps could do. If we get to the point where it has an API then at 
least some of these ideas could be developed as tools that use the API.

-Alan

From patrick at reini.net  Fri Nov 13 09:03:42 2015
From: patrick at reini.net (Patrick Reinhart)
Date: Fri, 13 Nov 2015 10:03:42 +0100
Subject: Proposal to enhance jdeps tool to search split packages/add some
	kind of general API
In-Reply-To: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com>
References: <BB261C69-BBB6-49E0-B3B2-153AA965AA85@reini.net>
	<156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com>
Message-ID: <9C036A95-6AF7-4888-BAD9-31B294F825B7@reini.net>


> Am 13.11.2015 um 03:49 schrieb Mandy Chung <mandy.chung at oracle.com>:
> 
>> On Nov 12, 2015, at 2:39 AM, Patrick Reinhart <patrick at reini.net> wrote:
>> 
>> Hi there,
>> 
>> I like to do some early adoption tests with software using the new module system. Now we got an unknown amount of split packages in our system, the we will need to fix in order to migrate our codebase.
>> 
>> I could imagine, that there are other potential users of the JDK, that have the same problem to solve. So I think it would be a good thing to have some detection within the jdeps tool or even have some kind of an API that could be used otherwise (as of in a IDE).
>> 
>> Now I wanted to know what you think about this? I would also be prepared to do some work in that area.
> 
> A tool to detect split packages and some other characteristics to aid migration to modules would be useful.   I tend to think that belongs to a different tool that can build other additional analysis in it.

I see your point there. I firstly just thought of the jdeps tool mainly, because you have to go thru the at least the same jar files. It sure can be done in a separate tool and it

> For split packages, it?d be useful to differentiate if the split package contains overlapping classes vs partitioned classes.   For partitioned classes, renaming the package would likely be one solution if it doesn?t need to live in a specific namespace.  For overlapping classes, one possibility is that the class path contains multiple copies of the same version or different version or patched version of a library, or redistribution.

I do not actually understand, what you mean by overlapping vs. partitioned ones? I somehow did not got it?

Patrick

From rafael.wth at gmail.com  Fri Nov 13 12:04:06 2015
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 13 Nov 2015 13:04:06 +0100
Subject: Locating a class file from a class loader by name
Message-ID: <CA+DM0Amj+cLFDkaga9uKyzt3Yf_zqxa1N-=ouHpVP4oxPv8QTQ@mail.gmail.com>

Hello,

I recently started testing several byte code manipulation frameworks
against a recent build of Jigsaw and found a common problem of all of these
libraries. I am myself the developer of Byte Buddy (
https://github.com/raphw/byte-buddy) and I know most tools for code
manipulation fairly well. I hope that this mailing list can provide me some
me advice on patching my library and providing help to other maintainers.

Especially in the context of using the instrumentation API, it is often not
possible to do reflection on load classes. Rather, code manipulation tools
read Java class files and parse these files for exposing classes using a
similar API but without the possibility to invoke a method or to read a
field.

Typically these tools read Java class files by querying a class loader for
the class file, e.g.:

ClassLoader.getSystemClassLoader("java/lang/Object.class");

This does not longer work using Jigsaw and I wonder how one is now supposed
to locate a class file. Do I need to find all runtime images and query each
single one? How would the path be for such a class file?

Thank you for your help!
Best regards, Rafael

From james.laskey at oracle.com  Fri Nov 13 13:29:34 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 13 Nov 2015 09:29:34 -0400
Subject: RFR 9: 8141571 : jdk/internal/jimage/JImageReadTest.java crashing
	in msvcr120.dll
In-Reply-To: <5644AE22.4030803@Oracle.com>
References: <5644AE22.4030803@Oracle.com>
Message-ID: <4B3A2B61-BF74-4BB2-A45D-802DCCB97033@oracle.com>

+1

> On Nov 12, 2015, at 11:20 AM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Please review additions to jimageFile to diagnose an intermittent failure.
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-jimage-segv-8141571/
> 
> Issue:
>  https://bugs.openjdk.java.net/browse/JDK-8141571
> 
> Thanks, Roger
> 
> 


From sergei.pikalev at oracle.com  Fri Nov 13 13:50:11 2015
From: sergei.pikalev at oracle.com (Sergei Pikalev)
Date: Fri, 13 Nov 2015 16:50:11 +0300
Subject: RFR 8135972: Implement new tests for native libjimage library
Message-ID: <5645EA93.5040102@oracle.com>


Hello,

This is the code with new tests for libjimage native library.

A webrev with the tests is here:

http://cr.openjdk.java.net/~jlaskey/8135972/webrev.00/index.html

Please review.

Thanks,
     Sergei


From Alan.Bateman at oracle.com  Fri Nov 13 14:12:14 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Nov 2015 14:12:14 +0000
Subject: RFR 8135972: Implement new tests for native libjimage library
In-Reply-To: <5645EA93.5040102@oracle.com>
References: <5645EA93.5040102@oracle.com>
Message-ID: <5645EFBE.1060903@oracle.com>

On 13/11/2015 13:50, Sergei Pikalev wrote:
>
> Hello,
>
> This is the code with new tests for libjimage native library.
>
> A webrev with the tests is here:
>
> http://cr.openjdk.java.net/~jlaskey/8135972/webrev.00/index.html

Are there tests passing cleanly on all platforms? At least some of them 
seems to be passing bad values to native methods that take memory addresses.

Are the tests tied to changes in jigsaw/jake or can these tests go into 
jdk9/dev to follow the jimage changes that are also going in via that route?

-Alan

From florian.trossbach at codecentric.de  Fri Nov 13 14:56:57 2015
From: florian.trossbach at codecentric.de (=?UTF-8?Q?Florian_Tro=C3=9Fbach?=)
Date: Fri, 13 Nov 2015 15:56:57 +0100
Subject: Question about javac and modules exporting the same packages at
	compile time
Message-ID: <CAPD9FEf7jH69mtyU9nCGfdVrXtJPzHK8euyE=595pvE9T8pyUQ@mail.gmail.com>

Hi,

Playing a bit more with Jigsaw, i was surprised by the behaviour of javac
and would like to inquire about the motivation for this.

I have three modules. One module reads the other two which have different
module names but are otherwise identical. Compiling this, I get a load of
compiler warnings about the same packages, but it compiles just fine. I
assume it compiles it against the first version of a class it finds.

When I run the application, I get a java.lang.module.ResolutionException,
so this is good. My question is though - this could have been a compile
error too, but the compiler tolerates it. What is the motivation behind
this?

Best regards,
Florian

From harold.seigel at oracle.com  Fri Nov 13 14:57:21 2015
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 13 Nov 2015 09:57:21 -0500
Subject: RFR 9: 8141571 : jdk/internal/jimage/JImageReadTest.java crashing
	in msvcr120.dll
In-Reply-To: <5644AE22.4030803@Oracle.com>
References: <5644AE22.4030803@Oracle.com>
Message-ID: <5645FA51.4010800@oracle.com>

Hi Roger,

The changes look good.

Eventually, will the out-of-memory asserts be replaced with an error in 
order to handle OOM's that occur in production code?

Thanks, Harold

On 11/12/2015 10:20 AM, Roger Riggs wrote:
> Please review additions to jimageFile to diagnose an intermittent 
> failure.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-jimage-segv-8141571/
>
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8141571
>
> Thanks, Roger
>
>


From Roger.Riggs at Oracle.com  Fri Nov 13 15:56:33 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 13 Nov 2015 10:56:33 -0500
Subject: RFR 9: 8141571 : jdk/internal/jimage/JImageReadTest.java crashing
	in msvcr120.dll
In-Reply-To: <5645FA51.4010800@oracle.com>
References: <5644AE22.4030803@Oracle.com> <5645FA51.4010800@oracle.com>
Message-ID: <56460831.4040905@Oracle.com>

Hi Harold,

Yes, this area still needs work; the JIMAGE_xxx functions are called 
from the VM classloader and
need to have the appropriate failure modes.

Roger


On 11/13/2015 9:57 AM, harold seigel wrote:
> Hi Roger,
>
> The changes look good.
>
> Eventually, will the out-of-memory asserts be replaced with an error 
> in order to handle OOM's that occur in production code?
>
> Thanks, Harold
>
> On 11/12/2015 10:20 AM, Roger Riggs wrote:
>> Please review additions to jimageFile to diagnose an intermittent 
>> failure.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-jimage-segv-8141571/
>>
>> Issue:
>>   https://bugs.openjdk.java.net/browse/JDK-8141571
>>
>> Thanks, Roger
>>
>>
>


From Alan.Bateman at oracle.com  Fri Nov 13 16:00:17 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Nov 2015 16:00:17 +0000
Subject: Locating a class file from a class loader by name
In-Reply-To: <CA+DM0Amj+cLFDkaga9uKyzt3Yf_zqxa1N-=ouHpVP4oxPv8QTQ@mail.gmail.com>
References: <CA+DM0Amj+cLFDkaga9uKyzt3Yf_zqxa1N-=ouHpVP4oxPv8QTQ@mail.gmail.com>
Message-ID: <56460911.8000300@oracle.com>

On 13/11/2015 12:04, Rafael Winterhalter wrote:
> Hello,
>
> I recently started testing several byte code manipulation frameworks
> against a recent build of Jigsaw and found a common problem of all of these
> libraries. I am myself the developer of Byte Buddy (
> https://github.com/raphw/byte-buddy) and I know most tools for code
> manipulation fairly well. I hope that this mailing list can provide me some
> me advice on patching my library and providing help to other maintainers.
>
> Especially in the context of using the instrumentation API, it is often not
> possible to do reflection on load classes. Rather, code manipulation tools
> read Java class files and parse these files for exposing classes using a
> similar API but without the possibility to invoke a method or to read a
> field.
>
> Typically these tools read Java class files by querying a class loader for
> the class file, e.g.:
>
> ClassLoader.getSystemClassLoader("java/lang/Object.class");
>
> This does not longer work using Jigsaw and I wonder how one is now supposed
> to locate a class file. Do I need to find all runtime images and query each
> single one? How would the path be for such a class file?
>
Java agents that do byte code instrumentation with java.lang.instrument 
should continue to work, this goes for both load-time and dynamic 
instrumentation and also where the code is instrumented to calling into 
supporting classes on the class path. There is still work to do for the 
scenario where agents modify the classes with references to types in 
other modules but that will come in time.

As regards ClassLoader.getResourceXXX (which I think is what you mean) 
then it continues to search the class path as before. It doesn't however 
locate resources in named modules because they are encapsulated. The 
same named methods in java.lang.Class to get resources allow code to get 
at resources in its own module but not other modules. As to how to get 
at resources in named modules then there are a few ways but the simplest 
for now is to look at java.lang.reflect.Module getResourceAsStream.

-Alan


From rafael.wth at gmail.com  Fri Nov 13 17:48:00 2015
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 13 Nov 2015 18:48:00 +0100
Subject: Locating a class file from a class loader by name
In-Reply-To: <56460911.8000300@oracle.com>
References: <CA+DM0Amj+cLFDkaga9uKyzt3Yf_zqxa1N-=ouHpVP4oxPv8QTQ@mail.gmail.com>
	<56460911.8000300@oracle.com>
Message-ID: <CA+DM0AnrxAJ7pvAeRnxK6J6nP27Z4X8=uSc7pYDTLwXpkPeyVg@mail.gmail.com>

Hi Alan,
thanks for your quick answer. I am less worried about the generated code
then I am about the generation process.

For example, a ClassFileTransformer might want to instrument all classes
that implement a certain interface. For this, the transformer needs to
parse the provided class file, extract the interfaces and locate their
class files and so forth in order to resolve the type hierarchy. For this,
it is now possible to query the ClassLoader which is an argument provided
to the transformer. I do not know how I would access the module at this
point or get hold of the class file.

Also, I would expect that a Java agent that worked in Java 8 would also
work in Java 9. If I had to use Java 9 APIs in order to patch my
application, I would be required to offer two versions of my library, one
for Java 9+ and one for Java 8-. That would be unfortunate.

Do I see this correctly?
Thank you, best regards, Rafael

2015-11-13 17:00 GMT+01:00 Alan Bateman <Alan.Bateman at oracle.com>:

> On 13/11/2015 12:04, Rafael Winterhalter wrote:
>
>> Hello,
>>
>> I recently started testing several byte code manipulation frameworks
>> against a recent build of Jigsaw and found a common problem of all of
>> these
>> libraries. I am myself the developer of Byte Buddy (
>> https://github.com/raphw/byte-buddy) and I know most tools for code
>> manipulation fairly well. I hope that this mailing list can provide me
>> some
>> me advice on patching my library and providing help to other maintainers.
>>
>> Especially in the context of using the instrumentation API, it is often
>> not
>> possible to do reflection on load classes. Rather, code manipulation tools
>> read Java class files and parse these files for exposing classes using a
>> similar API but without the possibility to invoke a method or to read a
>> field.
>>
>> Typically these tools read Java class files by querying a class loader for
>> the class file, e.g.:
>>
>> ClassLoader.getSystemClassLoader("java/lang/Object.class");
>>
>> This does not longer work using Jigsaw and I wonder how one is now
>> supposed
>> to locate a class file. Do I need to find all runtime images and query
>> each
>> single one? How would the path be for such a class file?
>>
>> Java agents that do byte code instrumentation with java.lang.instrument
> should continue to work, this goes for both load-time and dynamic
> instrumentation and also where the code is instrumented to calling into
> supporting classes on the class path. There is still work to do for the
> scenario where agents modify the classes with references to types in other
> modules but that will come in time.
>
> As regards ClassLoader.getResourceXXX (which I think is what you mean)
> then it continues to search the class path as before. It doesn't however
> locate resources in named modules because they are encapsulated. The same
> named methods in java.lang.Class to get resources allow code to get at
> resources in its own module but not other modules. As to how to get at
> resources in named modules then there are a few ways but the simplest for
> now is to look at java.lang.reflect.Module getResourceAsStream.
>
> -Alan
>
>

From Alan.Bateman at oracle.com  Fri Nov 13 18:28:33 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Nov 2015 18:28:33 +0000
Subject: Locating a class file from a class loader by name
In-Reply-To: <CA+DM0AnrxAJ7pvAeRnxK6J6nP27Z4X8=uSc7pYDTLwXpkPeyVg@mail.gmail.com>
References: <CA+DM0Amj+cLFDkaga9uKyzt3Yf_zqxa1N-=ouHpVP4oxPv8QTQ@mail.gmail.com>
	<56460911.8000300@oracle.com>
	<CA+DM0AnrxAJ7pvAeRnxK6J6nP27Z4X8=uSc7pYDTLwXpkPeyVg@mail.gmail.com>
Message-ID: <56462BD1.4030209@oracle.com>

On 13/11/2015 17:48, Rafael Winterhalter wrote:
> Hi Alan,
> thanks for your quick answer. I am less worried about the generated 
> code then I am about the generation process.
>
> For example, a ClassFileTransformer might want to instrument all 
> classes that implement a certain interface. For this, the transformer 
> needs to parse the provided class file, extract the interfaces and 
> locate their class files and so forth in order to resolve the type 
> hierarchy. For this, it is now possible to query the ClassLoader which 
> is an argument provided to the transformer. I do not know how I would 
> access the module at this point or get hold of the class file.
I assume you know this but if you have the Instrumentation object then 
you can invoke getAllLoadedClasses and filter this to the set of classes 
that implement the interface. Then call retransformClasses with this set 
(as an array) and your ClassFileTransformer should be invoked with the 
Class<?> + class bytes for each of these classes. This puts the onus on 
the VM to reconstitute the class bytes, no need for you to attempt to 
locate the .class file (which may not exist of course). It also allows 
multiple agents to work together.

>
> Also, I would expect that a Java agent that worked in Java 8 would 
> also work in Java 9. If I had to use Java 9 APIs in order to patch my 
> application, I would be required to offer two versions of my library, 
> one for Java 9+ and one for Java 8-. That would be unfortunate.
>
Existing java agents that are instrumenting code on the class path 
should continue to work as before. These agents are oblivious to modules 
but in many cases will be able to instrument code in named modules too. 
The VM is providing some "readability for free"  to keep existing 
instrumentation agents working. Beyond these cases then I expect agents 
will need to become module aware because they are instrumenting code in 
ways that interacts with modules and access checks. The current builds 
don't have these APIs yet. As to making use of newer APIs then it might 
add a bit of complexity to these agents or maybe to their how they are 
built.

-Alan

From mandy.chung at oracle.com  Fri Nov 13 18:43:28 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 13 Nov 2015 10:43:28 -0800
Subject: Proposal to enhance jdeps tool to search split packages/add some
	kind of general API
In-Reply-To: <9C036A95-6AF7-4888-BAD9-31B294F825B7@reini.net>
References: <BB261C69-BBB6-49E0-B3B2-153AA965AA85@reini.net>
	<156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com>
	<9C036A95-6AF7-4888-BAD9-31B294F825B7@reini.net>
Message-ID: <6D2D6E22-9F48-4F66-B116-4F0D08618DF5@oracle.com>


> On Nov 13, 2015, at 1:03 AM, Patrick Reinhart <patrick at reini.net> wrote:
> 
> I do not actually understand, what you mean by overlapping vs. partitioned ones? I somehow did not got it?

Let?s say package p is split across three jar files:

jar1 contains p.P1, p.P2, p.P3
jar2 contains p.P1 
jar3 contains p.P4, p.P5

jar2 overlaps classes with jar1
jar1 and jar3 both have a package p but they don?t have any overlapped class.

Mandy


From patrick at reini.net  Fri Nov 13 21:34:45 2015
From: patrick at reini.net (Patrick Reinhart)
Date: Fri, 13 Nov 2015 22:34:45 +0100
Subject: Proposal to enhance jdeps tool to search split packages/add some
	kind of general API
In-Reply-To: <56459D3F.6040408@oracle.com>
References: <BB261C69-BBB6-49E0-B3B2-153AA965AA85@reini.net>
	<156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com>
	<56459D3F.6040408@oracle.com>
Message-ID: <FA1D6EDE-973E-4A14-9D92-482947013F1D@reini.net>


> Am 13.11.2015 um 09:20 schrieb Alan Bateman <Alan.Bateman at oracle.com>:
> 
> On 13/11/2015 03:49, Mandy Chung wrote:
>> :
>> A tool to detect split packages and some other characteristics to aid migration to modules would be useful. I tend to think that belongs to a different tool that can build other additional analysis in it.
> I was chatting briefly with Patrick about this at Devoxx. For detecting split packages on a class path then I agree, it feels like another tool because it doesn't have to do any static analysis of the classes. More generally, I expect there will be many ideas and suggestions for things that jdeps could do. If we get to the point where it has an API then at least some of these ideas could be developed as tools that use the API.

For now, I?m thinking on providing only that much information, to help find out if there exist split packages at all. I agree that this can be done in a separate tool also and may fit better, even tough I believe having warnings in case of a split package shows up while analyzing the dependencies would be a good thing to have to start from. That would be the starting point using a second tool that would maybe help doing some extended analysis.

Patrick

From rfscholte at apache.org  Fri Nov 13 21:58:47 2015
From: rfscholte at apache.org (Robert Scholte)
Date: Fri, 13 Nov 2015 22:58:47 +0100
Subject: JDeps: detecting offending packages
Message-ID: <op.x717b917kdkhrr@robertscholte.dynamic.ziggo.nl>

Hi,

for the maven-jdeps-plugin I use the following code to detect offending  
packages:
---
import java.io.IOException;

import org.codehaus.plexus.util.StringUtils;

public class Base64Codec
{

     @SuppressWarnings( "restriction" )
     public static byte[] Base64decode( String input ) throws IOException
     {
         if( StringUtils.isNotEmpty( input ) )
         {
             return new sun.misc.BASE64Decoder().decodeBuffer( input );
         }
         else
         {
             return null;
         }
     }
}
---

Previous versions of JDK9 gave me the following output:

classes -> java.base
    <unnamed> (classes)
       -> java.io
       -> java.lang
       -> sun.misc                                           JDK internal  
API (java.base)


The current b86 gives me:

classes -> java.base
    <unnamed> (classes)
       -> java.io
       -> java.lang
       -> sun.misc

So why this change? And is there another way to detect the usage of  
non-accessible classes?

The maven-plugin has a parameter called failOnWarning (default:true) which  
should break the build in order to help developers to change their code  
when they rely on internal classes.

regards,
Robert Scholte

From patrick at reini.net  Fri Nov 13 22:16:34 2015
From: patrick at reini.net (Patrick Reinhart)
Date: Fri, 13 Nov 2015 23:16:34 +0100
Subject: Proposal to enhance jdeps tool to search split packages/add some
	kind of general API
In-Reply-To: <6D2D6E22-9F48-4F66-B116-4F0D08618DF5@oracle.com>
References: <BB261C69-BBB6-49E0-B3B2-153AA965AA85@reini.net>
	<156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com>
	<9C036A95-6AF7-4888-BAD9-31B294F825B7@reini.net>
	<6D2D6E22-9F48-4F66-B116-4F0D08618DF5@oracle.com>
Message-ID: <C0FC158A-D11F-4BE3-957B-61BCFCEF1F2A@reini.net>

> Am 13.11.2015 um 19:43 schrieb Mandy Chung <mandy.chung at oracle.com>:
> 
>> On Nov 13, 2015, at 1:03 AM, Patrick Reinhart <patrick at reini.net> wrote:
>> 
>> I do not actually understand, what you mean by overlapping vs. partitioned ones? I somehow did not got it?
> 
> Let?s say package p is split across three jar files:
> 
> jar1 contains p.P1, p.P2, p.P3
> jar2 contains p.P1
> jar3 contains p.P4, p.P5
> 
> jar2 overlaps classes with jar1
> jar1 and jar3 both have a package p but they don?t have any overlapped class.

Ah, I was thinking it that direction, but I was not absolutely sure. Thanks for clarification.

Patrick

From jonathan.gibbons at oracle.com  Sat Nov 14 00:29:18 2015
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Sat, 14 Nov 2015 00:29:18 +0000
Subject: hg: jigsaw/jake/langtools: fix whitespace and merge error in
	ProblemList.jake.txt
Message-ID: <201511140029.tAE0TISu022549@aojmv0008.oracle.com>

Changeset: 2e97a1c3478f
Author:    jjg
Date:      2015-11-13 16:28 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2e97a1c3478f

fix whitespace and merge error in ProblemList.jake.txt

! test/ProblemList.jake.txt


From jonathan.gibbons at oracle.com  Sat Nov 14 02:03:21 2015
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Sat, 14 Nov 2015 02:03:21 +0000
Subject: hg: jigsaw/jake/langtools: Fix tests on langtools ProblemList.jake.txt
Message-ID: <201511140203.tAE23LCg007897@aojmv0008.oracle.com>

Changeset: 8630a1e8260d
Author:    jjg
Date:      2015-11-13 18:02 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8630a1e8260d

Fix tests on langtools ProblemList.jake.txt

! test/ProblemList.jake.txt
- test/tools/javac/Object1.java
- test/tools/javac/Object1.out
- test/tools/javac/Object2.java
- test/tools/javac/Object2.out
! test/tools/javac/T4093617/T4093617.java
! test/tools/javac/T4093617/T4093617.out
+ test/tools/javac/T4093617/java.base/Object.java
! test/tools/javac/generics/diamond/neg/T8078473_2.java
! test/tools/javac/generics/diamond/neg/T8078473_2.out
+ test/tools/javac/redefineObject/Object1-test.java
+ test/tools/javac/redefineObject/Object1.out
+ test/tools/javac/redefineObject/Object2-test.java
+ test/tools/javac/redefineObject/Object2.out
+ test/tools/javac/redefineObject/java.base/Object1.java
+ test/tools/javac/redefineObject/java.base/Object2.java


From mandy.chung at oracle.com  Sat Nov 14 04:20:45 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 14 Nov 2015 04:20:45 +0000
Subject: hg: jigsaw/jake: 65 new changesets
Message-ID: <201511140420.tAE4KkBb029263@aojmv0008.oracle.com>

Changeset: 0c140bff9257
Author:    lana
Date:      2015-10-19 00:24 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/0c140bff9257

Added tag jdk9-b87 for changeset fd4f4f756107

! .hgtags

Changeset: a7ec2278c13d
Author:    ihse
Date:      2015-10-12 11:49 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/a7ec2278c13d

8139413: Use --with-x to set X11 root directory
Reviewed-by: erikj

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

Changeset: 81b90ca627de
Author:    lana
Date:      2015-10-15 16:49 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/81b90ca627de

Merge


Changeset: 0bb87e05d83e
Author:    lana
Date:      2015-10-21 15:15 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/0bb87e05d83e

Merge


Changeset: 9c467f2d46f0
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/9c467f2d46f0

Added tag jdk9-b88 for changeset 0bb87e05d83e

! .hgtags

Changeset: c867c33f584b
Author:    jlahoda
Date:      2015-10-19 19:13 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/c867c33f584b

8134254: JShell API/tool: REPL for Java into JDK9
Summary: Adding jdk.jshell module into modules.xml; and listing it among TOOLS_MODULES.
Reviewed-by: alanb, erikj, sundar
Contributed-by: robert.field at oracle.com, jan.lahoda at oracle.com

! make/Images.gmk
! modules.xml

Changeset: a60a0c1bd394
Author:    erikj
Date:      2015-10-20 09:47 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/a60a0c1bd394

8139735: Switch compilers in JPRT for windows and linux
Reviewed-by: tbell, ihse

! make/devkit/Tools.gmk
! make/devkit/createWindowsDevkit.sh
! make/jprt.properties

Changeset: 24a3936909e3
Author:    ihse
Date:      2015-10-20 10:39 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/24a3936909e3

8139668: Generate README-build.html from markdown
Reviewed-by: erikj

! README-builds.html
+ README-builds.md
+ common/bin/update-build-readme.sh

Changeset: 257534f191e8
Author:    ihse
Date:      2015-10-20 16:40 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/257534f191e8

8139969: Fix unzip in compare.sh broken by JDK-8136813
Reviewed-by: erikj

! common/autoconf/compare.sh.in
! common/bin/compare.sh

Changeset: cb3f10185e63
Author:    erikj
Date:      2015-10-20 17:29 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/cb3f10185e63

8139813: Base heap size on type of boot jdk, not architecture of build machine
Reviewed-by: tbell, ihse

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

Changeset: 8851df90bb66
Author:    erikj
Date:      2015-10-02 17:33 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/8851df90bb66

8138739: Enable devkit on macosx in JPRT (again)
Reviewed-by: ihse

! make/jprt.properties

Changeset: 11c070dc7985
Author:    ddehaven
Date:      2015-10-06 12:51 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/11c070dc7985

Merge


Changeset: efbea01d5b5c
Author:    prr
Date:      2015-10-12 14:44 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/efbea01d5b5c

Merge

- common/autoconf/builddeps.conf.example
- common/autoconf/builddeps.conf.nfs.example
- common/autoconf/builddeps.m4

Changeset: a44eac54cdc3
Author:    prr
Date:      2015-10-20 08:24 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/a44eac54cdc3

Merge

! make/jprt.properties

Changeset: 827ea558b8a3
Author:    prr
Date:      2015-10-20 10:33 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/827ea558b8a3

Merge


Changeset: 998803eeed50
Author:    neliasso
Date:      2015-09-18 10:09 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/998803eeed50

8135068: Extract method matchers from CompilerOracle
Summary: Ecapsulate code to enable reuse
Reviewed-by: roland, kvn

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

Changeset: b9acee978e94
Author:    iveresov
Date:      2015-09-25 12:04 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/b9acee978e94

Merge


Changeset: fd80ddb7553f
Author:    amurillo
Date:      2015-10-01 11:52 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/fd80ddb7553f

Merge


Changeset: 0b5d2c8bd667
Author:    amurillo
Date:      2015-10-08 14:28 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/0b5d2c8bd667

Merge


Changeset: 483de5dbcd96
Author:    dsamersoff
Date:      2015-09-24 20:39 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/483de5dbcd96

8086134: Deadlock detection fails to attach to core file
Summary: Test reimplemented for jtreg
Reviewed-by: jbachorik

! test/lib/share/classes/jdk/test/lib/apps/LingeredApp.java
+ test/lib/share/classes/jdk/test/lib/apps/LingeredAppWithDeadlock.java

Changeset: 34280222936a
Author:    jwilhelm
Date:      2015-09-28 15:05 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/34280222936a

Merge


Changeset: 9261bce638e3
Author:    jwilhelm
Date:      2015-10-07 00:46 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/9261bce638e3

Merge


Changeset: dec57655571e
Author:    twisti
Date:      2015-10-08 11:31 -1000
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/dec57655571e

8136421: JEP 243: Java-Level JVM Compiler Interface
Reviewed-by: ihse, alanb, roland, coleenp, iveresov, kvn, kbarrett

! .hgignore
! make/CompileJavaModules.gmk
! make/Images.gmk
! make/Main.gmk
! make/MainSupport.gmk
! make/common/Modules.gmk
! modules.xml
! test/lib/sun/hotspot/WhiteBox.java
! test/lib/sun/hotspot/code/NMethod.java

Changeset: 82f1be4bd9c3
Author:    dlong
Date:      2015-10-09 02:43 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/82f1be4bd9c3

Merge

- common/autoconf/builddeps.conf.example
- common/autoconf/builddeps.conf.nfs.example
- common/autoconf/builddeps.m4

Changeset: a6e5bdf52315
Author:    dlong
Date:      2015-10-17 15:41 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/a6e5bdf52315

Merge


Changeset: 3962780e2eda
Author:    amurillo
Date:      2015-10-19 12:30 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/3962780e2eda

Merge

! make/Images.gmk
! modules.xml

Changeset: 8d498217b215
Author:    amurillo
Date:      2015-10-20 11:56 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/8d498217b215

Merge


Changeset: e3cd4b33d245
Author:    lana
Date:      2015-10-21 18:38 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/e3cd4b33d245

Merge


Changeset: 23d62be63eef
Author:    ihse
Date:      2015-10-22 15:54 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/23d62be63eef

8140277: Configuration out-of-date check should also check closed sources
Reviewed-by: erikj

! make/Init.gmk

Changeset: ae4aba7142a1
Author:    ihse
Date:      2015-10-22 16:41 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/ae4aba7142a1

8140282: Remove test directories on clean-test-*
Reviewed-by: erikj

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! make/MainSupport.gmk

Changeset: 8d873b9b0031
Author:    lana
Date:      2015-10-22 11:12 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/8d873b9b0031

Merge


Changeset: 2396a16033e1
Author:    erikj
Date:      2015-10-27 13:48 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/2396a16033e1

8140484: Vardeps broken when variable value contains '$'
Reviewed-by: tbell

! make/common/MakeBase.gmk
! test/make/TestMakeBase.gmk

Changeset: 8001eddb1672
Author:    erikj
Date:      2015-10-27 17:51 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/8001eddb1672

8140312: Enable new sjavac server only mode in jdk build
Reviewed-by: ihse, tbell

! common/autoconf/build-performance.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! make/common/JavaCompilation.gmk
! make/common/SetupJavaCompilers.gmk
! make/test/BuildTestLib.gmk

Changeset: cd061b69a817
Author:    jwilhelm
Date:      2015-10-07 00:46 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/cd061b69a817

Merge


Changeset: 08b3c7a80f56
Author:    jprovino
Date:      2015-10-20 11:17 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/08b3c7a80f56

Merge


Changeset: 97134c4eba32
Author:    amurillo
Date:      2015-10-22 16:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/97134c4eba32

Merge


Changeset: 895353113f38
Author:    amurillo
Date:      2015-10-27 10:15 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/895353113f38

Merge


Changeset: cf1dc4c035fb
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/cf1dc4c035fb

Added tag jdk9-b89 for changeset 895353113f38

! .hgtags

Changeset: 3b1bba4161f3
Author:    lana
Date:      2015-10-30 10:28 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/3b1bba4161f3

Added tag jdk9-b90 for changeset cf1dc4c035fb

! .hgtags

Changeset: c8470ff83abe
Author:    ihse
Date:      2015-10-29 15:24 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/c8470ff83abe

8140762: Specifying --without-LIB if not needed should not result in warning
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/lib-alsa.m4
! common/autoconf/lib-cups.m4
! common/autoconf/lib-ffi.m4
! common/autoconf/lib-freetype.m4
! common/autoconf/lib-x11.m4

Changeset: f0b8f91a0c6f
Author:    ihse
Date:      2015-10-29 16:30 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/f0b8f91a0c6f

8140661: Rename LDFLAGS_SUFFIX to LIBS
Reviewed-by: erikj

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

Changeset: 5f7679c96d7d
Author:    erikj
Date:      2015-10-29 17:11 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/5f7679c96d7d

8140593: Add configure parameter for devkit for the build compiler
Reviewed-by: ihse

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

Changeset: d7c06f4e28b2
Author:    erikj
Date:      2015-10-29 17:14 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/d7c06f4e28b2

8140591: Add configure argument specifying make executable in JPRT
Reviewed-by: ihse, tbell

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! make/jprt.properties

Changeset: 0cde07d1082a
Author:    lana
Date:      2015-10-29 12:38 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/0cde07d1082a

Merge


Changeset: 122142a18538
Author:    lana
Date:      2015-11-04 13:45 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/122142a18538

Merge


Changeset: fe54fea946e8
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/fe54fea946e8

Added tag jdk9-b91 for changeset 122142a18538

! .hgtags

Changeset: 6a4c7c3c200b
Author:    mchung
Date:      2015-11-11 15:50 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/6a4c7c3c200b

Merge

! common/autoconf/basics.m4
! common/autoconf/boot-jdk.m4
! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4
! common/bin/compare.sh
! make/CompileJavaModules.gmk
! make/Images.gmk
! make/Main.gmk
! make/MainSupport.gmk
! make/common/JavaCompilation.gmk
! make/common/MakeBase.gmk
! make/common/Modules.gmk
! make/common/NativeCompilation.gmk
! make/common/SetupJavaCompilers.gmk
! make/jprt.properties
! test/lib/sun/hotspot/WhiteBox.java

Changeset: c90e05d02b5a
Author:    mchung
Date:      2015-11-12 20:35 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/c90e05d02b5a

jdk9-b91 fixup

! make/CompileJavaModules.gmk
! make/Images.gmk

Changeset: 05228b00bfcf
Author:    jbachorik
Date:      2015-11-02 13:46 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/05228b00bfcf

8140481: NoClassDefFoundError thrown by ManagementFactory.getPlatformMBeanServer
Reviewed-by: alanb, dsamersoff, erikj

! make/Images.gmk

Changeset: 5e06ef3a390a
Author:    neliasso
Date:      2015-10-20 18:07 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/5e06ef3a390a

8137167: JEP165: Compiler Control: Implementation task
Summary: Compiler Control JEP
Reviewed-by: roland, twisti, zmajo, simonis

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

Changeset: e81b35d4c8ad
Author:    dlong
Date:      2015-10-27 01:45 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/e81b35d4c8ad

Merge


Changeset: 27f356748627
Author:    amurillo
Date:      2015-10-30 12:03 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/27f356748627

Merge


Changeset: cda1da5fc2dd
Author:    amurillo
Date:      2015-11-02 10:47 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/cda1da5fc2dd

Merge


Changeset: a0c572d90b9d
Author:    erikj
Date:      2015-11-03 16:51 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/a0c572d90b9d

8141051: Build test libs -source/-target 9
Reviewed-by: tbell, vlivanov

! make/Main.gmk
! make/test/BuildTestLib.gmk

Changeset: d7f1098c2fc8
Author:    ihse
Date:      2015-11-03 17:48 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/d7f1098c2fc8

8141261: Clean up building of demos
Reviewed-by: erikj, tbell

! make/Images.gmk
! make/Main.gmk
! make/MainSupport.gmk
! make/common/JavaCompilation.gmk

Changeset: 426d96f4922f
Author:    ihse
Date:      2015-11-03 17:54 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/426d96f4922f

8141333: Rename SetupArchive to SetupJarArchive
Reviewed-by: erikj, tbell

! make/JrtfsJar.gmk
! make/common/JarArchive.gmk < make/common/JavaCompilation.gmk
+ make/common/JavaCompilation.gmk
! test/make/TestJavaCompilation.gmk

Changeset: d0f163fcd4c8
Author:    erikj
Date:      2015-11-03 18:00 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/d0f163fcd4c8

8141332: Switch macosx devkit in JPRT
Reviewed-by: ihse, tbell

! make/devkit/createMacosxDevkit.sh
! make/jprt.properties

Changeset: 82c695c9b53c
Author:    simonis
Date:      2015-11-04 12:45 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/82c695c9b53c

8141290: AIX: fix build after '8140661: Rename LDFLAGS_SUFFIX to LIBS'
Reviewed-by: ihse

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

Changeset: 1ad0a683c83d
Author:    ihse
Date:      2015-11-05 10:58 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/1ad0a683c83d

8141439: Fix compare.sh -o <otherdir> (broken by JDK-8136813)
Reviewed-by: tbell, erikj

! common/autoconf/compare.sh.in
! common/bin/compare.sh

Changeset: a36dc737a448
Author:    ihse
Date:      2015-11-05 15:14 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/a36dc737a448

8141414: Deprecate configure source overriding
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4
! common/autoconf/spec.gmk.in
! make/common/JavaCompilation.gmk

Changeset: 4ba17e992008
Author:    ihse
Date:      2015-11-05 17:32 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/4ba17e992008

8141543: Propagate --disable-warnings-as-errors to hotspot
Reviewed-by: erikj

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/hotspot-spec.gmk.in

Changeset: c26f2d9906cd
Author:    lana
Date:      2015-11-05 13:41 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/c26f2d9906cd

Merge


Changeset: 106c06398f7a
Author:    erikj
Date:      2015-11-05 23:25 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/106c06398f7a

8141574: recent change for 8141543 breaks all builds
Reviewed-by: darcy

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

Changeset: 0f0a47b76da7
Author:    lana
Date:      2015-11-12 10:38 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/0f0a47b76da7

Added tag jdk9-b92 for changeset 106c06398f7a

! .hgtags

Changeset: 0c780a08f739
Author:    mchung
Date:      2015-11-13 19:20 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/0c780a08f739

Merge

! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4
! common/autoconf/spec.gmk.in
! common/bin/compare.sh
- make/CheckModules.gmk
! make/CompileJavaModules.gmk
! make/Images.gmk
! make/JrtfsJar.gmk
! make/Main.gmk
! make/MainSupport.gmk
! make/common/JarArchive.gmk
! make/common/JavaCompilation.gmk
! make/jprt.properties
- modules.xml
! test/lib/sun/hotspot/WhiteBox.java
! test/make/TestJavaCompilation.gmk


From mandy.chung at oracle.com  Sat Nov 14 04:22:25 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 14 Nov 2015 04:22:25 +0000
Subject: hg: jigsaw/jake/hotspot: 226 new changesets
Message-ID: <201511140422.tAE4MRY9029781@aojmv0008.oracle.com>

Changeset: bc48b669bc66
Author:    lana
Date:      2015-10-19 00:24 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bc48b669bc66

Added tag jdk9-b87 for changeset d7ffd16382fe

! .hgtags

Changeset: b0e0a53226fd
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b0e0a53226fd

Added tag jdk9-b88 for changeset bc48b669bc66

! .hgtags

Changeset: e1517978bf12
Author:    enevill
Date:      2015-09-15 12:59 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e1517978bf12

8136524: aarch64: test/compiler/runtime/7196199/Test7196199.java fails
Summary: Fix safepoint handlers to save 128 bits on vector poll
Reviewed-by: kvn
Contributed-by: felix.yang at linaro.org

! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp
! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp

Changeset: 43451068d53c
Author:    roland
Date:      2015-09-15 13:08 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/43451068d53c

8136461: PhaseIdealLoop::try_move_store_before_loop() may bypass early loop exit
Summary: PhaseIdealLoop::try_move_store_before_loop() needs to check for early loop exit before candidate Stores
Reviewed-by: kvn

! src/share/vm/opto/loopopts.cpp
- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java
+ test/compiler/loopopts/TestMoveStoresOutOfLoopsStoreNoCtrl.java

Changeset: cc267038a9c1
Author:    kvn
Date:      2015-09-15 11:04 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cc267038a9c1

8136406: Remove ZapDeadCompiledLocals code
Summary: Dead code elimination.
Reviewed-by: roland, twisti

! agent/src/share/classes/sun/jvm/hotspot/compiler/ImmutableOopMapSet.java
! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapValue.java
! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapVisitor.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! src/share/vm/compiler/oopMap.cpp
! src/share/vm/compiler/oopMap.hpp
! src/share/vm/interpreter/oopMapCache.cpp
! src/share/vm/interpreter/oopMapCache.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/interfaceSupport.cpp
! src/share/vm/runtime/interfaceSupport.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 65c21ccab1bd
Author:    kvn
Date:      2015-09-16 20:33 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/65c21ccab1bd

Merge


Changeset: 10e79692c25e
Author:    mcberg
Date:      2015-09-16 13:16 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/10e79692c25e

8134802: LCM register pressure scheduling
Summary: Calculate register pressure in a block to help instructions scheduling.
Reviewed-by: kvn, dlong

! src/cpu/aarch64/vm/aarch64.ad
! src/cpu/aarch64/vm/c2_globals_aarch64.hpp
! src/cpu/ppc/vm/c2_globals_ppc.hpp
! src/cpu/ppc/vm/ppc.ad
! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/c2_globals_x86.hpp
! src/cpu/x86/vm/x86.ad
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/live.hpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/node.hpp

Changeset: a60e232aa8f2
Author:    kvn
Date:      2015-09-16 15:54 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a60e232aa8f2

8134553: CRC32C implementations for x86/x64 targets
Reviewed-by: kvn
Contributed-by: tomasz.wojtowicz at intel.com

! src/cpu/aarch64/vm/interpreterGenerator_aarch64.hpp
! src/cpu/ppc/vm/interpreterGenerator_ppc.hpp
! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/assembler_x86.inline.hpp
+ src/cpu/x86/vm/crc32c.h
! src/cpu/x86/vm/interpreterGenerator_x86.hpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86.cpp
! src/cpu/x86/vm/stubRoutines_x86.hpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/zero/vm/interpreterGenerator_zero.hpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 6d9d273e7f0d
Author:    thartmann
Date:      2015-09-17 08:08 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6d9d273e7f0d

8134739: compiler/loopopts/superword/TestVectorizationWithInvariant crashes in loop opts
Summary: Bail out of superword optimization if loop was removed (i.e., if zero-trip Opaque1Node was removed).
Reviewed-by: kvn, roland

! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/superword.cpp

Changeset: 476739c20b35
Author:    iveresov
Date:      2015-09-17 13:42 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/476739c20b35

Merge


Changeset: e3201914b83b
Author:    neliasso
Date:      2015-09-18 10:11 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3201914b83b

8135068: Extract method matchers from CompilerOracle
Summary: Ecapsulate code to enable reuse
Reviewed-by: roland, kvn

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/compiler/compilerOracle.hpp
+ src/share/vm/compiler/methodMatcher.cpp
+ src/share/vm/compiler/methodMatcher.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/globals.hpp
! test/compiler/c2/5091921/Test7005594.sh
! test/compiler/oracle/CheckCompileCommandOption.java
+ test/compiler/oracle/MethodMatcherTest.java
! test/compiler/oracle/TestCompileCommand.java
! test/compiler/oracle/command1.txt
! test/runtime/CommandLine/CompilerConfigFileWarning.java

Changeset: 17efe8fc4f48
Author:    mdoerr
Date:      2015-09-17 09:03 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/17efe8fc4f48

8136525: Generate interpreter entries only once and avoid unnecessary jump to jump
Reviewed-by: coleenp, twisti, aph

! src/cpu/aarch64/vm/interp_masm_aarch64.cpp
! src/cpu/aarch64/vm/interp_masm_aarch64.hpp
! src/cpu/aarch64/vm/interpreterGenerator_aarch64.hpp
! src/cpu/aarch64/vm/interpreter_aarch64.cpp
! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp
! src/cpu/ppc/vm/interp_masm_ppc_64.cpp
! src/cpu/ppc/vm/interp_masm_ppc_64.hpp
! src/cpu/ppc/vm/interpreterGenerator_ppc.hpp
! src/cpu/ppc/vm/interpreter_ppc.cpp
! src/cpu/ppc/vm/templateInterpreter_ppc.cpp
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp
! src/cpu/sparc/vm/interpreter_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/interp_masm_x86.cpp
! src/cpu/x86/vm/interp_masm_x86.hpp
! src/cpu/x86/vm/interpreterGenerator_x86.cpp
! src/cpu/x86/vm/interpreterGenerator_x86.hpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/templateInterpreter.cpp

Changeset: 3ac528612681
Author:    coleenp
Date:      2015-09-18 16:37 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3ac528612681

Merge


Changeset: 3b908f10337f
Author:    tpivovarova
Date:      2015-09-19 12:03 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3b908f10337f

8136693: add package statement 'compiler.testlibrary' to CompilerUtils
Reviewed-by: iignatyev

! test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java
! test/compiler/testlibrary/CompilerUtils.java

Changeset: d61e3154b6e0
Author:    dpochepk
Date:      2015-09-19 12:04 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d61e3154b6e0

8136718: [TESTBUG] introduce FileInstaller functionality
Reviewed-by: iignatyev

+ test/testlibrary/jdk/test/lib/FileInstaller.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: bab9d3d37ae8
Author:    iignatyev
Date:      2015-09-19 11:19 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bab9d3d37ae8

Merge


Changeset: 95e96bd4b70b
Author:    adinn
Date:      2015-09-16 09:52 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/95e96bd4b70b

8080293: AARCH64: Remove unnecessary dmbs from generated CAS code
Summary: The current encoding for CAS generates unnecessary leading and trailing dmbs for the MemBarAcquire and MemBarRelease which ought to be elided
Reviewed-by: kvn

! src/cpu/aarch64/vm/aarch64.ad

Changeset: 66d90f141fd8
Author:    zmajo
Date:      2015-09-22 13:42 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/66d90f141fd8

8136914: compiler/loopopts/superword/SumRedSqrt_Double.java times out
Summary: Change test to execute only on relevant (x86-based) platforms.
Reviewed-by: kvn, dlong

! test/compiler/loopopts/superword/SumRedSqrt_Double.java

Changeset: 6cc606e29b74
Author:    roland
Date:      2015-09-21 10:51 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6cc606e29b74

8136596: Remove aarch64: MemBarRelease when final field's allocation is NoEscape or ArgEscape
Summary: elide MemBar when AllocateNode _is_non_escaping
Reviewed-by: kvn, roland
Contributed-by: hui.shi at linaro.org

! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/memnode.cpp

Changeset: 7c288547a709
Author:    roland
Date:      2015-09-22 15:25 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7c288547a709

8136926: phi == NULL assert in PhaseIdealLoop::try_move_store_after_loop
Summary: multiple phis on same slice are possible in a loop
Reviewed-by: kvn, mcberg

! src/share/vm/opto/loopopts.cpp
! test/compiler/loopopts/TestMoveStoresOutOfLoops.java

Changeset: db3a3feccd9b
Author:    enevill
Date:      2015-09-16 13:50 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/db3a3feccd9b

8136615: aarch64: elide DecodeN when followed by CmpP 0
Summary: remove DecodeN when comparing a narrow oop with 0
Reviewed-by: kvn, adinn

! src/cpu/aarch64/vm/aarch64.ad

Changeset: 56024013648f
Author:    kzhaldyb
Date:      2015-09-24 18:24 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/56024013648f

8137020: [TESTBUG] Utils.runAndCheckException doesn't work well if no exception thrown
Summary: Changed handling a case when expected exception wasn't thrown
Reviewed-by: iignatyev

! test/testlibrary/jdk/test/lib/Utils.java

Changeset: 0855eb2338ae
Author:    ppunegov
Date:      2015-09-24 20:13 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0855eb2338ae

8066157: JEP-JDK-8046155: Test task: method matcher
Summary: MethodMatcher test and framework
Reviewed-by: iignatyev, neliasso

+ test/compiler/compilercontrol/matcher/MethodMatcherTest.java
+ test/compiler/compilercontrol/share/method/ClassType.java
+ test/compiler/compilercontrol/share/method/MethodDescriptor.java
+ test/compiler/compilercontrol/share/method/MethodElementType.java
+ test/compiler/compilercontrol/share/method/MethodGenerator.java
+ test/compiler/compilercontrol/share/method/MethodType.java
+ test/compiler/compilercontrol/share/method/SignatureType.java
+ test/compiler/compilercontrol/share/pool/MethodHolder.java
+ test/compiler/compilercontrol/share/pool/PoolHelper.java
+ test/compiler/compilercontrol/share/pool/sub/Klass.java
+ test/compiler/compilercontrol/share/pool/sub/KlassDup.java
+ test/compiler/compilercontrol/share/pool/subpack/Klass.java
+ test/compiler/compilercontrol/share/pool/subpack/KlassDup.java
+ test/testlibrary/jdk/test/lib/Pair.java
+ test/testlibrary/jdk/test/lib/Triple.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: df910cc4b9ea
Author:    roland
Date:      2015-09-17 16:53 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/df910cc4b9ea

8136820: Generate better code for some Unsafe addressing patterns
Summary: reshape address computation to move invariant part out of loops
Reviewed-by: kvn

! src/cpu/x86/vm/x86_64.ad
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/superword.cpp

Changeset: 8096c5205545
Author:    iveresov
Date:      2015-09-25 12:04 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8096c5205545

Merge

! src/cpu/aarch64/vm/interp_masm_aarch64.cpp
! src/cpu/ppc/vm/interp_masm_ppc_64.cpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/x86/vm/interp_masm_x86.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vmStructs.cpp
- test/gc/logging/TestPrintReferences.java
- test/gc/startup_warnings/TestDefaultMaxRAMFraction.java
- test/gc/startup_warnings/TestNoParNew.java

Changeset: 5ee8eccf7900
Author:    aph
Date:      2015-09-28 16:18 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5ee8eccf7900

8136165: AARCH64: Tidy up compiled native calls
Summary: Do some cleaning
Reviewed-by: roland, kvn, enevill

! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp

Changeset: fa430fa4f577
Author:    enevill
Date:      2015-09-23 12:39 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fa430fa4f577

8135231: aarch64: add support for vectorizing double precision sqrt
Reviewed-by: roland, aph

! src/cpu/aarch64/vm/aarch64.ad
! src/cpu/aarch64/vm/assembler_aarch64.hpp
! test/compiler/loopopts/superword/SumRedSqrt_Double.java

Changeset: f244d455e4dd
Author:    amurillo
Date:      2015-10-01 11:52 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f244d455e4dd

Merge

- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java

Changeset: 5ab466809f05
Author:    iveresov
Date:      2015-10-08 09:51 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5ab466809f05

8139094: Tier1 test java/util/zip/TestCRC32C.java fails due to fixes for JDK-8134553
Summary: Match correct intrinsic kind
Reviewed-by: iveresov, kvn
Contributed-by: tomasz.wojtowicz at intel.com

! src/cpu/x86/vm/templateInterpreter_x86_32.cpp

Changeset: daf8acf3afda
Author:    enevill
Date:      2015-09-30 04:35 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/daf8acf3afda

8138583: aarch64: add support for vectorizing fabs/fneg
Reviewed-by: aph, roland
Contributed-by: felix.yang at linaro.org

! src/cpu/aarch64/vm/aarch64.ad
! src/cpu/aarch64/vm/assembler_aarch64.hpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp
! src/share/vm/opto/vectornode.hpp
+ test/compiler/loopopts/superword/SumRedAbsNeg_Double.java
+ test/compiler/loopopts/superword/SumRedAbsNeg_Float.java

Changeset: 324ea1a2419a
Author:    iveresov
Date:      2015-10-05 20:02 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/324ea1a2419a

8132207: update for x86 exp in the math lib
Summary: Add new java.lang.Math() intrinsics from x86
Reviewed-by: kvn, iveresov
Contributed-by: vivek.r.deshpande at intel.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_LinearScan_x86.cpp
! src/cpu/x86/vm/interpreter_x86_32.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
+ src/cpu/x86/vm/macroAssembler_x86_libm.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/subnode.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 30f10e51ad6f
Author:    adinn
Date:      2015-10-07 06:56 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/30f10e51ad6f

8139042: AARCH64: Correct regression introduced by 8080293
Summary: Reinstate unsafe volatile optimization broken by JDK-8080293
Reviewed-by: aph, kvn

! src/cpu/aarch64/vm/aarch64.ad

Changeset: 017224c13b0e
Author:    dlong
Date:      2015-10-08 19:16 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/017224c13b0e

Merge


Changeset: f01629221703
Author:    amurillo
Date:      2015-10-08 14:28 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f01629221703

Merge

- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java

Changeset: eca671f4c014
Author:    ecaspole
Date:      2015-09-21 10:36 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/eca671f4c014

8131645: [ARM64] crash on Cavium when using G1
Summary: Add a fence when creating the CodeRootSetTable so the readers do not see invalid memory.
Reviewed-by: aph, tschatzl

! src/share/vm/gc/g1/g1CodeCacheRemSet.cpp

Changeset: c55ee4af240d
Author:    ctornqvi
Date:      2015-09-23 05:18 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c55ee4af240d

8027565: Enable /d2Zi+ when building with Visual Studio 2013
Reviewed-by: dcubed, ihse

! make/windows/makefiles/compile.make

Changeset: 1ce8347eea86
Author:    ddmitriev
Date:      2015-09-23 22:04 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1ce8347eea86

8073331: [TESTBUG] Test for VM option file feature (VM options specified in file)
Reviewed-by: dcubed, gtriantafill, rdurbin

+ test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java
+ test/runtime/CommandLine/VMOptionsFile/flags_file
+ test/runtime/CommandLine/VMOptionsFile/optionFILE_2
+ test/runtime/CommandLine/VMOptionsFile/optionfile_1
+ test/runtime/CommandLine/VMOptionsFile/optionfile_3
+ test/runtime/CommandLine/VMOptionsFile/optionfile_bad_option
+ test/runtime/CommandLine/VMOptionsFile/optionfile_long_property
+ test/runtime/CommandLine/VMOptionsFile/optionfile_lot_of_options_quote
+ test/runtime/CommandLine/VMOptionsFile/optionfile_only_tabsandspaces
+ test/runtime/CommandLine/VMOptionsFile/optionfile_quote
+ test/runtime/CommandLine/VMOptionsFile/optionfile_quote_max_size
+ test/runtime/CommandLine/VMOptionsFile/optionfile_unmatched_quote_1
+ test/runtime/CommandLine/VMOptionsFile/optionfile_unmatched_quote_2
+ test/runtime/CommandLine/VMOptionsFile/optionfile_very_long_property

Changeset: 91c907c47794
Author:    aph
Date:      2015-09-24 12:04 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/91c907c47794

8135018: AARCH64: Missing memory barriers for CMS collector
Summary: Add StoreStore barrier when CMS needs them
Reviewed-by: tschatzl

! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp

Changeset: f99ad7bb5df5
Author:    mlarsson
Date:      2015-09-24 12:36 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f99ad7bb5df5

8046148: JEP 158: Unified JVM Logging
Reviewed-by: coleenp, sla

! make/windows/makefiles/vm.make
! src/share/vm/Xusage.txt
+ src/share/vm/logging/log.hpp
+ src/share/vm/logging/logConfiguration.cpp
+ src/share/vm/logging/logConfiguration.hpp
+ src/share/vm/logging/logDecorations.cpp
+ src/share/vm/logging/logDecorations.hpp
+ src/share/vm/logging/logDecorators.cpp
+ src/share/vm/logging/logDecorators.hpp
+ src/share/vm/logging/logDiagnosticCommand.cpp
+ src/share/vm/logging/logDiagnosticCommand.hpp
+ src/share/vm/logging/logFileOutput.cpp
+ src/share/vm/logging/logFileOutput.hpp
+ src/share/vm/logging/logFileStreamOutput.cpp
+ src/share/vm/logging/logFileStreamOutput.hpp
+ src/share/vm/logging/logLevel.cpp
+ src/share/vm/logging/logLevel.hpp
+ src/share/vm/logging/logOutput.cpp
+ src/share/vm/logging/logOutput.hpp
+ src/share/vm/logging/logOutputList.cpp
+ src/share/vm/logging/logOutputList.hpp
+ src/share/vm/logging/logPrefix.hpp
+ src/share/vm/logging/logTag.cpp
+ src/share/vm/logging/logTag.hpp
+ src/share/vm/logging/logTagLevelExpression.cpp
+ src/share/vm/logging/logTagLevelExpression.hpp
+ src/share/vm/logging/logTagSet.cpp
+ src/share/vm/logging/logTagSet.hpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/services/management.hpp
! src/share/vm/services/nmtCommon.cpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/ostream.hpp
+ test/serviceability/logging/TestBasicLogOutput.java

Changeset: 1f6500dbefcb
Author:    mlarsson
Date:      2015-09-24 16:19 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1f6500dbefcb

Merge


Changeset: 83b9a8e8593d
Author:    mockner
Date:      2015-09-24 11:26 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/83b9a8e8593d

8130681: Kitchensink startup crashes JVM with NMT overlapping ranges
Summary: add_committed_region now handles overlapping commits.
Reviewed-by: hseigel, coleenp

! src/share/vm/services/virtualMemoryTracker.cpp
+ test/runtime/NMT/CommitOverlappingRegions.java

Changeset: f1e0206e75e1
Author:    dsamersoff
Date:      2015-09-24 20:39 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f1e0206e75e1

8086134: Deadlock detection fails to attach to core file
Summary: Test reimplemented for jtreg
Reviewed-by: jbachorik

+ test/serviceability/sa/DeadlockDetectionTest.java

Changeset: 4ed0a395857b
Author:    dsamersoff
Date:      2015-09-25 10:21 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4ed0a395857b

Merge


Changeset: d4dec7270392
Author:    kzhaldyb
Date:      2015-09-24 18:48 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d4dec7270392

8136398: Create test that checks that G1 MixedGC produces correct output to logfile
Summary: Added test that checks that G1 MixedGC produces correct output to logfile
Reviewed-by: tschatzl

+ test/gc/g1/mixedgc/TestLogging.java

Changeset: a4ae74ca2403
Author:    brutisso
Date:      2015-09-28 09:28 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a4ae74ca2403

8136991: [REDO] Additional number of processed references printed with -XX:+PrintReferenceGC after JDK-8047125
Reviewed-by: kbarrett, tschatzl

! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/shared/gcTraceTime.cpp
! src/share/vm/gc/shared/gcTraceTime.hpp
! src/share/vm/gc/shared/referenceProcessor.cpp
! src/share/vm/gc/shared/referenceProcessor.hpp
+ test/gc/logging/TestPrintReferences.java

Changeset: 142f04931a09
Author:    jwilhelm
Date:      2015-09-28 15:05 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/142f04931a09

Merge


Changeset: dc9930a04ab0
Author:    david
Date:      2015-09-29 11:02 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dc9930a04ab0

8080775: Better argument formatting for assert() and friends
Reviewed-by: kbarrett, pliden

! make/linux/makefiles/gcc.make
! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/methodHandles_aarch64.cpp
! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
! src/cpu/ppc/vm/macroAssembler_ppc.cpp
! src/cpu/ppc/vm/methodHandles_ppc.cpp
! src/cpu/ppc/vm/nativeInst_ppc.cpp
! src/cpu/ppc/vm/sharedRuntime_ppc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/register_x86.hpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/os/aix/vm/os_aix.cpp
! src/os/aix/vm/vmError_aix.cpp
! src/os/bsd/vm/os_bsd.cpp
! src/os/bsd/vm/vmError_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/vmError_linux.cpp
! src/os/posix/vm/os_posix.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/threadCritical_solaris.cpp
! src/os/solaris/vm/vmError_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/vmError_windows.cpp
! src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp
! src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/asm/register.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/ci/ciKlass.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethodData.cpp
! src/share/vm/ci/ciReplay.cpp
! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/classfile/altHashing.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/metadataOnStackMark.cpp
! src/share/vm/classfile/stringTable.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/code/codeCache.cpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/exceptionHandlerTable.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/stubs.cpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/gc/cms/adaptiveFreeList.cpp
! src/share/vm/gc/cms/allocationStats.hpp
! src/share/vm/gc/cms/compactibleFreeListSpace.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc/cms/parCardTableModRefBS.cpp
! src/share/vm/gc/cms/promotionInfo.hpp
! src/share/vm/gc/g1/bufferingOopClosure.cpp
! src/share/vm/gc/g1/collectionSetChooser.cpp
! src/share/vm/gc/g1/collectionSetChooser.hpp
! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/concurrentMark.inline.hpp
! src/share/vm/gc/g1/g1AllocRegion.cpp
! src/share/vm/gc/g1/g1AllocRegion.hpp
! src/share/vm/gc/g1/g1AllocRegion.inline.hpp
! src/share/vm/gc/g1/g1Allocator.cpp
! src/share/vm/gc/g1/g1Allocator.hpp
! src/share/vm/gc/g1/g1Allocator.inline.hpp
! src/share/vm/gc/g1/g1BiasedArray.cpp
! src/share/vm/gc/g1/g1BiasedArray.hpp
! src/share/vm/gc/g1/g1BlockOffsetTable.cpp
! src/share/vm/gc/g1/g1BlockOffsetTable.hpp
! src/share/vm/gc/g1/g1BlockOffsetTable.inline.hpp
! src/share/vm/gc/g1/g1CardCounts.cpp
! src/share/vm/gc/g1/g1CardCounts.hpp
! src/share/vm/gc/g1/g1CodeCacheRemSet.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectedHeap.hpp
! src/share/vm/gc/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.hpp
! src/share/vm/gc/g1/g1EvacFailure.cpp
! src/share/vm/gc/g1/g1EvacStats.cpp
! src/share/vm/gc/g1/g1GCPhaseTimes.cpp
! src/share/vm/gc/g1/g1HotCardCache.cpp
! src/share/vm/gc/g1/g1InCSetState.hpp
! src/share/vm/gc/g1/g1OopClosures.cpp
! src/share/vm/gc/g1/g1PageBasedVirtualSpace.cpp
! src/share/vm/gc/g1/g1ParScanThreadState.cpp
! src/share/vm/gc/g1/g1ParScanThreadState.hpp
! src/share/vm/gc/g1/g1ParScanThreadState.inline.hpp
! src/share/vm/gc/g1/g1RegionToSpaceMapper.cpp
! src/share/vm/gc/g1/g1RemSet.cpp
! src/share/vm/gc/g1/heapRegion.cpp
! src/share/vm/gc/g1/heapRegion.hpp
! src/share/vm/gc/g1/heapRegion.inline.hpp
! src/share/vm/gc/g1/heapRegionManager.cpp
! src/share/vm/gc/g1/heapRegionManager.inline.hpp
! src/share/vm/gc/g1/heapRegionRemSet.cpp
! src/share/vm/gc/g1/heapRegionSet.cpp
! src/share/vm/gc/g1/heapRegionSet.inline.hpp
! src/share/vm/gc/g1/heapRegionType.hpp
! src/share/vm/gc/g1/satbQueue.cpp
! src/share/vm/gc/g1/vm_operations_g1.cpp
! src/share/vm/gc/parallel/cardTableExtension.cpp
! src/share/vm/gc/parallel/gcTaskManager.cpp
! src/share/vm/gc/parallel/mutableNUMASpace.cpp
! src/share/vm/gc/parallel/objectStartArray.cpp
! src/share/vm/gc/parallel/objectStartArray.hpp
! src/share/vm/gc/parallel/parMarkBitMap.hpp
! src/share/vm/gc/parallel/parallelScavengeHeap.inline.hpp
! src/share/vm/gc/parallel/pcTasks.cpp
! src/share/vm/gc/parallel/psOldGen.hpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/tenuredGeneration.cpp
! src/share/vm/gc/shared/ageTable.cpp
! src/share/vm/gc/shared/blockOffsetTable.cpp
! src/share/vm/gc/shared/cardTableModRefBS.hpp
! src/share/vm/gc/shared/cardTableRS.cpp
! src/share/vm/gc/shared/collectedHeap.cpp
! src/share/vm/gc/shared/collectedHeap.inline.hpp
! src/share/vm/gc/shared/collectorPolicy.cpp
! src/share/vm/gc/shared/gcCause.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/plab.cpp
! src/share/vm/gc/shared/referenceProcessor.cpp
! src/share/vm/gc/shared/space.cpp
! src/share/vm/gc/shared/taskqueue.cpp
! src/share/vm/gc/shared/workgroup.cpp
! src/share/vm/gc/shared/workgroup.hpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp
! src/share/vm/interpreter/bytecodes.cpp
! src/share/vm/interpreter/bytecodes.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/logging/logConfiguration.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/binaryTreeDictionary.cpp
! src/share/vm/memory/iterator.inline.hpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspaceGCThresholdUpdater.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/memory/virtualspace.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klass.inline.hpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/oop.cpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/castnode.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/mathexactnode.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/stringopts.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/vectornode.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/memprofiler.cpp
! src/share/vm/runtime/mutex.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/signature.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vmThread.cpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/services/classLoadingService.cpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/memoryService.cpp
! src/share/vm/utilities/array.hpp
! src/share/vm/utilities/chunkedList.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/debug.hpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/fakeRttiSupport.hpp
! src/share/vm/utilities/globalDefinitions.cpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/vmError.cpp
! src/share/vm/utilities/vmError.hpp

Changeset: 143fe39b8533
Author:    brutisso
Date:      2015-09-29 17:44 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/143fe39b8533

8133706: Kitchensink hanged
Reviewed-by: pliden, jmasa

! src/share/vm/gc/g1/concurrentMarkThread.cpp

Changeset: 983c56341c80
Author:    brutisso
Date:      2015-09-30 09:07 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/983c56341c80

8134953: Make the GC ID available in a central place
Reviewed-by: pliden, jmasa

! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/cms/concurrentMarkSweepThread.cpp
! src/share/vm/gc/cms/parNewGeneration.cpp
! src/share/vm/gc/cms/vmCMSOperations.cpp
! src/share/vm/gc/cms/vmCMSOperations.hpp
! src/share/vm/gc/cms/yieldingWorkgroup.cpp
! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/concurrentMark.hpp
! src/share/vm/gc/g1/concurrentMarkThread.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1MMUTracker.cpp
! src/share/vm/gc/g1/g1MMUTracker.hpp
! src/share/vm/gc/g1/g1MarkSweep.cpp
! src/share/vm/gc/g1/vm_operations_g1.cpp
! src/share/vm/gc/g1/vm_operations_g1.hpp
! src/share/vm/gc/parallel/pcTasks.cpp
! src/share/vm/gc/parallel/psMarkSweep.cpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/defNewGeneration.cpp
! src/share/vm/gc/serial/genMarkSweep.cpp
! src/share/vm/gc/shared/collectedHeap.cpp
! src/share/vm/gc/shared/gcId.cpp
! src/share/vm/gc/shared/gcId.hpp
! src/share/vm/gc/shared/gcTrace.cpp
! src/share/vm/gc/shared/gcTrace.hpp
! src/share/vm/gc/shared/gcTraceSend.cpp
! src/share/vm/gc/shared/gcTraceTime.cpp
! src/share/vm/gc/shared/gcTraceTime.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/objectCountEventSender.cpp
! src/share/vm/gc/shared/objectCountEventSender.hpp
! src/share/vm/gc/shared/referenceProcessor.cpp
! src/share/vm/gc/shared/referenceProcessor.hpp
! src/share/vm/gc/shared/workgroup.cpp
! src/share/vm/gc/shared/workgroup.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/ostream.hpp

Changeset: 59e6f265dd40
Author:    aharlap
Date:      2015-09-30 18:09 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/59e6f265dd40

8130265: gctests/LargeObjects/large001 fails with OutOfMemoryError: Java heap space
Summary: Avoided G1 OutOfMemoryError by adding extra expand heap call
Reviewed-by: jwilhelm, tschatzl

! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectedHeap.hpp

Changeset: 43a1e4ca7ee4
Author:    hseigel
Date:      2015-10-01 15:14 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/43a1e4ca7ee4

8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding
Summary: TestBasicLogOutput.java edited to account for padding in tag descriptors
Reviewed-by: ddmitriev, hseigel, coleenp
Contributed-by: rachel.protacio at oracle.com

! test/serviceability/logging/TestBasicLogOutput.java

Changeset: 38bd261644c0
Author:    erikj
Date:      2015-10-02 10:15 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/38bd261644c0

8138692: libjsig compilation is missing EXTRA_CFLAGS on macosx
Reviewed-by: ihse, mikael

! make/bsd/makefiles/jsig.make

Changeset: b04892bbefa5
Author:    david
Date:      2015-10-02 10:43 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b04892bbefa5

8138637: Remove err_msg from LOG_PREFIX macro
Reviewed-by: brutisso

! src/share/vm/logging/logPrefix.hpp

Changeset: c0b0699bf991
Author:    david
Date:      2015-10-02 11:02 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c0b0699bf991

Merge


Changeset: 12a66b77145e
Author:    dcubed
Date:      2015-10-01 13:42 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/12a66b77145e

8135195: VM Options file should not be limited to 1k in bytes
Summary: Change Arguments::parse_vm_options_file() to remove 1024 byte limit on the VM options file.
Reviewed-by: dcubed, hseigel, gthornbr, dsamersoff, ddmitriev, coleenp

! src/share/vm/runtime/arguments.cpp

Changeset: 6020dab5cdcb
Author:    dcubed
Date:      2015-10-01 13:43 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6020dab5cdcb

8137105: [TESTBUG] Add test cases for VM Options file feature with removed file size limit
Summary: Update TestVMOptionsFile.java to match fix for 8135195; other minor cleanups.
Reviewed-by: dcubed, rdurbin

! test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java
! test/runtime/CommandLine/VMOptionsFile/optionfile_1
- test/runtime/CommandLine/VMOptionsFile/optionfile_long_property
! test/runtime/CommandLine/VMOptionsFile/optionfile_lot_of_options_quote
! test/runtime/CommandLine/VMOptionsFile/optionfile_quote
- test/runtime/CommandLine/VMOptionsFile/optionfile_quote_max_size
- test/runtime/CommandLine/VMOptionsFile/optionfile_very_long_property

Changeset: da0795953c69
Author:    dcubed
Date:      2015-10-02 11:58 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/da0795953c69

Merge


Changeset: ccf99d847b02
Author:    dcubed
Date:      2015-10-02 12:44 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ccf99d847b02

Merge

- test/runtime/CommandLine/VMOptionsFile/optionfile_long_property
- test/runtime/CommandLine/VMOptionsFile/optionfile_quote_max_size
- test/runtime/CommandLine/VMOptionsFile/optionfile_very_long_property

Changeset: f5379b29c4d7
Author:    ctornqvi
Date:      2015-10-02 06:06 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f5379b29c4d7

8137194: Exclude runtime/memory/RunUnitTestsConcurrently.java from JPRT
Reviewed-by: coleenp

! test/TEST.groups

Changeset: 0952227d9cfe
Author:    ddmitriev
Date:      2015-10-02 09:04 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0952227d9cfe

8138769: [TESTBUG] restore lost line from JDK-8137105 fix
Reviewed-by: dcubed, rdurbin

! test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java

Changeset: 4edb0704e9f3
Author:    dcubed
Date:      2015-10-02 16:48 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4edb0704e9f3

Merge


Changeset: d9d44c9d7bf0
Author:    goetz
Date:      2015-09-28 12:57 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d9d44c9d7bf0

8137260: fix warning after "8046148: JEP 158: Unified JVM Logging"
Reviewed-by: mlarsson, stuefe

! src/share/vm/logging/logFileOutput.cpp

Changeset: 786145ca3cdc
Author:    iklam
Date:      2015-10-05 13:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/786145ca3cdc

8078295: hotspot test_env.sh can set VM_CPU incorrectly
Summary: Use sed script to filter out irrelevant parts of -Xinternalversion
Reviewed-by: dlong, dcubed, dsamersoff

! test/test_env.sh

Changeset: f6da147987bb
Author:    kbarrett
Date:      2015-10-05 21:17 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f6da147987bb

8138833: Remove CMMarkStack::drain
Summary: Remove unused functions and data members.
Reviewed-by: pliden, brutisso

! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/concurrentMark.hpp

Changeset: 231ab9f9a824
Author:    pliden
Date:      2015-10-06 08:05 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/231ab9f9a824

8138846: Remove unused enum ConcurrentGCThread::CGC_flag_type
Reviewed-by: jwilhelm, brutisso

! src/share/vm/gc/shared/concurrentGCThread.cpp
! src/share/vm/gc/shared/concurrentGCThread.hpp

Changeset: 89c745739292
Author:    brutisso
Date:      2015-10-06 14:25 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/89c745739292

8138862: Remove some unused code and subclasses in gcTaskManager.hpp/cpp
Reviewed-by: mgerdin, jwilhelm

! src/share/vm/gc/parallel/gcTaskManager.cpp
! src/share/vm/gc/parallel/gcTaskManager.hpp

Changeset: 4704ecd9e198
Author:    brutisso
Date:      2015-10-06 14:26 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4704ecd9e198

8138863: Refactor WaitForBarrierGCTask
Reviewed-by: mgerdin, jwilhelm

! src/share/vm/gc/parallel/gcTaskManager.cpp
! src/share/vm/gc/parallel/gcTaskManager.hpp

Changeset: 17cfe2c6dc00
Author:    brutisso
Date:      2015-10-06 14:27 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/17cfe2c6dc00

8138707: TestPromotionEventWithParallelScavenge.java crashes using undefined GC id.
Reviewed-by: mgerdin, jwilhelm

! src/share/vm/gc/parallel/gcTaskManager.cpp
! src/share/vm/gc/parallel/gcTaskManager.hpp
! src/share/vm/gc/parallel/gcTaskThread.cpp

Changeset: f10efc097bae
Author:    mockner
Date:      2015-10-06 14:27 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f10efc097bae

8138917: Back out change for 8130681
Summary: Change 8130681 has been backed out.
Reviewed-by: coleenp, gtriantafill

! src/share/vm/services/virtualMemoryTracker.cpp
- test/runtime/NMT/CommitOverlappingRegions.java

Changeset: a6499084ccd4
Author:    coleenp
Date:      2015-10-06 18:51 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a6499084ccd4

Merge


Changeset: 00e5743fd189
Author:    jwilhelm
Date:      2015-10-07 01:03 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/00e5743fd189

Merge

! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/runtime/frame.cpp

Changeset: 5f9da6c532fe
Author:    ehelin
Date:      2015-10-07 15:06 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5f9da6c532fe

8138969: G1CollectorPolicy should use const for applicable methods
Reviewed-by: mgerdin, jwilhelm

! src/share/vm/gc/g1/g1CollectedHeap.hpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.hpp
! src/share/vm/gc/g1/g1CollectorState.hpp
! src/share/vm/gc/g1/g1MMUTracker.hpp

Changeset: 4d9b98fd9644
Author:    david
Date:      2015-10-07 15:27 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4d9b98fd9644

8138832: CreateCoredumpOnCrash on linux ARM causes assert message to be repeated.
Reviewed-by: jwilhelm, mgerdin

! src/share/vm/utilities/vmError.cpp
! src/share/vm/utilities/vmError.hpp

Changeset: c9d09b5085ea
Author:    david
Date:      2015-10-07 14:56 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c9d09b5085ea

Merge


Changeset: 313e94244ed8
Author:    ehelin
Date:      2015-10-07 17:00 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/313e94244ed8

8138971: G1CollectorPolicy::_rs_lengths_prediction is not initialized before use
Reviewed-by: mgerdin, jwilhelm

! src/share/vm/gc/g1/g1CollectorPolicy.cpp

Changeset: 81ae0334f957
Author:    ehelin
Date:      2015-10-07 17:33 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/81ae0334f957

Merge


Changeset: ee11c7701f8c
Author:    gtriantafill
Date:      2015-10-07 11:37 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ee11c7701f8c

8134432: [TESTBUG] Rewrite test/runtime/6888954/vmerrors.sh in Java
Reviewed-by: ddmitriev, ctornqvi, coleenp

! src/share/vm/utilities/debug.cpp
! test/TEST.groups
- test/runtime/6888954/vmerrors.sh
+ test/runtime/ErrorHandling/ErrorHandler.java

Changeset: 4740e6551edf
Author:    ctornqvi
Date:      2015-10-07 20:45 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4740e6551edf

Merge

- test/runtime/6888954/vmerrors.sh

Changeset: 01c086e6e523
Author:    stuefe
Date:      2015-10-01 09:30 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/01c086e6e523

8137329: [windows] Build broken on VS2010 after "8046148: JEP 158: Unified JVM Logging"
Reviewed-by: simonis, ihse, prr, goetz, dcubed

! src/share/vm/utilities/globalDefinitions_visCPP.hpp

Changeset: 332b3d89d2bd
Author:    dcubed
Date:      2015-10-07 16:41 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/332b3d89d2bd

Merge


Changeset: ad24aa13b296
Author:    dcubed
Date:      2015-10-07 22:54 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ad24aa13b296

Merge


Changeset: a9a4581814a8
Author:    kzhaldyb
Date:      2015-10-07 18:02 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a9a4581814a8

8138958: Quarantine gc/g1/mixedgc/TestLogging.java test
Reviewed-by: brutisso, iignatyev

! test/gc/g1/mixedgc/TestLogging.java

Changeset: e3053e6726f1
Author:    iignatyev
Date:      2015-10-08 01:04 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3053e6726f1

Merge


Changeset: 17986acb4825
Author:    goetz
Date:      2015-10-02 11:46 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/17986acb4825

8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775
Summary: Also fix one problematic format on ppc.
Reviewed-by: david, simonis

! make/linux/makefiles/gcc.make
! src/cpu/ppc/vm/stubGenerator_ppc.cpp
! src/share/vm/utilities/debug.hpp

Changeset: 371ac7d4ccb2
Author:    ehelin
Date:      2015-10-08 12:47 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/371ac7d4ccb2

8139134: Wrong tenuring threshold in young GC trace event
Reviewed-by: ehelin, jwilhelm
Contributed-by: Carsten Varming <cvarming at twitter.com>

! src/share/vm/gc/cms/parNewGeneration.cpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/defNewGeneration.cpp

Changeset: 5459f44b1a75
Author:    sangheki
Date:      2015-10-05 14:56 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5459f44b1a75

8134995: [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing
Summary: Add ranges and constraint functions for GC flags.
Reviewed-by: kbarrett, jmasa, jwilhelm, gziemski, zmajo

! src/share/vm/gc/g1/g1_globals.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.hpp
! src/share/vm/runtime/commandLineFlagConstraintsGC.cpp
! src/share/vm/runtime/commandLineFlagConstraintsGC.hpp
! src/share/vm/runtime/commandLineFlagRangeList.cpp
! src/share/vm/runtime/globals.hpp
+ test/gc/arguments/TestG1ConcMarkStepDurationMillis.java
! test/gc/arguments/TestG1HeapRegionSize.java
! test/gc/arguments/TestHeapFreeRatio.java
! test/gc/arguments/TestInitialTenuringThreshold.java
! test/gc/arguments/TestObjectTenuringFlags.java
! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java

Changeset: 4fa9cbb14029
Author:    jwilhelm
Date:      2015-10-08 22:35 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4fa9cbb14029

Merge


Changeset: e3b180765091
Author:    brutisso
Date:      2015-10-08 12:44 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3b180765091

8138717: TestGCEventMixedWithG1ConcurrentMark.java fails
Reviewed-by: jwilhelm, david

! src/share/vm/gc/shared/collectedHeap.cpp
! src/share/vm/gc/shared/gcId.cpp
! src/share/vm/gc/shared/gcId.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp

Changeset: 0cda477a3c85
Author:    mgerdin
Date:      2015-10-09 09:00 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0cda477a3c85

8139086: Solaris/Sparc slowdebug build fails for memset_with_concurrent_readers.cpp
Reviewed-by: dcubed, kbarrett, coleenp

! src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp

Changeset: 115188e14c15
Author:    david
Date:      2015-10-09 09:42 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/115188e14c15

8042893: compiler: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files
8042894: runtime: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files
Reviewed-by: goetz, brutisso

! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/nativeInst_x86.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/posix/vm/os_posix.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/share/vm/classfile/dictionary.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/stringTable.cpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/code/debugInfo.cpp
! src/share/vm/code/exceptionHandlerTable.cpp
! src/share/vm/code/icBuffer.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/pcDesc.cpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/scopeDesc.cpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/compiler/methodLiveness.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/oopMapCache.cpp
! src/share/vm/libadt/dict.cpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/virtualspace.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceRefKlass.cpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/markOop.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/oop.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/prims/jniCheck.cpp
! src/share/vm/prims/jvmtiEnter.xsl
! src/share/vm/prims/jvmtiEventController.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/privilegedStack.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/fprofiler.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/interfaceSupport.cpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/jniHandles.cpp
! src/share/vm/runtime/mutex.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/osThread.cpp
! src/share/vm/runtime/perfData.cpp
! src/share/vm/runtime/perfMemory.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/signature.cpp
! src/share/vm/runtime/stackValueCollection.cpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/unhandledOops.cpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vmThread.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/management.cpp
! src/share/vm/services/threadService.cpp
! src/share/vm/services/writeableFlags.cpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/globalDefinitions_gcc.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: f39faaf2ca61
Author:    david
Date:      2015-10-09 08:46 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f39faaf2ca61

Merge


Changeset: d6c2fafabfb4
Author:    ehelin
Date:      2015-10-09 15:48 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d6c2fafabfb4

8138972: G1CollectorPolicy::_max_survivor_regions should be intialized in the initializer list
Reviewed-by: jwilhelm, mgerdin

! src/share/vm/gc/g1/g1CollectorPolicy.cpp

Changeset: abd2f07dc9fa
Author:    kbarrett
Date:      2015-10-09 14:08 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/abd2f07dc9fa

8138659: Speed up InstanceKlass subclass discrimination
Summary: Add _misc_kind field and flags, move around predicates.
Reviewed-by: coleenp, stefank

! src/share/vm/oops/instanceClassLoaderKlass.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceMirrorKlass.hpp
! src/share/vm/oops/instanceRefKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/prims/jvmtiTagMap.cpp

Changeset: 2ecdb2c2d9be
Author:    brutisso
Date:      2015-10-09 20:31 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2ecdb2c2d9be

8139293: TestGCEventMixedWithG1ConcurrentMark.java fails after JDK-8134953
Reviewed-by: ecaspole, jwilhelm

! src/share/vm/gc/g1/concurrentMarkThread.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/shared/gcId.cpp
! src/share/vm/gc/shared/gcId.hpp

Changeset: 05b4a6f553fc
Author:    brutisso
Date:      2015-10-09 20:52 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/05b4a6f553fc

8139294: TestGCEventMixedWithCMSConcurrent.java still fails after JDK-8134953
Reviewed-by: jwilhelm, ecaspole

! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.hpp

Changeset: dd72902de3dc
Author:    brutisso
Date:      2015-10-09 20:45 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dd72902de3dc

Merge


Changeset: 53c5cb9d3fed
Author:    jwilhelm
Date:      2015-10-15 13:28 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/53c5cb9d3fed

Merge

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp

Changeset: 263abae1965e
Author:    thartmann
Date:      2015-10-08 08:54 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/263abae1965e

8139048: Quarantine compiler/startup/SmallCodeCacheStartup.java
Summary: Quarantine the test because it fails on JPRT for the CPU, CompactStrings and JVMCI repositories.
Reviewed-by: roland

! test/compiler/startup/SmallCodeCacheStartup.java

Changeset: f4f0e306133e
Author:    thartmann
Date:      2015-10-08 07:51 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f4f0e306133e

Merge


Changeset: 09fb2c936faa
Author:    zmajo
Date:      2015-10-08 12:10 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/09fb2c936faa

8137160: Use Compile::live_nodes instead of Compile::unique() in appropriate places -- followup
Summary: Change two code locations to use live_nodes() instead of unique() for allocating memory. Adjust comments.
Reviewed-by: kvn

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/matcher.cpp

Changeset: 0011fab3f1b5
Author:    zmajo
Date:      2015-10-08 10:25 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0011fab3f1b5

Merge


Changeset: a41fe5ffa839
Author:    twisti
Date:      2015-10-08 12:49 -1000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a41fe5ffa839

8136421: JEP 243: Java-Level JVM Compiler Interface
Reviewed-by: ihse, alanb, roland, coleenp, iveresov, kvn, kbarrett

! make/bsd/makefiles/compiler1.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/minimal1.make
! make/excludeSrc.make
+ make/gensrc/Gensrc-jdk.vm.ci.gmk
! make/linux/makefiles/compiler1.make
! make/linux/makefiles/minimal1.make
! make/solaris/makefiles/compiler1.make
! make/windows/build_vm_def.sh
! make/windows/create_obj_files.sh
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/vm.make
! src/cpu/aarch64/vm/compiledIC_aarch64.cpp
! src/cpu/aarch64/vm/cppInterpreterGenerator_aarch64.hpp
! src/cpu/aarch64/vm/interpreterGenerator_aarch64.hpp
+ src/cpu/aarch64/vm/jvmciCodeInstaller_aarch64.cpp
! src/cpu/aarch64/vm/relocInfo_aarch64.cpp
! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp
! src/cpu/ppc/vm/compiledIC_ppc.cpp
+ src/cpu/ppc/vm/jvmciCodeInstaller_ppc.cpp
! src/cpu/ppc/vm/relocInfo_ppc.cpp
! src/cpu/ppc/vm/sharedRuntime_ppc.cpp
! src/cpu/sparc/vm/compiledIC_sparc.cpp
! src/cpu/sparc/vm/cppInterpreterGenerator_sparc.hpp
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp
+ src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.hpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.hpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/sparc/vm/vmStructs_sparc.hpp
! src/cpu/sparc/vm/vm_version_sparc.hpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/assembler_x86.inline.hpp
! src/cpu/x86/vm/compiledIC_x86.cpp
! src/cpu/x86/vm/cppInterpreterGenerator_x86.hpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/cpu/x86/vm/globals_x86.hpp
! src/cpu/x86/vm/interp_masm_x86.cpp
! src/cpu/x86/vm/interp_masm_x86.hpp
! src/cpu/x86/vm/interpreterGenerator_x86.hpp
+ src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/nativeInst_x86.cpp
! src/cpu/x86/vm/nativeInst_x86.hpp
+ src/cpu/x86/vm/registerMap_x86.cpp
! src/cpu/x86/vm/registerMap_x86.hpp
! src/cpu/x86/vm/register_x86.cpp
! src/cpu/x86/vm/register_x86.hpp
! src/cpu/x86/vm/relocInfo_x86.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86.cpp
! src/cpu/x86/vm/vmStructs_x86.hpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/cpu/x86/vm/x86_64.ad
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/overview.html
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/AbstractAddress.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/Architecture.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BailoutException.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BytecodeFrame.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BytecodePosition.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CallingConvention.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CodeCacheProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CodeUtil.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CompilationResult.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/DataSection.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/DebugInfo.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/InfopointReason.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/InstalledCode.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/InvalidInstalledCodeException.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/Location.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/MemoryBarriers.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/ReferenceMap.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/Register.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterAttributes.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterConfig.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterSaveLayout.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/SourceStackTrace.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackLockValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackSlot.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackSlotValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/TargetDescription.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/UnsignedMath.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/ValueUtil.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/VirtualObject.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/VirtualStackSlot.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/package-info.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/InspectedFrame.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/InspectedFrameVisitor.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/StackIntrospection.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.common/src/jdk/vm/ci/common/JVMCIError.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.common/src/jdk/vm/ci/common/UnsafeUtil.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/Compiler.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/CompilerFactory.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/StartupEventListener.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotRegisterConfig.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.sparc/src/jdk/vm/ci/hotspot/sparc/SPARCHotSpotJVMCIBackendFactory.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.sparc/src/jdk/vm/ci/hotspot/sparc/SPARCHotSpotRegisterConfig.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCodeCacheProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompiledCode.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompiledNmethod.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompressedNullConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotForeignCallTarget.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotInstalledCode.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCICompilerConfig.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIMetaAccessContext.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntimeProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJavaType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProviderImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaAccessProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaspaceConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaspaceConstantImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethod.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodData.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodHandleAccessProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodUnresolved.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotNmethod.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotObjectConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotObjectConstantImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotOopMap.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProfilingInfo.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProxified.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotReferenceMap.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaField.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaFieldImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedPrimitiveType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSentinelConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSignature.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSpeculationLog.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotStackFrameReference.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotUnresolvedField.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotUnresolvedJavaType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigVerifier.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMEventListener.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVmSymbols.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/MetaspaceWrapperObject.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/Stable.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/SuppressFBWarnings.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/UnsafeAccess.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/events/EmptyEventProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/events/EventProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/logging/package-info.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMAddress.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMData.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMField.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMFlag.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMManual.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.inittimer/src/jdk/vm/ci/inittimer/InitTimer.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.inittimer/src/jdk/vm/ci/inittimer/SuppressFBWarnings.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/overview.html
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/AbstractJavaProfile.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/AbstractProfiledItem.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/AllocatableValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Assumptions.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Constant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ConstantPool.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ConstantReflectionProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/DefaultProfilingInfo.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/DeoptimizationAction.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/DeoptimizationReason.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ExceptionHandler.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/InvokeTarget.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JVMCIMetaAccessContext.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaField.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaKind.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaMethod.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaMethodProfile.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaTypeProfile.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LIRKind.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LineNumberTable.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LineNumberTableImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Local.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocalImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocalVariableTable.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocalVariableTableImpl.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocationIdentity.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MemoryAccessProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaAccessProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MethodHandleAccessProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ModifiersProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/NullConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/PlatformKind.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/PrimitiveConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ProfilingInfo.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/RawConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaField.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaMethod.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/SerializableConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Signature.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/SpeculationLog.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/TriState.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/TrustedInterface.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/VMConstant.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Value.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/package-info.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options.processor/src/META-INF/services/javax.annotation.processing.Processor
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options.processor/src/jdk/vm/ci/options/processor/OptionProcessor.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/DerivedOptionValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/JVMCIJarsOptionDescriptorsProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/NestedBooleanOptionValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/Option.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionDescriptor.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionDescriptors.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionType.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionsLoader.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionsParser.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/StableOptionValue.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCIBackend.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCIRuntime.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.service.processor/src/META-INF/services/javax.annotation.processing.Processor
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.service.processor/src/jdk/vm/ci/service/processor/ServiceProviderProcessor.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.service/src/jdk/vm/ci/service/ServiceProvider.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.service/src/jdk/vm/ci/service/Services.java
+ src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARC.java
+ src/os/aix/vm/vmStructs_aix.hpp
+ src/os/bsd/vm/vmStructs_bsd.hpp
+ src/os/linux/vm/vmStructs_linux.hpp
+ src/os/solaris/vm/vmStructs_solaris.hpp
! src/os/windows/vm/os_windows.cpp
+ src/os/windows/vm/vmStructs_windows.hpp
! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp
! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp
! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp
! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp
! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_IR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/metadataOnStackMark.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/compiledIC.cpp
! src/share/vm/code/compiledIC.hpp
! src/share/vm/code/debugInfo.cpp
! src/share/vm/code/debugInfo.hpp
! src/share/vm/code/debugInfoRec.cpp
! src/share/vm/code/debugInfoRec.hpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/dependencies.hpp
! src/share/vm/code/exceptionHandlerTable.cpp
! src/share/vm/code/exceptionHandlerTable.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/oopRecorder.cpp
! src/share/vm/code/oopRecorder.hpp
! src/share/vm/code/pcDesc.hpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/relocInfo.hpp
! src/share/vm/code/scopeDesc.cpp
! src/share/vm/code/scopeDesc.hpp
! src/share/vm/compiler/abstractCompiler.cpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/compiler/compileTask.cpp
! src/share/vm/compiler/compileTask.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/compiler/oopMap.cpp
! src/share/vm/compiler/oopMap.hpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1MarkSweep.cpp
! src/share/vm/gc/g1/g1SATBCardTableModRefBS.cpp
! src/share/vm/gc/g1/g1SATBCardTableModRefBS.hpp
! src/share/vm/gc/parallel/psMarkSweep.cpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/genMarkSweep.cpp
! src/share/vm/gc/shared/barrierSet.hpp
! src/share/vm/gc/shared/cardTableRS.cpp
! src/share/vm/gc/shared/collectedHeap.cpp
! src/share/vm/gc/shared/collectedHeap.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/referenceProcessor.cpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/interpreter/templateInterpreterGenerator.hpp
+ src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.cpp
+ src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.hpp
+ src/share/vm/jvmci/jvmciCodeInstaller.cpp
+ src/share/vm/jvmci/jvmciCodeInstaller.hpp
+ src/share/vm/jvmci/jvmciCompiler.cpp
+ src/share/vm/jvmci/jvmciCompiler.hpp
+ src/share/vm/jvmci/jvmciCompilerToVM.cpp
+ src/share/vm/jvmci/jvmciCompilerToVM.hpp
+ src/share/vm/jvmci/jvmciEnv.cpp
+ src/share/vm/jvmci/jvmciEnv.hpp
+ src/share/vm/jvmci/jvmciJavaClasses.cpp
+ src/share/vm/jvmci/jvmciJavaClasses.hpp
+ src/share/vm/jvmci/jvmciRuntime.cpp
+ src/share/vm/jvmci/jvmciRuntime.hpp
+ src/share/vm/jvmci/jvmci_globals.cpp
+ src/share/vm/jvmci/jvmci_globals.hpp
+ src/share/vm/jvmci/systemDictionary_jvmci.hpp
+ src/share/vm/jvmci/vmStructs_jvmci.hpp
+ src/share/vm/jvmci/vmSymbols_jvmci.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/superword.hpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiCodeBlobEvents.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.cpp
! src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp
! src/share/vm/runtime/commandLineFlagRangeList.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/deoptimization.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/globals_extension.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/javaCalls.cpp
! src/share/vm/runtime/javaCalls.hpp
! src/share/vm/runtime/rframe.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/timer.cpp
! src/share/vm/runtime/timer.hpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vmStructs.hpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp
! src/share/vm/shark/sharkCacheDecache.cpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/fakeRttiSupport.hpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/growableArray.hpp
! src/share/vm/utilities/macros.hpp
! src/share/vm/utilities/top.hpp
! src/share/vm/utilities/vmError.cpp
+ test/compiler/jvmci/JVM_GetJVMCIRuntimeTest.java
+ test/compiler/jvmci/SecurityRestrictionsTest.java
+ test/compiler/jvmci/common/CTVMUtilities.java
+ test/compiler/jvmci/common/CompilerToVMHelper.java
+ test/compiler/jvmci/common/JVMCIHelpers.java
+ test/compiler/jvmci/common/services/jdk.vm.ci.compiler.Compiler
+ test/compiler/jvmci/common/services/jdk.vm.ci.compiler.CompilerFactory
+ test/compiler/jvmci/common/services/jdk.vm.ci.hotspot.HotSpotVMEventListener
+ test/compiler/jvmci/common/testcases/AbstractClass.java
+ test/compiler/jvmci/common/testcases/AbstractClassExtender.java
+ test/compiler/jvmci/common/testcases/AnotherSingleImplementer.java
+ test/compiler/jvmci/common/testcases/AnotherSingleImplementerInterface.java
+ test/compiler/jvmci/common/testcases/DoNotExtendClass.java
+ test/compiler/jvmci/common/testcases/DoNotImplementInterface.java
+ test/compiler/jvmci/common/testcases/MultiSubclassedClass.java
+ test/compiler/jvmci/common/testcases/MultiSubclassedClassSubclass1.java
+ test/compiler/jvmci/common/testcases/MultiSubclassedClassSubclass2.java
+ test/compiler/jvmci/common/testcases/MultipleAbstractImplementer.java
+ test/compiler/jvmci/common/testcases/MultipleImplementer1.java
+ test/compiler/jvmci/common/testcases/MultipleImplementer2.java
+ test/compiler/jvmci/common/testcases/MultipleImplementersInterface.java
+ test/compiler/jvmci/common/testcases/MultipleImplementersInterfaceExtender.java
+ test/compiler/jvmci/common/testcases/PackagePrivateClass.java
+ test/compiler/jvmci/common/testcases/SimpleClass.java
+ test/compiler/jvmci/common/testcases/SingleImplementer.java
+ test/compiler/jvmci/common/testcases/SingleImplementerInterface.java
+ test/compiler/jvmci/common/testcases/SingleSubclass.java
+ test/compiler/jvmci/common/testcases/SingleSubclassedClass.java
+ test/compiler/jvmci/common/testcases/TestCase.java
+ test/compiler/jvmci/compilerToVM/AllocateCompileIdTest.java
+ test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java
+ test/compiler/jvmci/compilerToVM/CollectCountersTest.java
+ test/compiler/jvmci/compilerToVM/CompileCodeTestCase.java
+ test/compiler/jvmci/compilerToVM/ConstantPoolTestCase.java
+ test/compiler/jvmci/compilerToVM/ConstantPoolTestsHelper.java
+ test/compiler/jvmci/compilerToVM/DebugOutputTest.java
+ test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java
+ test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java
+ test/compiler/jvmci/compilerToVM/DummyAbstractClass.java
+ test/compiler/jvmci/compilerToVM/DummyClass.java
+ test/compiler/jvmci/compilerToVM/DummyInterface.java
+ test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java
+ test/compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java
+ test/compiler/jvmci/compilerToVM/GetBytecodeTest.java
+ test/compiler/jvmci/compilerToVM/GetClassInitializerTest.java
+ test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java
+ test/compiler/jvmci/compilerToVM/GetExceptionTableTest.java
+ test/compiler/jvmci/compilerToVM/GetImplementorTest.java
+ test/compiler/jvmci/compilerToVM/GetLineNumberTableTest.java
+ test/compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java
+ test/compiler/jvmci/compilerToVM/GetMaxCallTargetOffsetTest.java
+ test/compiler/jvmci/compilerToVM/GetNextStackFrameTest.java
+ test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodAtSlotTest.java
+ test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java
+ test/compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java
+ test/compiler/jvmci/compilerToVM/GetStackTraceElementTest.java
+ test/compiler/jvmci/compilerToVM/GetSymbolTest.java
+ test/compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java
+ test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java
+ test/compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java
+ test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java
+ test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java
+ test/compiler/jvmci/compilerToVM/IsMatureTest.java
+ test/compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java
+ test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java
+ test/compiler/jvmci/compilerToVM/LookupTypeTest.java
+ test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java
+ test/compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java
+ test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java
+ test/compiler/jvmci/compilerToVM/ReprofileTest.java
+ test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java
+ test/compiler/jvmci/compilerToVM/ResolveMethodTest.java
+ test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java
+ test/compiler/jvmci/compilerToVM/ShouldDebugNonSafepointsTest.java
+ test/compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java
+ test/compiler/jvmci/events/JvmciCompleteInitializationTest.config
+ test/compiler/jvmci/events/JvmciCompleteInitializationTest.java
+ test/compiler/jvmci/events/JvmciCreateMetaAccessContextTest.config
+ test/compiler/jvmci/events/JvmciCreateMetaAccessContextTest.java
+ test/compiler/jvmci/events/JvmciNotifyInstallEventTest.config
+ test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java
+ test/compiler/jvmci/events/JvmciShutdownEventListener.java
+ test/compiler/jvmci/events/JvmciShutdownEventTest.config
+ test/compiler/jvmci/events/JvmciShutdownEventTest.java
+ test/compiler/jvmci/events/MetaAccessWrapper.java
+ test/compiler/jvmci/jdk.vm.ci.options.test/src/jdk/vm/ci/options/test/NestedBooleanOptionValueTest.java
+ test/compiler/jvmci/jdk.vm.ci.options.test/src/jdk/vm/ci/options/test/TestOptionValue.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantTest.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/FieldUniverse.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/MethodUniverse.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/NameAndSignature.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveConcreteMethodTest.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveMethodTest.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaField.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaMethod.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaType.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java
+ test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TypeUniverse.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: 13c4fa17712e
Author:    dlong
Date:      2015-10-09 02:43 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/13c4fa17712e

Merge

! src/cpu/x86/vm/templateInterpreter_x86_32.cpp

Changeset: 926d9bae67d3
Author:    thartmann
Date:      2015-10-09 11:28 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/926d9bae67d3

8139150: ClassVerifier frees exception message while it's still in use
Summary: Remove ResourceMark in StackMapReader::parse_verification_type() to avoid freeing of error message.
Reviewed-by: zmajo, dcubed, hseigel

! src/share/vm/classfile/stackMapTable.cpp

Changeset: 0300297e7df3
Author:    zmajo
Date:      2015-10-09 14:21 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0300297e7df3

8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing
Summary: Add range check or constraint where necessary.
Reviewed-by: roland, thartmann

! src/cpu/sparc/vm/globals_sparc.hpp
! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/x86/vm/globals_x86.hpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/share/vm/c1/c1_globals.hpp
! src/share/vm/oops/methodCounters.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp
! src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp
! src/share/vm/runtime/globals.hpp
! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
! test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java
! test/testlibrary_tests/whitebox/vm_flags/IntxTest.java

Changeset: 71e75172487b
Author:    zmajo
Date:      2015-10-09 15:00 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/71e75172487b

8081288: erronous free in RegClass::~RegClass()
Summary: Remove the erronous free.
Reviewed-by: kvn

! src/share/vm/adlc/formsopt.cpp

Changeset: 6c4a9b1af999
Author:    twisti
Date:      2015-10-09 09:09 -1000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6c4a9b1af999

8138820: JDK Hotspot build fails with Xcode 7.0.1
Reviewed-by: iveresov

! make/bsd/makefiles/gcc.make

Changeset: a37a6ca422b1
Author:    iveresov
Date:      2015-10-09 12:17 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a37a6ca422b1

8136725: Provide utility for creation a counted loop reserve copy (clone)
Summary: Make it easier to revert to the original loop should that be needed
Reviewed-by: kvn
Contributed-by: jan.civlin at intel.com

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/superword.hpp

Changeset: dda16b631985
Author:    iveresov
Date:      2015-10-09 21:04 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dda16b631985

Merge


Changeset: de73f59378c1
Author:    redestad
Date:      2015-10-12 14:54 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/de73f59378c1

8134607: Remove per-compiler performance counters
Reviewed-by: twisti, neliasso

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp

Changeset: 1f0d9d89003a
Author:    iveresov
Date:      2015-10-12 16:35 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1f0d9d89003a

8139454: java/lang/Math/WorstCaseTests.java crashes on Linux-amd64
Summary: Emit the form of pextrw that works with sse2
Reviewed-by: iveresov, twisti
Contributed-by: vivek.r.deshpande at intel.com

! src/cpu/x86/vm/assembler_x86.cpp

Changeset: c6a1e7983723
Author:    mdoerr
Date:      2015-10-12 12:20 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c6a1e7983723

8139421: PPC64LE: MacroAssembler::bxx64_patchable kill register R12
Summary: Register R12 must be preserved for stub calls (e.g. deopt handler).
Reviewed-by: goetz

! src/cpu/ppc/vm/macroAssembler_ppc.cpp

Changeset: 7477b0afa5d6
Author:    zmajo
Date:      2015-10-13 10:09 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7477b0afa5d6

8139377: JVM can't be started w/ -XX:+EnableJVMCI -XX:+UseJVMCICompiler and default TypeProfileWidth
Summary: Raise upper bound of TypeProfileWidth from 4 to 8.
Reviewed-by: iveresov, twisti

! src/share/vm/runtime/globals.hpp

Changeset: 738f57684fed
Author:    enevill
Date:      2015-10-13 09:40 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/738f57684fed

8139259: aarch64: jtreg test TestLogSum segvs after 8132207
Summary: Fix jump to 0 caused by uninitialised _dexp in 8132207
Reviewed-by: roland, kvn

! src/share/vm/opto/library_call.cpp

Changeset: f2983a0f7a57
Author:    roland
Date:      2015-10-13 13:23 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f2983a0f7a57

Merge


Changeset: 2598332ad46c
Author:    aph
Date:      2015-09-30 13:23 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2598332ad46c

8138641: Disable C2 peephole by default for aarch64
Reviewed-by: roland
Contributed-by: felix.yang at linaro.org

! src/cpu/aarch64/vm/c2_globals_aarch64.hpp

Changeset: 0ca52fb7d980
Author:    aph
Date:      2015-09-29 17:01 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0ca52fb7d980

8138575: Improve generated code for profile counters
Reviewed-by: kvn

! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp

Changeset: 870c2e0f67f6
Author:    enevill
Date:      2015-10-08 13:14 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/870c2e0f67f6

8139043: aarch64: add support for adler32 intrinsic
Summary: Add adler32 support like 8132081 for sparc
Reviewed-by: kvn

! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp
! src/cpu/aarch64/vm/vm_version_aarch64.cpp

Changeset: c274072ab8f7
Author:    twisti
Date:      2015-10-13 09:21 -1000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c274072ab8f7

8139524: JVMCI cannot be initialized with CMS or Serial GCs
Reviewed-by: iveresov

! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java

Changeset: d9eb619390d9
Author:    twisti
Date:      2015-10-14 09:22 -1000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d9eb619390d9

8139545: JVMCI : guarantee(heap_end < allocation_end) failed on some sparcv9 hosts
Reviewed-by: iveresov, kvn

! src/share/vm/jvmci/jvmciRuntime.cpp

Changeset: 78888d676ed7
Author:    twisti
Date:      2015-10-14 12:29 -1000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/78888d676ed7

8139386: JVMCI test failed with assert(_jvmci._alternate_call_target == 0L) failed: must be
Reviewed-by: kvn

! src/cpu/sparc/vm/sharedRuntime_sparc.cpp

Changeset: baccb954c369
Author:    roland
Date:      2015-10-15 09:40 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/baccb954c369

8138956: Elide more final field's write memory barrier with escape analysis result
Summary: membar for final/stable fields eliminated if possible
Reviewed-by: roland, mdoerr, enevill, aph
Contributed-by: hui.shi at linaro.org

! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse3.cpp

Changeset: 9ab5571ccea8
Author:    roland
Date:      2015-10-15 07:56 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9ab5571ccea8

Merge


Changeset: db88a5e95717
Author:    iignatyev
Date:      2015-10-13 16:21 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/db88a5e95717

8139376: [TESTBUG] ExecuteInstalledCodeTest should be run only on amd64 and sparcv9
Reviewed-by: twisti, kvn

! test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java

Changeset: ceec25b3f949
Author:    tpivovarova
Date:      2015-10-15 01:58 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ceec25b3f949

8139375: [TESTBUG] compiler/jvmci/SecurityRestrictionsTest checks are too tight
Reviewed-by: twisti, iignatyev

! test/compiler/jvmci/SecurityRestrictionsTest.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: acf9f6650193
Author:    dpochepk
Date:      2015-10-15 02:46 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/acf9f6650193

8139438: [TESTBUG] JVMCI test fails with RuntimeException: Has no virtual object before materialization
Reviewed-by: iignatyev, twisti

! test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java

Changeset: 964538c2362a
Author:    iignatyev
Date:      2015-10-15 09:36 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/964538c2362a

Merge


Changeset: 2abd2feb000b
Author:    iignatyev
Date:      2015-10-15 11:20 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2abd2feb000b

Merge


Changeset: e9fede3afe79
Author:    kshefov
Date:      2015-10-15 18:00 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e9fede3afe79

8072369: [TESTBUG] Remove potentially insecure class cast in some hotspot tests
Reviewed-by: twisti, kvn, iignatyev, tpivovarova

! test/compiler/c2/5057225/Test5057225.java
! test/compiler/c2/6603011/Test.java
! test/compiler/c2/6800154/Test6800154.java
! test/compiler/c2/6805724/Test6805724.java
! test/compiler/codegen/6823354/Test6823354.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: cf43bef12125
Author:    zmajo
Date:      2015-10-15 17:38 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cf43bef12125

8080650: Enable stubs to use frame pointers correctly
Summary: Change MacroAssembler::verified_entry() to set up RBP correctly when generating stub code.
Reviewed-by: kvn

! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad

Changeset: e012dfc7ba2c
Author:    zmajo
Date:      2015-10-15 17:40 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e012dfc7ba2c

Merge


Changeset: 6bef5a526bee
Author:    iignatyev
Date:      2015-10-16 01:15 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6bef5a526bee

8138794: [TESTBUG] ctw tests fail to compile after 8137056
Reviewed-by: dlong, kvn

! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java

Changeset: fe46f2941ea9
Author:    iignatyev
Date:      2015-10-16 02:05 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fe46f2941ea9

8139707: [TESTBUG] Quarantine unstable compiler/jvmci tests
Reviewed-by: twisti

! test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java
! test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java
! test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java

Changeset: 41b06143f4f8
Author:    enevill
Date:      2015-10-15 15:33 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/41b06143f4f8

8139674: aarch64: guarantee failure in TestOptionsWithRanges.java
Summary: Fix negative overflow in instruction field
Reviewed-by: kvn, roland, adinn, aph

! src/cpu/aarch64/vm/interp_masm_aarch64.cpp

Changeset: 93ae449c9b52
Author:    aph
Date:      2015-10-13 16:25 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/93ae449c9b52

8139041: Redundant DMB instructions
Summary: Merge consecutive DMB intstructions
Reviewed-by: roland, kvn, twisti

! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp
! src/cpu/aarch64/vm/nativeInst_aarch64.hpp
! src/share/vm/asm/codeBuffer.hpp

Changeset: 5ffaf14b397d
Author:    roland
Date:      2015-10-16 11:47 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5ffaf14b397d

Merge


Changeset: bfd1cd5fbb7c
Author:    zmajo
Date:      2015-10-16 15:21 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bfd1cd5fbb7c

8139380: VMError::report_and_die() does not produce replay file
Summary: Change VMError::report() to use a correct format string in both JVMCI-enabled builds and builds without JVMCI.
Reviewed-by: roland, kvn

! src/share/vm/utilities/vmError.cpp

Changeset: 09338e9e661c
Author:    roland
Date:      2015-10-16 15:48 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/09338e9e661c

8139750: [BACKOUT] Elide more final field's write memory barrier with escape analysis result
Reviewed-by: kvn

! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse3.cpp

Changeset: 179aa0067f01
Author:    roland
Date:      2015-10-16 16:09 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/179aa0067f01

Merge


Changeset: a8a8604f890f
Author:    dlong
Date:      2015-10-17 19:40 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a8a8604f890f

Merge

! make/windows/makefiles/vm.make
! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp
! src/cpu/ppc/vm/macroAssembler_ppc.cpp
! src/cpu/ppc/vm/sharedRuntime_ppc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/nativeInst_x86.cpp
! src/cpu/x86/vm/register_x86.hpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/os/windows/vm/os_windows.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/metadataOnStackMark.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/code/debugInfo.cpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/exceptionHandlerTable.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/scopeDesc.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1MarkSweep.cpp
! src/share/vm/gc/parallel/psMarkSweep.cpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/genMarkSweep.cpp
! src/share/vm/gc/shared/cardTableRS.cpp
! src/share/vm/gc/shared/collectedHeap.cpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/referenceProcessor.cpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
+ src/share/vm/jvmci/jvmciCodeInstaller.cpp
+ src/share/vm/jvmci/jvmciJavaClasses.cpp
+ src/share/vm/jvmci/jvmciJavaClasses.hpp
+ src/share/vm/jvmci/jvmciRuntime.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.cpp
! src/share/vm/runtime/commandLineFlagRangeList.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/fakeRttiSupport.hpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/vmError.cpp
! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java

Changeset: 846276b97202
Author:    amurillo
Date:      2015-10-19 12:30 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/846276b97202

Merge

- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java
- test/runtime/6888954/vmerrors.sh

Changeset: 4be1d228e368
Author:    twisti
Date:      2015-10-21 11:41 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4be1d228e368

8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes
Reviewed-by: erikj

! make/gensrc/Gensrc-jdk.vm.ci.gmk

Changeset: e197d5a708f1
Author:    lana
Date:      2015-10-21 18:39 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e197d5a708f1

Merge

- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java
- test/runtime/6888954/vmerrors.sh

Changeset: 1904cb079212
Author:    lana
Date:      2015-10-22 11:13 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1904cb079212

Merge

- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java
- test/runtime/6888954/vmerrors.sh

Changeset: 2bc339eaafcd
Author:    david
Date:      2015-10-13 08:37 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2bc339eaafcd

8139427: Break out YoungList to own class.
Reviewed-by: mgerdin, jwilhelm

! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectedHeap.hpp
+ src/share/vm/gc/g1/youngList.cpp
+ src/share/vm/gc/g1/youngList.hpp

Changeset: 8b8a3e7af130
Author:    tschatzl
Date:      2015-10-13 14:49 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8b8a3e7af130

8069330: Adjustment of concurrent refinement thresholds does not take hot card cache into account
Summary: Measure HCC processing time separately and remove that time from the calculation of the refinement thresholds. HCC processing time is still taken into account for general pause time predictions.
Reviewed-by: tbenson, jmasa

! src/share/vm/gc/g1/concurrentG1Refine.hpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1CollectedHeap.hpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.hpp
! src/share/vm/gc/g1/g1ErgoVerbose.cpp
! src/share/vm/gc/g1/g1ErgoVerbose.hpp
! src/share/vm/gc/g1/g1GCPhaseTimes.cpp
! src/share/vm/gc/g1/g1GCPhaseTimes.hpp
! src/share/vm/gc/g1/g1HotCardCache.cpp
! src/share/vm/gc/g1/g1HotCardCache.hpp
! src/share/vm/gc/g1/g1RemSet.cpp
! test/gc/g1/TestGCLogMessages.java

Changeset: 3417a8fa7b45
Author:    david
Date:      2015-10-13 14:07 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3417a8fa7b45

8139506: Remove the WaterMark class
Reviewed-by: stefank, mgerdin

! src/share/vm/gc/g1/heapRegion.hpp
! src/share/vm/gc/shared/generation.hpp
! src/share/vm/gc/shared/space.cpp
! src/share/vm/gc/shared/space.hpp
- src/share/vm/gc/shared/watermark.hpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: b7618d69edaf
Author:    david
Date:      2015-10-13 17:34 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b7618d69edaf

Merge

- src/share/vm/gc/shared/watermark.hpp

Changeset: c8a4fbc7f6f4
Author:    hseigel
Date:      2015-10-14 13:30 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c8a4fbc7f6f4

8139069: JVM should throw ClassFormatError for <init> methods in interfaces
Summary: If method being parsed is in an interface, throw ClassFormatError if its name is "<init>"
Reviewed-by: acorn, lfoltan

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/verifier.cpp
+ test/runtime/classFileParserBug/InitInInterface.java
+ test/runtime/classFileParserBug/nonvoidinit.jasm
+ test/runtime/classFileParserBug/voidinit.jasm

Changeset: 088ca8a0e910
Author:    poonam
Date:      2015-10-14 15:36 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/088ca8a0e910

8136577: Make AbortVMOnException available in product builds
Reviewed-by: coleenp

! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/exceptions.hpp

Changeset: bc00f9701b9c
Author:    minqi
Date:      2015-10-14 08:12 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bc00f9701b9c

8135284: Remove Method::_method_size field
Summary: Remove Method::_method_size to improve memory footprint after JDK-8135085,which increased 4 bytes for 32 platform. Also removed related unused code in SA.
Reviewed-by: coleenp, hseigel

! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 5a7f73370cf8
Author:    minqi
Date:      2015-10-14 20:59 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5a7f73370cf8

Merge


Changeset: 1d78034f1852
Author:    minqi
Date:      2015-10-15 00:42 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1d78034f1852

Merge


Changeset: 8c666050d769
Author:    david
Date:      2015-10-14 09:33 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8c666050d769

8139434: Unify GenRemSet and CardTableRS
Reviewed-by: jwilhelm, mgerdin

! src/share/vm/gc/g1/g1CollectedHeap.hpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/serial/defNewGeneration.cpp
! src/share/vm/gc/serial/genMarkSweep.cpp
! src/share/vm/gc/serial/tenuredGeneration.cpp
! src/share/vm/gc/serial/tenuredGeneration.hpp
! src/share/vm/gc/shared/cardGeneration.cpp
! src/share/vm/gc/shared/cardGeneration.hpp
! src/share/vm/gc/shared/cardTableRS.cpp
! src/share/vm/gc/shared/cardTableRS.hpp
! src/share/vm/gc/shared/collectorPolicy.cpp
! src/share/vm/gc/shared/collectorPolicy.hpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
! src/share/vm/gc/shared/genCollectedHeap.hpp
! src/share/vm/gc/shared/genOopClosures.inline.hpp
- src/share/vm/gc/shared/genRemSet.cpp
- src/share/vm/gc/shared/genRemSet.hpp
! src/share/vm/gc/shared/generation.cpp
! src/share/vm/gc/shared/generation.hpp
! src/share/vm/gc/shared/generationSpec.cpp
! src/share/vm/gc/shared/generationSpec.hpp
! src/share/vm/gc/shared/space.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 5f32f22ba25e
Author:    mgerdin
Date:      2015-10-14 14:50 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5f32f22ba25e

8138762: Refactor setup of evacuation closures in G1
Summary: Introduce policy class containing the root scan closures.
Reviewed-by: ehelin, stefank

! src/share/vm/gc/g1/g1CodeBlobClosure.hpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1OopClosures.cpp
! src/share/vm/gc/g1/g1OopClosures.hpp
! src/share/vm/gc/g1/g1OopClosures.inline.hpp
! src/share/vm/gc/g1/g1ParScanThreadState.cpp
! src/share/vm/gc/g1/g1ParScanThreadState.hpp
! src/share/vm/gc/g1/g1RemSet.cpp
! src/share/vm/gc/g1/g1RemSet.hpp
+ src/share/vm/gc/g1/g1RootClosures.cpp
+ src/share/vm/gc/g1/g1RootClosures.hpp
! src/share/vm/gc/g1/g1RootProcessor.cpp
! src/share/vm/gc/g1/g1RootProcessor.hpp

Changeset: 5b33eeb13775
Author:    tschatzl
Date:      2015-10-15 10:07 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5b33eeb13775

8137082: Factor out G1 prediction code from G1CollectorPolicy and clean up
Summary: Factor out G1 prediction code from G1CollectorPolicy into its own class, constify methods of G1CollectorPolicy and move more implementations to the cpp file.
Reviewed-by: jmasa, sangheki, ecaspole, kbarrett

! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.cpp
! src/share/vm/gc/g1/g1CollectorPolicy.hpp
! src/share/vm/gc/g1/g1CollectorState.hpp
+ src/share/vm/gc/g1/g1Predictions.cpp
+ src/share/vm/gc/g1/g1Predictions.hpp
! src/share/vm/gc/g1/survRateGroup.cpp
! src/share/vm/gc/g1/survRateGroup.hpp
! src/share/vm/prims/jni.cpp

Changeset: 2feeca2b688f
Author:    tschatzl
Date:      2015-10-15 10:12 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2feeca2b688f

8139583: Fix formatting in survRateGroup.cpp
Reviewed-by: kbarrett, stefank

! src/share/vm/gc/g1/survRateGroup.cpp

Changeset: daa76166601c
Author:    tschatzl
Date:      2015-10-15 10:13 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/daa76166601c

8138750: Remove dead code in survivor rate group
Reviewed-by: mgerdin, tbenson

! src/share/vm/gc/g1/g1CollectorPolicy.hpp
! src/share/vm/gc/g1/g1CollectorState.hpp
! src/share/vm/gc/g1/survRateGroup.cpp
! src/share/vm/gc/g1/survRateGroup.hpp

Changeset: a0f7fb36730a
Author:    tschatzl
Date:      2015-10-15 10:15 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a0f7fb36730a

8138752: G1CollectorPolicy::should_should_update_surv_rate_group_predictors() uses wrong predicate
Summary: Instead of only updating the survivor rate groups in the young gc after marking and before mixed gc, update them during young gcs outside of marking
Reviewed-by: mgerdin, drwhite

! src/share/vm/gc/g1/g1CollectorPolicy.hpp

Changeset: 47181fafd4e9
Author:    tschatzl
Date:      2015-10-15 13:00 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/47181fafd4e9

Merge

! src/share/vm/gc/g1/g1CollectorPolicy.cpp

Changeset: 901d0ab08236
Author:    jbachorik
Date:      2015-10-15 17:35 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/901d0ab08236

8135188: RunFinalizationTest.java Exception java.lang.Error: Test failure: Object was not finalized
Reviewed-by: dcubed, martin

+ test/serviceability/dcmd/gc/FinalizationRunner.java
! test/serviceability/dcmd/gc/RunFinalizationTest.java

Changeset: 1a85bb362183
Author:    dcubed
Date:      2015-10-15 10:00 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1a85bb362183

8136552: Last argument wins does not work for special options with "-XX:VMOptionsFile" option
Summary: match_special_option_and_act() should insert_vm_options_file() earlier and process the inserted options right away to honor "last option wins" semantics.
Reviewed-by: dcubed, coleenp

! src/share/vm/runtime/arguments.cpp
! test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java

Changeset: cdd81465ef70
Author:    dcubed
Date:      2015-10-15 19:17 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cdd81465ef70

Merge


Changeset: 3f28db271235
Author:    gziemski
Date:      2015-10-15 13:34 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3f28db271235

8078556: Runtime: implement ranges (optionally constraints) for those flags that have them missing.
Summary: JEP 245: implement ranges and constraints for runtime flags.
Reviewed-by: coleenp, ddmitriev, jiangli, goetz
Contributed-by: goetz.lindenmaier at sap.com, gerard.ziemski at oracle.com

! src/cpu/aarch64/vm/globals_aarch64.hpp
! src/cpu/ppc/vm/globals_ppc.hpp
! src/cpu/sparc/vm/globals_sparc.hpp
! src/cpu/x86/vm/globals_x86.hpp
! src/cpu/zero/vm/globals_zero.hpp
! src/os/aix/vm/globals_aix.hpp
! src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.hpp
! src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
! src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
! src/share/vm/runtime/commandLineFlagRangeList.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/vmThread.cpp
! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java

Changeset: db268cb78542
Author:    coleenp
Date:      2015-10-16 00:01 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/db268cb78542

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 01b171218ecd
Author:    kbarrett
Date:      2015-10-15 10:10 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/01b171218ecd

8139200: Eliminate G1ParClosureSuper::_worker_id
Summary: Moved _worker_id from G1ParClosureSuper to G1ParCopyHelper.
Reviewed-by: mgerdin, tschatzl

! src/share/vm/gc/g1/g1OopClosures.cpp
! src/share/vm/gc/g1/g1OopClosures.hpp
! src/share/vm/gc/g1/g1OopClosures.inline.hpp
! src/share/vm/gc/g1/g1ParScanThreadState.cpp
! src/share/vm/gc/g1/g1ParScanThreadState.hpp
! src/share/vm/gc/g1/g1ParScanThreadState.inline.hpp

Changeset: 09c316072f18
Author:    mdoerr
Date:      2015-10-16 10:20 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/09c316072f18

8139734: ppc: fix build after "8078556: Runtime: implement ranges..."
Reviewed-by: goetz

! src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp

Changeset: a014961e513b
Author:    kbarrett
Date:      2015-10-16 14:55 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a014961e513b

8139341: Hide ExtendedOopClosure::_ref_processor
Summary: Make ExtendedOopClosure::_ref_processor private.
Reviewed-by: mgerdin, sjohanss

! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/g1/concurrentMark.cpp
! src/share/vm/gc/g1/g1OopClosures.hpp
! src/share/vm/gc/serial/markSweep.hpp
! src/share/vm/gc/shared/genOopClosures.hpp
! src/share/vm/memory/iterator.hpp
! src/share/vm/oops/instanceRefKlass.inline.hpp

Changeset: e70a21e29520
Author:    david
Date:      2015-10-16 14:11 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e70a21e29520

8139277: Remove ScavengeWithObjectsInToSpace, ParallelOldGCSplitALot, ParallelOldGCSplitInterval, PSAdjustTenuredGenForMinorPause and PSAdjustYoungGenForMajorPause
Reviewed-by: tschatzl, sjohanss

! src/share/vm/gc/parallel/psAdaptiveSizePolicy.cpp
! src/share/vm/gc/parallel/psAdaptiveSizePolicy.hpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psParallelCompact.hpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: ec3193176165
Author:    ehelin
Date:      2015-10-19 15:21 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ec3193176165

8135078: Refactor InCSetState::is_in_cset_or_humongous
Reviewed-by: tschatzl, jwilhelm

! src/share/vm/gc/g1/g1InCSetState.hpp

Changeset: 9b74c5f1b10e
Author:    brutisso
Date:      2015-10-20 14:00 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9b74c5f1b10e

8139868: CMSScavengeBeforeRemark broken after JDK-8134953
Reviewed-by: sjohanss, jwilhelm

! src/share/vm/gc/shared/gcId.cpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
+ test/gc/cms/TestCMSScavengeBeforeRemark.java

Changeset: 29c399fbbf25
Author:    jprovino
Date:      2015-10-20 11:17 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/29c399fbbf25

Merge

! src/cpu/sparc/vm/globals_sparc.hpp
! src/cpu/x86/vm/globals_x86.hpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/parallel/psParallelCompact.cpp
! src/share/vm/gc/parallel/psScavenge.cpp
! src/share/vm/gc/serial/genMarkSweep.cpp
! src/share/vm/gc/shared/cardTableRS.cpp
! src/share/vm/gc/shared/genCollectedHeap.cpp
- src/share/vm/gc/shared/genRemSet.cpp
- src/share/vm/gc/shared/genRemSet.hpp
- src/share/vm/gc/shared/watermark.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/commandLineFlagConstraintList.cpp
! src/share/vm/runtime/commandLineFlagRangeList.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/exceptions.cpp
! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java

Changeset: 6bea4fdaae80
Author:    amurillo
Date:      2015-10-22 16:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6bea4fdaae80

Merge

- src/share/vm/gc/shared/genRemSet.cpp
- src/share/vm/gc/shared/genRemSet.hpp
- src/share/vm/gc/shared/watermark.hpp

Changeset: 20dff0211ded
Author:    mgerdin
Date:      2015-10-26 17:13 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/20dff0211ded

8140452: Internal Error memory/allocation.cpp:179
Summary: use const ref & and avoid copy ctor
Reviewed-by: coleenp

! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp

Changeset: 7fe46dc64bb3
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7fe46dc64bb3

Added tag jdk9-b89 for changeset 20dff0211ded

! .hgtags

Changeset: 3fd5c2ca4c20
Author:    lana
Date:      2015-10-30 10:28 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3fd5c2ca4c20

Added tag jdk9-b90 for changeset 7fe46dc64bb3

! .hgtags

Changeset: c83fdb22d5a4
Author:    mchung
Date:      2015-11-11 15:32 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c83fdb22d5a4

Merge

! .hgtags
! src/os/aix/vm/os_aix.cpp
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/dictionary.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jniCheck.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/jniHandles.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/services/management.cpp
! src/share/vm/utilities/ostream.cpp
! test/compiler/c2/5057225/Test5057225.java
! test/compiler/c2/6603011/Test.java
! test/compiler/c2/6800154/Test6800154.java
! test/compiler/c2/6805724/Test6805724.java
! test/compiler/codegen/6823354/Test6823354.java
! test/gc/arguments/TestG1HeapRegionSize.java
- test/runtime/BadObjectClass/Object.java
! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
! test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java
! test/testlibrary_tests/whitebox/vm_flags/IntxTest.java

Changeset: 70497711c2e4
Author:    mchung
Date:      2015-11-11 15:51 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/70497711c2e4

Merge

+ src/jdk.vm.ci/share/classes/module-info.java

Changeset: 7fd0a4aeffa5
Author:    mchung
Date:      2015-11-12 15:26 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7fd0a4aeffa5

Merge

! make/gensrc/Gensrc-jdk.vm.ci.gmk
! src/share/vm/runtime/frame.cpp

Changeset: 18b6c7bfb8a4
Author:    mchung
Date:      2015-11-12 20:35 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/18b6c7bfb8a4

jdk9-b91 fixup

! make/gensrc/Gensrc-jdk.vm.ci.gmk

Changeset: 2760de77e5c5
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2760de77e5c5

Added tag jdk9-b91 for changeset 3fd5c2ca4c20

! .hgtags

Changeset: f5112887ebd7
Author:    vlivanov
Date:      2015-09-06 10:13 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f5112887ebd7

8065151: Support IdealGraphVisualizer in optimized build
Reviewed-by: kvn

! src/share/vm/opto/c2_globals.hpp

Changeset: 420908d02f8d
Author:    erikj
Date:      2015-10-20 10:24 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/420908d02f8d

8139657: Incremental build of jdk.vm.ci-gensrc creates repeated entries in services file
Reviewed-by: twisti

! make/gensrc/Gensrc-jdk.vm.ci.gmk

Changeset: 9108fab781a4
Author:    roland
Date:      2015-10-16 16:53 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9108fab781a4

8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI
Summary: Mismatched stores on same slice possible with Unsafe.Put*Unaligned methods
Reviewed-by: kvn, thartmann

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
+ test/compiler/intrinsics/unsafe/TestUnsafeUnalignedMismatchedAccesses.java

Changeset: eb7736a32a0f
Author:    roland
Date:      2015-10-20 13:36 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/eb7736a32a0f

Merge


Changeset: a176d4737606
Author:    neliasso
Date:      2015-10-20 18:07 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a176d4737606

8137167: JEP165: Compiler Control: Implementation task
Summary: Compiler Control JEP
Reviewed-by: roland, twisti, zmajo, simonis

! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_Compiler.cpp
! src/share/vm/c1/c1_Compiler.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/compiler/compileTask.cpp
+ src/share/vm/compiler/compilerDirectives.cpp
+ src/share/vm/compiler/compilerDirectives.hpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/compiler/compilerOracle.hpp
+ src/share/vm/compiler/directivesParser.cpp
+ src/share/vm/compiler/directivesParser.hpp
! src/share/vm/compiler/methodMatcher.cpp
! src/share/vm/compiler/methodMatcher.hpp
! src/share/vm/jvmci/jvmciCompiler.cpp
! src/share/vm/jvmci/jvmciCompiler.hpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/opto/c2compiler.hpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/idealGraphPrinter.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp
! src/share/vm/shark/sharkCompiler.cpp
! src/share/vm/shark/sharkCompiler.hpp
+ src/share/vm/utilities/json.cpp
+ src/share/vm/utilities/json.hpp
+ test/compiler/compilercontrol/InlineMatcherTest.java
+ test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityBase.java
+ test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOff.java
+ test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java
+ test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityFlag.java
+ test/compiler/compilercontrol/control_off.txt
+ test/compiler/compilercontrol/control_on.txt
+ test/serviceability/dcmd/compiler/CompilerDirectivesDCMDTest.java
+ test/serviceability/dcmd/compiler/control1.txt
+ test/serviceability/dcmd/compiler/control2.txt

Changeset: 535c335eb11c
Author:    ppunegov
Date:      2015-10-20 21:09 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/535c335eb11c

8066153: JEP-JDK-8046155: Test task: cover existing
Summary: Tests for CompilerCommand and CompilerControl's directives
Reviewed-by: kvn

+ test/compiler/compilercontrol/commandfile/CompileOnlyTest.java
+ test/compiler/compilercontrol/commandfile/ExcludeTest.java
+ test/compiler/compilercontrol/commandfile/LogTest.java
+ test/compiler/compilercontrol/commandfile/PrintTest.java
+ test/compiler/compilercontrol/commands/CompileOnlyTest.java
+ test/compiler/compilercontrol/commands/ExcludeTest.java
+ test/compiler/compilercontrol/commands/LogTest.java
+ test/compiler/compilercontrol/commands/PrintTest.java
+ test/compiler/compilercontrol/directives/CompileOnlyTest.java
+ test/compiler/compilercontrol/directives/ExcludeTest.java
+ test/compiler/compilercontrol/directives/LogTest.java
+ test/compiler/compilercontrol/directives/PrintTest.java
+ test/compiler/compilercontrol/mixed/RandomCommandsTest.java
+ test/compiler/compilercontrol/mixed/RandomValidCommandsTest.java
+ test/compiler/compilercontrol/share/AbstractTestBase.java
+ test/compiler/compilercontrol/share/JSONFile.java
+ test/compiler/compilercontrol/share/MultiCommand.java
+ test/compiler/compilercontrol/share/SingleCommand.java
+ test/compiler/compilercontrol/share/actions/BaseAction.java
+ test/compiler/compilercontrol/share/actions/CompileAction.java
! test/compiler/compilercontrol/share/method/MethodGenerator.java
! test/compiler/compilercontrol/share/method/SignatureType.java
+ test/compiler/compilercontrol/share/processors/CommandProcessor.java
+ test/compiler/compilercontrol/share/processors/LogProcessor.java
+ test/compiler/compilercontrol/share/processors/PrintProcessor.java
+ test/compiler/compilercontrol/share/processors/QuietProcessor.java
+ test/compiler/compilercontrol/share/scenario/AbstractCommandBuilder.java
+ test/compiler/compilercontrol/share/scenario/Command.java
+ test/compiler/compilercontrol/share/scenario/CommandFileBuilder.java
+ test/compiler/compilercontrol/share/scenario/CommandGenerator.java
+ test/compiler/compilercontrol/share/scenario/CommandOptionsBuilder.java
+ test/compiler/compilercontrol/share/scenario/CompileCommand.java
+ test/compiler/compilercontrol/share/scenario/DirectiveBuilder.java
+ test/compiler/compilercontrol/share/scenario/DirectiveWriter.java
+ test/compiler/compilercontrol/share/scenario/Scenario.java

Changeset: 11c3bed1e41e
Author:    ppunegov
Date:      2015-10-20 21:12 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/11c3bed1e41e

8066166: JEP-JDK-8046155: Test task: dcmd tests
Summary: Tests for diagnostic command in CompilerControl
Reviewed-by: kvn

+ test/compiler/compilercontrol/jcmd/AddAndRemoveTest.java
+ test/compiler/compilercontrol/jcmd/AddCompileOnlyTest.java
+ test/compiler/compilercontrol/jcmd/AddExcludeTest.java
+ test/compiler/compilercontrol/jcmd/AddLogTest.java
+ test/compiler/compilercontrol/jcmd/AddPrintAssemblyTest.java
+ test/compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java
+ test/compiler/compilercontrol/jcmd/ClearDirectivesStackTest.java
! test/compiler/compilercontrol/share/scenario/CommandGenerator.java
+ test/compiler/compilercontrol/share/scenario/JcmdCommand.java
+ test/compiler/compilercontrol/share/scenario/JcmdStateBuilder.java
! test/compiler/compilercontrol/share/scenario/Scenario.java

Changeset: 1cd251540653
Author:    vlivanov
Date:      2015-10-20 19:22 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1cd251540653

8132168: Support IdealGraphVisualizer in optimized build
Reviewed-by: kvn

! src/share/vm/opto/c2_globals.hpp

Changeset: 03fa0a35a468
Author:    vlivanov
Date:      2015-10-20 22:03 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/03fa0a35a468

Merge

! src/share/vm/opto/c2_globals.hpp

Changeset: 111d1c4c90e7
Author:    goetz
Date:      2015-10-21 18:22 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/111d1c4c90e7

8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build"
Reviewed-by: vlivanov

! src/share/vm/compiler/compilerDirectives.hpp

Changeset: 713aa577bd38
Author:    neliasso
Date:      2015-10-21 19:31 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/713aa577bd38

8140240: Missing test files in CompilerControl tests
Summary: Add missing files
Reviewed-by: kvn, neliasso

+ test/compiler/compilercontrol/share/scenario/State.java
+ test/compiler/compilercontrol/share/scenario/StateBuilder.java
! test/testlibrary/jdk/test/lib/ProcessTools.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: a60bd3d34158
Author:    neliasso
Date:      2015-10-21 21:59 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a60bd3d34158

Merge


Changeset: d80d1084cfdc
Author:    dlong
Date:      2015-10-21 18:05 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d80d1084cfdc

8140267: assert(is_native_ptr || alias_type->adr_type() == TypeOopPtr::BOTTOM || alias_type->field() != __null || alias_type->element() != __null) failed: field, array element or unknown
Summary: back out 8136473
Reviewed-by: twisti

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
- test/compiler/intrinsics/unsafe/TestUnsafeUnalignedMismatchedAccesses.java

Changeset: ffae03d59aa9
Author:    dlong
Date:      2015-10-21 18:34 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ffae03d59aa9

Merge


Changeset: ea9eaad05466
Author:    enevill
Date:      2015-10-21 12:15 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ea9eaad05466

8140238: Zero fails to build from source
Summary: Zero fails to build after 8136421 and 8078554
Reviewed-by: kvn

! src/cpu/zero/vm/compiledIC_zero.cpp
! src/cpu/zero/vm/relocInfo_zero.cpp
! src/cpu/zero/vm/vm_version_zero.cpp

Changeset: a0c5acb7c322
Author:    mdoerr
Date:      2015-10-09 20:58 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a0c5acb7c322

8138890: C1: Ambiguous operator delete
Summary: xlC on AIX rejects to compile LIRGenerator and RangeCheckEliminator::Verification
Reviewed-by: simonis, goetz, twisti

! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_RangeCheckElimination.hpp

Changeset: 5dc1db0a5290
Author:    twisti
Date:      2015-10-21 21:49 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5dc1db0a5290

Merge


Changeset: cc7b816cca18
Author:    twisti
Date:      2015-10-22 19:03 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cc7b816cca18

Merge


Changeset: 4b46d2b42fcb
Author:    iveresov
Date:      2015-10-22 21:39 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4b46d2b42fcb

8139575: Update for x86 log in the math lib
Summary: Add new java.lang.Math() intrinsics from x86
Reviewed-by: kvn, iveresov
Contributed-by: vivek.r.deshpande at intel.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_LinearScan_x86.cpp
! src/cpu/x86/vm/interpreter_x86_32.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/macroAssembler_x86_libm.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/subnode.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: d9315ec5c471
Author:    twisti
Date:      2015-10-22 13:18 -1000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d9315ec5c471

8140091: remove VMStructs cast_uint64_t workaround for GCC 4.1.1 bug
Reviewed-by: erikj, kvn

! make/bsd/makefiles/gcc.make
! make/linux/makefiles/gcc.make
! make/solaris/makefiles/gcc.make
! src/share/vm/runtime/vmStructs.cpp

Changeset: e32667cd477c
Author:    twisti
Date:      2015-10-23 07:18 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e32667cd477c

Merge

! src/share/vm/runtime/vmStructs.cpp

Changeset: 5d13c9b094c4
Author:    neliasso
Date:      2015-10-26 10:36 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5d13c9b094c4

8139996: CompileCommand prints quoted ascii strings
Summary: Print symbols as utf8
Reviewed-by: kvn

! src/share/vm/compiler/methodMatcher.cpp
! src/share/vm/oops/symbol.cpp
! src/share/vm/oops/symbol.hpp

Changeset: ae64ff428e18
Author:    iveresov
Date:      2015-10-26 19:33 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ae64ff428e18

8139340: SuperWord enhancement to support vector conditional move (CMovVD) on Intel AVX cpu
Summary: Emit vector conditional moves
Reviewed-by: kvn
Contributed-by: jan.civlin at intel.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/x86.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/superword.hpp
! src/share/vm/opto/vectornode.cpp
! src/share/vm/opto/vectornode.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: e7b4c40ebb11
Author:    dlong
Date:      2015-10-27 01:45 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e7b4c40ebb11

Merge

! make/gensrc/Gensrc-jdk.vm.ci.gmk
! src/share/vm/c1/c1_Runtime1.cpp
- src/share/vm/gc/shared/genRemSet.cpp
- src/share/vm/gc/shared/genRemSet.hpp
- src/share/vm/gc/shared/watermark.hpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 0ecd612047de
Author:    enevill
Date:      2015-10-27 10:08 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0ecd612047de

8140582: aarch64: jvm fails to initialise after 8078556
Summary: jvm fails to initialise on aarch64 systems with pagesize > 4K
Reviewed-by: duke

! src/cpu/aarch64/vm/globals_aarch64.hpp

Changeset: 427a91c68b67
Author:    enevill
Date:      2015-10-27 18:05 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/427a91c68b67

8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs
Summary: Fix register usage on calling native synchronized methods
Reviewed-by: kvn, adinn

! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp

Changeset: 9c4989b6889a
Author:    zmajo
Date:      2015-10-28 15:15 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9c4989b6889a

8139907: compiler/intrinsics/montgomerymultiply/MontgomeryMultiplyTest.java fails with timeout
Summary: Change MontgomeryMultiplyTest.java test to execute only on platforms on which the tested intrinsics are available.
Reviewed-by: kvn, neliasso

! test/compiler/intrinsics/montgomerymultiply/MontgomeryMultiplyTest.java

Changeset: ea4fcd70985d
Author:    ppunegov
Date:      2015-10-28 16:00 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ea4fcd70985d

8140350: compiler control tests fail with compiled: true,  but should: false on required level: 1
Summary: Replace isMethodCompiled with isMethodCompilable with particular level
Reviewed-by: kvn

! test/compiler/compilercontrol/share/actions/CompileAction.java

Changeset: 48b73c88892f
Author:    ppunegov
Date:      2015-10-28 16:26 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/48b73c88892f

8140453: compiler control test failed with RuntimeException: CompileCommand: nonexistent missing
Summary: Replace incorrect check for validity of method pattern with full command check
Reviewed-by: kvn

! test/compiler/compilercontrol/share/processors/CommandProcessor.java
! test/compiler/compilercontrol/share/processors/QuietProcessor.java

Changeset: 4883b314d4b9
Author:    ppunegov
Date:      2015-10-28 16:38 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4883b314d4b9

8066158: JEP-JDK-8046155: Test task: directive parser
Summary: check directive file parser with correct and incorrect files
Reviewed-by: kvn

+ test/compiler/compilercontrol/parser/DirectiveParser.java
! test/testlibrary/jdk/test/lib/Utils.java

Changeset: 0b2937220009
Author:    iignatyev
Date:      2015-10-28 16:01 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0b2937220009

Merge


Changeset: 96bcdd3a6e79
Author:    neliasso
Date:      2015-10-28 15:44 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/96bcdd3a6e79

8140581: Excluding compile messages should only be printed with PrintCompilation
Summary: Use PrintCompilation flag instead
Reviewed-by: kvn

! src/share/vm/compiler/compileBroker.cpp

Changeset: 0fa6910c516d
Author:    neliasso
Date:      2015-10-23 10:57 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0fa6910c516d

8140343: SEGV in DirectivesStack::getMatchingDirective
Summary: Could not match JVMCI compiler
Reviewed-by: kvn

! src/share/vm/compiler/compilerDirectives.cpp

Changeset: 1d49bd532a6f
Author:    zmajo
Date:      2015-10-29 09:24 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1d49bd532a6f

8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly
Summary: Improve parsing of DisableIntrinsic flag.
Reviewed-by: kvn, shade, neliasso

! src/share/vm/compiler/compilerDirectives.cpp
! src/share/vm/compiler/compilerDirectives.hpp
! src/share/vm/compiler/directivesParser.cpp
! src/share/vm/compiler/directivesParser.hpp
+ test/compiler/intrinsics/IntrinsicDisabledTest.java

Changeset: b62347567e9b
Author:    ppunegov
Date:      2015-10-29 01:16 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b62347567e9b

8140668: Quarantine RandomValidCommandsTest
8140669: Quarantine ClearDirectivesFileStackTest
Summary: Quarantine two tests
Reviewed-by: iignatyev, neliasso, kvn

! test/compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java
! test/compiler/compilercontrol/mixed/RandomValidCommandsTest.java

Changeset: e18469511c58
Author:    iignatyev
Date:      2015-10-29 10:56 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e18469511c58

Merge


Changeset: 0835ef4e6232
Author:    shade
Date:      2015-10-29 14:08 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0835ef4e6232

8140483: Atomic*FieldUpdaters final fields should be trusted
Summary: Add exceptions for A*FU subclasses that do the actual work.
Reviewed-by: jrose, vlivanov

! src/share/vm/ci/ciField.cpp
! src/share/vm/classfile/vmSymbols.hpp

Changeset: 7fb261378480
Author:    shade
Date:      2015-10-29 13:23 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7fb261378480

Merge


Changeset: e3690e58d28e
Author:    iveresov
Date:      2015-10-29 09:59 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3690e58d28e

8140604: Internal Error runtime/stubRoutines.hpp:392 assert(_intrinsic_log != 0L) failed: must be defined
Summary: Fix the faulty assert, remove remaining _intrinsic_log references
Reviewed-by: roland

! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp

Changeset: b03c5e9f24ba
Author:    ppunegov
Date:      2015-10-29 21:31 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b03c5e9f24ba

8140776: CompilerControl: Remove UTF-16 from the tests
Summary: remove UTF-16 from the generation until the failure reason isn't found
Reviewed-by: iignatyev

! test/compiler/compilercontrol/share/method/MethodGenerator.java

Changeset: 8c85cc5c9fb8
Author:    iignatyev
Date:      2015-10-29 19:30 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8c85cc5c9fb8

Merge


Changeset: 79b56d21b736
Author:    amurillo
Date:      2015-10-30 12:03 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/79b56d21b736

Merge


Changeset: 53cb98d68a1a
Author:    lana
Date:      2015-11-05 13:41 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/53cb98d68a1a

Merge


Changeset: 8fd684b8c649
Author:    lana
Date:      2015-11-12 10:39 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8fd684b8c649

Added tag jdk9-b92 for changeset 53cb98d68a1a

! .hgtags

Changeset: bbc92f9082c0
Author:    mchung
Date:      2015-11-13 19:20 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bbc92f9082c0

Merge

! .hgtags
! make/gensrc/Gensrc-jdk.vm.ci.gmk
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/jvmci/jvmciEnv.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/vmStructs.cpp
- test/runtime/BadObjectClass/Object.java


From mandy.chung at oracle.com  Sat Nov 14 04:22:58 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 14 Nov 2015 04:22:58 +0000
Subject: hg: jigsaw/jake/jaxp: 18 new changesets
Message-ID: <201511140422.tAE4MwnQ029869@aojmv0008.oracle.com>

Changeset: 4700fd67e942
Author:    lana
Date:      2015-10-19 00:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4700fd67e942

Added tag jdk9-b87 for changeset eb435c878c2c

! .hgtags

Changeset: 27b625ce80f4
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/27b625ce80f4

Added tag jdk9-b88 for changeset 4700fd67e942

! .hgtags

Changeset: 00fa5efc9ace
Author:    joehw
Date:      2015-04-18 00:17 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/00fa5efc9ace

8068842: Better JAXP data handling
Reviewed-by: dfuchs, lancea, hawtin

! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltSets.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/DOM.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyTemplates.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeSet.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValueTemplate.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CastExpr.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Choose.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ForEach.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Key.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Mode.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Stylesheet.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SymbolTable.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SyntaxTreeNode.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Template.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TestSeq.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnsupportedElement.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslAttribute.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslElement.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodGenerator.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MultiHashtable.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/AdaptiveResultTreeImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMAdapter.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMWSFilter.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/KeyIndex.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MultiDOM.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SAXImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SimpleResultTreeImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java
- src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXEvent2SAX.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXStream2SAX.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/CoreDocumentImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredDocumentImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentTypeImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/LCount.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/NodeImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/ParentNode.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLErrorReporter.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammarBucket.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DTDDVFactory.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/DTDDVFactoryImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11DTDDVFactoryImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/ParserForXMLSchema.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/Token.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SubstitutionGroupHandler.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSGrammarBucket.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserFactoryImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLGrammarPreparser.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/AugmentationsImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/DOMErrorHandlerWrapper.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/DOMUtil.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java
+ src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/PrimeNumberSequenceGenerator.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/SymbolHash.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/SymbolTable.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/XMLAttributesImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerHandler.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/CustomStringPool.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/Catalog.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogEntry.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/BootstrapResolver.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/ElementState.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/Encodings.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLSerializer.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLdtd.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/AttributesImplSerializer.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/EmptySerializer.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java
- src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Utils.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOM3TreeWalker.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/Utils.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/DOMHelper.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/ElemDesc.java
- src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java
! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Keywords.java
! src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java
! src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java
! src/java.xml/share/classes/org/xml/sax/helpers/NamespaceSupport.java

Changeset: 3345330dd03a
Author:    joehw
Date:      2015-05-12 10:02 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/3345330dd03a

8079323: Serialization compatibility for Templates: need to exclude Hashtable from serialization
Reviewed-by: dfuchs, lancea, hawtin

! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java
+ test/javax/xml/jaxp/unittest/transform/TemplatesTest.java

Changeset: e9fb9655fd36
Author:    joehw
Date:      2015-05-26 10:37 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e9fb9655fd36

8078427: More supportive home environment
Reviewed-by: dfuchs, lancea, skoivu

! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/Catalog.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/TreeWalker.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOM3TreeWalker.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/TreeWalker.java

Changeset: 5f2ff10c2974
Author:    joehw
Date:      2015-07-07 15:56 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/5f2ff10c2974

8086733: Improve namespace handling
Reviewed-by: dfuchs, lancea, ahgross

! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java
! 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/XMLEntityManager.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLVersionDetector.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java
! src/java.xml/share/classes/com/sun/xml/internal/stream/Entity.java

Changeset: 686f3a3e49ac
Author:    joehw
Date:      2015-07-07 16:57 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/686f3a3e49ac

8130078: Document better processing
Reviewed-by: dfuchs, lancea, ahgross

! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.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/xni/parser/XMLDTDScanner.java

Changeset: 198a7fd9ec1f
Author:    lana
Date:      2015-10-21 18:38 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/198a7fd9ec1f

Merge

- src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java
- src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Utils.java
- src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java

Changeset: 5021da4c9496
Author:    lana
Date:      2015-10-22 11:14 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/5021da4c9496

Merge

- src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java
- src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Utils.java
- src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java

Changeset: 35f68242b624
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/35f68242b624

Added tag jdk9-b89 for changeset 5021da4c9496

! .hgtags

Changeset: ffaff3d0ad0e
Author:    lana
Date:      2015-10-30 10:28 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ffaff3d0ad0e

Added tag jdk9-b90 for changeset 35f68242b624

! .hgtags

Changeset: 4c198fa1ddc5
Author:    mchung
Date:      2015-11-12 11:30 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4c198fa1ddc5

Merge

! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java

Changeset: c44ed58b7928
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/c44ed58b7928

Added tag jdk9-b91 for changeset ffaff3d0ad0e

! .hgtags

Changeset: d6dcb5df3d6d
Author:    joehw
Date:      2015-10-29 21:53 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/d6dcb5df3d6d

8081248: Implement JEP 268: XML Catalog API
Reviewed-by: lancea, dfuchs

+ src/java.xml/share/classes/javax/xml/catalog/AltCatalog.java
+ src/java.xml/share/classes/javax/xml/catalog/BaseEntry.java
+ src/java.xml/share/classes/javax/xml/catalog/Catalog.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogEntry.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogException.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java
+ 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/CatalogMessages.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogMessages.properties
+ src/java.xml/share/classes/javax/xml/catalog/CatalogReader.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogResolver.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogResolverImpl.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolver.java
+ src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolverImpl.java
+ src/java.xml/share/classes/javax/xml/catalog/DelegatePublic.java
+ src/java.xml/share/classes/javax/xml/catalog/DelegateSystem.java
+ src/java.xml/share/classes/javax/xml/catalog/DelegateUri.java
+ src/java.xml/share/classes/javax/xml/catalog/GroupEntry.java
+ src/java.xml/share/classes/javax/xml/catalog/NextCatalog.java
+ src/java.xml/share/classes/javax/xml/catalog/Normalizer.java
+ src/java.xml/share/classes/javax/xml/catalog/PublicEntry.java
+ src/java.xml/share/classes/javax/xml/catalog/RewriteSystem.java
+ src/java.xml/share/classes/javax/xml/catalog/RewriteUri.java
+ src/java.xml/share/classes/javax/xml/catalog/SystemEntry.java
+ src/java.xml/share/classes/javax/xml/catalog/SystemSuffix.java
+ src/java.xml/share/classes/javax/xml/catalog/UriEntry.java
+ src/java.xml/share/classes/javax/xml/catalog/UriSuffix.java
+ src/java.xml/share/classes/javax/xml/catalog/Util.java
+ src/java.xml/share/classes/javax/xml/catalog/package.html
+ src/java.xml/share/classes/jdk/xml/internal/SecuritySupport.java
! test/javax/xml/jaxp/unittest/TEST.properties
+ test/javax/xml/jaxp/unittest/catalog/CatalogTest.java
+ test/javax/xml/jaxp/unittest/catalog/catalog.xml
+ test/javax/xml/jaxp/unittest/catalog/catalog_invalid.xml
+ test/javax/xml/jaxp/unittest/catalog/delegatepublic.xml
+ test/javax/xml/jaxp/unittest/catalog/delegatesystem.xml
+ test/javax/xml/jaxp/unittest/catalog/files/delegatecatalog.xml
+ test/javax/xml/jaxp/unittest/catalog/files/delegatepublic.dtd
+ test/javax/xml/jaxp/unittest/catalog/files/delegatesystem.dtd
+ test/javax/xml/jaxp/unittest/catalog/files/rewritesystem.dtd
+ test/javax/xml/jaxp/unittest/catalog/files/systemsuffix.dtd
+ test/javax/xml/jaxp/unittest/catalog/public.dtd
+ test/javax/xml/jaxp/unittest/catalog/public.xml
+ test/javax/xml/jaxp/unittest/catalog/rewritesystem.xml
+ test/javax/xml/jaxp/unittest/catalog/rewritesystem1.xml
+ test/javax/xml/jaxp/unittest/catalog/system.dtd
+ test/javax/xml/jaxp/unittest/catalog/system.xml
+ test/javax/xml/jaxp/unittest/catalog/systemsuffix.xml

Changeset: 395cd2b14c1d
Author:    joehw
Date:      2015-10-29 22:12 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/395cd2b14c1d

8077931: Develop tests for XML Catalog API
Reviewed-by: joehw, lancea
Contributed-by: sha.jiang at oracle.com

+ test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java
+ test/javax/xml/jaxp/functional/catalog/DefaultFeaturesTest.java
+ test/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java
+ test/javax/xml/jaxp/functional/catalog/DelegatePublicTest.java
+ test/javax/xml/jaxp/functional/catalog/DelegateSystemTest.java
+ test/javax/xml/jaxp/functional/catalog/DelegateUriTest.java
+ test/javax/xml/jaxp/functional/catalog/GroupTest.java
+ test/javax/xml/jaxp/functional/catalog/LoadCatalogTest.java
+ test/javax/xml/jaxp/functional/catalog/NextCatalogTest.java
+ test/javax/xml/jaxp/functional/catalog/NormalizationTest.java
+ test/javax/xml/jaxp/functional/catalog/PreferFeatureTest.java
+ test/javax/xml/jaxp/functional/catalog/PreferTest.java
+ test/javax/xml/jaxp/functional/catalog/PublicFamilyTest.java
+ test/javax/xml/jaxp/functional/catalog/PublicTest.java
+ test/javax/xml/jaxp/functional/catalog/ResolveFeatureTest.java
+ test/javax/xml/jaxp/functional/catalog/RewriteSystemTest.java
+ test/javax/xml/jaxp/functional/catalog/RewriteUriTest.java
+ test/javax/xml/jaxp/functional/catalog/SpecifyCatalogTest.java
+ test/javax/xml/jaxp/functional/catalog/SystemFamilyTest.java
+ test/javax/xml/jaxp/functional/catalog/SystemSuffixTest.java
+ test/javax/xml/jaxp/functional/catalog/SystemTest.java
+ test/javax/xml/jaxp/functional/catalog/UriFamilyTest.java
+ test/javax/xml/jaxp/functional/catalog/UriSuffixTest.java
+ test/javax/xml/jaxp/functional/catalog/UriTest.java
+ test/javax/xml/jaxp/functional/catalog/UrnUnwrappingTest.java
+ test/javax/xml/jaxp/functional/catalog/ValidateCatalogTest.java
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/catalogReferCircle-itself.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/catalogReferCircle-left.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/catalogReferCircle-right.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/deferFeature.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegatePublic-alice.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegatePublic-bob.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegatePublic-carl.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegatePublic.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateSystem-alice.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateSystem-bob.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateSystem-carl.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateSystem.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateUri-alice.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateUri-bob.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateUri-carl.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateUri.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/group.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/loadCatalogFiles.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-left.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-leftAlice.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-leftBob.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-leftCarl.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-right.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-rightAlice.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-rightBob.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/normalization.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/prefer.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/preferFeature.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/public.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/publicFamily.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/rewriteSystem.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/rewriteUri.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/specifyCatalog-api.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/specifyCatalog-feature.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/specifyCatalog-sysProps.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/system.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/systemFamily.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/systemSuffix.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/uri.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/uriFamily.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/uriSuffix.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/urnUnwrapping.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/validateCatalog-malformed.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/validateCatalog-noNamingSpace.xml
+ test/javax/xml/jaxp/functional/catalog/catalogFiles/validateCatalog-wrongRoot.xml
+ test/javax/xml/jaxp/isolatedjdk/IsolatedJDK.sh
+ test/javax/xml/jaxp/isolatedjdk/TEST.properties
+ test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.java
+ test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh
+ test/javax/xml/jaxp/isolatedjdk/catalog/catalogFiles/properties.xml
+ test/javax/xml/jaxp/libs/catalog/CatalogTestUtils.java
+ test/javax/xml/jaxp/libs/catalog/ResolutionChecker.java

Changeset: fcabfb3c38ac
Author:    lana
Date:      2015-11-05 13:42 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/fcabfb3c38ac

Merge


Changeset: f665f69fa8e3
Author:    lana
Date:      2015-11-12 10:39 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f665f69fa8e3

Added tag jdk9-b92 for changeset fcabfb3c38ac

! .hgtags

Changeset: 91fb735c7175
Author:    mchung
Date:      2015-11-13 19:20 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/91fb735c7175

Merge



From mandy.chung at oracle.com  Sat Nov 14 04:22:53 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 14 Nov 2015 04:22:53 +0000
Subject: hg: jigsaw/jake/jdk: 161 new changesets
Message-ID: <201511140422.tAE4MxRA029872@aojmv0008.oracle.com>

Changeset: 0198481aa9bd
Author:    lana
Date:      2015-10-19 00:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0198481aa9bd

Added tag jdk9-b87 for changeset 110fc90bdfa0

! .hgtags

Changeset: e860e54043fd
Author:    aefimov
Date:      2015-10-10 12:52 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e860e54043fd

8139107: DateTimeFormatter with Locale.UK throw a NullPointerException when parsing zone
Reviewed-by: naoto

! src/jdk.localedata/share/classes/sun/util/resources/en/GB/TimeZoneNames_en_GB.java
! src/jdk.localedata/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java
+ test/sun/util/resources/TimeZone/Bug8139107.java

Changeset: 3bd60f298de4
Author:    chegar
Date:      2015-10-10 17:27 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3bd60f298de4

8139307: Remove sun.misc.ConditionLock and Lock
Reviewed-by: alanb, lancea, martin, mchung, shade, smarks

- src/java.base/share/classes/sun/misc/ConditionLock.java
- src/java.base/share/classes/sun/misc/Lock.java

Changeset: 7fea29aaa921
Author:    chegar
Date:      2015-10-10 17:30 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7fea29aaa921

8139179: URLStreamHandler* should link to URL ctor that specifies how factories/providers are located
Reviewed-by: alanb

! src/java.base/share/classes/java/net/URLStreamHandlerFactory.java
! src/java.base/share/classes/java/net/spi/URLStreamHandlerProvider.java

Changeset: de8723d4d615
Author:    amlu
Date:      2015-10-12 17:07 +0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/de8723d4d615

8139407: Mark java/rmi/registry/readTest/readTest.sh as intermittently failing
Reviewed-by: chegar

! test/java/rmi/registry/readTest/readTest.sh

Changeset: d1aa33d3720c
Author:    dfuchs
Date:      2015-10-12 20:13 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d1aa33d3720c

8033661: readConfiguration does not cleanly reinitialize the logging system
Summary: two new updateConfiguration methods have been added to LogManager: call updateConfiguration to update a configuration *after* the LogManager is initialized.
Reviewed-by: mchung

! src/java.logging/share/classes/java/util/logging/LogManager.java
+ test/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java
+ test/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexUpdate.java
+ test/java/util/logging/LogManager/Configuration/updateConfiguration/SimpleUpdateConfigWithInputStreamTest.java
+ test/java/util/logging/LogManager/Configuration/updateConfiguration/SimpleUpdateConfigurationTest.java
+ test/java/util/logging/LogManager/Configuration/updateConfiguration/UpdateConfigurationTest.java

Changeset: 640d543aea86
Author:    chegar
Date:      2015-10-12 19:14 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/640d543aea86

8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate
Reviewed-by: alanb, jlaskey

! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java

Changeset: fed8b8b53b4b
Author:    plevart
Date:      2015-10-14 00:08 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fed8b8b53b4b

8136893: Improve early java.lang.invoke infrastructure initialization
Reviewed-by: mhaupt, psandoz, redestad, vlivanov

! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/MemberName.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java
! src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java

Changeset: 96524d5330db
Author:    dl
Date:      2015-10-13 16:04 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/96524d5330db

8134851: Integrate CompletableFuture with API enhancements
8039378: CompletableFuture: Avoid StackOverflowError for long linear chains
Reviewed-by: martin, psandoz, chegar

! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java
! src/java.base/share/classes/java/util/concurrent/CompletionStage.java
! test/java/util/concurrent/CompletableFuture/Basic.java
! test/java/util/concurrent/CompletableFuture/ThenComposeAsyncTest.java
! test/java/util/concurrent/CompletableFuture/ThenComposeExceptionTest.java

Changeset: a0c71499805e
Author:    dl
Date:      2015-10-13 16:15 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0c71499805e

8134852: Integrate fork/join with API enhancements
Reviewed-by: martin, psandoz, chegar

! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java
! test/java/util/concurrent/forkjoin/Integrate.java

Changeset: adec55c103f6
Author:    dl
Date:      2015-10-13 16:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/adec55c103f6

8134850: Integrate the Flow API
Reviewed-by: martin, psandoz, chegar

+ src/java.base/share/classes/java/util/concurrent/Flow.java
+ src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java

Changeset: 02bb920a3b12
Author:    dl
Date:      2015-10-13 16:35 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/02bb920a3b12

8134855: Bulk integration of java.util.concurrent.locks classes
8051848: ReentrantReadWriteLock.ReadLock fails on unlock by different thread
8049843: Lack of save / restore interrupt mechanism undermines the StampedLock
Reviewed-by: martin, psandoz, chegar

! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/Condition.java
! src/java.base/share/classes/java/util/concurrent/locks/Lock.java
! src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java
! src/java.base/share/classes/java/util/concurrent/locks/ReadWriteLock.java
! src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java
! src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
! src/java.base/share/classes/java/util/concurrent/locks/StampedLock.java
+ test/java/util/concurrent/locks/Lock/CheckedLockLoops.java
+ test/java/util/concurrent/locks/Lock/LoopHelpers.java
+ test/java/util/concurrent/locks/Lock/Mutex.java
! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java
+ test/java/util/concurrent/locks/LockSupport/ParkLoops.java
! test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java
! test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java
! test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java
! test/java/util/concurrent/locks/ReentrantReadWriteLock/RWMap.java
! test/java/util/concurrent/locks/StampedLock/Basic.java

Changeset: 6dd59c01f011
Author:    dl
Date:      2015-10-13 16:45 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6dd59c01f011

8134853: Bulk integration of java.util.concurrent classes
8080939: ForkJoinPool and Phaser deadlock
8044616: Clients of Unsafe.compareAndSwapLong need to beware of using direct stores to the same field
8071638: [JAVADOC] Buggy example in javadoc for afterExecute to access a submitted job's Throwable
8043743: Data missed in java.util.concurrent.LinkedTransferQueue
8054446: Repeated offer and remove on ConcurrentLinkedQueue lead to an OutOfMemoryError
8031374: TEST_BUG: java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java fails Intermittently
8034208: Cleanup to test/java/util/concurrent/BlockingQueue/Interrupt.java
8035661: Test fix java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java from jsr166 CVS
8062841: ConcurrentHashMap.computeIfAbsent stuck in an endless loop
8073208: javadoc typo in java.util.concurrent.Executor
8073704: FutureTask.isDone returns true when task has not yet completed
8037093: java/util/concurrent/locks/Lock/TimedAcquireLeak.java fails intermittently
8022642: ScheduledThreadPoolExecutor with zero corePoolSize create endlessly threads
8065320: Busy loop in ThreadPoolExecutor.getTask for ScheduledThreadPoolExecutor
8129861: High processor load for ScheduledThreadPoolExecutor with 0 core threads
8051859: ScheduledExecutorService.scheduleWithFixedDelay fails with max delay
7146994: example afterExecute for ScheduledThreadPoolExecutor hangs
Reviewed-by: martin, psandoz, chegar

! src/java.base/share/classes/java/util/AbstractQueue.java
! src/java.base/share/classes/java/util/ArrayDeque.java
! src/java.base/share/classes/java/util/ArrayPrefixHelpers.java
! src/java.base/share/classes/java/util/Deque.java
! src/java.base/share/classes/java/util/NavigableMap.java
! src/java.base/share/classes/java/util/NavigableSet.java
! src/java.base/share/classes/java/util/PriorityQueue.java
! src/java.base/share/classes/java/util/Queue.java
! src/java.base/share/classes/java/util/SplittableRandom.java
! src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
! src/java.base/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/BlockingDeque.java
! src/java.base/share/classes/java/util/concurrent/BlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/java.base/share/classes/java/util/concurrent/CountDownLatch.java
! src/java.base/share/classes/java/util/concurrent/CountedCompleter.java
! src/java.base/share/classes/java/util/concurrent/CyclicBarrier.java
! src/java.base/share/classes/java/util/concurrent/DelayQueue.java
! src/java.base/share/classes/java/util/concurrent/Exchanger.java
! src/java.base/share/classes/java/util/concurrent/Executor.java
! src/java.base/share/classes/java/util/concurrent/ExecutorCompletionService.java
! src/java.base/share/classes/java/util/concurrent/ExecutorService.java
! src/java.base/share/classes/java/util/concurrent/Executors.java
! src/java.base/share/classes/java/util/concurrent/Future.java
! src/java.base/share/classes/java/util/concurrent/FutureTask.java
+ src/java.base/share/classes/java/util/concurrent/Helpers.java
! src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/java.base/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/java.base/share/classes/java/util/concurrent/Phaser.java
! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/RecursiveAction.java
! src/java.base/share/classes/java/util/concurrent/RecursiveTask.java
! src/java.base/share/classes/java/util/concurrent/ScheduledExecutorService.java
! src/java.base/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
! src/java.base/share/classes/java/util/concurrent/Semaphore.java
! src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java
! src/java.base/share/classes/java/util/concurrent/ThreadFactory.java
! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java
! src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java
! src/java.base/share/classes/java/util/concurrent/TimeUnit.java
! src/java.base/share/classes/java/util/concurrent/TransferQueue.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
! src/java.base/share/classes/java/util/concurrent/package-info.java
! test/java/util/AbstractList/CheckForComodification.java
! test/java/util/AbstractList/FailFastIterator.java
! test/java/util/Collection/BiggernYours.java
! test/java/util/Collection/MOAT.java
! test/java/util/Collection/testlibrary/CollectionAsserts.java
! test/java/util/Collections/BigBinarySearch.java
! test/java/util/Collections/BinarySearchNullComparator.java
! test/java/util/Collections/CheckedListBash.java
! test/java/util/Collections/CheckedMapBash.java
! test/java/util/Collections/CheckedSetBash.java
! test/java/util/Collections/EmptyCollectionSerialization.java
! test/java/util/Collections/EmptyIterator.java
! test/java/util/Collections/EmptyNavigableMap.java
! test/java/util/Collections/EmptyNavigableSet.java
! test/java/util/Collections/RacingCollections.java
! test/java/util/Collections/ReverseOrder.java
! test/java/util/Collections/RotateEmpty.java
! test/java/util/Collections/T6433170.java
! test/java/util/Collections/WrappedNull.java
! test/java/util/Hashtable/IllegalLoadFactor.java
! test/java/util/Hashtable/ReadObject.java
! test/java/util/IdentityHashMap/ToString.java
! test/java/util/LinkedHashMap/Basic.java
! test/java/util/LinkedHashMap/Cache.java
! test/java/util/LinkedHashSet/Basic.java
! test/java/util/LinkedList/Clone.java
! test/java/util/LinkedList/ComodifiedRemove.java
! test/java/util/List/ListDefaults.java
! test/java/util/Map/Defaults.java
! test/java/util/Map/Get.java
! test/java/util/NavigableMap/LockStep.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java
! test/java/util/Spliterator/SpliteratorLateBindingFailFastTest.java
! test/java/util/TimSort/Sorter.java
! test/java/util/TreeMap/ContainsValue.java
! test/java/util/TreeMap/HeadTailTypeError.java
! test/java/util/TreeMap/SubMap.java
! test/java/util/Vector/ComodifiedRemoveAllElements.java
! test/java/util/Vector/IllegalConstructorArgs.java
! test/java/util/Vector/LastIndexOf.java
! test/java/util/Vector/SyncLastIndexOf.java
! test/java/util/WeakHashMap/GCDuringIteration.java
+ test/java/util/concurrent/ArrayBlockingQueue/IteratorConsistency.java
+ test/java/util/concurrent/BlockingQueue/DrainToFails.java
! test/java/util/concurrent/BlockingQueue/Interrupt.java
! test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java
! test/java/util/concurrent/ConcurrentHashMap/ConcurrentContainsKeyTest.java
! test/java/util/concurrent/ConcurrentHashMap/MapCheck.java
! test/java/util/concurrent/ConcurrentHashMap/MapLoops.java
+ test/java/util/concurrent/ConcurrentLinkedQueue/RemoveLeak.java
! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java
! test/java/util/concurrent/ConcurrentQueues/GCRetention.java
! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java
! test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java
! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java
! test/java/util/concurrent/CopyOnWriteArrayList/COWSubList.java
! test/java/util/concurrent/CountDownLatch/Basic.java
! test/java/util/concurrent/Exchanger/ExchangeLoops.java
! test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java
! test/java/util/concurrent/Executors/AutoShutdown.java
+ test/java/util/concurrent/FutureTask/DoneMeansDone.java
! test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java
! test/java/util/concurrent/FutureTask/ExplicitSet.java
! test/java/util/concurrent/FutureTask/NegativeTimeout.java
! test/java/util/concurrent/Phaser/Basic.java
! test/java/util/concurrent/ScheduledThreadPoolExecutor/DelayOverflow.java
+ test/java/util/concurrent/ScheduledThreadPoolExecutor/GCRetention.java
+ test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCoreThreads.java
! test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java
! test/java/util/concurrent/ThreadPoolExecutor/Custom.java
+ test/java/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java
+ test/java/util/concurrent/ThreadPoolExecutor/ThreadRestarts.java

Changeset: 7dc9726cfa82
Author:    darcy
Date:      2015-10-14 16:17 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7dc9726cfa82

8136799: Port fdlibm cbrt to Java
Reviewed-by: bpb

! make/mapfiles/libjava/mapfile-vers
! src/java.base/share/classes/java/lang/FdLibm.java
! src/java.base/share/classes/java/lang/StrictMath.java
- src/java.base/share/native/libfdlibm/s_cbrt.c
! src/java.base/share/native/libjava/StrictMath.c
! test/java/lang/Math/CubeRootTests.java
! test/java/lang/Math/HypotTests.java
! test/java/lang/Math/IeeeRecommendedTests.java
! test/java/lang/Math/Log1pTests.java
! test/java/lang/StrictMath/CubeRootTests.java
! test/java/lang/StrictMath/FdlibmTranslit.java
! test/java/lang/StrictMath/HypotTests.java

Changeset: d97306dd54cd
Author:    coffeys
Date:      2015-10-15 09:33 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d97306dd54cd

6907252: ZipFileInputStream Not Thread-Safe
Reviewed-by: sherman

! src/java.base/share/classes/java/util/zip/ZStreamRef.java
! src/java.base/share/classes/java/util/zip/ZipFile.java
! src/java.base/share/native/libzip/zip_util.c
+ test/java/util/zip/ZipFile/ZipEntryFreeTest.java

Changeset: 63ddd8dea0ff
Author:    igerasim
Date:      2015-10-15 13:56 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/63ddd8dea0ff

8138938: Clarify javadoc for java.util.Collections.copy()
Reviewed-by: smarks

! src/java.base/share/classes/java/util/Collections.java

Changeset: 91fc3c3826e6
Author:    coffeys
Date:      2015-10-15 14:41 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/91fc3c3826e6

8038502: Deflater.needsInput() should use synchronization
Reviewed-by: chegar

! src/java.base/share/classes/java/util/zip/Deflater.java

Changeset: 34d73930289e
Author:    lana
Date:      2015-10-15 16:51 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/34d73930289e

Merge

- src/java.base/share/classes/sun/misc/ConditionLock.java
- src/java.base/share/classes/sun/misc/Lock.java
- src/java.base/share/native/libfdlibm/s_cbrt.c

Changeset: 0440acded788
Author:    aefimov
Date:      2015-10-16 19:05 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0440acded788

8073519: schemagen does not report errors while generating xsd files
Reviewed-by: dfuchs

+ test/javax/xml/bind/jxc/8073519/InputWithError.java
+ test/javax/xml/bind/jxc/8073519/SchemagenErrorReporting.java

Changeset: 6e50b992bef4
Author:    lana
Date:      2015-10-21 15:16 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6e50b992bef4

Merge

- src/java.base/share/classes/sun/misc/ConditionLock.java
- src/java.base/share/classes/sun/misc/Lock.java
- src/java.base/share/native/libfdlibm/s_cbrt.c

Changeset: 4a00f31b3995
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4a00f31b3995

Added tag jdk9-b88 for changeset 6e50b992bef4

! .hgtags

Changeset: 2a83d5647e07
Author:    redestad
Date:      2015-10-18 01:43 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2a83d5647e07

8139706: JarFile.getBytes could use InputStream.readNBytes
Reviewed-by: sherman, chegar, alanb

! src/java.base/share/classes/java/util/jar/JarFile.java

Changeset: 9c12c03654a4
Author:    xuelei
Date:      2015-10-19 08:19 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9c12c03654a4

8077806: mismatch comment and code in CipherSuite.java
Reviewed-by: xuelei
Contributed-by: Time Du <tiantian.du at oracle.com>

! src/java.base/share/classes/sun/security/ssl/CipherSuite.java

Changeset: fb7d69e4c624
Author:    jlahoda
Date:      2015-10-19 19:14 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fb7d69e4c624

8134254: JShell API/tool: REPL for Java into JDK9
Summary: Adding makefile for jshell tool launcher.
Reviewed-by: alanb, erikj, sundar
Contributed-by: robert.field at oracle.com, jan.lahoda at oracle.com

+ make/launcher/Launcher-jdk.jshell.gmk

Changeset: 423df075cf72
Author:    psandoz
Date:      2015-10-19 11:28 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/423df075cf72

8080418: Add Optional.or()
Reviewed-by: chegar, forax, scolebourne

! src/java.base/share/classes/java/util/Optional.java
! src/java.base/share/classes/java/util/OptionalDouble.java
! src/java.base/share/classes/java/util/OptionalInt.java
! src/java.base/share/classes/java/util/OptionalLong.java
! test/java/util/Optional/Basic.java

Changeset: 9d2d39daa496
Author:    darcy
Date:      2015-10-19 13:48 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9d2d39daa496

8139925: Problem list LFMultiThreadCachingTest.java on windows
Reviewed-by: rriggs, chegar

! test/ProblemList.txt

Changeset: a4bb084549a1
Author:    ascarpino
Date:      2015-10-19 17:26 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a4bb084549a1

8139860: Add ucrypto/TestRSA.java to ProblemList: Message is larger than modulus
Reviewed-by: xuelei

! test/ProblemList.txt

Changeset: 5f032cc89bfd
Author:    ascarpino
Date:      2015-10-19 17:35 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5f032cc89bfd

8133151: Preferred provider configuration for JCE
Reviewed-by: valeriep

! make/gendata/Gendata-java.base.gmk
! make/src/classes/build/tools/makejavasecurity/MakeJavaSecurity.java
! src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java
! src/java.base/share/classes/java/security/AlgorithmParameters.java
! src/java.base/share/classes/java/security/KeyFactory.java
! src/java.base/share/classes/java/security/KeyPairGenerator.java
! src/java.base/share/classes/java/security/KeyStore.java
! src/java.base/share/classes/java/security/MessageDigest.java
! src/java.base/share/classes/java/security/Policy.java
! src/java.base/share/classes/java/security/SecureRandom.java
! src/java.base/share/classes/java/security/Signature.java
! src/java.base/share/classes/java/security/cert/CertPathBuilder.java
! src/java.base/share/classes/java/security/cert/CertPathValidator.java
! src/java.base/share/classes/java/security/cert/CertStore.java
! src/java.base/share/classes/java/security/cert/CertificateFactory.java
! src/java.base/share/classes/javax/crypto/Cipher.java
! src/java.base/share/classes/javax/crypto/ExemptionMechanism.java
! src/java.base/share/classes/javax/crypto/KeyAgreement.java
! src/java.base/share/classes/javax/crypto/KeyGenerator.java
! src/java.base/share/classes/javax/crypto/Mac.java
! src/java.base/share/classes/javax/crypto/SecretKeyFactory.java
! src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java
! src/java.base/share/classes/javax/net/ssl/SSLContext.java
! src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java
! src/java.base/share/classes/javax/security/auth/login/Configuration.java
! src/java.base/share/classes/sun/security/jca/ProviderList.java
! src/java.base/share/conf/security/java.security
! src/java.security.sasl/share/classes/javax/security/sasl/Sasl.java
! src/java.smartcardio/share/classes/javax/smartcardio/TerminalFactory.java
! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/TransformService.java
! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java
! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java

Changeset: 37de30468e37
Author:    peytoia
Date:      2015-10-20 19:34 +0900
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/37de30468e37

8072600: Unicode 8 support
Reviewed-by: okutsu

! make/data/characterdata/CharacterData00.java.template
! make/data/characterdata/CharacterData01.java.template
! make/data/unicodedata/PropList.txt
! make/data/unicodedata/Scripts.txt
! make/data/unicodedata/SpecialCasing.txt
! make/data/unicodedata/UnicodeData.txt
! make/data/unicodedata/VERSION
! src/java.base/share/classes/java/lang/Character.java
! src/java.base/share/classes/sun/text/resources/nfc.icu
! src/java.base/share/classes/sun/text/resources/nfkc.icu
! src/java.base/share/classes/sun/text/resources/nfkc_cf.icu
! src/java.base/share/classes/sun/text/resources/ubidi.icu
! src/java.base/share/classes/sun/text/resources/uprops.icu
! src/java.desktop/share/classes/java/awt/font/NumericShaper.java
! test/java/lang/Character/CheckProp.java
! test/java/lang/Character/CheckScript.java
! test/java/lang/Character/PropList.txt
! test/java/lang/Character/PropertyValueAliases.txt
! test/java/lang/Character/Scripts.txt

Changeset: 86713515444c
Author:    ntv
Date:      2015-10-20 13:10 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/86713515444c

8134928: java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970
Reviewed-by: rriggs, scolebourne

! src/java.base/share/classes/java/time/Instant.java
! test/java/time/tck/java/time/TCKInstant.java

Changeset: 392e83351179
Author:    azvegint
Date:      2015-09-30 13:31 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/392e83351179

8076540: [macosx] NPE due to incorrect threading
Reviewed-by: alexsch, azvegint

+ test/sun/java2d/loops/CopyAreaSpeed.html
+ test/sun/java2d/loops/CopyAreaSpeed.java

Changeset: 1ca9365c8173
Author:    alexsch
Date:      2015-09-30 17:46 +0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1ca9365c8173

8040322: TextArea.replaceRange() and insert() are broken with setText(null)
Reviewed-by: serb, azvegint
Contributed-by: Ambarish Rapte <ambarish.rapte at oracle.com>

! src/java.desktop/share/classes/java/awt/TextArea.java
+ test/java/awt/TextArea/TextAreaEditing/TextAreaEditing.java

Changeset: 605ab377eed1
Author:    alexsch
Date:      2015-10-02 10:29 +0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/605ab377eed1

8138674: Some platforms may not support showing the user-specified title in a file dialog
Reviewed-by: serb

! src/java.desktop/share/classes/java/awt/FileDialog.java

Changeset: 6fa168f3c0c0
Author:    alexsch
Date:      2015-10-02 17:12 +0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6fa168f3c0c0

8067346: Swing submenu has a changed starting offset
Reviewed-by: serb, alexsch
Contributed-by: Rajeev Chamyal <rajeev.chamyal at oracle.com>

! src/java.desktop/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/java.desktop/share/classes/sun/awt/OSInfo.java
+ test/javax/swing/JMenu/8067346/bug8067346.java

Changeset: 53700840d4d5
Author:    ssadetsky
Date:      2015-10-05 15:13 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/53700840d4d5

8058959: closed/java/awt/event/ComponentEvent/MovedResizedTwiceTest/MovedResizedTwiceTest.java failed automatically
Reviewed-by: alexsch, serb

! src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java

Changeset: b5125fa7ef4b
Author:    ssadetsky
Date:      2015-10-05 15:29 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b5125fa7ef4b

8079595: Resizing dialog which is JWindow parent makes JVM crash
Reviewed-by: alexsch, serb

! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
+ test/java/awt/Frame/FrameResize/ShowChildWhileResizingTest.java

Changeset: 9b0e9d8ccccf
Author:    psadhukhan
Date:      2015-10-05 15:36 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9b0e9d8ccccf

8132985: Crash in freetypescaler.c due to double free
Reviewed-by: prr, simonis

! src/java.desktop/share/native/libfontmanager/freetypeScaler.c
+ test/java/awt/FontClass/FontDisposer/FontDisposeTest.java

Changeset: eafaa1778c63
Author:    mcherkas
Date:      2015-10-06 10:24 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eafaa1778c63

8086038: [macosx] No available data flavors when copying from Microsoft Word for Mac
Reviewed-by: serb, alexsch

! src/java.datatransfer/macosx/classes/sun/datatransfer/resources/flavormap.properties
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDataTransferer.m

Changeset: 95263779ee37
Author:    ddehaven
Date:      2015-10-06 12:51 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/95263779ee37

Merge


Changeset: b89f353e2f9a
Author:    serb
Date:      2015-10-07 19:47 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b89f353e2f9a

4763438: Replace uses of @beaninfo with meta facility in core j2se
Reviewed-by: alexsch, erikj

! make/gensrc/GensrcSwing.gmk
! src/java.desktop/share/classes/java/awt/Button.java
! src/java.desktop/share/classes/java/awt/Component.java
! src/java.desktop/share/classes/java/awt/Container.java
! src/java.desktop/share/classes/java/awt/KeyboardFocusManager.java
! src/java.desktop/share/classes/java/beans/SimpleBeanInfo.java
! src/java.desktop/share/classes/javax/accessibility/AccessibleContext.java
! src/java.desktop/share/classes/javax/swing/AbstractButton.java
! src/java.desktop/share/classes/javax/swing/Box.java
! src/java.desktop/share/classes/javax/swing/ImageIcon.java
! src/java.desktop/share/classes/javax/swing/JApplet.java
! src/java.desktop/share/classes/javax/swing/JButton.java
! src/java.desktop/share/classes/javax/swing/JCheckBox.java
! src/java.desktop/share/classes/javax/swing/JCheckBoxMenuItem.java
! src/java.desktop/share/classes/javax/swing/JColorChooser.java
! src/java.desktop/share/classes/javax/swing/JComboBox.java
! src/java.desktop/share/classes/javax/swing/JComponent.java
! src/java.desktop/share/classes/javax/swing/JDesktopPane.java
! src/java.desktop/share/classes/javax/swing/JDialog.java
! src/java.desktop/share/classes/javax/swing/JEditorPane.java
! src/java.desktop/share/classes/javax/swing/JFileChooser.java
! src/java.desktop/share/classes/javax/swing/JFormattedTextField.java
! src/java.desktop/share/classes/javax/swing/JFrame.java
! src/java.desktop/share/classes/javax/swing/JInternalFrame.java
! src/java.desktop/share/classes/javax/swing/JLabel.java
! src/java.desktop/share/classes/javax/swing/JLayeredPane.java
! src/java.desktop/share/classes/javax/swing/JList.java
! src/java.desktop/share/classes/javax/swing/JMenu.java
! src/java.desktop/share/classes/javax/swing/JMenuBar.java
! src/java.desktop/share/classes/javax/swing/JMenuItem.java
! src/java.desktop/share/classes/javax/swing/JOptionPane.java
! src/java.desktop/share/classes/javax/swing/JPanel.java
! src/java.desktop/share/classes/javax/swing/JPasswordField.java
! src/java.desktop/share/classes/javax/swing/JPopupMenu.java
! src/java.desktop/share/classes/javax/swing/JProgressBar.java
! src/java.desktop/share/classes/javax/swing/JRadioButton.java
! src/java.desktop/share/classes/javax/swing/JRadioButtonMenuItem.java
! src/java.desktop/share/classes/javax/swing/JRootPane.java
! src/java.desktop/share/classes/javax/swing/JScrollBar.java
! src/java.desktop/share/classes/javax/swing/JScrollPane.java
! src/java.desktop/share/classes/javax/swing/JSeparator.java
! src/java.desktop/share/classes/javax/swing/JSlider.java
! src/java.desktop/share/classes/javax/swing/JSpinner.java
! src/java.desktop/share/classes/javax/swing/JSplitPane.java
! src/java.desktop/share/classes/javax/swing/JTabbedPane.java
! src/java.desktop/share/classes/javax/swing/JTable.java
! src/java.desktop/share/classes/javax/swing/JTextArea.java
! src/java.desktop/share/classes/javax/swing/JTextField.java
! src/java.desktop/share/classes/javax/swing/JTextPane.java
! src/java.desktop/share/classes/javax/swing/JToggleButton.java
! src/java.desktop/share/classes/javax/swing/JToolBar.java
! src/java.desktop/share/classes/javax/swing/JToolTip.java
! src/java.desktop/share/classes/javax/swing/JTree.java
! src/java.desktop/share/classes/javax/swing/JViewport.java
! src/java.desktop/share/classes/javax/swing/JWindow.java
! src/java.desktop/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java
! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java
! src/java.desktop/share/classes/javax/swing/table/TableColumn.java
! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java
! src/java.desktop/share/classes/javax/swing/tree/AbstractLayoutCache.java
! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeCellEditor.java
! src/java.desktop/share/classes/javax/swing/tree/VariableHeightLayoutCache.java

Changeset: aafc0a279f95
Author:    psadhukhan
Date:      2015-10-12 15:28 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aafc0a279f95

8072682: getBounds call on graphics.getDeviceConfiguration() returning cached information
Reviewed-by: serb, flar

! src/java.desktop/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java
+ test/java/awt/Graphics2D/DeviceBounds.java

Changeset: bdc017c292af
Author:    serb
Date:      2015-10-12 16:26 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bdc017c292af

8136858: Examine the usage of ThreadGroup.stop() in sun.awt.AppContext
Reviewed-by: alexsch, chegar

! src/java.desktop/share/classes/sun/awt/AppContext.java
+ test/java/awt/AppContext/ApplicationThreadsStop/ApplicationThreadsStop.java
+ test/java/awt/AppContext/ApplicationThreadsStop/java.policy

Changeset: 4b901a05d4ee
Author:    prr
Date:      2015-10-12 14:41 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4b901a05d4ee

Merge

- src/java.base/share/classes/sun/misc/ConditionLock.java
- src/java.base/share/classes/sun/misc/IOUtils.java
- src/java.base/share/classes/sun/misc/Lock.java

Changeset: daf3f9e17405
Author:    serb
Date:      2015-10-13 14:59 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/daf3f9e17405

8066904: NullPointerException when calling ImageIO.read(InputStream) with corrupt BMP
Reviewed-by: serb, prr
Contributed-by: Jayathirth D V <jayathirth.d.v at oracle.com>

! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
! src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties
+ test/javax/imageio/plugins/bmp/Bug8066904.java

Changeset: 54a5ff7b22b6
Author:    prr
Date:      2015-10-20 08:24 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/54a5ff7b22b6

Merge

- src/java.base/share/native/libfdlibm/s_cbrt.c

Changeset: 3b02e93e1f9d
Author:    prr
Date:      2015-10-20 10:33 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3b02e93e1f9d

Merge


Changeset: f4b410327913
Author:    jbachorik
Date:      2015-10-20 20:53 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f4b410327913

8139870: sun.management.LazyCompositeData.isTypeMatched() fails for composite types with items of ArrayType
Reviewed-by: dfuchs

! src/java.management/share/classes/sun/management/LazyCompositeData.java
+ test/sun/management/LazyCompositeDataTest.java

Changeset: 4bedcee102c4
Author:    zmajo
Date:      2015-10-05 10:30 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4bedcee102c4

8137173: @HotSpotIntrinsicCandidate is not Oracle-specific
Summary: Change the description of the @HotSpotIntrinsicCandidate annotation.
Reviewed-by: mr, alanb

! src/java.base/share/classes/jdk/internal/HotSpotIntrinsicCandidate.java

Changeset: a1029a7e5efe
Author:    amurillo
Date:      2015-10-08 14:28 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a1029a7e5efe

Merge


Changeset: a0917b713fda
Author:    dsamersoff
Date:      2015-09-24 20:40 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0917b713fda

8086134: Deadlock detection fails to attach to core file
Summary: Test reimplemented for jtreg
Reviewed-by: jbachorik

+ test/sun/tools/jstack/DeadlockDetectionTest.java

Changeset: 8a9a7b1a3210
Author:    jwilhelm
Date:      2015-09-28 15:05 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8a9a7b1a3210

Merge


Changeset: 703df4322ebb
Author:    dsamersoff
Date:      2015-10-01 10:33 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/703df4322ebb

8133063: Remove BasicLauncherTest from the problem list
Summary: Remove BasicLauncherTest from the problem list
Reviewed-by: jbachorik

! test/ProblemList.txt

Changeset: 593313eedbb0
Author:    jwilhelm
Date:      2015-10-07 00:46 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/593313eedbb0

Merge


Changeset: 12c67db03ee7
Author:    jbachorik
Date:      2015-10-02 18:49 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/12c67db03ee7

8138748: ManagementAgent.status DCMD fails with NPE for JMX configured on command line
Reviewed-by: sspitsyn, dsamersoff, olagneau

! src/java.management/share/classes/sun/management/Agent.java
+ test/sun/management/jmxremote/startstop/JMXStatus1Test.java
+ test/sun/management/jmxremote/startstop/JMXStatus2Test.java
! test/sun/management/jmxremote/startstop/JMXStatusTest.java

Changeset: 3691b2ca322d
Author:    jbachorik
Date:      2015-10-08 09:40 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3691b2ca322d

8138579: Custom launcher fails to start because of permission problem
Reviewed-by: sspitsyn, dsamersoff

! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java

Changeset: 6bacc922bef7
Author:    jwilhelm
Date:      2015-10-15 13:23 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6bacc922bef7

Merge


Changeset: de4d2d6b5530
Author:    twisti
Date:      2015-10-08 13:32 -1000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/de4d2d6b5530

8136421: JEP 243: Java-Level JVM Compiler Interface
Reviewed-by: ihse, alanb, roland, coleenp, iveresov, kvn, kbarrett

! make/src/classes/build/tools/module/boot.modules

Changeset: dd09922656aa
Author:    dlong
Date:      2015-10-09 02:43 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dd09922656aa

Merge


Changeset: 8ed2bee756d6
Author:    redestad
Date:      2015-10-12 15:41 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8ed2bee756d6

8134607: Remove per-compiler performance counters
Reviewed-by: twisti, neliasso

! src/java.management/share/classes/sun/management/CompilerThreadStat.java
! src/java.management/share/classes/sun/management/HotspotCompilation.java
! src/java.management/share/classes/sun/management/HotspotCompilationMBean.java

Changeset: ab8c2b15a29a
Author:    dlong
Date:      2015-10-17 15:41 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ab8c2b15a29a

Merge


Changeset: eb6219ff2930
Author:    amurillo
Date:      2015-10-19 12:30 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eb6219ff2930

Merge


Changeset: 92ff2c7d2c50
Author:    amurillo
Date:      2015-10-20 11:56 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/92ff2c7d2c50

Merge

! test/ProblemList.txt

Changeset: 796a4f0d5082
Author:    amurillo
Date:      2015-10-20 17:15 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/796a4f0d5082

Merge


Changeset: d715a59bca20
Author:    rriggs
Date:      2015-10-21 14:18 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d715a59bca20

8138963: java.lang.Objects new method to default to non-null
Summary: add java.util.Object.nonNullElse and nonNullElseGet
Reviewed-by: dfuchs, jrose, psandoz, smarks, igerasim, chegar

! src/java.base/share/classes/java/util/Objects.java
! test/java/util/Objects/BasicObjectsTest.java

Changeset: 9a84eb7c34e1
Author:    igerasim
Date:      2015-10-21 22:49 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9a84eb7c34e1

8139373: [TEST_BUG] java/net/MulticastSocket/MultiDead.java failed with timeout
Reviewed-by: chegar

! test/java/net/MulticastSocket/MultiDead.java
! test/lib/testlibrary/jdk/testlibrary/Utils.java

Changeset: 26690783d6fd
Author:    sjiang
Date:      2015-05-07 09:37 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/26690783d6fd

8078440: Safer managed types
Reviewed-by: dfuchs, ahgross

! src/java.management/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java

Changeset: a0e3501ef531
Author:    smarks
Date:      2015-05-08 15:23 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0e3501ef531

8076413: Better JRMP message handling
Reviewed-by: coffeys, igerasim, ahgross

! src/java.rmi/share/classes/sun/rmi/transport/DGCClient.java

Changeset: e803843a9a36
Author:    serb
Date:      2015-05-23 02:49 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e803843a9a36

8080541: More direct property handling
Reviewed-by: prr, alexsch

! src/java.desktop/share/classes/java/beans/PropertyDescriptor.java

Changeset: 3975503a71c5
Author:    weijun
Date:      2015-05-24 16:35 +0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3975503a71c5

8048030: Expectations should be consistent
Reviewed-by: valeriep, mullan, ahgross

! src/java.base/share/classes/javax/security/auth/AuthPermission.java
! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java
! src/java.security.jgss/share/classes/javax/security/auth/kerberos/ServicePermission.java
! src/java.security.jgss/share/classes/org/ietf/jgss/GSSName.java
! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5NameElement.java
! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java
! src/java.security.jgss/share/classes/sun/security/krb5/KrbServiceLocator.java
! src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java
! src/java.security.jgss/share/classes/sun/security/krb5/Realm.java
! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java
! test/sun/security/krb5/auto/KDC.java
! test/sun/security/krb5/auto/SSL.java
! test/sun/security/krb5/name/Constructors.java

Changeset: 662689223d73
Author:    joehw
Date:      2015-05-26 10:39 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/662689223d73

8078427: More supportive home environment
Reviewed-by: dfuchs, lancea, skoivu

! src/java.base/share/conf/security/java.security
! test/java/lang/SecurityManager/CheckPackageAccess.java
! test/java/lang/SecurityManager/RestrictedPackages.java

Changeset: 7cdc4d83ad66
Author:    dtitov
Date:      2015-06-09 11:52 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7cdc4d83ad66

8080246: JNLP app cannot be launched due to deadlock
Reviewed-by: serb, vdrozdov

! src/java.desktop/share/classes/sun/awt/SunToolkit.java

Changeset: 2fed1d855201
Author:    prr
Date:      2015-06-16 14:38 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2fed1d855201

8086092: More palette improvements
Reviewed-by: bae, serb, mschoene

! make/lib/Awt2dLibraries.gmk

Changeset: 323d428e6f0f
Author:    jbachorik
Date:      2015-06-15 12:58 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/323d428e6f0f

8087350: Improve array conversions
Reviewed-by: dfuchs, ahgross

! src/java.management/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java

Changeset: aa49cbb03b23
Author:    ptbrunet
Date:      2015-06-25 15:00 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aa49cbb03b23

8129611: Accessbridge error handling improvement
Reviewed-by: prr, ahgross, asmotrak
Contributed-by: peter.brunet at oracle.com

! src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp
! src/jdk.accessibility/windows/native/common/AccessBridgeDebug.h
! src/jdk.accessibility/windows/native/libwindowsaccessbridge/WinAccessBridge.cpp

Changeset: 56af9a78c8b7
Author:    smarks
Date:      2015-06-25 16:44 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/56af9a78c8b7

8080688: Service for DGC services
Reviewed-by: skoivu, igerasim, jeff

! src/java.rmi/share/classes/sun/rmi/transport/DGCImpl.java

Changeset: 21be49e17e72
Author:    chegar
Date:      2015-06-29 11:44 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/21be49e17e72

8103671: More objective stream classes
Reviewed-by: rriggs, igerasim

! src/java.base/share/classes/java/io/ObjectStreamClass.java

Changeset: 6b7960246d55
Author:    juh
Date:      2015-06-30 14:22 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6b7960246d55

8081744: Clear out list corner case
Reviewed-by: mullan, rhalade

! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java

Changeset: 5bf77113d49b
Author:    chegar
Date:      2015-07-03 14:40 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5bf77113d49b

8130253: ObjectStreamClass.getFields too restrictive
Reviewed-by: igerasim, skoivu

! src/java.base/share/classes/java/io/ObjectStreamClass.java

Changeset: 76abc44582c5
Author:    michaelm
Date:      2015-07-09 13:23 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/76abc44582c5

8130193: Improve HTTP connections
Reviewed-by: alanb

! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java

Changeset: 271003ea3228
Author:    xuelei
Date:      2015-07-13 13:37 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/271003ea3228

8130864: Better server identity handling
Reviewed-by: jnimeh, asmotrak, ahgross

! src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java

Changeset: 1fc869ad86a0
Author:    ptbrunet
Date:      2015-07-14 17:06 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1fc869ad86a0

8130185: More accessible access switch
Reviewed-by: prr, ahgross, asmotrak
Contributed-by: peter.brunet at oracle.com

! src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp

Changeset: 5a5525f17ba1
Author:    xuelei
Date:      2015-07-20 01:45 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5a5525f17ba1

8081760: Better group dynamics
Summary: Allows user to specify custom DH groups. Also reviewed by Alexander Fomin <alexander.fomin at oracle.com>.
Reviewed-by: coffeys, mullan, weijun, jnimeh, ahgross, asmotrak

! src/java.base/share/classes/sun/security/ssl/DHCrypt.java
! src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java
! src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java
! src/java.base/share/conf/security/java.security
! test/sun/security/ssl/DHKeyExchange/DHEKeySizing.java

Changeset: 4a64fcb2f34f
Author:    smarks
Date:      2015-07-20 14:37 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4a64fcb2f34f

8076339: Better handling of remote object invocation
Reviewed-by: asmotrak, igerasim, skoivu

! src/java.rmi/share/classes/java/rmi/server/RemoteObjectInvocationHandler.java

Changeset: a9dbc8a56c73
Author:    vinnie
Date:      2015-07-24 16:47 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a9dbc8a56c73

8131291: Perfect parameter patterning
Reviewed-by: mullan

! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java

Changeset: a4dd1239afd6
Author:    prr
Date:      2015-07-24 09:44 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a4dd1239afd6

8103675: Better Binary searches
Reviewed-by: srl, serb, mschoene

! src/java.desktop/share/native/libfontmanager/layout/LookupTables.cpp

Changeset: 7b7c731a73d1
Author:    prr
Date:      2015-07-29 11:04 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7b7c731a73d1

8132042: Preserve layout presentation
Reviewed-by: mschoene, srl, serb

! src/java.desktop/share/native/libfontmanager/layout/IndicRearrangementProcessor.cpp
! src/java.desktop/share/native/libfontmanager/layout/IndicRearrangementProcessor.h
! src/java.desktop/share/native/libfontmanager/layout/IndicRearrangementProcessor2.cpp
! src/java.desktop/share/native/libfontmanager/layout/IndicRearrangementProcessor2.h
! src/java.desktop/share/native/libfontmanager/layout/MorphTables.cpp
! src/java.desktop/share/native/libfontmanager/layout/MorphTables2.cpp
! src/java.desktop/share/native/libfontmanager/layout/SegmentArrayProcessor.cpp
! src/java.desktop/share/native/libfontmanager/layout/SegmentArrayProcessor2.cpp
! src/java.desktop/share/native/libfontmanager/layout/SegmentSingleProcessor2.cpp
! src/java.desktop/share/native/libfontmanager/layout/SimpleArrayProcessor2.cpp
! src/java.desktop/share/native/libfontmanager/layout/SingleTableProcessor.cpp

Changeset: 49760292750d
Author:    bpb
Date:      2015-08-06 10:13 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/49760292750d

8130891: (bf) More direct buffering
Summary: Improve non-byte direct buffering.
Reviewed-by: alanb, jeff, ahgross, robm, rriggs

! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template

Changeset: b30f4c331df7
Author:    coffeys
Date:      2015-09-01 18:12 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b30f4c331df7

8133196: HTTPS hostname invalid issue with InetAddress
Reviewed-by: chegar, xuelei

! src/java.base/share/classes/java/net/Inet4Address.java
! src/java.base/share/classes/java/net/InetAddress.java
! src/java.base/share/native/libnet/InetAddress.c
! src/java.base/share/native/libnet/net_util.c
! src/java.base/share/native/libnet/net_util.h
+ test/java/net/InetAddress/getOriginalHostName.java

Changeset: 5dcf71508c1f
Author:    chegar
Date:      2015-09-08 12:40 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5dcf71508c1f

8135043: ObjectStreamClass.getField(String) too restrictive
Reviewed-by: igerasim

! src/java.base/share/classes/java/io/ObjectStreamClass.java
+ test/java/io/ObjectInputStream/TestObjectStreamClass.java

Changeset: a6edbf822256
Author:    chegar
Date:      2015-10-12 10:33 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a6edbf822256

8139352: java/net/InetAddress/getOriginalHostName.java fails to compile
Reviewed-by: mchung, henryjen

! test/java/net/InetAddress/getOriginalHostName.java

Changeset: 35f286a7dd46
Author:    lana
Date:      2015-10-21 18:40 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/35f286a7dd46

Merge


Changeset: f92824cdbaf3
Author:    erikj
Date:      2015-10-22 12:12 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f92824cdbaf3

8140223: fix the build with a toolchain with a linker defaulting to ld --as-needed
Reviewed-by: erikj, ihse
Contributed-by: doko at ubuntu.com

! make/launcher/Launcher-jdk.pack200.gmk
! make/lib/Awt2dLibraries.gmk

Changeset: d93844d0cdd5
Author:    lancea
Date:      2015-10-22 11:36 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d93844d0cdd5

8139056: Add convenience methods to Statement.java
Reviewed-by: joehw, rriggs

! src/java.sql/share/classes/java/sql/Statement.java
+ test/java/sql/testng/test/sql/CallableStatementTests.java
+ test/java/sql/testng/test/sql/PreparedStatementTests.java
+ test/java/sql/testng/test/sql/StatementTests.java
+ test/java/sql/testng/util/StubCallableStatement.java
+ test/java/sql/testng/util/StubPreparedStatement.java
+ test/java/sql/testng/util/StubStatement.java

Changeset: 7ee964fb0608
Author:    jjg
Date:      2015-10-22 10:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7ee964fb0608

8140325: Incorrect package.html file
Reviewed-by: darcy

! src/java.base/share/classes/overview-core.html
! src/java.naming/share/classes/javax/naming/spi/package.html

Changeset: eec915634930
Author:    lana
Date:      2015-10-22 11:14 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eec915634930

Merge


Changeset: eb131795e76e
Author:    naoto
Date:      2015-10-22 21:41 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eb131795e76e

8136668: Default locale provider adapter incorrectly set to JRE
Reviewed-by: okutsu

! make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java
! src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java

Changeset: 7e55cb303917
Author:    naoto
Date:      2015-10-22 21:44 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7e55cb303917

8134720: Lazy initialization support for currency names in DecimalFormatSymbols
Reviewed-by: okutsu

! src/java.base/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/java.base/share/classes/java/text/DecimalFormatSymbols.java
! src/java.base/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/CalendarDataUtility.java
! src/java.base/share/classes/sun/util/locale/provider/CalendarProviderImpl.java
! src/java.base/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
! src/java.base/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java
! src/java.base/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java

Changeset: 3349db932831
Author:    stuefe
Date:      2015-10-07 15:29 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3349db932831

8139037: [aix] Crash in ResolverConfigurationImpl.c - pointer shearing
Reviewed-by: goetz, simonis

! src/java.base/unix/native/libnet/ResolverConfigurationImpl.c

Changeset: 0f6c981f1cbf
Author:    mhaupt
Date:      2015-10-27 09:09 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0f6c981f1cbf

8136967: revert all changes applied to obtain information about 8131129
Reviewed-by: sundar

! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java
! test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java

Changeset: 6d88d51aa352
Author:    vtewari
Date:      2015-10-27 10:14 +0530
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6d88d51aa352

8068887: java.lang.Throwable could use Collections.emptyList for suppressedException
Summary: java.lang.Throwable could use Collections.emptyList for suppressedException
Reviewed-by: mchung, alanb, shade, redestad

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

Changeset: 8271f42bae4a
Author:    bchristi
Date:      2015-10-27 09:20 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8271f42bae4a

8138824: java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches()
Reviewed-by: naoto, rriggs

! src/java.base/share/classes/java/lang/String.java
+ test/java/lang/String/EqualsIgnoreCase.java

Changeset: 2cdd66d42587
Author:    jbachorik
Date:      2015-09-23 14:25 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2cdd66d42587

7199353: Define ConstructorProperties annotation type for MXBeans
Reviewed-by: duke

! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
+ src/java.management/share/classes/javax/management/ConstructorProperties.java
! src/java.management/share/classes/javax/management/MXBean.java
! test/javax/management/Introspector/AnnotationSecurityTest.java
! test/javax/management/Introspector/Described.java
! test/javax/management/Introspector/DescribedMX.java
+ test/javax/management/Introspector/LegacyConstructorPropertiesTest.java
! test/javax/management/mxbean/AmbiguousConstructorTest.java
! test/javax/management/mxbean/ExceptionDiagnosisTest.java
! test/javax/management/mxbean/LeakTest.java
! test/javax/management/mxbean/MXBeanTest.java
! test/javax/management/mxbean/PropertyNamesTest.java
! test/javax/management/mxbean/TigerMXBean.java

Changeset: d68de0bab8ee
Author:    jbachorik
Date:      2015-10-16 06:29 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d68de0bab8ee

8139725: Backout escaped partial fix for JDK-7199353
Reviewed-by: alanb

! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
- src/java.management/share/classes/javax/management/ConstructorProperties.java
! src/java.management/share/classes/javax/management/MXBean.java
! test/javax/management/Introspector/AnnotationSecurityTest.java
! test/javax/management/Introspector/Described.java
! test/javax/management/Introspector/DescribedMX.java
- test/javax/management/Introspector/LegacyConstructorPropertiesTest.java
! test/javax/management/mxbean/AmbiguousConstructorTest.java
! test/javax/management/mxbean/ExceptionDiagnosisTest.java
! test/javax/management/mxbean/LeakTest.java
! test/javax/management/mxbean/MXBeanTest.java
! test/javax/management/mxbean/PropertyNamesTest.java
! test/javax/management/mxbean/TigerMXBean.java

Changeset: d8a2e5cf4627
Author:    jprovino
Date:      2015-10-20 11:17 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d8a2e5cf4627

Merge


Changeset: de3398e1b429
Author:    amurillo
Date:      2015-10-22 16:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/de3398e1b429

Merge


Changeset: f70dcc362579
Author:    amurillo
Date:      2015-10-26 17:19 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f70dcc362579

Merge


Changeset: 0d0a63b32559
Author:    amurillo
Date:      2015-10-27 10:15 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0d0a63b32559

Merge


Changeset: b433e4dfb830
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b433e4dfb830

Added tag jdk9-b89 for changeset 0d0a63b32559

! .hgtags

Changeset: 19c5d1129851
Author:    lana
Date:      2015-10-30 10:28 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/19c5d1129851

Added tag jdk9-b90 for changeset b433e4dfb830

! .hgtags

Changeset: 2e63fa2efdb1
Author:    shurailine
Date:      2015-10-27 20:06 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2e63fa2efdb1

8140336: Add @modules for exported dependencies to jdk_core tests
Reviewed-by: alanb, mchung

! test/java/lang/ProcessHandle/TEST.properties
! test/java/lang/annotation/AnnotationType/AnnotationTypeDeadlockTest.java
! test/java/lang/instrument/AddTransformerTest.java
! test/java/lang/instrument/AppendToBootstrapClassPathTest.java
! test/java/lang/instrument/AppendToClassPathTest.java
! test/java/lang/instrument/BootClassPath/BootClassPathTest.sh
! test/java/lang/instrument/FromShutdownHook.java
! test/java/lang/instrument/GetAllLoadedClassesTest.java
! test/java/lang/instrument/GetInitiatedClassesTest.java
! test/java/lang/instrument/GetObjectSizeTest.java
! test/java/lang/instrument/IsModifiableClassAgent.java
! test/java/lang/instrument/ManifestTest.sh
! test/java/lang/instrument/NativeMethodPrefixAgent.java
! test/java/lang/instrument/NoTransformerAddedTest.java
! test/java/lang/instrument/NullGetObjectSizeTest.java
! test/java/lang/instrument/NullRedefineClassesTests.java
! test/java/lang/instrument/NullTransformerAddTest.java
! test/java/lang/instrument/NullTransformerRemoveTest.java
! test/java/lang/instrument/ParallelTransformerLoader.sh
! test/java/lang/instrument/PremainClass/InheritAgent0010.java
! test/java/lang/instrument/PremainClass/InheritAgent0011.java
! test/java/lang/instrument/PremainClass/InheritAgent0110.java
! test/java/lang/instrument/PremainClass/InheritAgent0111.java
! test/java/lang/instrument/PremainClass/InheritAgent1000.java
! test/java/lang/instrument/PremainClass/InheritAgent1001.java
! test/java/lang/instrument/PremainClass/InheritAgent1010.java
! test/java/lang/instrument/PremainClass/InheritAgent1011.java
! test/java/lang/instrument/PremainClass/InheritAgent1100.java
! test/java/lang/instrument/PremainClass/InheritAgent1101.java
! test/java/lang/instrument/PremainClass/InheritAgent1110.java
! test/java/lang/instrument/PremainClass/InheritAgent1111.java
! test/java/lang/instrument/RedefineBigClass.sh
! test/java/lang/instrument/RedefineClassWithNativeMethod.sh
! test/java/lang/instrument/RedefineClassesDisabledTest.java
! test/java/lang/instrument/RedefineClassesTests.java
! test/java/lang/instrument/RedefineMethodAddInvoke.sh
! test/java/lang/instrument/RedefineMethodDelInvoke.sh
! test/java/lang/instrument/RedefineMethodInBacktrace.sh
! test/java/lang/instrument/RedefineMethodWithAnnotations.sh
! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh
! test/java/lang/instrument/RemoveAbsentTransformerTest.java
! test/java/lang/instrument/RemoveTransformerTest.java
! test/java/lang/instrument/RetransformBigClass.sh
! test/java/lang/instrument/SingleTransformerTest.java
! test/java/lang/instrument/StressGetObjectSizeTest.sh
+ test/java/lang/instrument/TEST.properties
! test/java/lang/instrument/TransformMethodTest.java
! test/java/lang/instrument/TransformerManagementThreadAddTests.java
! test/java/lang/instrument/TransformerManagementThreadRemoveTests.java
! test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh
! test/java/lang/instrument/appendToClassLoaderSearch/CircularityErrorTest.sh
! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh
! test/java/lang/instrument/appendToClassLoaderSearch/run_tests.sh
! test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java
! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java
! test/java/lang/invoke/lambda/LambdaAccessControlTest.java
! test/java/lang/invoke/lambda/LambdaAsm.java
! test/java/lang/invoke/lambda/LambdaStackTrace.java
! test/jdk/lambda/TEST.properties
! test/sun/misc/JarIndex/metaInfFilenames/Basic.java
! test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java
! test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java

Changeset: 03453e4301fc
Author:    redestad
Date:      2015-10-28 12:35 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/03453e4301fc

6823565: Excessive use of HandleList class in de-serialization code causes OutOfMemory
Reviewed-by: chegar, shade

! src/java.base/share/classes/java/io/ObjectInputStream.java

Changeset: 71e43dd2e0b9
Author:    naoto
Date:      2015-10-26 19:49 +0530
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/71e43dd2e0b9

8061287: Update i18n tests to remove references of jre dir
Summary: Updated PropertiesTest.sh to remove references of jre dir.
Reviewed-by: naoto, peytoia
Contributed-by: Rachna Goel <rachna.goel at oracle.com>

! test/java/util/Currency/PropertiesTest.sh

Changeset: d7caf74c48ab
Author:    redestad
Date:      2015-10-28 23:31 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d7caf74c48ab

8066644: Fix deprecation warnings in jdk.zipfs module
Reviewed-by: sherman, shade
Contributed-by: Peter Levart <peter.levart at gmail.com>, Claes Redestad <claes.redestad at gmail.com>

! src/java.base/share/classes/java/util/zip/ZipUtils.java
! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java

Changeset: a0eb148fa9d5
Author:    ihse
Date:      2015-10-29 16:31 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0eb148fa9d5

8140661: Rename LDFLAGS_SUFFIX to LIBS
Reviewed-by: erikj

! make/CompileDemos.gmk
! make/launcher/Launcher-java.base.gmk
! make/launcher/Launcher-jdk.accessibility.gmk
! make/launcher/Launcher-jdk.jconsole.gmk
! make/launcher/Launcher-jdk.pack200.gmk
! make/launcher/LauncherCommon.gmk
! make/lib/Awt2dLibraries.gmk
! make/lib/CoreLibraries.gmk
! make/lib/Lib-java.instrument.gmk
! make/lib/Lib-java.management.gmk
! make/lib/Lib-java.prefs.gmk
! make/lib/Lib-java.security.jgss.gmk
! make/lib/Lib-java.smartcardio.gmk
! make/lib/Lib-jdk.accessibility.gmk
! make/lib/Lib-jdk.attach.gmk
! make/lib/Lib-jdk.crypto.ec.gmk
! make/lib/Lib-jdk.crypto.mscapi.gmk
! make/lib/Lib-jdk.crypto.pkcs11.gmk
! make/lib/Lib-jdk.crypto.ucrypto.gmk
! make/lib/Lib-jdk.deploy.osx.gmk
! make/lib/Lib-jdk.internal.le.gmk
! make/lib/Lib-jdk.jdi.gmk
! make/lib/Lib-jdk.jdwp.agent.gmk
! make/lib/Lib-jdk.management.gmk
! make/lib/Lib-jdk.pack200.gmk
! make/lib/Lib-jdk.sctp.gmk
! make/lib/Lib-jdk.security.auth.gmk
! make/lib/NetworkingLibraries.gmk
! make/lib/NioLibraries.gmk
! make/lib/PlatformLibraries.gmk
! make/lib/SecurityLibraries.gmk
! make/lib/SoundLibraries.gmk

Changeset: bd6ca4cbfa4f
Author:    ascarpino
Date:      2015-10-29 09:09 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bd6ca4cbfa4f

8139859: TestRSA.java: 'message larger than modulus' using SunRsaSign KeyFactory
Reviewed-by: xuelei

! test/ProblemList.txt
! test/com/oracle/security/ucrypto/TestRSA.java

Changeset: 071b08d30f81
Author:    lana
Date:      2015-10-29 12:39 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/071b08d30f81

Merge


Changeset: 97624df5026a
Author:    lana
Date:      2015-11-04 13:46 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/97624df5026a

Merge


Changeset: 30cae8145c33
Author:    mchung
Date:      2015-11-11 15:50 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/30cae8145c33

Merge

! .hgtags
! make/CompileDemos.gmk
! make/CompileInterimRmic.gmk
! make/gendata/Gendata-java.base.gmk
- make/gendata/Gendata-jdk.jdeps.gmk
- make/gensrc/Gensrc-jdk.dev.gmk
! make/gensrc/GensrcSwing.gmk
! make/launcher/Launcher-java.base.gmk
! make/launcher/Launcher-jdk.accessibility.gmk
- make/launcher/Launcher-jdk.dev.gmk
! make/launcher/Launcher-jdk.jconsole.gmk
! make/launcher/Launcher-jdk.pack200.gmk
! make/launcher/LauncherCommon.gmk
! make/lib/Awt2dLibraries.gmk
! make/lib/CoreLibraries.gmk
! make/lib/Lib-java.instrument.gmk
! make/lib/Lib-java.management.gmk
! make/lib/Lib-java.prefs.gmk
! make/lib/Lib-java.security.jgss.gmk
! make/lib/Lib-java.smartcardio.gmk
! make/lib/Lib-jdk.accessibility.gmk
! make/lib/Lib-jdk.attach.gmk
! make/lib/Lib-jdk.crypto.ec.gmk
! make/lib/Lib-jdk.crypto.mscapi.gmk
! make/lib/Lib-jdk.crypto.pkcs11.gmk
! make/lib/Lib-jdk.deploy.osx.gmk
! make/lib/Lib-jdk.internal.le.gmk
! make/lib/Lib-jdk.jdi.gmk
! make/lib/Lib-jdk.jdwp.agent.gmk
! make/lib/Lib-jdk.management.gmk
! make/lib/Lib-jdk.pack200.gmk
! make/lib/Lib-jdk.sctp.gmk
! make/lib/Lib-jdk.security.auth.gmk
! make/lib/NetworkingLibraries.gmk
! make/lib/NioLibraries.gmk
! make/lib/PlatformLibraries.gmk
! make/lib/SecurityLibraries.gmk
! make/lib/SoundLibraries.gmk
! make/mapfiles/libjava/mapfile-vers
- make/scripts/localelist.sh
- make/src/classes/build/tools/module/GenJdepsModulesXml.java
- make/src/classes/build/tools/module/GenModulesList.java
- make/src/classes/build/tools/module/ImageBuilder.java
- make/src/classes/build/tools/module/ModuleArchive.java
- make/src/classes/build/tools/module/boot.modules
- make/src/classes/build/tools/module/ext.modules
! src/java.base/share/classes/java/io/ObjectInputStream.java
! src/java.base/share/classes/java/lang/invoke/MemberName.java
- src/java.base/share/classes/jdk/internal/jimage/Archive.java
! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java
- src/java.base/share/classes/jdk/internal/jimage/BasicImageWriter.java
- src/java.base/share/classes/jdk/internal/jimage/ExternalFilesWriter.java
- src/java.base/share/classes/jdk/internal/jimage/ImageFileCreator.java
- src/java.base/share/classes/jdk/internal/jimage/ImageLocationWriter.java
- src/java.base/share/classes/jdk/internal/jimage/ImageModuleDataWriter.java
- src/java.base/share/classes/jdk/internal/jimage/ImageResourcesTree.java
- src/java.base/share/classes/jdk/internal/jimage/ImageStringsWriter.java
- src/java.base/share/classes/jdk/internal/jimage/PerfectHashBuilder.java
- src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java
- src/java.base/share/classes/jdk/internal/jimage/ResourcePoolImpl.java
+ src/java.base/share/classes/module-info.java
- src/java.base/share/classes/sun/misc/Launcher.java
! src/java.base/share/classes/sun/security/jca/ProviderList.java
- src/java.base/share/classes/sun/util/CoreResourceBundleControl-XLocales.java.template
! src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java
! src/java.base/share/conf/security/java.security
- src/java.base/share/native/libjava/Package.c
- src/java.base/share/native/libjava/Proxy.c
! src/java.base/share/native/libzip/zip_util.c
- src/java.desktop/share/classes/META-INF/services/java.net.ContentHandlerFactory
- src/java.desktop/share/classes/META-INF/services/javax.print.PrintServiceLookup
- src/java.desktop/share/classes/META-INF/services/javax.print.StreamPrintServiceFactory
- src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiDeviceProvider
- src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileReader
- src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileWriter
- src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.SoundbankReader
- src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileReader
- src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileWriter
- src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider
- src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.MixerProvider
- src/java.desktop/share/classes/META-INF/services/sun.datatransfer.DesktopDatatransferService
! src/java.desktop/share/classes/java/awt/Component.java
! src/java.desktop/share/classes/java/beans/PropertyDescriptor.java
! src/java.desktop/share/classes/javax/swing/JEditorPane.java
! src/java.desktop/share/classes/javax/swing/JTable.java
! src/java.logging/share/classes/java/util/logging/LogManager.java
! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
! src/java.management/share/classes/sun/management/Agent.java
- src/java.security.jgss/share/classes/META-INF/services/sun.security.ssl.ClientKeyExchangeService
- src/jdk.accessibility/windows/classes/META-INF/services/javax.accessibility.AccessibilityProvider
- src/jdk.attach/share/classes/META-INF/services/com.sun.tools.attach.spi.AttachProvider
- src/jdk.charsets/share/classes/META-INF/services/java.nio.charset.spi.CharsetProvider
- src/jdk.dev/share/classes/jdk/tools/jimage/ExtractedImage.java
- src/jdk.dev/share/classes/jdk/tools/jimage/JImageTask.java
- src/jdk.dev/share/classes/jdk/tools/jimage/Main.java
- src/jdk.dev/share/classes/jdk/tools/jimage/TaskHelper.java
- src/jdk.dev/share/classes/jdk/tools/jimage/resources/jimage.properties
- src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector
- src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.spi.TransportService
- src/jdk.jvmstat/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService
- src/jdk.localedata/share/classes/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo
- src/jdk.management/share/classes/META-INF/services/sun.management.spi.PlatformMBeanProvider
- src/jdk.naming.dns/share/classes/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor
- src/jdk.zipfs/share/classes/META-INF/services/java.nio.file.spi.FileSystemProvider
! test/ProblemList.txt
! test/java/lang/SecurityManager/CheckPackageAccess.java
! test/java/lang/instrument/NativeMethodPrefixAgent.java
! test/java/lang/instrument/RedefineMethodInBacktrace.sh
! test/java/lang/instrument/SingleTransformerTest.java
! test/java/lang/instrument/TransformMethodTest.java
! test/java/lang/invoke/lambda/LambdaAsm.java
- test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh
- test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java/net/MyDatagramSocketImplFactory.java
! test/java/rmi/registry/readTest/readTest.sh
! test/javax/management/mxbean/LeakTest.java
- test/jdk/internal/jimage/ExecutableTest.java
- test/jdk/internal/jimage/JImageTest.java
- test/jdk/internal/jimage/VerifyJimage.java
! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java
! test/sun/misc/JarIndex/metaInfFilenames/Basic.java
! test/sun/security/krb5/auto/SSL.java

Changeset: 46891039e911
Author:    mchung
Date:      2015-11-12 15:31 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/46891039e911

Merge

! make/gensrc/GensrcModuleLoaderMap.gmk
! src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java

Changeset: 52814ae373b7
Author:    mchung
Date:      2015-11-12 19:25 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/52814ae373b7

Update module-info.java for jdk9-b91

! src/java.base/share/classes/module-info.java
! src/jdk.internal.le/share/classes/module-info.java

Changeset: a28acd9a8c74
Author:    mchung
Date:      2015-11-12 19:25 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a28acd9a8c74

Merge


Changeset: 13e434966a52
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/13e434966a52

Added tag jdk9-b91 for changeset 97624df5026a

! .hgtags

Changeset: 7f6a82dc978e
Author:    rriggs
Date:      2015-10-30 11:12 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7f6a82dc978e

8139390: Very long classname in jimage causes SIGSEGV
Summary: Correct issues with ImageNativeSubstrate and JImageReadTest
Reviewed-by: mchung

! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp
! src/java.base/share/native/libjimage/jimage.cpp
! test/jdk/internal/jimage/JImageReadTest.java

Changeset: 8bd5a6e85a2f
Author:    simonis
Date:      2015-11-02 14:57 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8bd5a6e85a2f

8140514: [TESTBUG] enable sun/security/pkcs11 tests on Linux/ppc64
Reviewed-by: wetmore

! test/sun/security/pkcs11/PKCS11Test.java

Changeset: 185252122a39
Author:    naoto
Date:      2015-11-02 08:46 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/185252122a39

8062006: Add a new locale data name "COMPAT" for java.locale.providers system property to reduce ambiguity
Reviewed-by: okutsu

! src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! test/java/util/Locale/LocaleProviders.sh

Changeset: 9fef91483af7
Author:    vlivanov
Date:      2015-10-19 17:52 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9fef91483af7

8139881: Exclude java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java from execution
Reviewed-by: kvn

! test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java

Changeset: 5ff0a80ee6c7
Author:    dlong
Date:      2015-10-27 01:45 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5ff0a80ee6c7

Merge

- src/java.base/share/classes/sun/misc/ConditionLock.java
- src/java.base/share/classes/sun/misc/IOUtils.java
- src/java.base/share/classes/sun/misc/Lock.java
- src/java.base/share/native/libfdlibm/s_cbrt.c

Changeset: 780bec42fe40
Author:    amurillo
Date:      2015-10-30 12:03 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/780bec42fe40

Merge


Changeset: 5afa5a406c20
Author:    amurillo
Date:      2015-11-02 10:47 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5afa5a406c20

Merge


Changeset: a21b0e82392d
Author:    jbachorik
Date:      2015-09-23 14:25 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a21b0e82392d

8139727: Define ConstructorParameters annotation type for MXBeans
Reviewed-by: alanb, mchung, dfuchs, abuckley, plevart, mr

! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
+ src/java.management/share/classes/javax/management/ConstructorParameters.java
! src/java.management/share/classes/javax/management/MXBean.java
! test/javax/management/Introspector/AnnotationSecurityTest.java
! test/javax/management/Introspector/Described.java
! test/javax/management/Introspector/DescribedMX.java
+ test/javax/management/Introspector/LegacyConstructorPropertiesTest.java
! test/javax/management/mxbean/AmbiguousConstructorTest.java
! test/javax/management/mxbean/ExceptionDiagnosisTest.java
! test/javax/management/mxbean/LeakTest.java
! test/javax/management/mxbean/MXBeanTest.java
! test/javax/management/mxbean/PropertyNamesTest.java
! test/javax/management/mxbean/TigerMXBean.java

Changeset: 226cd203e48a
Author:    ihse
Date:      2015-11-03 16:15 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/226cd203e48a

6512052: Remove java-rmi.exe and java-rmi.cgi
Reviewed-by: alanb

! make/launcher/Launcher-java.rmi.gmk
- src/java.rmi/unix/bin/java-rmi.cgi.sh

Changeset: 7d07e7aa69ef
Author:    rriggs
Date:      2015-11-03 10:20 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7d07e7aa69ef

8139345: java/lang/ProcessHandle/TreeTest.java test fails with ... Wrong number of children expected [3] but found [2]
Reviewed-by: darcy

! test/java/lang/ProcessHandle/TreeTest.java

Changeset: b6c25628a82d
Author:    ihse
Date:      2015-11-03 17:48 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b6c25628a82d

8141261: Clean up building of demos
Reviewed-by: erikj, tbell

! make/CompileDemos.gmk

Changeset: 30a4e10baf9c
Author:    ihse
Date:      2015-11-03 17:54 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/30a4e10baf9c

8141333: Rename SetupArchive to SetupJarArchive
Reviewed-by: erikj, tbell

! make/gendata/GendataPolicyJars.gmk

Changeset: b66591d98c6b
Author:    serb
Date:      2015-10-18 13:33 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b66591d98c6b

6815345: java.awt.Component.createImage(int width,int height) should remove behavioral optionality
Reviewed-by: prr, ssadetsky

! src/java.desktop/share/classes/java/awt/Component.java
+ test/java/awt/Component/CreateImage/CreateImage.java

Changeset: ddc8bbf88d36
Author:    yan
Date:      2015-10-20 12:42 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ddc8bbf88d36

8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw
Reviewed-by: serb, yan
Contributed-by: Renjith Alexander <renjith.alexander at oracle.com>

+ test/java/awt/EmbeddedFrame/GraphicsConfigTest/GraphicsConfigTest.java
+ test/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.html
+ test/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.java

Changeset: f574643a1c16
Author:    ssadetsky
Date:      2015-10-20 15:42 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f574643a1c16

8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity
Reviewed-by: alexsch, serb

! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
+ test/java/awt/Window/ScreenLocation/ScreenLocationTest.java

Changeset: 7993027bcb2f
Author:    ssadetsky
Date:      2015-10-20 15:59 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7993027bcb2f

8022334: After calling frame.toBack() dialog goes to the back on Ubuntu 12.04
Reviewed-by: alexsch, serb

! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
+ test/java/awt/Window/MultiWindowApp/MultiWindowAppTest.java

Changeset: 4d719805b1f1
Author:    aivanov
Date:      2015-10-20 16:55 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4d719805b1f1

8130136: Swing window sometimes fails to repaint partially when it becomes exposed
Reviewed-by: alexp, serb

! src/java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp
! src/java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.h
! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
! src/java.desktop/windows/native/libawt/windows/awt_Component.h

Changeset: b70f060eadf7
Author:    serb
Date:      2015-10-20 22:46 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b70f060eadf7

7182758: BMPMetadata returns invalid PhysicalPixelSpacing
Reviewed-by: serb, vadim
Contributed-by: Jayathirth D V <jayathirth.d.v at oracle.com>

! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java
+ test/javax/imageio/plugins/bmp/BMPPixelSpacingTest.java

Changeset: c62b791a8960
Author:    serb
Date:      2015-10-21 18:32 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c62b791a8960

8138764: In some cases the usage of TreeLock can be replaced by other synchronization
Reviewed-by: alexp, alexsch

! src/java.desktop/share/classes/java/awt/Component.java
! src/java.desktop/share/classes/java/awt/Window.java
! src/java.desktop/share/classes/sun/swing/CachedPainter.java
+ test/java/awt/Component/TreeLockDeadlock/TreeLockDeadlock.java

Changeset: 3fdbedd9ff1b
Author:    mcherkas
Date:      2015-10-21 18:58 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3fdbedd9ff1b

8136763: [macosx] java always returns only one value for "text/uri-list" dataflavor even if several files were copied
Reviewed-by: alexsch, serb

! src/java.datatransfer/macosx/classes/sun/datatransfer/resources/flavormap.properties
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
+ test/java/awt/datatransfer/DataFlavor/MacOsXFileAndMultipleFileCopingTest/MacOsXFileAndMultipleFileCopingTest.java
- test/java/awt/datatransfer/DataFlavor/XJavaUrlDataFlavorTest/XJavaUrlDataFlavorTest.java

Changeset: edec0fe63ceb
Author:    prr
Date:      2015-10-21 09:21 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/edec0fe63ceb

8132890: Text overlapping on dot matrix printers.
Reviewed-by: jgodinez, serb

! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java
! test/java/awt/print/PrinterJob/PrintTextTest.java

Changeset: 0746c20f1365
Author:    serb
Date:      2015-10-21 21:28 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0746c20f1365

8041900: [macosx] Java forces the use of discrete GPU
Reviewed-by: ssadetsky, alexsch

! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m
! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLGraphicsConfig.m

Changeset: deb544c19dec
Author:    sebastian
Date:      2015-10-22 13:46 +0400
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/deb544c19dec

8139754: Change Boolean constructor use to the use of Boolean factorymethods. For the macosx-port-dev area
Reviewed-by: serb, alexsch

! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java

Changeset: 8bf32c4c2332
Author:    prr
Date:      2015-10-23 10:50 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8bf32c4c2332

Merge

- src/java.base/share/native/libfdlibm/s_cbrt.c

Changeset: 14f8bca09c9b
Author:    ddehaven
Date:      2015-11-03 09:45 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/14f8bca09c9b

Merge

- test/java/awt/datatransfer/DataFlavor/XJavaUrlDataFlavorTest/XJavaUrlDataFlavorTest.java

Changeset: 240ca1b2eb59
Author:    darcy
Date:      2015-11-03 17:41 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/240ca1b2eb59

8141368: Typo in java/lang/Class/IsEnum.java test
Reviewed-by: jjg

! test/java/lang/Class/IsEnum.java

Changeset: 76203cb95f2c
Author:    simonis
Date:      2015-11-04 12:46 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/76203cb95f2c

8141290: AIX: fix build after '8140661: Rename LDFLAGS_SUFFIX to LIBS'
Reviewed-by: ihse

! make/lib/Awt2dLibraries.gmk
! make/lib/Lib-java.instrument.gmk
! make/lib/Lib-jdk.jdwp.agent.gmk

Changeset: 034043795e42
Author:    psandoz
Date:      2015-11-04 16:44 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/034043795e42

8033148: Lexicographic comparators for arrays
Reviewed-by: jrose, chegar, bchristi, mduigou

! src/java.base/share/classes/java/lang/Byte.java
! src/java.base/share/classes/java/lang/Short.java
! src/java.base/share/classes/java/util/Arrays.java
+ test/java/util/Arrays/ArraysEqCmpTest.java

Changeset: ff09a5eddc89
Author:    darcy
Date:      2015-11-04 09:01 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ff09a5eddc89

8141359: @Deprecated on packages should be clarified
Reviewed-by: rriggs

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

Changeset: d3f793857ca3
Author:    darcy
Date:      2015-11-04 11:27 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d3f793857ca3

8141454: Move java/lang/ProcessHandle/TreeTest.java until stability improves
Reviewed-by: rriggs

! test/TEST.groups

Changeset: 9ecb10ce62c6
Author:    bpb
Date:      2015-11-04 14:06 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9ecb10ce62c6

8140630: java/nio/Buffer/Basic.java crashes vm on linux-x64 using latest devkit to build
Summary: Build Bits.c at a lower optimization level on linux-x64.
Reviewed-by: tbell

! make/lib/CoreLibraries.gmk

Changeset: 20ccac7e0705
Author:    ihse
Date:      2015-11-05 10:54 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/20ccac7e0705

8141444: Clean up building of JDK launchers
Reviewed-by: erikj

! make/launcher/Launcher-java.base.gmk
! make/launcher/Launcher-java.corba.gmk
! make/launcher/Launcher-java.desktop.gmk
! make/launcher/Launcher-java.rmi.gmk
! make/launcher/Launcher-java.scripting.gmk
! make/launcher/Launcher-java.security.jgss.gmk
! make/launcher/Launcher-jdk.compiler.gmk
! make/launcher/Launcher-jdk.dev.gmk
! make/launcher/Launcher-jdk.hotspot.agent.gmk
! make/launcher/Launcher-jdk.jartool.gmk
! make/launcher/Launcher-jdk.javadoc.gmk
! make/launcher/Launcher-jdk.jcmd.gmk
! make/launcher/Launcher-jdk.jconsole.gmk
! make/launcher/Launcher-jdk.jdeps.gmk
! make/launcher/Launcher-jdk.jdi.gmk
! make/launcher/Launcher-jdk.jshell.gmk
! make/launcher/Launcher-jdk.jvmstat.gmk
! make/launcher/Launcher-jdk.pack200.gmk
! make/launcher/Launcher-jdk.policytool.gmk
! make/launcher/Launcher-jdk.rmic.gmk
! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk
! make/launcher/Launcher-jdk.xml.bind.gmk
! make/launcher/Launcher-jdk.xml.ws.gmk
! make/launcher/LauncherCommon.gmk

Changeset: 67d91e7479c1
Author:    lancea
Date:      2015-11-05 10:37 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/67d91e7479c1

8136496: Add Connection.begin/endRequest
Reviewed-by: joehw, rriggs, psandoz

! src/java.sql/share/classes/java/sql/Connection.java
! src/java.sql/share/classes/javax/sql/PooledConnection.java

Changeset: a16ce5acb643
Author:    redestad
Date:      2015-11-05 16:29 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a16ce5acb643

8141539: Avoid calculating string constants in InnerClassLambdaMetaFactory
Reviewed-by: vlivanov

! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java

Changeset: 6c9b3dc5bf6b
Author:    redestad
Date:      2015-11-05 16:36 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6c9b3dc5bf6b

8141536: MethodType field offset calculation could be lazy
Reviewed-by: vlivanov

! src/java.base/share/classes/java/lang/invoke/MethodType.java

Changeset: 5b710994aafb
Author:    lancea
Date:      2015-11-05 14:57 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5b710994aafb

8141546: Fix javadoc warnings in Connection due to 8136496
Reviewed-by: alanb

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

Changeset: 6a5c99506f44
Author:    lana
Date:      2015-11-05 13:42 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6a5c99506f44

Merge

- src/java.rmi/unix/bin/java-rmi.cgi.sh
- test/java/awt/datatransfer/DataFlavor/XJavaUrlDataFlavorTest/XJavaUrlDataFlavorTest.java

Changeset: 16fc042acee6
Author:    lana
Date:      2015-11-12 10:39 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/16fc042acee6

Added tag jdk9-b92 for changeset 6a5c99506f44

! .hgtags

Changeset: 950cdf782005
Author:    mchung
Date:      2015-11-13 19:20 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/950cdf782005

Merge

! .hgtags
! make/CompileDemos.gmk
- make/gendata/Gendata-jdk.jdeps.gmk
! make/gendata/GendataPolicyJars.gmk
- make/gensrc/Gensrc-jdk.dev.gmk
! make/launcher/Launcher-java.base.gmk
! make/launcher/Launcher-java.corba.gmk
! make/launcher/Launcher-java.desktop.gmk
! make/launcher/Launcher-java.rmi.gmk
! make/launcher/Launcher-java.scripting.gmk
! make/launcher/Launcher-java.security.jgss.gmk
! make/launcher/Launcher-jdk.compiler.gmk
- make/launcher/Launcher-jdk.dev.gmk
! make/launcher/Launcher-jdk.hotspot.agent.gmk
! make/launcher/Launcher-jdk.jartool.gmk
! make/launcher/Launcher-jdk.javadoc.gmk
! make/launcher/Launcher-jdk.jcmd.gmk
! make/launcher/Launcher-jdk.jconsole.gmk
! make/launcher/Launcher-jdk.jdeps.gmk
! make/launcher/Launcher-jdk.jdi.gmk
+ make/launcher/Launcher-jdk.jlink.gmk
! make/launcher/Launcher-jdk.jshell.gmk
! make/launcher/Launcher-jdk.jvmstat.gmk
! make/launcher/Launcher-jdk.pack200.gmk
! make/launcher/Launcher-jdk.policytool.gmk
! make/launcher/Launcher-jdk.rmic.gmk
! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk
! make/launcher/Launcher-jdk.xml.bind.gmk
! make/launcher/Launcher-jdk.xml.ws.gmk
! make/launcher/LauncherCommon.gmk
! make/lib/Awt2dLibraries.gmk
! make/lib/CoreLibraries.gmk
! make/lib/Lib-java.instrument.gmk
! make/lib/Lib-jdk.jdwp.agent.gmk
- make/scripts/localelist.sh
- make/src/classes/build/tools/module/GenJdepsModulesXml.java
- make/src/classes/build/tools/module/GenModulesList.java
- make/src/classes/build/tools/module/ImageBuilder.java
- make/src/classes/build/tools/module/ModuleArchive.java
- make/src/classes/build/tools/module/boot.modules
- make/src/classes/build/tools/module/ext.modules
- src/java.base/share/classes/jdk/internal/jimage/Archive.java
- src/java.base/share/classes/jdk/internal/jimage/BasicImageWriter.java
- src/java.base/share/classes/jdk/internal/jimage/ExternalFilesWriter.java
- src/java.base/share/classes/jdk/internal/jimage/ImageFileCreator.java
- src/java.base/share/classes/jdk/internal/jimage/ImageLocationWriter.java
- src/java.base/share/classes/jdk/internal/jimage/ImageModuleDataWriter.java
- src/java.base/share/classes/jdk/internal/jimage/ImageResourcesTree.java
- src/java.base/share/classes/jdk/internal/jimage/ImageStringsWriter.java
- src/java.base/share/classes/jdk/internal/jimage/PerfectHashBuilder.java
- src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java
- src/java.base/share/classes/jdk/internal/jimage/ResourcePoolImpl.java
- src/java.base/share/classes/sun/misc/Launcher.java
- src/java.base/share/classes/sun/util/CoreResourceBundleControl-XLocales.java.template
! src/java.base/share/native/launcher/defines.h
! src/java.base/share/native/launcher/main.c
- src/java.base/share/native/libjava/Package.c
- src/java.base/share/native/libjava/Proxy.c
! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp
! src/java.base/share/native/libjimage/jimage.cpp
! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
- src/java.desktop/share/classes/META-INF/services/java.net.ContentHandlerFactory
- src/java.desktop/share/classes/META-INF/services/javax.print.PrintServiceLookup
- src/java.desktop/share/classes/META-INF/services/javax.print.StreamPrintServiceFactory
- src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiDeviceProvider
- src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileReader
- src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileWriter
- src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.SoundbankReader
- src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileReader
- src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileWriter
- src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider
- src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.MixerProvider
- src/java.desktop/share/classes/META-INF/services/sun.datatransfer.DesktopDatatransferService
! src/java.desktop/share/classes/java/awt/Component.java
! src/java.desktop/share/classes/java/awt/Window.java
! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
- src/java.security.jgss/share/classes/META-INF/services/sun.security.ssl.ClientKeyExchangeService
- src/jdk.accessibility/windows/classes/META-INF/services/javax.accessibility.AccessibilityProvider
- src/jdk.attach/share/classes/META-INF/services/com.sun.tools.attach.spi.AttachProvider
- src/jdk.charsets/share/classes/META-INF/services/java.nio.charset.spi.CharsetProvider
- src/jdk.dev/share/classes/jdk/tools/jimage/ExtractedImage.java
- src/jdk.dev/share/classes/jdk/tools/jimage/JImageTask.java
- src/jdk.dev/share/classes/jdk/tools/jimage/Main.java
- src/jdk.dev/share/classes/jdk/tools/jimage/TaskHelper.java
- src/jdk.dev/share/classes/jdk/tools/jimage/resources/jimage.properties
- src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector
- src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.spi.TransportService
- src/jdk.jvmstat/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService
- src/jdk.localedata/share/classes/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo
- src/jdk.management/share/classes/META-INF/services/sun.management.spi.PlatformMBeanProvider
- src/jdk.naming.dns/share/classes/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor
- src/jdk.zipfs/share/classes/META-INF/services/java.nio.file.spi.FileSystemProvider
! test/TEST.groups
- test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh
- test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java/net/MyDatagramSocketImplFactory.java
! test/java/util/Locale/LocaleProviders.sh
! test/javax/management/mxbean/LeakTest.java
- test/jdk/internal/jimage/ExecutableTest.java
! test/jdk/internal/jimage/JImageReadTest.java
- test/jdk/internal/jimage/JImageTest.java
- test/jdk/internal/jimage/VerifyJimage.java
! test/sun/security/pkcs11/PKCS11Test.java


From mandy.chung at oracle.com  Sat Nov 14 04:23:50 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 14 Nov 2015 04:23:50 +0000
Subject: hg: jigsaw/jake/jaxws: 12 new changesets
Message-ID: <201511140423.tAE4NptV000049@aojmv0008.oracle.com>

Changeset: 136e8bcba562
Author:    lana
Date:      2015-10-19 00:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/136e8bcba562

Added tag jdk9-b87 for changeset f7dba191a38c

! .hgtags

Changeset: 3d533243505d
Author:    aefimov
Date:      2015-10-16 19:07 +0300
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/3d533243505d

8073519: schemagen does not report errors while generating xsd files
Reviewed-by: dfuchs

! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/SchemaGenerator.java

Changeset: f6425fec60ab
Author:    lana
Date:      2015-10-21 15:15 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/f6425fec60ab

Merge


Changeset: 2d84c6f4cbba
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2d84c6f4cbba

Added tag jdk9-b88 for changeset f6425fec60ab

! .hgtags

Changeset: b3e45213d574
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b3e45213d574

Added tag jdk9-b89 for changeset 2d84c6f4cbba

! .hgtags

Changeset: 3b2a3cb658e4
Author:    lana
Date:      2015-10-30 10:28 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/3b2a3cb658e4

Added tag jdk9-b90 for changeset b3e45213d574

! .hgtags

Changeset: 35b9769a8003
Author:    mchung
Date:      2015-11-12 11:30 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/35b9769a8003

Merge


Changeset: 59060592a8fc
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/59060592a8fc

Added tag jdk9-b91 for changeset 3b2a3cb658e4

! .hgtags

Changeset: 63c89fbee619
Author:    mkos
Date:      2015-10-30 10:34 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/63c89fbee619

8139743: Update JAX-WS RI integration to latest version (2.3.0-SNAPSHOT)
Reviewed-by: lancea

! src/java.xml.bind/share/classes/com/sun/istack/internal/logging/Logger.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/AccessorFactoryImpl.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/DatatypeConverterImpl.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/api/JAXBRIContext.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/DataWriter.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/NamespacePrefixMapper.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/XMLWriter.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ClassFactory.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ContextFactory.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/WellKnownNamespace.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/ElementInfo.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/ElementPropertyInfo.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/RegistryInfo.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/package-info.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/ClassInfoImpl.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/DummyPropertyInfo.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeClassInfo.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimePropertyInfo.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/package-info.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/AssociationMap.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/NamespaceContext2.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/RuntimeUtil.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/C14nXmlOutput.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/NamespaceContextImpl.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LocatorEx.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallingContext.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XmlVisitor.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/schemagen/Util.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/CleanUpExecutorFactory.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/DecodingException.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FactoryFinder.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FinalArrayList.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEConfig.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEMessage.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEParser.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/WeakDataFile.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/staxex/util/XMLStreamReaderToXMLStreamWriter.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/txw2/Document.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/txw2/output/ResultFactory.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/txw2/output/XMLWriter.java
! src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java
! src/java.xml.ws/share/classes/com/oracle/webservices/internal/api/message/MessageContextFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/MessagingException.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/BMMimeMultipart.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ContentDisposition.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ContentType.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/HeaderTokenizer.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/InternetHeaders.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeBodyPart.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeMultipart.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimePullMultipart.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeUtility.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ParameterList.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/UniqueValue.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/OutputUtil.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ContextClassloaderLocal.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxReaderBridge.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StringDataContentHandler.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/XmlDataContentHandler.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPMessageFactoryDynamicImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/EnvelopeImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/Base64.java
- src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/CharReader.java
- src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/CharWriter.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/FastInfosetReflection.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/FinalArrayList.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/JAXMStreamSource.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/JaxmURI.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/ParseUtil.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/XMLDeclarationParser.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriter.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriterEx.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/BindingIDFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/message/MessageContextFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/message/Packet.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/message/saaj/SAAJFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/FiberContextSwitchInterceptor.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/client/package-info.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/db/DatabindingImpl.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/package-info.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/privateutil/ServiceFinder.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/server/package-info.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/spi/db/BindingContext.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/spi/db/BindingContextFactory.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java
! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties
- src/java.xml.ws/share/classes/javax/xml/soap/package.html
! src/java.xml.ws/share/classes/javax/xml/ws/spi/FactoryFinder.java
! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JAnnotationUse.java
! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JClass.java
! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JExpr.java
! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JExpression.java
! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JJavaName.java
! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/package-info.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ConfigReader.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_de.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_es.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_it.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/SchemaGenerator.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/Const.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_de.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_es.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_fr.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_it.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ja.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ko.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_pt_BR.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_CN.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_TW.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_de.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_es.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_it.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/ModelLoader.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/Plugin.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/J2SJAXBModel.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/Mapping.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/S2JJAXBModel.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/SchemaCompiler.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/XJC.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/FilerCodeWriter.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_de.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_es.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_fr.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_it.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_ja.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_ko.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_pt_BR.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_zh_CN.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_zh_TW.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/package.html
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/CElementInfo.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/CEnumLeafInfo.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/nav/NavigatorImpl.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/package-info.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/package-info.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/Const.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIAttribute.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIConstructor.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIContent.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIConversion.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIElement.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIEnumeration.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIInterface.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIUserConversion.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BindInfo.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/AbstractReferenceFinderImpl.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/DOMBuilder.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/InternalizationLogic.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/Internalizer.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/relaxng/DatatypeLib.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGInternalizationLogic.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BGMBuilder.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/DefaultClassBinder.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/SimpleTypeBuilder.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIConversion.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIEnum.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIGlobalBinding.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIInlineBinaryData.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BISchemaBinding.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIXDom.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BindInfo.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/EnumMemberMode.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/CustomizationContextChecker.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/SchemaConstraintChecker.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/XMLSchemaInternalizationLogic.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/DTDEventListener.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/DTDParser.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/EntityDecl.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/InputEntity.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/MessageCatalog.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/Resolver.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/XmlChars.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/XmlReader.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/resources/Messages.properties
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/Datatype.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeBuilder.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeException.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeLibrary.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeLibraryFactory.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeStreamingValidator.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/ValidationContext.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/helpers/StreamingValidatorImpl.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/ast/builder/Grammar.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/ast/builder/GrammarSection.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/ast/builder/IncludedGrammar.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/ast/builder/SchemaBuilder.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/digested/DChoicePattern.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/digested/DDataPattern.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/digested/DGrammarPattern.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/nc/NameClass.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/XSSchema.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/XSTerm.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/state/NGCCRuntime.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/scd/Iterators.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/scd/ParseException.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/util/SchemaTreeTraverser.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/parser/AnnotationParser.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/parser/XSOMParser.java
! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/util/DomAnnotationParserFactory.java
! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/package-info.java
! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/version.properties
! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/Options.java

Changeset: fe772cbc64f4
Author:    lana
Date:      2015-11-05 13:43 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/fe772cbc64f4

Merge

- src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/CharReader.java
- src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/CharWriter.java
- src/java.xml.ws/share/classes/javax/xml/soap/package.html
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_de.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_es.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_it.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_de.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_es.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_fr.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_it.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ja.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ko.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_pt_BR.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_CN.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_TW.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/FilerCodeWriter.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages.java
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_de.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_es.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_fr.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_it.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_ja.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_ko.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_pt_BR.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_zh_CN.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_zh_TW.properties
- src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/package.html

Changeset: 5e94fbbb7032
Author:    lana
Date:      2015-11-12 10:39 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/5e94fbbb7032

Added tag jdk9-b92 for changeset fe772cbc64f4

! .hgtags

Changeset: fa025bbc0479
Author:    mchung
Date:      2015-11-13 19:20 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/fa025bbc0479

Merge

! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ClassFactory.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/ClassInfoImpl.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java
! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FactoryFinder.java
! src/java.xml.ws/share/classes/javax/xml/ws/spi/FactoryFinder.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ConfigReader.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BindInfo.java
! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BindInfo.java


From mandy.chung at oracle.com  Sat Nov 14 04:24:43 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 14 Nov 2015 04:24:43 +0000
Subject: hg: jigsaw/jake/corba: 13 new changesets
Message-ID: <201511140424.tAE4OhrR000263@aojmv0008.oracle.com>

Changeset: 00f48ecbc099
Author:    lana
Date:      2015-10-19 00:24 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/00f48ecbc099

Added tag jdk9-b87 for changeset a5c40ac9b916

! .hgtags

Changeset: 98075de2b055
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/98075de2b055

Added tag jdk9-b88 for changeset 00f48ecbc099

! .hgtags

Changeset: e2c563af9ef4
Author:    msheppar
Date:      2015-06-25 13:48 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/e2c563af9ef4

8076383: Better CORBA exception handling
Reviewed-by: rriggs, coffeys, skoivu, ahgross

! src/jdk.rmic/share/classes/sun/rmi/rmic/iiop/StubGenerator.java

Changeset: dc8238c2c66a
Author:    msheppar
Date:      2015-07-14 16:49 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/dc8238c2c66a

8076392: Improve IIOPInputStream consistency
Reviewed-by: rriggs, coffeys, skoivu, ahgross

! src/java.corba/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java

Changeset: a88d571b42b6
Author:    msheppar
Date:      2015-07-14 18:03 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/a88d571b42b6

8076387: Better CORBA value handling
Reviewed-by: rriggs, coffeys, skoivu, ahgross

! src/java.corba/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java
! src/java.corba/share/classes/com/sun/corba/se/impl/io/IIOPOutputStream.java

Changeset: ab90c50a6a13
Author:    lana
Date:      2015-10-21 18:38 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/ab90c50a6a13

Merge


Changeset: c847a53b38d2
Author:    lana
Date:      2015-10-22 11:12 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/c847a53b38d2

Merge


Changeset: 29cc8228d623
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/29cc8228d623

Added tag jdk9-b89 for changeset c847a53b38d2

! .hgtags

Changeset: 75843e0a9371
Author:    lana
Date:      2015-10-30 10:28 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/75843e0a9371

Added tag jdk9-b90 for changeset 29cc8228d623

! .hgtags

Changeset: e9dd95120409
Author:    mchung
Date:      2015-11-12 11:30 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/e9dd95120409

Merge

! src/java.corba/share/classes/com/sun/corba/se/impl/io/IIOPOutputStream.java

Changeset: f7d70caad89a
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/f7d70caad89a

Added tag jdk9-b91 for changeset 75843e0a9371

! .hgtags

Changeset: f82629452836
Author:    lana
Date:      2015-11-12 10:38 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/f82629452836

Added tag jdk9-b92 for changeset f7d70caad89a

! .hgtags

Changeset: 86606630eb99
Author:    mchung
Date:      2015-11-13 19:20 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/86606630eb99

Merge



From mandy.chung at oracle.com  Sat Nov 14 04:24:55 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 14 Nov 2015 04:24:55 +0000
Subject: hg: jigsaw/jake/langtools: 39 new changesets
Message-ID: <201511140424.tAE4OtV4000289@aojmv0008.oracle.com>

Changeset: 288f18dd9157
Author:    lana
Date:      2015-10-19 00:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/288f18dd9157

Added tag jdk9-b87 for changeset 45f796d8cdcd

! .hgtags

Changeset: 79e637c1e083
Author:    mcimadamore
Date:      2015-10-12 12:24 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/79e637c1e083

8138840: NPE when compiling bitwise operations with illegal operand types
8139243: compiler crashes with exception on sum operation of String var and void method call result
8139249: Compiler crashes on unary bitwise complement with non-integral operand
Summary: Certain binary operator checks are accepting more operands than required.
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Operators.java
+ test/tools/javac/8138840/T8138840.java
+ test/tools/javac/8138840/T8138840.out
+ test/tools/javac/8138840/T8139243.java
+ test/tools/javac/8138840/T8139243.out
+ test/tools/javac/8138840/T8139249.java
+ test/tools/javac/8138840/T8139249.out

Changeset: 700677b16a97
Author:    sadayapalam
Date:      2015-10-12 19:43 +0530
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/700677b16a97

8139245: compiler crashes with exception on int:new method reference and generic method inference
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/lambda/methodReference/MethodRefIntColonColonNewTest.java
+ test/tools/javac/lambda/methodReference/MethodRefIntColonColonNewTest.out

Changeset: 814a0cab8c90
Author:    sadayapalam
Date:      2015-10-13 09:48 +0530
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/814a0cab8c90

8000316: Huge performance bottleneck in com.sun.tools.javac.comp.Check.localClassName
Summary: Speed up Check.localClassName by avoiding generating names known to be in use already
Reviewed-by: mcimadamore, jlahoda, sadayapalam
Contributed-by: dmitry.chuyko at oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
+ test/tools/javac/T8000316/T8000316.java

Changeset: 575ea88f69a5
Author:    chegar
Date:      2015-10-13 09:02 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/575ea88f69a5

8139371: Three langtools test failures after the removal of sun.misc.Lock
Reviewed-by: jjg, mchung

! test/tools/javac/proprietary/WarnClass.java
! test/tools/javac/proprietary/WarnClass.out
! test/tools/javac/warnings/6594914/T6594914b.java
! test/tools/javac/warnings/6594914/T6594914b.out
! test/tools/jdeps/APIDeps.java
! test/tools/jdeps/m/Gee.java

Changeset: 126e5c6abd1d
Author:    lana
Date:      2015-10-15 16:50 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/126e5c6abd1d

Merge


Changeset: ac57d80b205d
Author:    lana
Date:      2015-10-21 15:15 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ac57d80b205d

Merge


Changeset: 4789df418bc3
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4789df418bc3

Added tag jdk9-b88 for changeset ac57d80b205d

! .hgtags

Changeset: 23f76aadbb36
Author:    ksrini
Date:      2015-09-11 16:34 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/23f76aadbb36

8078320: Improve DocTrees parsing.
Reviewed-by: jjg, jlahoda

! src/jdk.compiler/share/classes/com/sun/source/doctree/DocCommentTree.java
! src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java
! src/jdk.compiler/share/classes/com/sun/tools/doclint/HtmlTag.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java
! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java
! test/tools/javac/doctree/DocCommentTester.java
! test/tools/javac/doctree/ElementTest.java
! test/tools/javac/doctree/FirstSentenceTest.java
+ test/tools/javac/doctree/InPreTest.java
! test/tools/javac/doctree/TagTest.java

Changeset: 777c5a760a84
Author:    jlahoda
Date:      2015-10-19 12:41 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/777c5a760a84

8139751: Javac crash with -XDallowStringFolding=false
Summary: When string folding is disabled, need to keep the original expression.
Reviewed-by: mcimadamore

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

Changeset: 15bdc18525ff
Author:    jlahoda
Date:      2015-10-19 19:15 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/15bdc18525ff

8134254: JShell API/tool: REPL for Java into JDK9
Summary: Adding the implementation of the jshell (read-eval-print-loop) tool.
Reviewed-by: briangoetz, mcimadamore, psandoz, forax
Contributed-by: robert.field at oracle.com, bitterfoxc at gmail.com, jan.lahoda at oracle.com

! make/build.properties
! make/build.xml
+ make/gensrc/Gensrc-jdk.jshell.gmk
! make/intellij/langtools.iml
! make/intellij/workspace.xml
! make/launcher.sh-template
! make/netbeans/langtools/build.xml
! make/netbeans/langtools/nbproject/project.xml
+ make/tools/anttasks/DumpClassesTask.java
! make/tools/anttasks/SelectToolTask.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/debug/InternalDebugControl.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteAgent.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteClassLoader.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteCodes.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteResolutionException.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/EditPad.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/EditingHistory.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ExternalEditor.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/IOContext.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/version.properties-template
+ src/jdk.jshell/share/classes/jdk/jshell/ClassTracker.java
+ src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java
+ src/jdk.jshell/share/classes/jdk/jshell/DeclarationSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/Diag.java
+ src/jdk.jshell/share/classes/jdk/jshell/DiagList.java
+ src/jdk.jshell/share/classes/jdk/jshell/ErroneousSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/Eval.java
+ src/jdk.jshell/share/classes/jdk/jshell/EvalException.java
+ src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.java
+ src/jdk.jshell/share/classes/jdk/jshell/ExpressionSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/GeneralWrap.java
+ src/jdk.jshell/share/classes/jdk/jshell/ImportSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/JDIConnection.java
+ src/jdk.jshell/share/classes/jdk/jshell/JDIEnv.java
+ src/jdk.jshell/share/classes/jdk/jshell/JDIEventHandler.java
+ src/jdk.jshell/share/classes/jdk/jshell/JDINotConnectedException.java
+ src/jdk.jshell/share/classes/jdk/jshell/JShell.java
+ src/jdk.jshell/share/classes/jdk/jshell/Key.java
+ src/jdk.jshell/share/classes/jdk/jshell/KeyMap.java
+ src/jdk.jshell/share/classes/jdk/jshell/MaskCommentsAndModifiers.java
+ src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java
+ src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/OuterWrap.java
+ src/jdk.jshell/share/classes/jdk/jshell/PersistentSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/ReplParser.java
+ src/jdk.jshell/share/classes/jdk/jshell/ReplParserFactory.java
+ src/jdk.jshell/share/classes/jdk/jshell/ReplResolve.java
+ src/jdk.jshell/share/classes/jdk/jshell/Snippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/SnippetEvent.java
+ src/jdk.jshell/share/classes/jdk/jshell/SnippetMaps.java
+ src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java
+ src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
+ src/jdk.jshell/share/classes/jdk/jshell/StatementSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java
+ src/jdk.jshell/share/classes/jdk/jshell/TreeDependencyScanner.java
+ src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java
+ src/jdk.jshell/share/classes/jdk/jshell/TypeDeclSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/TypePrinter.java
+ src/jdk.jshell/share/classes/jdk/jshell/Unit.java
+ src/jdk.jshell/share/classes/jdk/jshell/UnresolvedReferenceException.java
+ src/jdk.jshell/share/classes/jdk/jshell/Util.java
+ src/jdk.jshell/share/classes/jdk/jshell/VarSnippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/Wrap.java
+ src/jdk.jshell/share/classes/jdk/jshell/package-info.java
+ test/jdk/jshell/AnalysisTest.java
+ test/jdk/jshell/ClassMembersTest.java
+ test/jdk/jshell/ClassPathTest.java
+ test/jdk/jshell/ClassesTest.java
+ test/jdk/jshell/CommandCompletionTest.java
+ test/jdk/jshell/Compiler.java
+ test/jdk/jshell/CompletenessStressTest.java
+ test/jdk/jshell/CompletenessTest.java
+ test/jdk/jshell/CompletionSuggestionTest.java
+ test/jdk/jshell/CustomEditor.java
+ test/jdk/jshell/DropTest.java
+ test/jdk/jshell/EditorPadTest.java
+ test/jdk/jshell/EditorTestBase.java
+ test/jdk/jshell/EmptyTest.java
+ test/jdk/jshell/ErrorTranslationTest.java
+ test/jdk/jshell/ExceptionsTest.java
+ test/jdk/jshell/ExpectedDiagnostic.java
+ test/jdk/jshell/ExternalEditorTest.java
+ test/jdk/jshell/HistoryTest.java
+ test/jdk/jshell/IOTest.java
+ test/jdk/jshell/IdGeneratorTest.java
+ test/jdk/jshell/IgnoreTest.java
+ test/jdk/jshell/IllegalArgumentExceptionTest.java
+ test/jdk/jshell/ImportTest.java
+ test/jdk/jshell/JShellStateClosedTest.java
+ test/jdk/jshell/KullaCompletenessStressTest.java
+ test/jdk/jshell/KullaTesting.java
+ test/jdk/jshell/MethodsTest.java
+ test/jdk/jshell/ModifiersTest.java
+ test/jdk/jshell/NullTest.java
+ test/jdk/jshell/RejectedFailedTest.java
+ test/jdk/jshell/ReplToolTesting.java
+ test/jdk/jshell/ReplaceTest.java
+ test/jdk/jshell/ShutdownTest.java
+ test/jdk/jshell/SimpleRegressionTest.java
+ test/jdk/jshell/SnippetStatusListenerTest.java
+ test/jdk/jshell/SnippetTest.java
+ test/jdk/jshell/StartOptionTest.java
+ test/jdk/jshell/StopExecutionTest.java
+ test/jdk/jshell/TestingInputStream.java
+ test/jdk/jshell/ToolBasicTest.java
+ test/jdk/jshell/TypeNameTest.java
+ test/jdk/jshell/VariablesTest.java

Changeset: 161940723360
Author:    sadayapalam
Date:      2015-10-20 15:25 +0530
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/161940723360

8139836: Can't use super::x method reference when x is protected
Summary: Javac incorrectly diasllows reference to a protected method from a super class in method reference expressions.
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/lambda/MethodReference74.java
+ test/tools/javac/lambda/pkg/Parent.java

Changeset: 0cce85265987
Author:    sadayapalam
Date:      2015-10-21 17:52 +0530
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0cce85265987

8138729: javac -parameters should not emit parameter names for lambda expressions
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! test/tools/javac/MethodParameters/ClassFileVisitor.java
! test/tools/javac/MethodParameters/LambdaTest.java
! test/tools/javac/MethodParameters/LambdaTest.out
! test/tools/javac/MethodParameters/ReflectionVisitor.java

Changeset: 96a99cfb21be
Author:    lana
Date:      2015-10-21 18:40 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/96a99cfb21be

Merge


Changeset: 820841f0e8bd
Author:    alundblad
Date:      2015-10-22 09:05 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/820841f0e8bd

8087349: Test tools/sjavac/IncCompInheritance.java is failing
Summary: Refactoring of Dependencies framework.
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Dependencies.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/dependencies/NewDependencyCollector.java
! test/tools/javac/importscope/dependencies/DependenciesTest.java

Changeset: 4b374a9b4b22
Author:    sadayapalam
Date:      2015-10-22 16:18 +0530
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4b374a9b4b22

8074803: Name clash
Summary: Javac incorrectly reports a name clash.
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/NameClash/NameClashTest.java

Changeset: 86e463879ae7
Author:    mcimadamore
Date:      2015-10-22 18:58 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/86e463879ae7

8140333: Tweak langtools IntelliJ project to better support Kulla changes
Summary: Add support for target.java.home option to the idea target
Reviewed-by: jlahoda

! make/build.xml
! make/intellij/ant.xml
! make/intellij/workspace.xml

Changeset: b3f440e93b97
Author:    lana
Date:      2015-10-22 11:12 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b3f440e93b97

Merge


Changeset: b3ed4ac7cd91
Author:    sadayapalam
Date:      2015-10-23 08:21 +0530
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b3ed4ac7cd91

8057685: javac should not crash compiling type annotations
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java
! test/tools/javac/annotations/typeAnnotations/newlocations/AllLocations.java

Changeset: 16873e56156e
Author:    aeriksso
Date:      2015-10-27 10:35 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/16873e56156e

8134759: jdb: Incorrect stepping inside finally block
Summary: Add LineNumberTable attribute for return bytecodes split around finally code
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/linenumbers/FinallyLineNumberTest.java

Changeset: 00a25f93cee8
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/00a25f93cee8

Added tag jdk9-b89 for changeset 16873e56156e

! .hgtags

Changeset: 49da3649b796
Author:    lana
Date:      2015-10-30 10:29 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/49da3649b796

Added tag jdk9-b90 for changeset 00a25f93cee8

! .hgtags

Changeset: 522e516b8a83
Author:    ksrini
Date:      2015-10-28 10:41 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/522e516b8a83

8132096: Augment the Compiler Tree API to support the new Simplified Doclet API
Reviewed-by: jjg, jlahoda

! src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java
! test/tools/javac/doctree/DocCommentTester.java
! test/tools/javac/doctree/FirstSentenceTest.java
+ test/tools/javac/doctree/dcapi/DocCommentTreeApiTester.java
+ test/tools/javac/doctree/dcapi/OverviewTest.java
+ test/tools/javac/doctree/dcapi/overview0.html
+ test/tools/javac/doctree/dcapi/overview1.html
+ test/tools/javac/doctree/dcapi/overview2.html
+ test/tools/javac/doctree/dcapi/overview3.html
+ test/tools/javac/doctree/dcapi/overview4.html
+ test/tools/javac/doctree/dcapi/overview5.html
+ test/tools/javac/doctree/dcapi/overview6.html
+ test/tools/javac/doctree/dcapi/package.html
+ test/tools/javac/doctree/dcapi/pkg/Anchor.java
+ test/tools/javac/doctree/dcapi/pkg/package.html
! test/tools/javac/tree/NoPrivateTypesExported.java

Changeset: b278abcd113b
Author:    lana
Date:      2015-10-29 12:40 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b278abcd113b

Merge


Changeset: 79501a97ca57
Author:    lana
Date:      2015-11-04 13:46 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/79501a97ca57

Merge


Changeset: 1669922f641d
Author:    mchung
Date:      2015-11-12 11:30 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1669922f641d

Merge

! .hgtags
! make/build.properties
! make/build.xml
! make/launcher.sh-template
! make/netbeans/langtools/build.xml
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
- src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java
- src/jdk.compiler/share/classes/com/sun/tools/javac/sym/Profiles.java
- src/jdk.compiler/share/classes/com/sun/tools/javac/util/ServiceLoader.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java
- src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulesXmlReader.java
- src/jdk.jdeps/share/classes/com/sun/tools/jdeps/PlatformClassPath.java
- test/tools/javac/T6873845.java
- test/tools/javac/profiles/ProfileTest.java
- test/tools/javac/proprietary/WarnClass.java
- test/tools/javac/proprietary/WarnClass.out
- 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
- test/tools/javac/proprietary/WarnVariable.java
- test/tools/javac/proprietary/WarnVariable.out
- test/tools/javac/proprietary/WarnWildcard.java
- test/tools/javac/proprietary/WarnWildcard.out
! test/tools/jdeps/APIDeps.java
- test/tools/jdeps/VerboseFormat/use/indirect/DontUseUnsafe2.java
- test/tools/jdeps/VerboseFormat/use/indirect/UseUnsafeIndirectly.java
- test/tools/jdeps/VerboseFormat/use/indirect2/DontUseUnsafe3.java
- test/tools/jdeps/VerboseFormat/use/indirect2/UseUnsafeIndirectly2.java
- test/tools/jdeps/VerboseFormat/use/unsafe/DontUseUnsafe.java
- test/tools/jdeps/VerboseFormat/use/unsafe/UseClassWithUnsafe.java
- test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass.java
- test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass2.java
- test/tools/jdeps/javax/activity/NotCompactProfile.java
! test/tools/jdeps/m/Gee.java

Changeset: f6fd3e9f6bc9
Author:    mchung
Date:      2015-11-12 20:36 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f6fd3e9f6bc9

Merge

! src/jdk.compiler/share/classes/module-info.java
+ src/jdk.jshell/share/classes/module-info.java

Changeset: 9adfacce560e
Author:    mchung
Date:      2015-11-12 20:50 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9adfacce560e

Merge


Changeset: ab33a84365a0
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ab33a84365a0

Added tag jdk9-b91 for changeset 79501a97ca57

! .hgtags

Changeset: 03bb9c99b573
Author:    jlahoda
Date:      2015-10-30 17:00 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/03bb9c99b573

8140766: langtools/make/test/sym/CreateSymbolsTest.java contains incorrect paths
Summary: Fixing paths in CreateSymbolsTest; fixing imports in CreateSymbolsTestImpl.
Reviewed-by: mcimadamore

! make/test/sym/CreateSymbolsTest.java
! make/test/sym/CreateSymbolsTestImpl.java

Changeset: 19e44405ab4f
Author:    ihse
Date:      2015-11-03 17:54 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/19e44405ab4f

8141333: Rename SetupArchive to SetupJarArchive
Reviewed-by: erikj, tbell

! make/gendata/Gendata-jdk.compiler.gmk

Changeset: 155f6671cab4
Author:    alundblad
Date:      2015-11-03 21:29 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/155f6671cab4

8137075: Sjavac tests are leaking file managers
Summary: Closing sjavac file managers.
Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/sjavac/JavacState.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/PubApiExtractor.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java
! test/tools/sjavac/ApiExtraction.java

Changeset: a32f899caa49
Author:    alundblad
Date:      2015-11-03 22:55 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a32f899caa49

8141355: PackagePathMismatch.java does not use --state-dir option
Summary: Added --state-dir to the PackagePathMismatch.java test.
Reviewed-by: jlahoda

! test/tools/sjavac/PackagePathMismatch.java

Changeset: 17d15aa9140d
Author:    alundblad
Date:      2015-11-04 12:27 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/17d15aa9140d

8139961: Various sjavac tests result in error on Windows (JPRT)
Summary: Test now closes Stream properly.
Reviewed-by: jlahoda

! test/tools/sjavac/NoState.java

Changeset: 3298cbc00d2f
Author:    mcimadamore
Date:      2015-11-05 11:32 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3298cbc00d2f

8141343: Subtle semantics changes for union types in cast conversion
Summary: cast applied to union types do not behave correctly and sometimes pass erroneously
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/8141343/T8141343.java
+ test/tools/javac/cast/8141343/T8141343.out

Changeset: a3415b57507c
Author:    lana
Date:      2015-11-05 13:42 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a3415b57507c

Merge


Changeset: 5245927b10eb
Author:    lana
Date:      2015-11-12 10:39 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5245927b10eb

Added tag jdk9-b92 for changeset a3415b57507c

! .hgtags

Changeset: e9ebd8cea634
Author:    mchung
Date:      2015-11-13 19:20 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e9ebd8cea634

Merge

! .hgtags
! make/gendata/Gendata-jdk.compiler.gmk
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
- src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java
- src/jdk.compiler/share/classes/com/sun/tools/javac/sym/Profiles.java
- src/jdk.compiler/share/classes/com/sun/tools/javac/util/ServiceLoader.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/PubApiExtractor.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java
- src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java
- src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulesXmlReader.java
- src/jdk.jdeps/share/classes/com/sun/tools/jdeps/PlatformClassPath.java
- test/tools/javac/T6873845.java
- test/tools/javac/profiles/ProfileTest.java
- test/tools/javac/proprietary/WarnClass.java
- test/tools/javac/proprietary/WarnClass.out
- 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
- test/tools/javac/proprietary/WarnVariable.java
- test/tools/javac/proprietary/WarnVariable.out
- test/tools/javac/proprietary/WarnWildcard.java
- test/tools/javac/proprietary/WarnWildcard.out
- test/tools/jdeps/VerboseFormat/use/indirect/DontUseUnsafe2.java
- test/tools/jdeps/VerboseFormat/use/indirect/UseUnsafeIndirectly.java
- test/tools/jdeps/VerboseFormat/use/indirect2/DontUseUnsafe3.java
- test/tools/jdeps/VerboseFormat/use/indirect2/UseUnsafeIndirectly2.java
- test/tools/jdeps/VerboseFormat/use/unsafe/DontUseUnsafe.java
- test/tools/jdeps/VerboseFormat/use/unsafe/UseClassWithUnsafe.java
- test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass.java
- test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass2.java
- test/tools/jdeps/javax/activity/NotCompactProfile.java

Changeset: 1bace0d78e0a
Author:    mchung
Date:      2015-11-13 20:20 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1bace0d78e0a

Merge

- test/tools/javac/Object1.java
- test/tools/javac/Object1.out
- test/tools/javac/Object2.java
- test/tools/javac/Object2.out


From mandy.chung at oracle.com  Sat Nov 14 04:25:25 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 14 Nov 2015 04:25:25 +0000
Subject: hg: jigsaw/jake/nashorn: 43 new changesets
Message-ID: <201511140425.tAE4PPHL000418@aojmv0008.oracle.com>

Changeset: 061682b25ca9
Author:    lana
Date:      2015-10-19 00:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/061682b25ca9

Added tag jdk9-b87 for changeset 0bf2fe0c7b32

! .hgtags

Changeset: 0cae16c0043d
Author:    attila
Date:      2015-10-12 10:27 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0cae16c0043d

8139273: Small improvements to DynamicLinker and DynamicLinkerFactory
Reviewed-by: lagergren, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java

Changeset: 494bc9750691
Author:    attila
Date:      2015-10-12 10:28 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/494bc9750691

8139274: Use JDK 8 default method for LinkerServices.asTypeLosslessReturn
Reviewed-by: lagergren, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java

Changeset: 6c6df82265f0
Author:    mhaupt
Date:      2015-10-12 13:36 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/6c6df82265f0

8139266: add JSAdapter example with fallthrough
Reviewed-by: attila, hannesw

+ samples/jsadapter-fallthrough.js

Changeset: 0a640d17732d
Author:    attila
Date:      2015-10-12 13:44 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0a640d17732d

8139270: Drastically reduce memory footprint of ChainedCallSite
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java

Changeset: 022f7146248d
Author:    attila
Date:      2015-10-12 14:52 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/022f7146248d

8139282: Remove @author and @id tags from Dynalink JavaDoc; some minor edits
Reviewed-by: mhaupt, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/NoSuchDynamicMethodException.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/RelinkableCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AccessibleMembersLookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeanLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/GuardedInvocationComponent.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/MaximallySpecific.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SimpleDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/ConversionComparator.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassMap.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkRequestImpl.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeUtilities.java

Changeset: 781e7d23a367
Author:    lana
Date:      2015-10-15 16:50 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/781e7d23a367

Merge


Changeset: a2aa804daac9
Author:    lana
Date:      2015-10-21 15:15 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a2aa804daac9

Merge


Changeset: 40bda1a456b9
Author:    lana
Date:      2015-10-22 08:47 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/40bda1a456b9

Added tag jdk9-b88 for changeset a2aa804daac9

! .hgtags

Changeset: 04ed602df062
Author:    attila
Date:      2015-10-19 08:23 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/04ed602df062

8139304: Remove elaborate call site descriptor class hierarchy and factory for them. Remove AutoDiscovery, DefaultPrelinkFilter, and BottomGuardingDynamicLinker as they can be inlined into DynamicLinkerFactory. Remove CallerSensitiveDetector as it can be inlined into AbstractJavaLinker. Make ClassMap non-public.
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassLoaderGetterContextProvider.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/LinkerServicesImpl.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDetector.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethodLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AutoDiscovery.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassMap.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultPrelinkFilter.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeConverterFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java

Changeset: 33f2143b60a3
Author:    attila
Date:      2015-10-19 08:30 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/33f2143b60a3

8139435: Make sure CallSiteDescriptor.getLookup is subject to a security check
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/LinkerServicesImpl.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SimpleDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java

Changeset: 7dd80d7f47c3
Author:    attila
Date:      2015-10-19 08:39 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7dd80d7f47c3

8139588: Remove concept of runtime context arguments, call site tokens, and link counts
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkRequestImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleLinkRequest.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java

Changeset: 335632718c1e
Author:    attila
Date:      2015-10-19 08:45 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/335632718c1e

8139590: Improve Dynalink JavaDoc
Reviewed-by: hannesw, lagergren

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/RelinkableCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClass.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/ConversionComparator.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/MethodHandleTransformer.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/MethodTypeConversionStrategy.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package.html
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultInternalObjectFilter.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleLinkRequest.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/package-info.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/package.html

Changeset: f93753325c7b
Author:    sundar
Date:      2015-10-19 15:49 +0530
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f93753325c7b

8139852: jjs interactive mode fails to work with security manager
Reviewed-by: attila, hannesw

! src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/PackagesHelper.java

Changeset: 1faacf3cd85f
Author:    attila
Date:      2015-10-19 18:24 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/1faacf3cd85f

8139756: Eliminate GuardedTypeConversion, DynamicLinker.getCurrentLinkRequest and its associated permission
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/LinkerServicesImpl.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java

Changeset: 17b58e15ad54
Author:    attila
Date:      2015-10-19 22:36 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/17b58e15ad54

8139884: Use privileged blocks when working with class loaders
Reviewed-by: hannesw, mhaupt, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java

Changeset: dd36e980905b
Author:    attila
Date:      2015-10-20 23:33 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/dd36e980905b

8139761: Improve Dynalink class nomenclature and package organization
Reviewed-by: hannesw, sundar

- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/RelinkableCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeanLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethodLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/MaximallySpecific.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocationTransformer.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/CompositeGuardingDynamicLinker.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/CompositeTypeBasedGuardingDynamicLinker.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/DefaultInternalObjectFilter.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Guards.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Lookup.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/SimpleLinkRequest.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/TypeUtilities.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ChainedCallSite.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultInternalObjectFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleLinkRequest.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleRelinkableCallSite.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeUtilities.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeFunction.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJava.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NativeJavaPackage.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/OptimisticReturnFilters.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BoundCallableLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java

Changeset: a8d5f14eebcc
Author:    attila
Date:      2015-10-20 23:33 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a8d5f14eebcc

8139887: Reduce visibility of few methods in TypeUtilities and Guards API
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/internal/InternalTypeUtilities.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Guards.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/TypeUtilities.java

Changeset: c3a5e415a09f
Author:    attila
Date:      2015-10-20 23:34 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c3a5e415a09f

8139888: Improve Dynalink JavaDoc some more
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClass.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/package-info.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/package.html
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocationTransformer.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/MethodHandleTransformer.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/MethodTypeConversionStrategy.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/package-info.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/package.html
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/CompositeTypeBasedGuardingDynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/DefaultInternalObjectFilter.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Guards.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Lookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/SimpleLinkRequest.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/package-info.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java

Changeset: 490cafd88488
Author:    attila
Date:      2015-10-20 23:34 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/490cafd88488

8139895: Introduce GuardingDynamicLinkerExporter
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinkerExporter.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java

Changeset: e6bb9489faac
Author:    attila
Date:      2015-10-21 10:41 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e6bb9489faac

8139905: Add a convenience AccessControlContext factory
Reviewed-by: hannesw, sundar

- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassLoaderGetterContextProvider.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CheckRestrictedPackage.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/internal/AccessControlContextFactory.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessControlContextFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java

Changeset: d35aa8beb997
Author:    attila
Date:      2015-10-21 10:42 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/d35aa8beb997

8139919: Make CallSiteDescriptor a concrete class
Reviewed-by: hannesw, lagergren, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java

Changeset: 7cb19fa78763
Author:    attila
Date:      2015-10-21 19:33 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7cb19fa78763

8139931: Introduce Operation objects in Dynalink instead of string encoding
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CompositeOperation.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/NamedOperation.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/Operation.java
+ src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/StandardOperation.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeanLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethodLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClass.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionCall.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornTextifier.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSAdapter.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSON.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJavaImporter.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeString.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ListAdapter.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NativeJavaPackage.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SetMethodCreator.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ArrayData.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BoundCallableLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/InvokeByName.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java

Changeset: b640f10ccd6d
Author:    lana
Date:      2015-10-21 18:39 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b640f10ccd6d

Merge

- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDetector.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/package.html
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/package.html
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package.html
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AutoDiscovery.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassMap.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultInternalObjectFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultPrelinkFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkRequestImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeConverterFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeUtilities.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/package.html

Changeset: 77d303d8a943
Author:    attila
Date:      2015-10-22 10:43 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/77d303d8a943

8140273: restore use of CompositeOperation.contains where it is needed
Reviewed-by: hannesw, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CompositeOperation.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java

Changeset: 62641244c378
Author:    lana
Date:      2015-10-22 11:12 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/62641244c378

Merge

- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDetector.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/package.html
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/package.html
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package.html
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AutoDiscovery.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassMap.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultInternalObjectFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultPrelinkFilter.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkRequestImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeConverterFactory.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeUtilities.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java
- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/package.html

Changeset: bc92163c4e0a
Author:    lana
Date:      2015-10-29 08:42 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/bc92163c4e0a

Added tag jdk9-b89 for changeset 62641244c378

! .hgtags

Changeset: f570370bc7b8
Author:    lana
Date:      2015-10-30 10:29 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f570370bc7b8

Added tag jdk9-b90 for changeset bc92163c4e0a

! .hgtags

Changeset: 6d9a3ef84ebf
Author:    mhaupt
Date:      2015-10-28 10:54 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/6d9a3ef84ebf

8134941: Implement ES6 template literal support
Reviewed-by: attila, hannesw
Contributed-by: andreas.woess at oracle.com

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Lexer.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Token.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/TokenType.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Messages.properties

Changeset: 1ceda730b9a3
Author:    mhaupt
Date:      2015-10-29 11:37 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/1ceda730b9a3

8140759: add ES6 template literal test
Reviewed-by: hannesw, sundar
Contributed-by: andreas.woess at oracle.com

+ test/script/basic/es6/template-literals.js
+ test/script/basic/es6/template-literals.js.EXPECTED

Changeset: f414ae010340
Author:    lana
Date:      2015-10-29 12:39 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f414ae010340

Merge


Changeset: fee4d2015e24
Author:    lana
Date:      2015-11-04 13:46 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/fee4d2015e24

Merge


Changeset: e7a3b9f01ae4
Author:    mchung
Date:      2015-11-12 11:30 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e7a3b9f01ae4

Merge

! .hgtags
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CheckRestrictedPackage.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Guards.java
! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Lookup.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java

Changeset: 09f1d75775ef
Author:    lana
Date:      2015-11-05 08:15 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/09f1d75775ef

Added tag jdk9-b91 for changeset fee4d2015e24

! .hgtags

Changeset: c7ef0fb26eff
Author:    attila
Date:      2015-11-02 18:26 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c7ef0fb26eff

8141144: Move NameCodec to jdk.nashorn.internal space
Reviewed-by: hannesw, sundar

- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Compiler.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornTextifier.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java
+ src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NameCodec.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java

Changeset: ae3c6d8c1fc4
Author:    sundar
Date:      2015-11-03 21:08 +0530
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ae3c6d8c1fc4

8141285: NameCode should pass tests from BytecodeNameTest.java
Reviewed-by: attila, mhaupt

+ samples/find_underscores.js
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NameCodec.java
+ test/src/jdk/nashorn/internal/runtime/linker/test/NameCodecTest.java

Changeset: 1d7341033121
Author:    ihse
Date:      2015-11-03 17:54 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/1d7341033121

8141333: Rename SetupArchive to SetupJarArchive
Reviewed-by: erikj, tbell

! make/BuildNashorn.gmk

Changeset: cc95f96b51d8
Author:    attila
Date:      2015-11-05 12:13 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/cc95f96b51d8

8141425: Improve caching in NashornCallSiteDescriptor
Reviewed-by: hannesw, lagergren

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java

Changeset: a8b20725bcf2
Author:    attila
Date:      2015-11-05 12:15 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a8b20725bcf2

8141524: CompilerTest execution time dominated by Field.setAccessible
Reviewed-by: hannesw, mhaupt, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ASTWriter.java

Changeset: 0c621f5166c5
Author:    attila
Date:      2015-11-05 15:02 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0c621f5166c5

8141446: Cache Class.forName for permanently loaded classes
Reviewed-by: hannesw, mhaupt, sundar

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/Type.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java

Changeset: 34b77a618e98
Author:    lana
Date:      2015-11-05 13:42 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/34b77a618e98

Merge

- src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java

Changeset: 435d7217b35d
Author:    lana
Date:      2015-11-12 10:39 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/435d7217b35d

Added tag jdk9-b92 for changeset 34b77a618e98

! .hgtags

Changeset: 6b4d91e1593d
Author:    mchung
Date:      2015-11-13 19:20 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/6b4d91e1593d

Merge

! .hgtags
! make/BuildNashorn.gmk
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java


From mandy.chung at oracle.com  Sat Nov 14 05:51:31 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 14 Nov 2015 05:51:31 +0000
Subject: hg: jigsaw/jake: Add hotspot to javadoc -modulesourcepath
Message-ID: <201511140551.tAE5pVOr014193@aojmv0008.oracle.com>

Changeset: cdf7dd951649
Author:    mchung
Date:      2015-11-13 21:51 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/cdf7dd951649

Add hotspot to javadoc -modulesourcepath

! make/Javadoc.gmk


From mandy.chung at oracle.com  Sat Nov 14 06:20:12 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 14 Nov 2015 06:20:12 +0000
Subject: hg: jigsaw/jake/jdk: Add new modular resource bundle test
Message-ID: <201511140620.tAE6KCCk018739@aojmv0008.oracle.com>

Changeset: f83388bef364
Author:    okutsu
Date:      2015-11-13 22:20 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f83388bef364

Add new modular resource bundle test

+ test/java/util/ResourceBundle/modules/visibility/src/embargo/jdk/embargo/TestWithNoModuleArg.java
+ test/java/util/ResourceBundle/modules/visibility/src/embargo/jdk/embargo/TestWithUnnamedModuleArg.java
+ test/java/util/ResourceBundle/modules/visibility/src/embargo/module-info.java
+ test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/MyResources.java
+ test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/MyResourcesProvider.java
+ test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/props/MyResources.properties
+ test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/module-info.java
+ test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/classes/MyResources.java
+ test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/classes/MyResourcesProvider.java
+ test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/MyResources.properties
+ test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/MyResourcesProvider.java
+ test/java/util/ResourceBundle/modules/visibility/src/named.bundles/module-info.java
+ test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/resources/classes/MyResources.java
+ test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/resources/props/MyResources.properties
+ test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/test/Main.java
+ test/java/util/ResourceBundle/modules/visibility/src/test/jdk/test/TestWithNoModuleArg.java
+ test/java/util/ResourceBundle/modules/visibility/src/test/jdk/test/TestWithUnnamedModuleArg.java
+ test/java/util/ResourceBundle/modules/visibility/src/test/module-info.java
+ test/java/util/ResourceBundle/modules/visibility/visibility.sh


From alan.bateman at oracle.com  Sat Nov 14 08:23:46 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 14 Nov 2015 08:23:46 +0000
Subject: hg: jigsaw/jake/jdk: Update JDWP CLassPaths commands to not include
	bootclasspaths
Message-ID: <201511140823.tAE8Nkgb009819@aojmv0008.oracle.com>

Changeset: 6276fb427a98
Author:    alanb
Date:      2015-11-14 08:23 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6276fb427a98

Update JDWP CLassPaths commands to not include bootclasspaths

! src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c
! src/jdk.jdwp.agent/share/native/libjdwp/util.c
! src/jdk.jdwp.agent/share/native/libjdwp/util.h


From alan.bateman at oracle.com  Sat Nov 14 08:35:28 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 14 Nov 2015 08:35:28 +0000
Subject: hg: jigsaw/jake/jdk: appletviewer needs -addmods ALL-SYSTEM
Message-ID: <201511140835.tAE8ZSUj012011@aojmv0008.oracle.com>

Changeset: c98256f2e102
Author:    alanb
Date:      2015-11-14 08:35 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c98256f2e102

appletviewer needs -addmods ALL-SYSTEM

! make/launcher/Launcher-java.desktop.gmk


From alan.bateman at oracle.com  Sat Nov 14 10:31:33 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 14 Nov 2015 10:31:33 +0000
Subject: hg: jigsaw/jake/langtools: Initial changes to get jshell working
Message-ID: <201511141031.tAEAVXlo000276@aojmv0008.oracle.com>

Changeset: bcb5a42de9a0
Author:    alanb
Date:      2015-11-14 10:30 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bcb5a42de9a0

Initial changes to get jshell working

! src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteAgent.java
! src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.java
! test/jdk/jshell/ClassPathTest.java
! test/jdk/jshell/CommandCompletionTest.java
! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/ErrorTranslationTest.java
! test/jdk/jshell/HistoryTest.java
! test/jdk/jshell/ImportTest.java
! test/jdk/jshell/KullaCompletenessStressTest.java
! test/jdk/jshell/StartOptionTest.java
! test/jdk/jshell/StopExecutionTest.java


From alan.bateman at oracle.com  Sat Nov 14 14:44:37 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 14 Nov 2015 14:44:37 +0000
Subject: hg: jigsaw/jake/jdk: 2 new changesets
Message-ID: <201511141444.tAEEibJg011577@aojmv0008.oracle.com>

Changeset: 4fd9addf4669
Author:    alanb
Date:      2015-11-14 11:31 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4fd9addf4669

Expand test coverage for java -XaddExports
Contributed-by: sergei.pikalev at oracle.com

! test/jdk/jigsaw/launcher/addexports/AddExportsTest.java
+ test/jdk/jigsaw/launcher/addexports/src/java.transaction/javax/transaction/Transaction.java
+ test/jdk/jigsaw/launcher/addexports/src/java.transaction/javax/transaction/internal/InternalTransaction.java
+ test/jdk/jigsaw/launcher/addexports/src/java.transaction/module-info.java
+ test/jdk/jigsaw/launcher/addexports/src/one.more/module-info.java
+ test/jdk/jigsaw/launcher/addexports/src/one.more/one/internal/InternalClass.java
+ test/jdk/jigsaw/launcher/addexports/src/one.more/one/more/OneMoreClass.java
+ test/jdk/jigsaw/launcher/addexports/src/testAdd/jdk/test/UsesInternalClass.java
+ test/jdk/jigsaw/launcher/addexports/src/testAdd/module-info.java
+ test/jdk/jigsaw/launcher/addexports/src/testUpgrade/jdk/test/UsesInternalTransaction.java
+ test/jdk/jigsaw/launcher/addexports/src/testUpgrade/module-info.java

Changeset: b7d2a7346aa6
Author:    alanb
Date:      2015-11-14 14:44 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b7d2a7346aa6

Minor clean-up of tests for -XaddExports

! test/jdk/jigsaw/launcher/addexports/AddExportsTest.java
! test/jdk/jigsaw/launcher/addexports/src/java.transaction/javax/transaction/internal/Helper.java < test/jdk/jigsaw/launcher/addexports/src/java.transaction/javax/transaction/internal/InternalTransaction.java
+ test/jdk/jigsaw/launcher/addexports/src/m1/jdk/test1/Main.java
+ test/jdk/jigsaw/launcher/addexports/src/m1/module-info.java
! test/jdk/jigsaw/launcher/addexports/src/m2/jdk/test2/Main.java < test/jdk/jigsaw/launcher/addexports/src/testUpgrade/jdk/test/UsesInternalTransaction.java
! test/jdk/jigsaw/launcher/addexports/src/m2/module-info.java < test/jdk/jigsaw/launcher/addexports/src/testUpgrade/module-info.java
+ test/jdk/jigsaw/launcher/addexports/src/m3/jdk/test3/Main.java
+ test/jdk/jigsaw/launcher/addexports/src/m3/module-info.java
+ test/jdk/jigsaw/launcher/addexports/src/m4/jdk/test4/Type.java
+ test/jdk/jigsaw/launcher/addexports/src/m4/module-info.java
- test/jdk/jigsaw/launcher/addexports/src/one.more/module-info.java
- test/jdk/jigsaw/launcher/addexports/src/one.more/one/internal/InternalClass.java
- test/jdk/jigsaw/launcher/addexports/src/one.more/one/more/OneMoreClass.java
- test/jdk/jigsaw/launcher/addexports/src/test/jdk/test/UsesUnsafe.java
- test/jdk/jigsaw/launcher/addexports/src/test/module-info.java
- test/jdk/jigsaw/launcher/addexports/src/testAdd/jdk/test/UsesInternalClass.java
- test/jdk/jigsaw/launcher/addexports/src/testAdd/module-info.java


From alan.bateman at oracle.com  Sat Nov 14 14:55:42 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 14 Nov 2015 14:55:42 +0000
Subject: hg: jigsaw/jake/jdk: J2DBench demo doesn't need BCP
Message-ID: <201511141455.tAEEtg9a013557@aojmv0008.oracle.com>

Changeset: 5c676ed31145
Author:    alanb
Date:      2015-11-14 14:54 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c676ed31145

J2DBench demo doesn't need BCP

! src/demo/share/java2d/J2DBench/src/j2dbench/ResultSet.java


From Alan.Bateman at oracle.com  Sat Nov 14 15:20:36 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 14 Nov 2015 15:20:36 +0000
Subject: JDeps: detecting offending packages
In-Reply-To: <op.x717b917kdkhrr@robertscholte.dynamic.ziggo.nl>
References: <op.x717b917kdkhrr@robertscholte.dynamic.ziggo.nl>
Message-ID: <56475144.9030205@oracle.com>

On 13/11/2015 21:58, Robert Scholte wrote:
> :
>
> Previous versions of JDK9 gave me the following output:
>
> classes -> java.base
>    <unnamed> (classes)
>       -> java.io
>       -> java.lang
>       -> sun.misc                                           JDK 
> internal API (java.base)
>
>
> The current b86 gives me:
>
> classes -> java.base
>    <unnamed> (classes)
>       -> java.io
>       -> java.lang
>       -> sun.misc
>
> So why this change? And is there another way to detect the usage of 
> non-accessible classes?
>
> The maven-plugin has a parameter called failOnWarning (default:true) 
> which should break the build in order to help developers to change 
> their code when they rely on internal classes.

In the regular JDK 9 EA builds then a usage of sun.misc.BASE64Decoder 
will be reported as a usage of a JDK internal API.

Not so with the Jigsaw builds because package sun.misc is temporarily 
exported by module java.base. This means that all public types in that 
package are accessible. This might seem surprising but it is because 
we're not there yet with JEP 260 [1]. Once JEP 260 is further along thne 
the critical internal APIs listed in JEP 260 will be accessible. The 
non-critical internal APIs will be encapsulated.

For the Maven plugin then maybe it might be better to choose a 
JDK-internal type that is not in sun.misc or sun.reflect. That would 
keep your test stable while we work through all the transition issues.

-Alan

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

From mandy.chung at oracle.com  Sat Nov 14 16:05:25 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 14 Nov 2015 08:05:25 -0800
Subject: JDeps: detecting offending packages
In-Reply-To: <56475144.9030205@oracle.com>
References: <op.x717b917kdkhrr@robertscholte.dynamic.ziggo.nl>
	<56475144.9030205@oracle.com>
Message-ID: <46139409-8DDF-4A17-94CB-4A9026242CDA@oracle.com>


> On Nov 14, 2015, at 7:20 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 13/11/2015 21:58, Robert Scholte wrote:
>> :
>> 
>> Previous versions of JDK9 gave me the following output:
>> 
>> classes -> java.base
>>   <unnamed> (classes)
>>      -> java.io
>>      -> java.lang
>>      -> sun.misc                                           JDK internal API (java.base)
>> 
>> 
>> The current b86 gives me:
>> 
>> classes -> java.base
>>   <unnamed> (classes)
>>      -> java.io
>>      -> java.lang
>>      -> sun.misc
>> 
>> So why this change? And is there another way to detect the usage of non-accessible classes?
>> 
>> The maven-plugin has a parameter called failOnWarning (default:true) which should break the build in order to help developers to change their code when they rely on internal classes.
> 
> In the regular JDK 9 EA builds then a usage of sun.misc.BASE64Decoder will be reported as a usage of a JDK internal API.
> 
> Not so with the Jigsaw builds because package sun.misc is temporarily exported by module java.base. This means that all public types in that package are accessible. This might seem surprising but it is because we're not there yet with JEP 260 [1]. Once JEP 260 is further along thne the critical internal APIs listed in JEP 260 will be accessible. The non-critical internal APIs will be encapsulated.

I think jdeps should continue to flag the critical JDK internal APIs listed in JEP 260 but they are accessible at runtime.  I file a bug:

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

> 
> For the Maven plugin then maybe it might be better to choose a JDK-internal type that is not in sun.misc or sun.reflect. That would keep your test stable while we work through all the transition issues.


Yes that allows to work through the transition.

Mandy


From Alan.Bateman at oracle.com  Sat Nov 14 16:29:58 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 14 Nov 2015 16:29:58 +0000
Subject: JDeps: detecting offending packages
In-Reply-To: <46139409-8DDF-4A17-94CB-4A9026242CDA@oracle.com>
References: <op.x717b917kdkhrr@robertscholte.dynamic.ziggo.nl>
	<56475144.9030205@oracle.com>
	<46139409-8DDF-4A17-94CB-4A9026242CDA@oracle.com>
Message-ID: <56476186.7030807@oracle.com>



On 14/11/2015 16:05, Mandy Chung wrote:
> :
> I think jdeps should continue to flag the critical JDK internal APIs listed in JEP 260 but they are accessible at runtime.  I file a bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8143011
>
I agree and I expect it will be straight-forward once they are moved to 
their own module.

-Alan.

From Alan.Bateman at oracle.com  Sat Nov 14 16:50:07 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 14 Nov 2015 16:50:07 +0000
Subject: Locating a class file from a class loader by name
In-Reply-To: <CA+DM0A=peiUUw_TF1j2tZusGDgSJAnDDgVCpAyNKTiks+VqNRw@mail.gmail.com>
References: <CA+DM0Amj+cLFDkaga9uKyzt3Yf_zqxa1N-=ouHpVP4oxPv8QTQ@mail.gmail.com>
	<56460911.8000300@oracle.com>
	<CA+DM0AnrxAJ7pvAeRnxK6J6nP27Z4X8=uSc7pYDTLwXpkPeyVg@mail.gmail.com>
	<56462BD1.4030209@oracle.com>
	<CA+DM0A=peiUUw_TF1j2tZusGDgSJAnDDgVCpAyNKTiks+VqNRw@mail.gmail.com>
Message-ID: <5647663F.20801@oracle.com>

On 14/11/2015 16:07, Rafael Winterhalter wrote:
> Hi Alan,
>
> As for your suggestion to rather retransform/redefine classes, this 
> would unfortunately not be a feasible alternative for most 
> applications that I have seen. The HotSwap functionaltiy does not 
> allow to add fields or to override methods of super types as the class 
> layout cannot be changed. Also, many code generation frameworks 
> function by renaming existing methods and by reimplementing the same 
> methods to call a user method. The renamed methods can then be invoked 
> by injecting a proxy class into the user code that makes the original 
> code available using a standard interface. If the user method is 
> non-static, this dispatcher also needs to be stored within a new field 
> of the class being instrumented.
Yes, I'm aware of the limitations to redefine/retransformClasses, I was 
pointing out that refransformClasses will invoke the 
ClassFileTransformer with the class bytes and may be the most reliable 
way to get them.

>
> It is correct, of course that a class file does not always exist so 
> the above approach might fail but in practice this is not a problem. 
> Users do normally only want to instrument specific classes of their 
> application via Java agents that are available on the class path and 
> not runtime generated code.
>
> As for the necessity to locate class file, cglib can be named as 
> another example (used by e.g. Spring, Hibernate, Mockito) which needs 
> to parse class files to determine the target of a bridge methods. For 
> this, cglib calls:
>
> Class<?> clazz = ...
> clazz.getClassLoader().getResourceAsStream(clazz.getName().replace('.', '/') 
> + '.class');
>
> If this would return null as it does with the current build of Jigsaw, 
> most real-world applications would stop to function. Therefore my 
> concern with the current implementation where the above call to the 
> class loader returns null.
The current proposal is that resources in named modules be encapsulated. 
There is discussion on EG list for JSR 376 on this topic. The 
ClassLoader.getResourcesXXX do of course work exactly as before for 
resources on the class path or loaded by custom other class loaders.

A general point on frameworks is that we expect they will need need at 
least some changes to work with modules.

-Alan

From rafael.wth at gmail.com  Sun Nov 15 09:51:32 2015
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Sun, 15 Nov 2015 10:51:32 +0100
Subject: Locating a class file from a class loader by name
In-Reply-To: <5647663F.20801@oracle.com>
References: <CA+DM0Amj+cLFDkaga9uKyzt3Yf_zqxa1N-=ouHpVP4oxPv8QTQ@mail.gmail.com>
	<56460911.8000300@oracle.com>
	<CA+DM0AnrxAJ7pvAeRnxK6J6nP27Z4X8=uSc7pYDTLwXpkPeyVg@mail.gmail.com>
	<56462BD1.4030209@oracle.com>
	<CA+DM0A=peiUUw_TF1j2tZusGDgSJAnDDgVCpAyNKTiks+VqNRw@mail.gmail.com>
	<5647663F.20801@oracle.com>
Message-ID: <CA+DM0An=Y8b4YHP8YKGmESDQSLdFDufoCM0nMLZDNuuDFu7nFQ@mail.gmail.com>

Hi Alan,

thank you for your feedback. I agree that the current way of implementing a
class file lookup is not a fail-safe solution but it works for almost all
real use-cases and has therefore become a standard approach used by a lot
of code. I wanted to make sure that you are aware of the dependence on such
class file lookup of code generation libraries and their heavy use in
enterprise software. Of course, we will adapt the new APIs into our
software but as these libraries are non-commercial and developed after
hours, the adoption process will take some time. Currently, all of cglib,
Byte Buddy or Javassist do not function with Jigsaw when running the test
cases of their current stable build because of null pointer exceptions
triggered by unsuccessful class file lookups and I would not know how to
fix this problem.

I will continue to test Jigsaw pre-releases and hope that the mentioned
APIs allow for migrating the libraries such that I can offer a version of
Byte Buddy that supports Jigsaw rather sooner than later.
Best regards, Rafael

2015-11-14 17:50 GMT+01:00 Alan Bateman <Alan.Bateman at oracle.com>:

> On 14/11/2015 16:07, Rafael Winterhalter wrote:
>
>> Hi Alan,
>>
>> As for your suggestion to rather retransform/redefine classes, this would
>> unfortunately not be a feasible alternative for most applications that I
>> have seen. The HotSwap functionaltiy does not allow to add fields or to
>> override methods of super types as the class layout cannot be changed.
>> Also, many code generation frameworks function by renaming existing methods
>> and by reimplementing the same methods to call a user method. The renamed
>> methods can then be invoked by injecting a proxy class into the user code
>> that makes the original code available using a standard interface. If the
>> user method is non-static, this dispatcher also needs to be stored within a
>> new field of the class being instrumented.
>>
> Yes, I'm aware of the limitations to redefine/retransformClasses, I was
> pointing out that refransformClasses will invoke the ClassFileTransformer
> with the class bytes and may be the most reliable way to get them.
>
>
>> It is correct, of course that a class file does not always exist so the
>> above approach might fail but in practice this is not a problem. Users do
>> normally only want to instrument specific classes of their application via
>> Java agents that are available on the class path and not runtime generated
>> code.
>>
>> As for the necessity to locate class file, cglib can be named as another
>> example (used by e.g. Spring, Hibernate, Mockito) which needs to parse
>> class files to determine the target of a bridge methods. For this, cglib
>> calls:
>>
>> Class<?> clazz = ...
>> clazz.getClassLoader().getResourceAsStream(clazz.getName().replace('.',
>> '/') + '.class');
>>
>> If this would return null as it does with the current build of Jigsaw,
>> most real-world applications would stop to function. Therefore my concern
>> with the current implementation where the above call to the class loader
>> returns null.
>>
> The current proposal is that resources in named modules be encapsulated.
> There is discussion on EG list for JSR 376 on this topic. The
> ClassLoader.getResourcesXXX do of course work exactly as before for
> resources on the class path or loaded by custom other class loaders.
>
> A general point on frameworks is that we expect they will need need at
> least some changes to work with modules.
>
> -Alan
>

From reinier at zwitserloot.com  Sun Nov 15 11:03:20 2015
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Sun, 15 Nov 2015 12:03:20 +0100
Subject: A way to opt out of access restrictions on non-exported members.
Message-ID: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>

TL;DR: There are rather a lot of libraries out there that access private
members via reflection. I posit that almost all such libraries break
without an easy way to fix the problem, if there is no way to use
reflection to access non-exported members.



setAccessible(true) doesn't let you opt out of module access rules. There
are ways to effectively 'read' everything (and if not, there's addRead),
but that still doesn't help if you need to reflectively access a member
that isn't exported. According to the questions at the end of the J1
session 'Advanced Modular Development (CON6821)', by Mark Reinhold, Alex
Buckley, and Alex Bateman, there is no way to in-process get around the
JVM-enforced access restriction.

Now, under normal circumstances you shouldn't be accessing such classes /
methods / fields / constructors in the first place, but that exact same
line of reasoning can be used to defend not including setAccessible,
getDeclaredMethod(s), getDeclaredField(s), and all the other ways the
reflection API can be used to access (in JDK1-JDK8, at least) protected,
package private, and private elements. Those things were never designed to
be accessed either, and yet, accessing private members of existing stuff
occurs in lots of libraries, usually for:

* Dependency injection (guice and company)

* Debugging tools (not all of these use JVMTI; sometimes you just have a
utility method that dumps some information to a log that includes private
members just because that seems like it'll help debug an exotic condition
that you can't quite put your finger on).

* Code automation tools (apache has a few utilities that return a useful
hashCode, which work by inspecting your instance's fields).

* Serialization libraries. I'm pretty sure a number of core JDK devs have
gone on record not liking the built in serialization mechanism
(java.io.Serializable and co), but third party solutions access private
members all the time to do their job.

* Workarounds. This one is a perhaps controversial, but as the saying goes,
java is a 'blue collar' programming language. Sometimes you use access to
private members to work around a bug or to get access to functionality that
optimally speaking should be done differently or should be accomodated with
an update to the library to make that part designed for public access.

What are such libraries to do? They could provide the user with ways to use
command line switches to hack in the required exports, but this is the kind
of hassle that is going to reflect badly on JDK9 and slow adoption rates. I
propose some mechanism to get around the restriction is added, with all due
warnings in the documentation that this should be considered a hacky
workaround. (interestingly, such commentary is not part of the javadoc on
.setAccessible!)

Alternatively, there are 3 ways this can go:

* The authors of these libraries, or the help forums associated with such
libraries, start espousing the principle that you should just export
everything from your modules, or 'things might break'. This doesn't sound
like a desirable outcome for the jigsaw project. It certainly doesn't sound
desirable to me.

* The authors of these libraries, or the help forums associated with this
libraries, start espousing the principle that upgrading to JDK9 is an
arduous slog, and that it is better to just stick with JDK8 for the
foreseeable future. Certainly, not a desirable outcome.

* The heavens part, ponies and rainbows for all, and everyone takes the
time to update their serialized data structures or whatnot to make sense in
a 'these are exported, these are not' world. I'm not sure this is even
possible; it would make sense to have a public interface, and then 2
(non-exported!) classes that are implementations of this. How would a
no-hassle serialization library ever get this done without a way to dodge
the rules? A module can export _TO_ a serialization library, but this
breaks encapsulation: Now the author of framework A needs to know that the
user of said framework so happens to have a desire to serialize the stuff
from framework A using serialization library X. In practice you'd have to
export everything to all the serialization frameworks out there, and now no
new framework can ever be created because all these libraries failed to
export their internals to them. In any case this boils down to 'just export
every package to this subset of tools',  and that's the best case scenario,
which doesn't sound desirable either.

I guess option 4 is: "Surely it won't be that bad", but that's a bit of a
gamble to make, given that the stakes are serious lack of adoption of JDK9,
or widespread misconfiguration of exports clauses.

NB1: Note also that JDK9 has taken its time (and rightly so) to fix its
ball-o-twine dependency mess. However, once JDK9 is unleashed upon the
masses, a 'quick fix' to make libraries at least workable with JDK9
probably require such hacks. If it's not possible to do it, then libraries
won't be JDK9 ready for years. Perhaps other projects aren't as messy as
JDK pre-9 was, but let's not make that assumption.

NB2: The module system already has a larger impact on adoption (compared to
6, 7, or 8) simply because of the unavoidable differences inherent in what
jigsaw is doing (I bet a bunch of command line scripts are going to end up
breaking, for example, or at least will be obsolete). Adding more barriers
to adoption is something that should, in my opinion, by taken particularly
seriously for this release.

 --Reinier Zwitserloot

From Alan.Bateman at oracle.com  Sun Nov 15 12:04:30 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 15 Nov 2015 12:04:30 +0000
Subject: Locating a class file from a class loader by name
In-Reply-To: <CA+DM0An=Y8b4YHP8YKGmESDQSLdFDufoCM0nMLZDNuuDFu7nFQ@mail.gmail.com>
References: <CA+DM0Amj+cLFDkaga9uKyzt3Yf_zqxa1N-=ouHpVP4oxPv8QTQ@mail.gmail.com>
	<56460911.8000300@oracle.com>
	<CA+DM0AnrxAJ7pvAeRnxK6J6nP27Z4X8=uSc7pYDTLwXpkPeyVg@mail.gmail.com>
	<56462BD1.4030209@oracle.com>
	<CA+DM0A=peiUUw_TF1j2tZusGDgSJAnDDgVCpAyNKTiks+VqNRw@mail.gmail.com>
	<5647663F.20801@oracle.com>
	<CA+DM0An=Y8b4YHP8YKGmESDQSLdFDufoCM0nMLZDNuuDFu7nFQ@mail.gmail.com>
Message-ID: <564874CE.6020404@oracle.com>

On 15/11/2015 09:51, Rafael Winterhalter wrote:
> Hi Alan,
>
> thank you for your feedback. I agree that the current way of 
> implementing a class file lookup is not a fail-safe solution but it 
> works for almost all real use-cases and has therefore become a 
> standard approach used by a lot of code. I wanted to make sure that 
> you are aware of the dependence on such class file lookup of code 
> generation libraries and their heavy use in enterprise software.
We have of course used static analysis on a huge number of libraries to 
get data on usage of these methods. One thing to say about this is that 
such code should work exactly the same as it did with JDK 8 except where 
it is using the ClassLoader APIs to get at JDK-internal resources 
(including .class files). This is because the only modules when 
initially trying out the Jigsaw builds are the platform modules.

We know this is a compatibility issue, it's the second item in the Risks 
and Assumptions section of JEP 261. That compatibility issue could get 
bigger as more code is migrated to modules but this assumes the 
frameworks and tools that are relying on the ClassLoader.getResourceXXX 
methods don't add support for modules. I would hope in time that the 
frameworks and tools will add support for modules, in which case this 
issue should slowly go away.

As to where to lobby for the ClassLoader APIs to support locating 
resources in modules then jpms-spec-comments is the mailing list to send 
feedback.


> Of course, we will adapt the new APIs into our software but as these 
> libraries are non-commercial and developed after hours, the adoption 
> process will take some time. Currently, all of cglib, Byte Buddy or 
> Javassist do not function with Jigsaw when running the test cases of 
> their current stable build because of null pointer exceptions 
> triggered by unsuccessful class file lookups and I would not know how 
> to fix this problem.
>
> I will continue to test Jigsaw pre-releases and hope that the 
> mentioned APIs allow for migrating the libraries such that I can offer 
> a version of Byte Buddy that supports Jigsaw rather sooner than later.
>
Thank you, it's important to have as many people trying out the builds 
and seeing what works and doesn't work. Modules is a huge change to the 
platform and we have to get it right.

-Alan

From alan.bateman at oracle.com  Sun Nov 15 14:49:01 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sun, 15 Nov 2015 14:49:01 +0000
Subject: hg: jigsaw/jake/corba: Remove core reflection usage in CORBA utility
	class
Message-ID: <201511151449.tAFEn1KS006570@aojmv0008.oracle.com>

Changeset: 54d9b908806a
Author:    alanb
Date:      2015-11-15 14:48 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/54d9b908806a

Remove core reflection usage in CORBA utility class

! src/java.corba/share/classes/com/sun/corba/se/impl/util/Modules.java


From mik3hall at gmail.com  Sun Nov 15 17:04:07 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 15 Nov 2015 11:04:07 -0600
Subject: jrt file system now has /package and /modules directories
In-Reply-To: <55B48789.6020907@oracle.com>
References: <55B3C320.8060705@oracle.com>
	<4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com>
	<55B48789.6020907@oracle.com>
Message-ID: <7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com>

Would it still be the case that the exploded build in the jdk directory is invalid to use?

I am having some difficulties on this again. As long as I had done this once I thought it would make sense to be most up to date by just continuing to build from source.
So I redid the command to get new source.
And tried building. At some point this told me my configuration was no longer valid and the best thing to do was something like
make reconfigure
I did that, got through the build but the ?make install? shows errors and the images directory ends up with only?
_the.nashorn.jar.vardeps
I did get a OS X application to boot with the ?exploded?? build in the jdk directory but if I try listing files with the JRT filesystem to be sure I?m running a new release I get errors like?

ava.nio.file.FileSystemNotFoundException: /Users/mjh/HalfPipe/bundles/HalfPipe9/HalfPipe9.app/Contents/PlugIns/Java/Contents/Home/lib/modules/bootmodules.jimage
	at jdk.internal.jrtfs.JrtFileSystem.checkExists(JrtFileSystem.java:87)

Although I didn?t seem to have a build step fail on a compiler warning I did also try?
./configure --disable-warnings-as-errors

So what I am doing is basically?
[get updated source bash get_source.sh or whatever it is]
[confifgure]
make clean
make 
sudo make install

Sort of consistently getting?

Building target 'install' in configuration 'macosx-x86_64-normal-server-release'
Installing jdk image into /usr/local/jvm/openjdk-1.9.0-internal
and creating 0 links from /usr/local/bin into the jdk.
cp: /Users/mjh/jdk9/build/macosx-x86_64-normal-server-release/images/jdk/*: No such file or directory
make[3]: *** [install] Error 1
make[2]: *** [install] Error 2

I tried searching on ] Error as also suggested and don?t think I saw any for the last build besides the ones immediately above.


> On Jul 26, 2015, at 2:08 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 26/07/2015 01:29, Michael Hall wrote:
>>> On Jul 25, 2015, at 12:10 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> 
>>> 
>>> Just a heads-up that jdk9-b74 has a refresh of the jimage and jrt file system implementation.
>> Have mostly just been following along on this a little with the early access releases. I was a little curious on this though so I cloned and built current jdk9.
>> I have a simple jrt filesystem lister that I tried running getting?
>> 
>> ~/jdk9/build/macosx-x86_64-normal-server-release/jdk/bin/java -cp . JRTLister
>> java.nio.file.FileSystemNotFoundException: /Users/mjh/jdk9/build/macosx-x86_64-normal-server-release/jdk/lib/modules/bootmodules.jimage
>> 	at jdk.internal.jrtfs.JrtFileSystem.checkExists(JrtFileSystem.java:87)
>> 	at jdk.internal.jrtfs.JrtFileSystem.<init>(JrtFileSystem.java:102)
>> 	at jdk.internal.jrtfs.JrtFileSystemProvider$1.<init>(JrtFileSystemProvider.java:113)
>> 	at jdk.internal.jrtfs.JrtFileSystemProvider.getTheFileSystem(JrtFileSystemProvider.java:113)
>> 	at jdk.internal.jrtfs.JrtFileSystemProvider.getFileSystem(JrtFileSystemProvider.java:131)
>> 	at java.nio.file.FileSystems.getFileSystem(FileSystems.java:221)
>> 	at JRTLister.main(JRTLister.java:13)
>> 
>> Obviously finding JrtFileSystem but not modules/bootmodules.jimage?
>> 
> Replace jdk/bin/java with images/jdk/bin/java in your path above and I expect it should work.
> 
> The jdk directory in the build output is the "exploded build". It's an intermediate step in the build before the JDK and JRE images are created. Many people working on the JDK use the exploded builds for quick edit-build-debug sessions and local testing but I don't think is used much beyond that.
> 
> JDK-8066860 [1] is tracking an update to the jrt file system to support exploded builds. Sundar has an initial patch but it's not in JDK 9 yet.
> 
> -Alan
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8066860 <https://bugs.openjdk.java.net/browse/JDK-8066860>

Michael Hall






From rfscholte at apache.org  Sun Nov 15 17:49:42 2015
From: rfscholte at apache.org (Robert Scholte)
Date: Sun, 15 Nov 2015 18:49:42 +0100
Subject: JDeps: detecting offending packages
In-Reply-To: <56476186.7030807@oracle.com>
References: <op.x717b917kdkhrr@robertscholte.dynamic.ziggo.nl>
	<56475144.9030205@oracle.com>
	<46139409-8DDF-4A17-94CB-4A9026242CDA@oracle.com>
	<56476186.7030807@oracle.com>
Message-ID: <op.x75k44qvkdkhrr@robertscholte.dynamic.ziggo.nl>

Ah, I see. Adding usage of java.awt.peer.ComponentPeer did indeed expose  
an offending package again.

Just out of interest: will jdeps only detect violations of JDK internal  
APIs or will it also detect violations on modules? In case I switch from  
executable jar to executable module it could happen that it breaks due to  
usage of non-exported packages, right?

regards,
Robert

Op Sat, 14 Nov 2015 17:29:58 +0100 schreef Alan Bateman  
<Alan.Bateman at oracle.com>:

>
>
> On 14/11/2015 16:05, Mandy Chung wrote:
>> :
>> I think jdeps should continue to flag the critical JDK internal APIs  
>> listed in JEP 260 but they are accessible at runtime.  I file a bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8143011
>>
> I agree and I expect it will be straight-forward once they are moved to  
> their own module.
>
> -Alan.

From forax at univ-mlv.fr  Sun Nov 15 18:14:17 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 15 Nov 2015 19:14:17 +0100 (CET)
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
Message-ID: <90409445.3423948.1447611257010.JavaMail.zimbra@u-pem.fr>

There are several ways to opt-out if you control the command line,
- put all your modules in the classpath or remove all the module-info from the modules in the module-path,
- create a jlink plugin that will crawle all modules (or the ones you want) and change the module-info,
- at runtime to create a new layer that will bypass the application classloader and change the module configuration on-the-fly.
And there are more exotic ways if you are able to change the bytecodes.

Anyway, one goal of jigsaw is to harden the Java plateform, so you can weaken the plateform if you want but it should not be neither the default mode nor it should not be too easy (reflection i'm looking at you) to do that.

Now, in the details,
- you can still access to members of exported classes by reflection, you may have to add a read edge between the corresponding modules for that, but it's possible.
- you can access to members of a non exported classes by using their interfaces if these interfaces are exported (the same way you can access members of a non public class in pre-jigsaw world).

regards,
R?mi

----- Mail original -----
> De: "Reinier Zwitserloot" <reinier at zwitserloot.com>
> ?: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoy?: Dimanche 15 Novembre 2015 12:03:20
> Objet: A way to opt out of access restrictions on non-exported members.
> 
> TL;DR: There are rather a lot of libraries out there that access private
> members via reflection. I posit that almost all such libraries break
> without an easy way to fix the problem, if there is no way to use
> reflection to access non-exported members.
> 
> 
> 
> setAccessible(true) doesn't let you opt out of module access rules. There
> are ways to effectively 'read' everything (and if not, there's addRead),
> but that still doesn't help if you need to reflectively access a member
> that isn't exported. According to the questions at the end of the J1
> session 'Advanced Modular Development (CON6821)', by Mark Reinhold, Alex
> Buckley, and Alex Bateman, there is no way to in-process get around the
> JVM-enforced access restriction.
> 
> Now, under normal circumstances you shouldn't be accessing such classes /
> methods / fields / constructors in the first place, but that exact same
> line of reasoning can be used to defend not including setAccessible,
> getDeclaredMethod(s), getDeclaredField(s), and all the other ways the
> reflection API can be used to access (in JDK1-JDK8, at least) protected,
> package private, and private elements. Those things were never designed to
> be accessed either, and yet, accessing private members of existing stuff
> occurs in lots of libraries, usually for:
> 
> * Dependency injection (guice and company)
> 
> * Debugging tools (not all of these use JVMTI; sometimes you just have a
> utility method that dumps some information to a log that includes private
> members just because that seems like it'll help debug an exotic condition
> that you can't quite put your finger on).
> 
> * Code automation tools (apache has a few utilities that return a useful
> hashCode, which work by inspecting your instance's fields).
> 
> * Serialization libraries. I'm pretty sure a number of core JDK devs have
> gone on record not liking the built in serialization mechanism
> (java.io.Serializable and co), but third party solutions access private
> members all the time to do their job.
> 
> * Workarounds. This one is a perhaps controversial, but as the saying goes,
> java is a 'blue collar' programming language. Sometimes you use access to
> private members to work around a bug or to get access to functionality that
> optimally speaking should be done differently or should be accomodated with
> an update to the library to make that part designed for public access.
> 
> What are such libraries to do? They could provide the user with ways to use
> command line switches to hack in the required exports, but this is the kind
> of hassle that is going to reflect badly on JDK9 and slow adoption rates. I
> propose some mechanism to get around the restriction is added, with all due
> warnings in the documentation that this should be considered a hacky
> workaround. (interestingly, such commentary is not part of the javadoc on
> .setAccessible!)
> 
> Alternatively, there are 3 ways this can go:
> 
> * The authors of these libraries, or the help forums associated with such
> libraries, start espousing the principle that you should just export
> everything from your modules, or 'things might break'. This doesn't sound
> like a desirable outcome for the jigsaw project. It certainly doesn't sound
> desirable to me.
> 
> * The authors of these libraries, or the help forums associated with this
> libraries, start espousing the principle that upgrading to JDK9 is an
> arduous slog, and that it is better to just stick with JDK8 for the
> foreseeable future. Certainly, not a desirable outcome.
> 
> * The heavens part, ponies and rainbows for all, and everyone takes the
> time to update their serialized data structures or whatnot to make sense in
> a 'these are exported, these are not' world. I'm not sure this is even
> possible; it would make sense to have a public interface, and then 2
> (non-exported!) classes that are implementations of this. How would a
> no-hassle serialization library ever get this done without a way to dodge
> the rules? A module can export _TO_ a serialization library, but this
> breaks encapsulation: Now the author of framework A needs to know that the
> user of said framework so happens to have a desire to serialize the stuff
> from framework A using serialization library X. In practice you'd have to
> export everything to all the serialization frameworks out there, and now no
> new framework can ever be created because all these libraries failed to
> export their internals to them. In any case this boils down to 'just export
> every package to this subset of tools',  and that's the best case scenario,
> which doesn't sound desirable either.
> 
> I guess option 4 is: "Surely it won't be that bad", but that's a bit of a
> gamble to make, given that the stakes are serious lack of adoption of JDK9,
> or widespread misconfiguration of exports clauses.
> 
> NB1: Note also that JDK9 has taken its time (and rightly so) to fix its
> ball-o-twine dependency mess. However, once JDK9 is unleashed upon the
> masses, a 'quick fix' to make libraries at least workable with JDK9
> probably require such hacks. If it's not possible to do it, then libraries
> won't be JDK9 ready for years. Perhaps other projects aren't as messy as
> JDK pre-9 was, but let's not make that assumption.
> 
> NB2: The module system already has a larger impact on adoption (compared to
> 6, 7, or 8) simply because of the unavoidable differences inherent in what
> jigsaw is doing (I bet a bunch of command line scripts are going to end up
> breaking, for example, or at least will be obsolete). Adding more barriers
> to adoption is something that should, in my opinion, by taken particularly
> seriously for this release.
> 
>  --Reinier Zwitserloot
> 

From claes.redestad at oracle.com  Sun Nov 15 23:58:11 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 16 Nov 2015 00:58:11 +0100
Subject: jrt file system now has /package and /modules directories
In-Reply-To: <7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com>
References: <55B3C320.8060705@oracle.com>	<4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com>	<55B48789.6020907@oracle.com>
	<7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com>
Message-ID: <56491C13.9010203@oracle.com>

Hi,

maybe a long shot, but could you replace the "make" with "make images" 
and try again?

/Claes

On 2015-11-15 18:04, Michael Hall wrote:
> make clean
> make
> sudo make install


From mik3hall at gmail.com  Mon Nov 16 00:44:40 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 15 Nov 2015 18:44:40 -0600
Subject: jrt file system now has /package and /modules directories
In-Reply-To: <56491C13.9010203@oracle.com>
References: <55B3C320.8060705@oracle.com>
	<4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com>
	<55B48789.6020907@oracle.com>
	<7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com>
	<56491C13.9010203@oracle.com>
Message-ID: <CBA81A07-B234-44B7-BAED-CF422666E551@gmail.com>

> On Nov 15, 2015, at 5:58 PM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> maybe a long shot, but could you replace the "make" with "make images" and try again?

Not a bad long shot. Seemed to work fine.

Creating jre jimage
Creating jdk jimage
duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", skipping
Access verification succeeded.
## Finished verify-modules (build time 00:03:40)

Finished building target 'images' in configuration 'macosx-x86_64-normal-server-release?

Running this?
~/jdk9/build/macosx-x86_64-normal-server-release/images/jdk/bin/java JRTLister
/packages
/modules

also works now. 
I am sure it will likewise work from the app.

Thanks much

Michael Hall






From Alan.Bateman at oracle.com  Mon Nov 16 07:42:34 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Nov 2015 07:42:34 +0000
Subject: jrt file system now has /package and /modules directories
In-Reply-To: <CBA81A07-B234-44B7-BAED-CF422666E551@gmail.com>
References: <55B3C320.8060705@oracle.com>
	<4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com>
	<55B48789.6020907@oracle.com>
	<7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com>
	<56491C13.9010203@oracle.com>
	<CBA81A07-B234-44B7-BAED-CF422666E551@gmail.com>
Message-ID: <564988EA.3080005@oracle.com>



On 16/11/2015 00:44, Michael Hall wrote:
> Not a bad long shot. Seemed to work fine.
>
> Creating jre jimage
> Creating jdk jimage
> duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", skipping
> Access verification succeeded.
> ## Finished verify-modules (build time 00:03:40)
>
> Finished building target 'images' in configuration 'macosx-x86_64-normal-server-release?
>
> Running this?
> ~/jdk9/build/macosx-x86_64-normal-server-release/images/jdk/bin/java JRTLister
> /packages
> /modules
>
> also works now.
> I am sure it will likewise work from the app.
>
>
To your original question then the jrt file system provider in the 
jigsaw/jake forest has support for exploded builds, the version in the 
main line JDK 9 forest does not have this support (yet). From the above 
output then it looks like you have a clone of the JDK 9 main line, maybe 
jdk9/jdk9 or jdk9/dev, so that explains that part.

As regards the make target then the README-builds suggests "make all" so 
that everything is built. When you run just "make" without any make 
target then it defaults to developer/exploded builds, this is what most 
people working on the JDK use. I'm not 100% sure why the "install" 
target doesn't build and install the images, Erik or someone in the 
build area can probably say more on this.

-Alan

From erik.joelsson at oracle.com  Mon Nov 16 09:04:49 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 16 Nov 2015 10:04:49 +0100
Subject: jrt file system now has /package and /modules directories
In-Reply-To: <564988EA.3080005@oracle.com>
References: <55B3C320.8060705@oracle.com>
	<4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com>
	<55B48789.6020907@oracle.com>
	<7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com>
	<56491C13.9010203@oracle.com>
	<CBA81A07-B234-44B7-BAED-CF422666E551@gmail.com>
	<564988EA.3080005@oracle.com>
Message-ID: <56499C31.4060608@oracle.com>

The "install" target should most definitely depend on "images". I see 
that it currently doesn't, which is certainly a bug. The workaround is 
to do "make images && make install".

Filing a bug.

/Erik

On 2015-11-16 08:42, Alan Bateman wrote:
>
>
> On 16/11/2015 00:44, Michael Hall wrote:
>> Not a bad long shot. Seemed to work fine.
>>
>> Creating jre jimage
>> Creating jdk jimage
>> duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", 
>> skipping
>> Access verification succeeded.
>> ## Finished verify-modules (build time 00:03:40)
>>
>> Finished building target 'images' in configuration 
>> 'macosx-x86_64-normal-server-release?
>>
>> Running this?
>> ~/jdk9/build/macosx-x86_64-normal-server-release/images/jdk/bin/java 
>> JRTLister
>> /packages
>> /modules
>>
>> also works now.
>> I am sure it will likewise work from the app.
>>
>>
> To your original question then the jrt file system provider in the 
> jigsaw/jake forest has support for exploded builds, the version in the 
> main line JDK 9 forest does not have this support (yet). From the 
> above output then it looks like you have a clone of the JDK 9 main 
> line, maybe jdk9/jdk9 or jdk9/dev, so that explains that part.
>
> As regards the make target then the README-builds suggests "make all" 
> so that everything is built. When you run just "make" without any make 
> target then it defaults to developer/exploded builds, this is what 
> most people working on the JDK use. I'm not 100% sure why the 
> "install" target doesn't build and install the images, Erik or someone 
> in the build area can probably say more on this.
>
> -Alan


From mik3hall at gmail.com  Mon Nov 16 09:42:32 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 16 Nov 2015 03:42:32 -0600
Subject: jrt file system now has /package and /modules directories
In-Reply-To: <564988EA.3080005@oracle.com>
References: <55B3C320.8060705@oracle.com>
	<4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com>
	<55B48789.6020907@oracle.com>
	<7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com>
	<56491C13.9010203@oracle.com>
	<CBA81A07-B234-44B7-BAED-CF422666E551@gmail.com>
	<564988EA.3080005@oracle.com>
Message-ID: <F7D087BC-725C-440D-BF08-D2ECF28C3F3E@gmail.com>

> On Nov 16, 2015, at 1:42 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> To your original question then the jrt file system provider in the jigsaw/jake forest has support for exploded builds, the version in the main line JDK 9 forest does not have this support (yet). From the above output then it looks like you have a clone of the JDK 9 main line, maybe jdk9/jdk9 or jdk9/dev, so that explains that part.
> 
> As regards the make target then the README-builds suggests "make all" so that everything is built. When you run just "make" without any make target then it defaults to developer/exploded builds, this is what most people working on the JDK use. I'm not 100% sure why the "install" target doesn't build and install the images, Erik or someone in the build area can probably say more on this.

The install failed because of the missing images. Up to Eric I guess if that is a bug. Yes, I am using a mainline jdk 9 forest. I wouldn?t know how to get a jigsaw specific one.
I did end up doing the install and it worked fine with images there. I shouldn?t of installed. I?m still trying to use Java 8 as the default on my machine and only use 9 embedded runtime from a test app. Now I?ll probably have to reinstall 8 over the top to get it back to default.
A default build that doesn?t create a jvm fully usable from an application doesn?t make a lot of sense to me but I?ll believe you that it does for a majority of people.
Thanks for referring me to the README that I should of looked at, my own page documenting what I did last time on this did say to do ?make all? and I didn?t even read that. But I did update it for what thats worth. Maybe I?ll read it next time. 

A couple of other things?
?make clean? I remembered had to be sudo?d for me? Doesn?t seem like what I?ve usually done. 

After not succeeding with this I tried to just grab a early access I could work with. Any time I tried to download instead of downloading it took me to a Oracle developer community page. Kenai, Oracle didn?t seem to matter, I couldn?t get a download, everything hauled me off to the community page?

Why are there still separate jre and jdk images? I thought these were going to end up sort of merged depending on modules? Or is the main line build process not really supporting the module part of this at this time? This one I?m assuming is one of those will change over time as the branches merge?

Michael Hall




> 
> 
> 
> 
> On 16/11/2015 00:44, Michael Hall wrote:
>> Not a bad long shot. Seemed to work fine.
>> 
>> Creating jre jimage
>> Creating jdk jimage
>> duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", skipping
>> Access verification succeeded.
>> ## Finished verify-modules (build time 00:03:40)
>> 
>> Finished building target 'images' in configuration 'macosx-x86_64-normal-server-release?
>> 
>> Running this?
>> ~/jdk9/build/macosx-x86_64-normal-server-release/images/jdk/bin/java JRTLister
>> /packages
>> /modules
>> 
>> also works now.
>> I am sure it will likewise work from the app.
>> 
>> 
> 
> 
> -Alan


From alan.bateman at oracle.com  Mon Nov 16 10:53:16 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 16 Nov 2015 10:53:16 +0000
Subject: hg: jigsaw/jake/jdk: Remove dependency on sun.boot.class.path from
	more tests
Message-ID: <201511161053.tAGArG1M025577@aojmv0008.oracle.com>

Changeset: 1d9005d2200d
Author:    alanb
Date:      2015-11-16 10:52 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1d9005d2200d

Remove dependency on sun.boot.class.path from more tests

! test/java/lang/instrument/BootClassPath/Agent.java
! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java
! test/java/rmi/reliability/benchmark/bench/HtmlReporter.java
! test/java/rmi/reliability/benchmark/bench/TextReporter.java


From pm at netcetera.ch  Mon Nov 16 11:19:48 2015
From: pm at netcetera.ch (Philippe Marschall)
Date: Mon, 16 Nov 2015 12:19:48 +0100
Subject: Annotations across modules
In-Reply-To: <CACzrW9CvQu0O=eVsuEb9PQRgoB+Zk2+p+idmgFgcQpSPqL+N5Q@mail.gmail.com>
References: <CACzrW9CvQu0O=eVsuEb9PQRgoB+Zk2+p+idmgFgcQpSPqL+N5Q@mail.gmail.com>
Message-ID: <5649BBD4.4060405@netcetera.ch>

On 12.11.15 14:50, Stephen Colebourne wrote:
> My understanding of annotations today is that annotations are not
> required at runtime. ie. if an annotation is placed into a class at
> compile time but the .class file for the annotation is not available
> on the runtime classpath. then there is no error.
>
> Does this change in any way with modules?
>
> My specific case is wrt @ConstructorProperties which is in java.beans.
> In 9, a user may run my software without the java.beans module. Can I
> safely assume that if the annotation is available on the compile
> module path but not the runtime module path, everything will be OK
> (ie. no error)?

My understanding is that you can't have optional dependencies. So if you 
have @ConstructorProperties in your source you also need to have a 
java.desktop module dependency in your module-info.java. If your library 
is in the module path the java.desktop module then it needs to be 
present at runtime.

The only option you have is to make your jar not a modular jar by one of 
those:
  - not providing a module-info.class
  - not putting your module in the module path

Cheers
Philippe


From scolebourne at joda.org  Mon Nov 16 12:28:22 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 16 Nov 2015 12:28:22 +0000
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
Message-ID: <CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>

Access to private members of classes by reflection is indeed very,
very common. I agree that JDK 9 needs to be cautious around this.

For me, I'm not yet sure I'm comfortable with setAccessible(true) no
longer being sufficient to access them.

I did wonder if perhaps a change could be made such that any instance
of 'Class' passed into a module would automatically be granted the
necessary enhanced module readability. Unfortunately, I don't think it
will be enough for most serialization frameworks, as they traverse a
graph of objects.

I do think that there may need to be separate JDK 8 and 9 versions of
many OSS libraries (for which the multi-version jar file is one
option). This will certainly slow adoption.

Stephen
PS. I'm reminded of Java's missing "properties" feature again, cf.
http://jodastephen.github.io/property-alliance/



On 15 November 2015 at 11:03, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> TL;DR: There are rather a lot of libraries out there that access private
> members via reflection. I posit that almost all such libraries break
> without an easy way to fix the problem, if there is no way to use
> reflection to access non-exported members.
>
>
>
> setAccessible(true) doesn't let you opt out of module access rules. There
> are ways to effectively 'read' everything (and if not, there's addRead),
> but that still doesn't help if you need to reflectively access a member
> that isn't exported. According to the questions at the end of the J1
> session 'Advanced Modular Development (CON6821)', by Mark Reinhold, Alex
> Buckley, and Alex Bateman, there is no way to in-process get around the
> JVM-enforced access restriction.
>
> Now, under normal circumstances you shouldn't be accessing such classes /
> methods / fields / constructors in the first place, but that exact same
> line of reasoning can be used to defend not including setAccessible,
> getDeclaredMethod(s), getDeclaredField(s), and all the other ways the
> reflection API can be used to access (in JDK1-JDK8, at least) protected,
> package private, and private elements. Those things were never designed to
> be accessed either, and yet, accessing private members of existing stuff
> occurs in lots of libraries, usually for:
>
> * Dependency injection (guice and company)
>
> * Debugging tools (not all of these use JVMTI; sometimes you just have a
> utility method that dumps some information to a log that includes private
> members just because that seems like it'll help debug an exotic condition
> that you can't quite put your finger on).
>
> * Code automation tools (apache has a few utilities that return a useful
> hashCode, which work by inspecting your instance's fields).
>
> * Serialization libraries. I'm pretty sure a number of core JDK devs have
> gone on record not liking the built in serialization mechanism
> (java.io.Serializable and co), but third party solutions access private
> members all the time to do their job.
>
> * Workarounds. This one is a perhaps controversial, but as the saying goes,
> java is a 'blue collar' programming language. Sometimes you use access to
> private members to work around a bug or to get access to functionality that
> optimally speaking should be done differently or should be accomodated with
> an update to the library to make that part designed for public access.
>
> What are such libraries to do? They could provide the user with ways to use
> command line switches to hack in the required exports, but this is the kind
> of hassle that is going to reflect badly on JDK9 and slow adoption rates. I
> propose some mechanism to get around the restriction is added, with all due
> warnings in the documentation that this should be considered a hacky
> workaround. (interestingly, such commentary is not part of the javadoc on
> .setAccessible!)
>
> Alternatively, there are 3 ways this can go:
>
> * The authors of these libraries, or the help forums associated with such
> libraries, start espousing the principle that you should just export
> everything from your modules, or 'things might break'. This doesn't sound
> like a desirable outcome for the jigsaw project. It certainly doesn't sound
> desirable to me.
>
> * The authors of these libraries, or the help forums associated with this
> libraries, start espousing the principle that upgrading to JDK9 is an
> arduous slog, and that it is better to just stick with JDK8 for the
> foreseeable future. Certainly, not a desirable outcome.
>
> * The heavens part, ponies and rainbows for all, and everyone takes the
> time to update their serialized data structures or whatnot to make sense in
> a 'these are exported, these are not' world. I'm not sure this is even
> possible; it would make sense to have a public interface, and then 2
> (non-exported!) classes that are implementations of this. How would a
> no-hassle serialization library ever get this done without a way to dodge
> the rules? A module can export _TO_ a serialization library, but this
> breaks encapsulation: Now the author of framework A needs to know that the
> user of said framework so happens to have a desire to serialize the stuff
> from framework A using serialization library X. In practice you'd have to
> export everything to all the serialization frameworks out there, and now no
> new framework can ever be created because all these libraries failed to
> export their internals to them. In any case this boils down to 'just export
> every package to this subset of tools',  and that's the best case scenario,
> which doesn't sound desirable either.
>
> I guess option 4 is: "Surely it won't be that bad", but that's a bit of a
> gamble to make, given that the stakes are serious lack of adoption of JDK9,
> or widespread misconfiguration of exports clauses.
>
> NB1: Note also that JDK9 has taken its time (and rightly so) to fix its
> ball-o-twine dependency mess. However, once JDK9 is unleashed upon the
> masses, a 'quick fix' to make libraries at least workable with JDK9
> probably require such hacks. If it's not possible to do it, then libraries
> won't be JDK9 ready for years. Perhaps other projects aren't as messy as
> JDK pre-9 was, but let's not make that assumption.
>
> NB2: The module system already has a larger impact on adoption (compared to
> 6, 7, or 8) simply because of the unavoidable differences inherent in what
> jigsaw is doing (I bet a bunch of command line scripts are going to end up
> breaking, for example, or at least will be obsolete). Adding more barriers
> to adoption is something that should, in my opinion, by taken particularly
> seriously for this release.
>
>  --Reinier Zwitserloot

From alexandre.iline at oracle.com  Mon Nov 16 13:01:20 2015
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Mon, 16 Nov 2015 16:01:20 +0300
Subject: RFR: 8139430
In-Reply-To: <CBB16E61-EB4B-4BF1-9696-0D2A4DADEBA9@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<564256C7.60905@oracle.com>
	<CBB16E61-EB4B-4BF1-9696-0D2A4DADEBA9@oracle.com>
Message-ID: <14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com>

V6:
http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/

Thank you.

Shura

> On Nov 11, 2015, at 7:41 PM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
> 
> 
>> On Nov 10, 2015, at 11:42 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> 
>> 
>> On 09/11/2015 19:12, Alexandre (Shura) Iline wrote:
>>> Hi
>>> 
>>> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also:
>>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/
>>> 
>>> Shura
>>> 
>> I skimmed through the webrev and it looks okay. Assuming InputArguments is not renamed then you could rename containsPrefix to something like hasArgStartingWith or something that makes it clear what this method does.
>> 
>> Would it break many tests if getProcessId were changed to return long to match ProcessHandle::getPid?
> 
> Yes, there are a few places only, actually. Let me also fix those.
> 
> Shura
> 
>> 
>> When this is pushed then can we drop @modules java.management from any tests or were those changes held back assuming the dependency would be dropped?
>> 
>> -Alan.
>> 
>> 
>> 
> 


From jaroslav.bachorik at oracle.com  Mon Nov 16 13:11:42 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 16 Nov 2015 14:11:42 +0100
Subject: RFR: 8139430
In-Reply-To: <14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<564256C7.60905@oracle.com>
	<CBB16E61-EB4B-4BF1-9696-0D2A4DADEBA9@oracle.com>
	<14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com>
Message-ID: <5649D60E.6090008@oracle.com>

On 16.11.2015 14:01, Alexandre (Shura) Iline wrote:
> V6:
> http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/

Looks good!

Thanks,

-JB-


>
> Thank you.
>
> Shura
>
>> On Nov 11, 2015, at 7:41 PM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>>
>>
>>> On Nov 10, 2015, at 11:42 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>
>>>
>>>
>>> On 09/11/2015 19:12, Alexandre (Shura) Iline wrote:
>>>> Hi
>>>>
>>>> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also:
>>>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/
>>>>
>>>> Shura
>>>>
>>> I skimmed through the webrev and it looks okay. Assuming InputArguments is not renamed then you could rename containsPrefix to something like hasArgStartingWith or something that makes it clear what this method does.
>>>
>>> Would it break many tests if getProcessId were changed to return long to match ProcessHandle::getPid?
>>
>> Yes, there are a few places only, actually. Let me also fix those.
>>
>> Shura
>>
>>>
>>> When this is pushed then can we drop @modules java.management from any tests or were those changes held back assuming the dependency would be dropped?
>>>
>>> -Alan.
>>>
>>>
>>>
>>
>


From reinier at zwitserloot.com  Mon Nov 16 13:21:15 2015
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Mon, 16 Nov 2015 14:21:15 +0100
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <90409445.3423948.1447611257010.JavaMail.zimbra@u-pem.fr>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<90409445.3423948.1447611257010.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAK6PxWMhj55GpHAgWa-hS-gY=iRp7JsVyBy+XWi6HjThUakyFQ@mail.gmail.com>

Security hardening? The security manager already stops .setAccessible() if
you want it to, and if you don't stop that, you have no security anyway, so
there's no point. I do not understand the argument of '... blocking
.setAccessible() from letting you access members from non-exported packages
is better for security' at all.

With some more depth:

On Sun, Nov 15, 2015 at 7:14 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> - put all your modules in the classpath or remove all the module-info from
> the modules in the module-path,
> - create a jlink plugin that will crawle all modules (or the ones you
> want) and change the module-info,
> - at runtime to create a new layer that will bypass the application
> classloader and change the module configuration on-the-fly.
> And there are more exotic ways if you are able to change the bytecodes.
>

Exactly. Exotic ways. These options sounds sufficiently user hostile that
it'll slow JDK9 adoption significantly. A lot of them also don't sound like
something that team jigsaw would want. For example, if most java
deployments start dumping all the modules on the CP to get around this
issue, then... what was the point of the module system in the first place?

I'm trying to make the point: This COULD lead to the community en masse
establishing some hacky workaround as 'the new normal' because libraries
simply do not have the tools to become JDK9 ready in time (or ever). That
sounds like something to be avoided.

I don't understand the security element at all. The only way to cause
security issues if .setAccessible() would let you break through exports
requirements, is if untrusted code is allowed to run, in-process, on your
own JVM in the first place*. There is NO WAY to have such code (untrusted,
running in-process) be in any way or form safe unless a security manager is
involved, and the security manager is _already_ set up to allow you to deny
.setAccessible.

*) Technically, you could have code that calls .setAccessible(true) on an
element that is found based on untrusted user input, but this sounds like a
very exotic case, is already a security nightmare both in JDK8 and even in
a fully modularized JDK9 world; if we take as written that accessing any
element of a non-exported package is a huge security leak, how is accessing
private members of exported packages perfectly fine? That makes no sense
either.

 --Reinier Zwitserloot

From Alan.Bateman at oracle.com  Mon Nov 16 13:38:57 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Nov 2015 13:38:57 +0000
Subject: RFR: 8139430
In-Reply-To: <14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<564256C7.60905@oracle.com>
	<CBB16E61-EB4B-4BF1-9696-0D2A4DADEBA9@oracle.com>
	<14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com>
Message-ID: <5649DC71.60106@oracle.com>



On 16/11/2015 13:01, Alexandre (Shura) Iline wrote:
> V6:
> http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/
>
>
This looks okay to me. For completeness then I assume the 
THreadMXBeanTool.waitUntilXXX methods should re-assert the interrupt 
status if interrupted when waiting.

-Alan

From forax at univ-mlv.fr  Mon Nov 16 14:20:57 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 16 Nov 2015 15:20:57 +0100 (CET)
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <CAK6PxWMhj55GpHAgWa-hS-gY=iRp7JsVyBy+XWi6HjThUakyFQ@mail.gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<90409445.3423948.1447611257010.JavaMail.zimbra@u-pem.fr>
	<CAK6PxWMhj55GpHAgWa-hS-gY=iRp7JsVyBy+XWi6HjThUakyFQ@mail.gmail.com>
Message-ID: <1625155799.438546.1447683657461.JavaMail.zimbra@u-pem.fr>

Reinier,
please answer to my mail, not to something i may have said.

My previous mail is not about security*, it's about stronger encapsulation.
To develop applications with several dozens of jars/modules, internal implementation details of a module should never leak outside of a module.

R?mi
* my mom told me to never use a 's' word. 

----- Mail original -----
> De: "Reinier Zwitserloot" <reinier at zwitserloot.com>
> ?: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoy?: Lundi 16 Novembre 2015 14:21:15
> Objet: Re: A way to opt out of access restrictions on non-exported members.
> 
> Security hardening? The security manager already stops .setAccessible() if
> you want it to, and if you don't stop that, you have no security anyway, so
> there's no point. I do not understand the argument of '... blocking
> .setAccessible() from letting you access members from non-exported packages
> is better for security' at all.
> 
> With some more depth:
> 
> On Sun, Nov 15, 2015 at 7:14 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> > - put all your modules in the classpath or remove all the module-info from
> > the modules in the module-path,
> > - create a jlink plugin that will crawle all modules (or the ones you
> > want) and change the module-info,
> > - at runtime to create a new layer that will bypass the application
> > classloader and change the module configuration on-the-fly.
> > And there are more exotic ways if you are able to change the bytecodes.
> >
> 
> Exactly. Exotic ways. These options sounds sufficiently user hostile that
> it'll slow JDK9 adoption significantly. A lot of them also don't sound like
> something that team jigsaw would want. For example, if most java
> deployments start dumping all the modules on the CP to get around this
> issue, then... what was the point of the module system in the first place?
> 
> I'm trying to make the point: This COULD lead to the community en masse
> establishing some hacky workaround as 'the new normal' because libraries
> simply do not have the tools to become JDK9 ready in time (or ever). That
> sounds like something to be avoided.
> 
> I don't understand the security element at all. The only way to cause
> security issues if .setAccessible() would let you break through exports
> requirements, is if untrusted code is allowed to run, in-process, on your
> own JVM in the first place*. There is NO WAY to have such code (untrusted,
> running in-process) be in any way or form safe unless a security manager is
> involved, and the security manager is _already_ set up to allow you to deny
> .setAccessible.
> 
> *) Technically, you could have code that calls .setAccessible(true) on an
> element that is found based on untrusted user input, but this sounds like a
> very exotic case, is already a security nightmare both in JDK8 and even in
> a fully modularized JDK9 world; if we take as written that accessing any
> element of a non-exported package is a huge security leak, how is accessing
> private members of exported packages perfectly fine? That makes no sense
> either.
> 
>  --Reinier Zwitserloot
> 

From ali.ebrahimi1781 at gmail.com  Mon Nov 16 16:25:49 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Mon, 16 Nov 2015 19:55:49 +0330
Subject: build error on windows
Message-ID: <CAA0cW5B4RL6iVUfaeR8j3AzFk5AOMPUTJmeCmrOQFijt+L6cuQ@mail.gmail.com>

Hi,

.
.
Creating jsoundds.dll from 4 file(s)
f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.
c(106) : error C2220: warning treated as error - no 'object' file generated
f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.
c(106) : warning C4101: 'stream' : unreferenced local variable
Awt2dLibraries.gmk:639: recipe for target
'/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj'
failedmake[3]: ***
[/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj]
Error 2

make/Main.gmk:204: recipe for target 'java.desktop-libs' failedmake[2]: ***
[java.desktop-libs] Error 1

make[2]: INTERNAL: Exiting with 1 jobserver tokens available; should be 2!

ERROR: Build failed for target 'all' in configuration 'win' (exit code 2)
=== Output from failing command(s) repeated here ===
* For target BUILD_LIBFONTMANAGER_freetypeScaler.c:freetypeScaler.c
f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.
c(106) : error C2220: warning treated as error - no 'object' file generated
f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.
c(106) : warning C4101: 'stream' : unreferenced local variable
=== End of repeated output ===
=== Make failure sequence repeated here ===
Awt2dLibraries.gmk:639: recipe for target
'/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj'
failed
make/Main.gmk:204: recipe for target 'java.desktop-libs' failed
=== End of repeated output ===
Hint: Try searching the build log for the name of the first failed target.
Hint: If caused by a warning, try configure --disable-warnings-as-errors.

/cygdrive/f/openjdk/jake/make/Init.gmk:278: recipe for target 'main' failed
make[1]: *** [main] Error 1
/cygdrive/f/openjdk/jake/make/Init.gmk:182: recipe for target 'all' failed
make: *** [all] Error 2
-- 

Best Regards,
Ali Ebrahimi

From philip.race at oracle.com  Mon Nov 16 16:34:15 2015
From: philip.race at oracle.com (Philip Race)
Date: Mon, 16 Nov 2015 08:34:15 -0800
Subject: build error on windows
In-Reply-To: <CAA0cW5B4RL6iVUfaeR8j3AzFk5AOMPUTJmeCmrOQFijt+L6cuQ@mail.gmail.com>
References: <CAA0cW5B4RL6iVUfaeR8j3AzFk5AOMPUTJmeCmrOQFijt+L6cuQ@mail.gmail.com>
Message-ID: <564A0587.9040608@oracle.com>

This is a known issue and the fix should go into jdk9/dev in about 24 hours.
--disable-warnings-as-errors will work around it.

-phil.

On 11/16/15, 8:25 AM, Ali Ebrahimi wrote:
> Hi,
>
> .
> .
> Creating jsoundds.dll from 4 file(s)
> f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.
> c(106) : error C2220: warning treated as error - no 'object' file generated
> f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.
> c(106) : warning C4101: 'stream' : unreferenced local variable
> Awt2dLibraries.gmk:639: recipe for target
> '/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj'
> failedmake[3]: ***
> [/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj]
> Error 2
>
> make/Main.gmk:204: recipe for target 'java.desktop-libs' failedmake[2]: ***
> [java.desktop-libs] Error 1
>
> make[2]: INTERNAL: Exiting with 1 jobserver tokens available; should be 2!
>
> ERROR: Build failed for target 'all' in configuration 'win' (exit code 2)
> === Output from failing command(s) repeated here ===
> * For target BUILD_LIBFONTMANAGER_freetypeScaler.c:freetypeScaler.c
> f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.
> c(106) : error C2220: warning treated as error - no 'object' file generated
> f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.
> c(106) : warning C4101: 'stream' : unreferenced local variable
> === End of repeated output ===
> === Make failure sequence repeated here ===
> Awt2dLibraries.gmk:639: recipe for target
> '/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj'
> failed
> make/Main.gmk:204: recipe for target 'java.desktop-libs' failed
> === End of repeated output ===
> Hint: Try searching the build log for the name of the first failed target.
> Hint: If caused by a warning, try configure --disable-warnings-as-errors.
>
> /cygdrive/f/openjdk/jake/make/Init.gmk:278: recipe for target 'main' failed
> make[1]: *** [main] Error 1
> /cygdrive/f/openjdk/jake/make/Init.gmk:182: recipe for target 'all' failed
> make: *** [all] Error 2

From ali.ebrahimi1781 at gmail.com  Mon Nov 16 16:37:56 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Mon, 16 Nov 2015 20:07:56 +0330
Subject: build error on windows
In-Reply-To: <564A0587.9040608@oracle.com>
References: <CAA0cW5B4RL6iVUfaeR8j3AzFk5AOMPUTJmeCmrOQFijt+L6cuQ@mail.gmail.com>
	<564A0587.9040608@oracle.com>
Message-ID: <CAA0cW5Dg6AEiKWEw2v+7HO8jW5jBzLXg1O1Vp9bhcS8tyak78Q@mail.gmail.com>

Thanks.

On Mon, Nov 16, 2015 at 8:04 PM, Philip Race <philip.race at oracle.com> wrote:

> This is a known issue and the fix should go into jdk9/dev in about 24
> hours.
> --disable-warnings-as-errors will work around it.
>
> -phil.
>
>
> On 11/16/15, 8:25 AM, Ali Ebrahimi wrote:
>
>> Hi,
>>
>> .
>> .
>> Creating jsoundds.dll from 4 file(s)
>>
>> f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.
>> c(106) : error C2220: warning treated as error - no 'object' file
>> generated
>>
>> f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.
>> c(106) : warning C4101: 'stream' : unreferenced local variable
>> Awt2dLibraries.gmk:639: recipe for target
>>
>> '/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj'
>> failedmake[3]: ***
>>
>> [/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj]
>> Error 2
>>
>> make/Main.gmk:204: recipe for target 'java.desktop-libs' failedmake[2]:
>> ***
>> [java.desktop-libs] Error 1
>>
>> make[2]: INTERNAL: Exiting with 1 jobserver tokens available; should be 2!
>>
>> ERROR: Build failed for target 'all' in configuration 'win' (exit code 2)
>> === Output from failing command(s) repeated here ===
>> * For target BUILD_LIBFONTMANAGER_freetypeScaler.c:freetypeScaler.c
>>
>> f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.
>> c(106) : error C2220: warning treated as error - no 'object' file
>> generated
>>
>> f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.
>> c(106) : warning C4101: 'stream' : unreferenced local variable
>> === End of repeated output ===
>> === Make failure sequence repeated here ===
>> Awt2dLibraries.gmk:639: recipe for target
>>
>> '/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj'
>> failed
>> make/Main.gmk:204: recipe for target 'java.desktop-libs' failed
>> === End of repeated output ===
>> Hint: Try searching the build log for the name of the first failed target.
>> Hint: If caused by a warning, try configure --disable-warnings-as-errors.
>>
>> /cygdrive/f/openjdk/jake/make/Init.gmk:278: recipe for target 'main'
>> failed
>> make[1]: *** [main] Error 1
>> /cygdrive/f/openjdk/jake/make/Init.gmk:182: recipe for target 'all' failed
>> make: *** [all] Error 2
>>
>


-- 

Best Regards,
Ali Ebrahimi

From Alan.Bateman at oracle.com  Mon Nov 16 16:45:18 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Nov 2015 16:45:18 +0000
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
Message-ID: <564A081E.3010809@oracle.com>



On 16/11/2015 12:28, Stephen Colebourne wrote:
> Access to private members of classes by reflection is indeed very,
> very common. I agree that JDK 9 needs to be cautious around this.
>
>
I think this thread is just highlighting the obvious tension between 
modules with encapsulation vs. serialization and other frameworks that 
need to break encapsulation. At this time then explicit modules have to 
opt-in to allow frameworks get access types in those packages. This can 
be done in the module declaration or at run-time via the API. The 
alternative is of course the all-powerful command line.

As regards setAccessible(true) then it would be nice to have it 
eventually go away in some future release. This would clearly require 
coming up with solutions to some difficult problems and use-cases.

-Alan

From njbartlett at gmail.com  Mon Nov 16 17:48:54 2015
From: njbartlett at gmail.com (Neil Bartlett)
Date: Mon, 16 Nov 2015 17:48:54 +0000
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <564A081E.3010809@oracle.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
Message-ID: <C05DAB25-7021-4AA7-8404-1A1FC3C57DFB@gmail.com>

Alan,

In your consideration does the following declaration break encapsulation of a module, assuming that package ?org.example.impl? is not exported?

	module foo {
		provides org.example.api.ServiceInterface with org.example.impl.ServiceImpl;
	}

This appears to allow the ServiceLoader to punch through encapsulation and obtain instances of a non-exported type. How does this differ from a declaration that one might see in a Dependency Injection framework such as Spring? I.e. something like:

	<bean class=?org.example.impl.ServiceImpl?> ?

Regards,
Neil


> On 16 Nov 2015, at 16:45, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 16/11/2015 12:28, Stephen Colebourne wrote:
>> Access to private members of classes by reflection is indeed very,
>> very common. I agree that JDK 9 needs to be cautious around this.
>> 
>> 
> I think this thread is just highlighting the obvious tension between modules with encapsulation vs. serialization and other frameworks that need to break encapsulation. At this time then explicit modules have to opt-in to allow frameworks get access types in those packages. This can be done in the module declaration or at run-time via the API. The alternative is of course the all-powerful command line.
> 
> As regards setAccessible(true) then it would be nice to have it eventually go away in some future release. This would clearly require coming up with solutions to some difficult problems and use-cases.
> 
> -Alan


From Alan.Bateman at oracle.com  Mon Nov 16 18:57:54 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Nov 2015 18:57:54 +0000
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <C05DAB25-7021-4AA7-8404-1A1FC3C57DFB@gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<C05DAB25-7021-4AA7-8404-1A1FC3C57DFB@gmail.com>
Message-ID: <564A2732.4030307@oracle.com>

On 16/11/2015 17:48, Neil Bartlett wrote:
> Alan,
>
> In your consideration does the following declaration break encapsulation of a module, assuming that package ?org.example.impl? is not exported?
>
> 	module foo {
> 		provides org.example.api.ServiceInterface with org.example.impl.ServiceImpl;
> 	}
>
> This appears to allow the ServiceLoader to punch through encapsulation and obtain instances of a non-exported type.
Sure, but this just part of the support for services. In this example 
then the service provider is fully encapsulated. The consumer of the 
service can't access ServiceImpl, it instead accesses it via 
ServiceInterface (assuming of course that the consumer reads the module 
with ServiceInterface and org.example.api is exported to the consumer).

>   How does this differ from a declaration that one might see in a Dependency Injection framework such as Spring? I.e. something like:
>
> 	<bean class=?org.example.impl.ServiceImpl?> ?
>
There isn't way to give Spring super powers so this needs foo to export 
org.example.impl to Spring.

-Alan.

From njbartlett at gmail.com  Mon Nov 16 19:41:25 2015
From: njbartlett at gmail.com (Neil Bartlett)
Date: Mon, 16 Nov 2015 19:41:25 +0000
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <564A2732.4030307@oracle.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<C05DAB25-7021-4AA7-8404-1A1FC3C57DFB@gmail.com>
	<564A2732.4030307@oracle.com>
Message-ID: <ED48165A-EB62-433A-814D-17BB6C47EC59@gmail.com>

Thanks Alan,

So you?re saying that ServiceLoader is permitted to have ?super powers? to punch through encapsulation, but other libraries are not. This is disappointing ? ServiceLoader is extremely limited in functionality, and is no match for any of the widely used DI frameworks like Spring, Guice, CDI etc. Why should this library be blessed above all others?

Neil


> On 16 Nov 2015, at 18:57, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 16/11/2015 17:48, Neil Bartlett wrote:
>> Alan,
>> 
>> In your consideration does the following declaration break encapsulation of a module, assuming that package ?org.example.impl? is not exported?
>> 
>> 	module foo {
>> 		provides org.example.api.ServiceInterface with org.example.impl.ServiceImpl;
>> 	}
>> 
>> This appears to allow the ServiceLoader to punch through encapsulation and obtain instances of a non-exported type.
> Sure, but this just part of the support for services. In this example then the service provider is fully encapsulated. The consumer of the service can't access ServiceImpl, it instead accesses it via ServiceInterface (assuming of course that the consumer reads the module with ServiceInterface and org.example.api is exported to the consumer).
> 
>>  How does this differ from a declaration that one might see in a Dependency Injection framework such as Spring? I.e. something like:
>> 
>> 	<bean class=?org.example.impl.ServiceImpl?> ?
>> 
> There isn't way to give Spring super powers so this needs foo to export org.example.impl to Spring.
> 
> -Alan.


From Alan.Bateman at oracle.com  Mon Nov 16 20:28:05 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Nov 2015 20:28:05 +0000
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <ED48165A-EB62-433A-814D-17BB6C47EC59@gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<C05DAB25-7021-4AA7-8404-1A1FC3C57DFB@gmail.com>
	<564A2732.4030307@oracle.com>
	<ED48165A-EB62-433A-814D-17BB6C47EC59@gmail.com>
Message-ID: <564A3C55.303@oracle.com>


On 16/11/2015 19:41, Neil Bartlett wrote:
> Thanks Alan,
>
> So you?re saying that ServiceLoader is permitted to have ?super powers? to punch through encapsulation, but other libraries are not. This is disappointing ? ServiceLoader is extremely limited in functionality, and is no match for any of the widely used DI frameworks like Spring, Guice, CDI etc. Why should this library be blessed above all others?

It's never been a goal to create a new DI framework. However there is a requirement to expose the service bindings via the ServiceLoader API [1]. Time will tell if we have to introduce a way for frameworks and serialization libraries to break encapsulation.

-Alan.

[1] http://openjdk.java.net/projects/jigsaw/spec/reqs/#binding

From harold.seigel at oracle.com  Mon Nov 16 20:56:24 2015
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Mon, 16 Nov 2015 20:56:24 +0000
Subject: hg: jigsaw/jake/hotspot: Set property sun.boot.class.path to NULL,
	and include Jiangli's build fix and other build fix.
Message-ID: <201511162056.tAGKuOVZ024421@aojmv0008.oracle.com>

Changeset: d83120ae736e
Author:    hseigel
Date:      2015-11-16 15:35 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d83120ae736e

Set property sun.boot.class.path to NULL, and include Jiangli's build fix and other build fix.

! src/share/vm/classfile/systemDictionaryShared.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/runtime/arguments.cpp
+ test/runtime/BootClassAppendProp/SunBootClassPath.java


From alex.buckley at oracle.com  Mon Nov 16 22:04:32 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 16 Nov 2015 14:04:32 -0800
Subject: Annotations across modules
In-Reply-To: <5649BBD4.4060405@netcetera.ch>
References: <CACzrW9CvQu0O=eVsuEb9PQRgoB+Zk2+p+idmgFgcQpSPqL+N5Q@mail.gmail.com>
	<5649BBD4.4060405@netcetera.ch>
Message-ID: <564A52F0.7090309@oracle.com>

On 11/16/2015 3:19 AM, Philippe Marschall wrote:
> On 12.11.15 14:50, Stephen Colebourne wrote:
>> My understanding of annotations today is that annotations are not
>> required at runtime. ie. if an annotation is placed into a class at
>> compile time but the .class file for the annotation is not available
>> on the runtime classpath. then there is no error.
>>
>> Does this change in any way with modules?
>>
>> My specific case is wrt @ConstructorProperties which is in java.beans.
>> In 9, a user may run my software without the java.beans module. Can I
>> safely assume that if the annotation is available on the compile
>> module path but not the runtime module path, everything will be OK
>> (ie. no error)?
>
> My understanding is that you can't have optional dependencies. So if you
> have @ConstructorProperties in your source you also need to have a
> java.desktop module dependency in your module-info.java. If your library
> is in the module path the java.desktop module then it needs to be
> present at runtime.
>
> The only option you have is to make your jar not a modular jar by one of
> those:
>   - not providing a module-info.class
>   - not putting your module in the module path

This is all true -- a static reference to 
java.beans.ConstructorProperties necessitates a dependency on 
java.desktop at compile time.

The reason for my stripped-down answer was that Stephen phrased the 
question using some rather abstract language -- "an annotation is placed 
into a class", "a user may run my software ...". This made me think 
something clever was going on -- for example, the user's dependency on 
java.desktop is factored out and Stephen's software receives a Class 
object for java.beans.ConstructorProperties from someone else.

Alex

From forax at univ-mlv.fr  Mon Nov 16 22:12:04 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 16 Nov 2015 23:12:04 +0100 (CET)
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
Message-ID: <739333142.678615.1447711924259.JavaMail.zimbra@u-pem.fr>

Hi Stephen,

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> ?: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoy?: Lundi 16 Novembre 2015 13:28:22
> Objet: Re: A way to opt out of access restrictions on non-exported members.
> 
> Access to private members of classes by reflection is indeed very,
> very common. I agree that JDK 9 needs to be cautious around this.
> 
> For me, I'm not yet sure I'm comfortable with setAccessible(true) no
> longer being sufficient to access them.
> 
> I did wonder if perhaps a change could be made such that any instance
> of 'Class' passed into a module would automatically be granted the
> necessary enhanced module readability. Unfortunately, I don't think it
> will be enough for most serialization frameworks, as they traverse a
> graph of objects.

We discuss something like this at Devoxx,
add a read edge between the current module and the module of the declaring class when you do a setAccessible on a member of that class.

This will not solved all the issues, frameworks will still not be able to call setAccessible on a non exported class but i think it will fix most of the issues if (and it's a big if) creators of modules do not allow non-exported classes to leak. 

> 
> I do think that there may need to be separate JDK 8 and 9 versions of
> many OSS libraries (for which the multi-version jar file is one
> option). This will certainly slow adoption.
> 
> Stephen

R?mi

> 
> 
> 
> On 15 November 2015 at 11:03, Reinier Zwitserloot
> <reinier at zwitserloot.com> wrote:
> > TL;DR: There are rather a lot of libraries out there that access private
> > members via reflection. I posit that almost all such libraries break
> > without an easy way to fix the problem, if there is no way to use
> > reflection to access non-exported members.
> >
> >
> >
> > setAccessible(true) doesn't let you opt out of module access rules. There
> > are ways to effectively 'read' everything (and if not, there's addRead),
> > but that still doesn't help if you need to reflectively access a member
> > that isn't exported. According to the questions at the end of the J1
> > session 'Advanced Modular Development (CON6821)', by Mark Reinhold, Alex
> > Buckley, and Alex Bateman, there is no way to in-process get around the
> > JVM-enforced access restriction.
> >
> > Now, under normal circumstances you shouldn't be accessing such classes /
> > methods / fields / constructors in the first place, but that exact same
> > line of reasoning can be used to defend not including setAccessible,
> > getDeclaredMethod(s), getDeclaredField(s), and all the other ways the
> > reflection API can be used to access (in JDK1-JDK8, at least) protected,
> > package private, and private elements. Those things were never designed to
> > be accessed either, and yet, accessing private members of existing stuff
> > occurs in lots of libraries, usually for:
> >
> > * Dependency injection (guice and company)
> >
> > * Debugging tools (not all of these use JVMTI; sometimes you just have a
> > utility method that dumps some information to a log that includes private
> > members just because that seems like it'll help debug an exotic condition
> > that you can't quite put your finger on).
> >
> > * Code automation tools (apache has a few utilities that return a useful
> > hashCode, which work by inspecting your instance's fields).
> >
> > * Serialization libraries. I'm pretty sure a number of core JDK devs have
> > gone on record not liking the built in serialization mechanism
> > (java.io.Serializable and co), but third party solutions access private
> > members all the time to do their job.
> >
> > * Workarounds. This one is a perhaps controversial, but as the saying goes,
> > java is a 'blue collar' programming language. Sometimes you use access to
> > private members to work around a bug or to get access to functionality that
> > optimally speaking should be done differently or should be accomodated with
> > an update to the library to make that part designed for public access.
> >
> > What are such libraries to do? They could provide the user with ways to use
> > command line switches to hack in the required exports, but this is the kind
> > of hassle that is going to reflect badly on JDK9 and slow adoption rates. I
> > propose some mechanism to get around the restriction is added, with all due
> > warnings in the documentation that this should be considered a hacky
> > workaround. (interestingly, such commentary is not part of the javadoc on
> > .setAccessible!)
> >
> > Alternatively, there are 3 ways this can go:
> >
> > * The authors of these libraries, or the help forums associated with such
> > libraries, start espousing the principle that you should just export
> > everything from your modules, or 'things might break'. This doesn't sound
> > like a desirable outcome for the jigsaw project. It certainly doesn't sound
> > desirable to me.
> >
> > * The authors of these libraries, or the help forums associated with this
> > libraries, start espousing the principle that upgrading to JDK9 is an
> > arduous slog, and that it is better to just stick with JDK8 for the
> > foreseeable future. Certainly, not a desirable outcome.
> >
> > * The heavens part, ponies and rainbows for all, and everyone takes the
> > time to update their serialized data structures or whatnot to make sense in
> > a 'these are exported, these are not' world. I'm not sure this is even
> > possible; it would make sense to have a public interface, and then 2
> > (non-exported!) classes that are implementations of this. How would a
> > no-hassle serialization library ever get this done without a way to dodge
> > the rules? A module can export _TO_ a serialization library, but this
> > breaks encapsulation: Now the author of framework A needs to know that the
> > user of said framework so happens to have a desire to serialize the stuff
> > from framework A using serialization library X. In practice you'd have to
> > export everything to all the serialization frameworks out there, and now no
> > new framework can ever be created because all these libraries failed to
> > export their internals to them. In any case this boils down to 'just export
> > every package to this subset of tools',  and that's the best case scenario,
> > which doesn't sound desirable either.
> >
> > I guess option 4 is: "Surely it won't be that bad", but that's a bit of a
> > gamble to make, given that the stakes are serious lack of adoption of JDK9,
> > or widespread misconfiguration of exports clauses.
> >
> > NB1: Note also that JDK9 has taken its time (and rightly so) to fix its
> > ball-o-twine dependency mess. However, once JDK9 is unleashed upon the
> > masses, a 'quick fix' to make libraries at least workable with JDK9
> > probably require such hacks. If it's not possible to do it, then libraries
> > won't be JDK9 ready for years. Perhaps other projects aren't as messy as
> > JDK pre-9 was, but let's not make that assumption.
> >
> > NB2: The module system already has a larger impact on adoption (compared to
> > 6, 7, or 8) simply because of the unavoidable differences inherent in what
> > jigsaw is doing (I bet a bunch of command line scripts are going to end up
> > breaking, for example, or at least will be obsolete). Adding more barriers
> > to adoption is something that should, in my opinion, by taken particularly
> > seriously for this release.
> >
> >  --Reinier Zwitserloot
> 

From forax at univ-mlv.fr  Mon Nov 16 22:37:49 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 16 Nov 2015 23:37:49 +0100 (CET)
Subject: Property Was: A way to opt out of access restrictions on
	non-exported members.
In-Reply-To: <CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
Message-ID: <194121383.681185.1447713469955.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> ?: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoy?: Lundi 16 Novembre 2015 13:28:22
> Objet: Re: A way to opt out of access restrictions on non-exported members.
> 

[...]

> Stephen
> PS. I'm reminded of Java's missing "properties" feature again, cf.
> http://jodastephen.github.io/property-alliance/

I still think we should introduce properties into the language and i agree with you that it should have a meta-model.

Here is how i see properties nowadays:
- a property represents a public value that can be implemented either as a field or using a getter and optionally a setter.
- declaring a property is done by using the keyword 'property' in front of a field.
- accessing a property is done by using '.' followed by the name of the property.
- a final property is a property that can only be read.
- an abstract property is a property with no backing field, a getter and a setter must be defined (only a getter if the property is final).
- The reflection API (this is the meta-model of Java) is enhanced by adding a class java.lang.reflect.Property that
  can be obtained by using getProperty(String)/getProperties() on a Class.
  The property is non mutable object (no setAccesssible), that is not parameterized and there is only one kind of property.

everything else can be implemented on top of this property spec.

and we (the community) should agree on the property spec we want and wait a Java release with no big language change in order to propose it.

regards,
R?mi

From scolebourne at joda.org  Mon Nov 16 23:43:16 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 16 Nov 2015 23:43:16 +0000
Subject: Annotations across modules
In-Reply-To: <564A52F0.7090309@oracle.com>
References: <CACzrW9CvQu0O=eVsuEb9PQRgoB+Zk2+p+idmgFgcQpSPqL+N5Q@mail.gmail.com>
	<5649BBD4.4060405@netcetera.ch> <564A52F0.7090309@oracle.com>
Message-ID: <CACzrW9A+72G26QGYBSn4HhEVV6Z8eRQxHmpGfqs1iGbnUQ+9MA@mail.gmail.com>

On 16 November 2015 at 22:04, Alex Buckley <alex.buckley at oracle.com> wrote:
> This is all true -- a static reference to java.beans.ConstructorProperties
> necessitates a dependency on java.desktop at compile time.
>
> The reason for my stripped-down answer was that Stephen phrased the question
> using some rather abstract language -- "an annotation is placed into a
> class", "a user may run my software ...". This made me think something
> clever was going on -- for example, the user's dependency on java.desktop is
> factored out and Stephen's software receives a Class object for
> java.beans.ConstructorProperties from someone else.

FWIW, the case I was considering no longer applies. Joda-Beans is a
source code generator. I was planning on always adding
@ConstructorProperties and relying on the fact that if the annotation
is not found at runtime it does not matter. But the discussion above
indicates that it will be hard to have a different set of modules at
compile time to runtime. In the end, I made generation of
@ConstructorProperties opt-in, so the problem effectively goes away.

I suspect that I will return to discuss optional dependencies before
too long, as it is a big concern of mine.

Stephen

From mandy.chung at oracle.com  Tue Nov 17 00:02:08 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 17 Nov 2015 00:02:08 +0000
Subject: hg: jigsaw/jake/jdk: 3 new changesets
Message-ID: <201511170002.tAH0281w017478@aojmv0008.oracle.com>

Changeset: 5babde7bd078
Author:    jjg
Date:      2015-11-13 15:55 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5babde7bd078

8142996: move jdk java/util/streams tests into java.base directories
Reviewed-by: mchung

! test/java/util/stream/bootlib/TEST.properties
+ test/java/util/stream/bootlib/java.base/java/util/stream/CollectorOps.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/DefaultMethodStreams.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/DoubleStreamTestDataProvider.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/DoubleStreamTestScenario.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/FlagDeclaringOp.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/IntStreamTestDataProvider.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/IntStreamTestScenario.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/IntermediateTestOp.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/LambdaTestHelpers.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/LambdaTestMode.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/LoggingTestCase.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/LongStreamTestDataProvider.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/LongStreamTestScenario.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/OpTestCase.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/SpliteratorTestHelper.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/StatefulTestOp.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/StatelessTestOp.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/StreamOpFlagTestHelper.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/StreamTestDataProvider.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/StreamTestScenario.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/TestData.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/TestFlagExpectedOp.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/ThowableHelper.java
- test/java/util/stream/bootlib/java/util/stream/CollectorOps.java
- test/java/util/stream/bootlib/java/util/stream/DefaultMethodStreams.java
- test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestDataProvider.java
- test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java
- test/java/util/stream/bootlib/java/util/stream/FlagDeclaringOp.java
- test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java
- test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java
- test/java/util/stream/bootlib/java/util/stream/IntermediateTestOp.java
- test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java
- test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java
- test/java/util/stream/bootlib/java/util/stream/LoggingTestCase.java
- test/java/util/stream/bootlib/java/util/stream/LongStreamTestDataProvider.java
- test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java
- test/java/util/stream/bootlib/java/util/stream/OpTestCase.java
- test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java
- test/java/util/stream/bootlib/java/util/stream/StatefulTestOp.java
- test/java/util/stream/bootlib/java/util/stream/StatelessTestOp.java
- test/java/util/stream/bootlib/java/util/stream/StreamOpFlagTestHelper.java
- test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java
- test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java
- test/java/util/stream/bootlib/java/util/stream/TestData.java
- test/java/util/stream/bootlib/java/util/stream/TestFlagExpectedOp.java
- test/java/util/stream/bootlib/java/util/stream/ThowableHelper.java
! test/java/util/stream/boottest/TEST.properties
+ test/java/util/stream/boottest/java.base/java/util/stream/DoubleNodeTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/FlagOpTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/IntNodeTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/LongNodeTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/NodeBuilderTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/NodeTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/SliceSpliteratorTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/StreamFlagsTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/StreamOpFlagsTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/StreamReuseTest.java
- test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
- test/java/util/stream/boottest/java/util/stream/FlagOpTest.java
- test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
- test/java/util/stream/boottest/java/util/stream/LongNodeTest.java
- test/java/util/stream/boottest/java/util/stream/NodeBuilderTest.java
- test/java/util/stream/boottest/java/util/stream/NodeTest.java
- test/java/util/stream/boottest/java/util/stream/SliceSpliteratorTest.java
- test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java
- test/java/util/stream/boottest/java/util/stream/StreamFlagsTest.java
- test/java/util/stream/boottest/java/util/stream/StreamOpFlagsTest.java
- test/java/util/stream/boottest/java/util/stream/StreamReuseTest.java
! test/java/util/stream/test/TEST.properties

Changeset: 7d50c0ed10ea
Author:    weijun
Date:      2015-11-16 12:54 +0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7d50c0ed10ea

8143015: 5 tests fail with error "Can't find source for class: java.util.stream.OpTestCase"
Reviewed-by: weijun
Contributed-by: felix.yang at oracle.com

! test/java/net/NetworkInterface/NetworkInterfaceStreamTest.java
! test/java/nio/file/Files/StreamLinesTest.java
! test/java/security/PermissionCollection/PermissionCollectionStreamTest.java
! test/java/util/Scanner/ScannerStreamTest.java
! test/java/util/regex/PatternStreamTest.java

Changeset: 5b75092f3ecc
Author:    mchung
Date:      2015-11-16 16:02 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5b75092f3ecc

Enable java.util.stream tests

! test/ProblemList.jake.txt
! test/java/net/NetworkInterface/NetworkInterfaceStreamTest.java
! test/java/nio/file/Files/StreamLinesTest.java
! test/java/security/PermissionCollection/PermissionCollectionStreamTest.java
! test/java/util/Scanner/ScannerStreamTest.java
! test/java/util/regex/PatternStreamTest.java
! test/java/util/stream/bootlib/TEST.properties
! test/java/util/stream/boottest/TEST.properties
! test/java/util/stream/test/TEST.properties


From mik3hall at gmail.com  Tue Nov 17 00:33:24 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 16 Nov 2015 18:33:24 -0600
Subject: jrt file system now has /package and /modules directories
In-Reply-To: <F7D087BC-725C-440D-BF08-D2ECF28C3F3E@gmail.com>
References: <55B3C320.8060705@oracle.com>
	<4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com>
	<55B48789.6020907@oracle.com>
	<7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com>
	<56491C13.9010203@oracle.com>
	<CBA81A07-B234-44B7-BAED-CF422666E551@gmail.com>
	<564988EA.3080005@oracle.com>
	<F7D087BC-725C-440D-BF08-D2ECF28C3F3E@gmail.com>
Message-ID: <93BA8310-EEC8-4CEB-8F90-1855C59F0802@gmail.com>

> On Nov 16, 2015, at 3:42 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>  Now I?ll probably have to reinstall 8 over the top to get it back to default.

Going OT again, but if of interest, this didn?t work.

I installed the 8 release from the web page. It did download the OS X dmg and seemed to install fine.
/usr/libexec/java_home 
/Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home

However,
java -version
openjdk version "1.9.0-internal"
OpenJDK Runtime Environment (build 1.9.0-internal-mjh_2015_11_15_10_18-b00)
OpenJDK 64-Bit Server VM (build 1.9.0-internal-mjh_2015_11_15_10_18-b00, mixed mode)

I am OK with 9, I haven?t had any problems related to it?s use yet for the jdk. But it seems I have to now maintain the jdk going forward through manual builds? 

Michael Hall






From mandy.chung at oracle.com  Tue Nov 17 03:12:32 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 16 Nov 2015 19:12:32 -0800
Subject: JDeps: detecting offending packages
In-Reply-To: <op.x75k44qvkdkhrr@robertscholte.dynamic.ziggo.nl>
References: <op.x717b917kdkhrr@robertscholte.dynamic.ziggo.nl>
	<56475144.9030205@oracle.com>
	<46139409-8DDF-4A17-94CB-4A9026242CDA@oracle.com>
	<56476186.7030807@oracle.com>
	<op.x75k44qvkdkhrr@robertscholte.dynamic.ziggo.nl>
Message-ID: <FD31859A-91E4-495D-B53D-CFBC7E658881@oracle.com>


> On Nov 15, 2015, at 9:49 AM, Robert Scholte <rfscholte at apache.org> wrote:
> 
> Ah, I see. Adding usage of java.awt.peer.ComponentPeer did indeed expose an offending package again.
> 
> Just out of interest: will jdeps only detect violations of JDK internal APIs or will it also detect violations on modules? In case I switch from executable jar to executable module it could happen that it breaks due to usage of non-exported packages, right?
> 

jdeps does the static analysis on class level and it will flag any use of JDK internal API regardless modules or non-modules.  

The RFE for jdeps would be to take into the module descriptor into account and see what other thing it could report (e.g. missing require public, stale require, etc). 

Mandy

> regards,
> Robert
> 
> Op Sat, 14 Nov 2015 17:29:58 +0100 schreef Alan Bateman <Alan.Bateman at oracle.com>:
> 
>> 
>> 
>> On 14/11/2015 16:05, Mandy Chung wrote:
>>> :
>>> I think jdeps should continue to flag the critical JDK internal APIs listed in JEP 260 but they are accessible at runtime.  I file a bug:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8143011
>>> 
>> I agree and I expect it will be straight-forward once they are moved to their own module.
>> 
>> -Alan.


From mandy.chung at oracle.com  Tue Nov 17 04:33:19 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 16 Nov 2015 20:33:19 -0800
Subject: RFR: 8139430
In-Reply-To: <5649DC71.60106@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<564256C7.60905@oracle.com>
	<CBB16E61-EB4B-4BF1-9696-0D2A4DADEBA9@oracle.com>
	<14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com>
	<5649DC71.60106@oracle.com>
Message-ID: <D909E983-EEC8-44FF-A3FE-0F5619120A6C@oracle.com>


> On Nov 16, 2015, at 5:38 AM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> 
> 
> On 16/11/2015 13:01, Alexandre (Shura) Iline wrote:
>> V6:
>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/
>> 
>> 
> This looks okay to me. For completeness then I assume the THreadMXBeanTool.waitUntilXXX methods should re-assert the interrupt status if interrupted when waiting.

+1

Mandy


From mandy.chung at oracle.com  Tue Nov 17 06:11:16 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 17 Nov 2015 06:11:16 +0000
Subject: hg: jigsaw/jake/hotspot: Add uses/provides for jdk.vm.ci module
Message-ID: <201511170611.tAH6BGR5009468@aojmv0008.oracle.com>

Changeset: 40952d9e4128
Author:    mchung
Date:      2015-11-16 22:11 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/40952d9e4128

Add uses/provides for jdk.vm.ci module

! src/jdk.vm.ci/share/classes/module-info.java


From frank.yuan at oracle.com  Tue Nov 17 10:02:19 2015
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 17 Nov 2015 18:02:19 +0800
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <564A2732.4030307@oracle.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>	<564A081E.3010809@oracle.com>	<C05DAB25-7021-4AA7-8404-1A1FC3C57DFB@gmail.com>
	<564A2732.4030307@oracle.com>
Message-ID: <045401d1211f$0d6c7710$28456530$@oracle.com>



> -----Original Message-----
> From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of Alan Bateman
> Subject: Re: A way to opt out of access restrictions on non-exported members.
> 
> On 16/11/2015 17:48, Neil Bartlett wrote:
> > Alan,
> >
> > In your consideration does the following declaration break encapsulation of a module, assuming that package ?org.example.impl? is
> not exported?
> >
> > 	module foo {
> > 		provides org.example.api.ServiceInterface with org.example.impl.ServiceImpl;
> > 	}
> >
> > This appears to allow the ServiceLoader to punch through encapsulation and obtain instances of a non-exported type.
> Sure, but this just part of the support for services. In this example then the service provider is fully encapsulated. The consumer of the
> service can't access ServiceImpl, it instead accesses it via ServiceInterface (assuming of course that the consumer reads the module
> with ServiceInterface and org.example.api is exported to the consumer).
> 
> >   How does this differ from a declaration that one might see in a Dependency Injection framework such as Spring? I.e. something like:
> >
> > 	<bean class=?org.example.impl.ServiceImpl?> ?
> >
> There isn't way to give Spring super powers so this needs foo to export org.example.impl to Spring.

I think exporting org.example.impl and then Spring reading is reasonable and enough for supporting DI framework, but is it ok to give super power to java.base?

I am not sure if it punches only for supporting ServiceLoader in AccessibleObject.java:
void checkCanSetAccessible(Class<?> caller, Class<?> declaringClass) {
        Module callerModule = caller.getModule();
        Module declaringModule = declaringClass.getModule();

        if (callerModule != declaringModule
                && callerModule != Object.class.getModule()) {

            // check reads
            if (!callerModule.canRead(declaringModule)) {
                String msg = "Unable to make member of "
                        + declaringClass + " accessible:  "
                        + callerModule + " does not read " + declaringModule;
                Reflection.throwInaccessibleObjectException(msg);
            }
          ....

Why we don't make special handling for use and provide in our code? that should also achieve Service loading.
At least, javadoc of AccessibleObject.setAccessible doesn't state java.base has special permission, we need to update if we keep this impl.

Frank

> 
> -Alan.


From alan.bateman at oracle.com  Tue Nov 17 10:55:28 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 17 Nov 2015 10:55:28 +0000
Subject: hg: jigsaw/jake/jaxp: API package for JEP 268 needs to be exported
Message-ID: <201511171055.tAHAtSdS027203@aojmv0008.oracle.com>

Changeset: ae316cf164c6
Author:    alanb
Date:      2015-11-17 10:54 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ae316cf164c6

API package for JEP 268 needs to be exported

! src/java.xml/share/classes/module-info.java


From sundararajan.athijegannathan at oracle.com  Tue Nov 17 11:59:12 2015
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Tue, 17 Nov 2015 11:59:12 +0000
Subject: hg: jigsaw/jake/jdk: 8141521: jrt file system's DirectoryStream
	reports child paths with wrong paths for directories under /packages
Message-ID: <201511171159.tAHBxb2W015935@aojmv0008.oracle.com>

Changeset: 67c711a267db
Author:    sundar
Date:      2015-11-17 12:56 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/67c711a267db

8141521: jrt file system's DirectoryStream reports child paths with wrong paths for directories under /packages
Reviewed-by: alanb

! src/java.base/share/classes/jdk/internal/jimage/UTF8String.java
! src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtFileSystem.java
! src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtPath.java
! src/java.base/share/classes/jdk/internal/jrtfs/JrtDirectoryStream.java
! src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedFileSystem.java
! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java
! test/jdk/internal/jrtfs/Basic.java


From jean-francois.denise at oracle.com  Tue Nov 17 12:39:58 2015
From: jean-francois.denise at oracle.com (Jean-Francois Denise)
Date: Tue, 17 Nov 2015 13:39:58 +0100
Subject: RFR: 8143126
Message-ID: <94617ED1-75DB-4CAA-99AA-06A2A74AEC42@oracle.com>

Hi,
I removed a noisy call to System.out.
Webrev http://cr.openjdk.java.net/~jfdenise/8143126/
Thanks.
JF




From alan.bateman at oracle.com  Tue Nov 17 13:26:59 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 17 Nov 2015 13:26:59 +0000
Subject: hg: jigsaw/jake/langtools: Temporarily exclude jshell tests
Message-ID: <201511171326.tAHDQxFj011487@aojmv0008.oracle.com>

Changeset: 4618e0097e6a
Author:    alanb
Date:      2015-11-17 13:26 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4618e0097e6a

Temporarily exclude jshell tests

! test/ProblemList.jake.txt


From jean-francois.denise at oracle.com  Tue Nov 17 14:41:19 2015
From: jean-francois.denise at oracle.com (jean-francois.denise at oracle.com)
Date: Tue, 17 Nov 2015 14:41:19 +0000
Subject: hg: jigsaw/jake/jdk: Fix for 8142485,
	Jake doesn't build on Windows after recent change to libjimage
Message-ID: <201511171441.tAHEfKdl001314@aojmv0008.oracle.com>

Changeset: e1579b30cbec
Author:    jfdenise
Date:      2015-11-17 15:41 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e1579b30cbec

Fix for 8142485, Jake doesn't build on Windows after recent change to libjimage
Reviewed-by: mchung, jlaskey

! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java
! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java
! src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java
! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java
! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp
! src/java.base/share/native/libjimage/imageDecompressor.cpp
! src/java.base/share/native/libjimage/imageDecompressor.hpp
! src/java.base/share/native/libjimage/imageFile.cpp


From erik.joelsson at oracle.com  Tue Nov 17 15:30:32 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 17 Nov 2015 15:30:32 +0000
Subject: hg: jigsaw/jake: Preparing makefiles for sjavac
Message-ID: <201511171530.tAHFUWUa014351@aojmv0008.oracle.com>

Changeset: 2cffaee2b44e
Author:    erikj
Date:      2015-11-17 16:26 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/2cffaee2b44e

Preparing makefiles for sjavac

! make/JrtfsJar.gmk
! make/common/JavaCompilation.gmk


From erik.joelsson at oracle.com  Tue Nov 17 15:30:38 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 17 Nov 2015 15:30:38 +0000
Subject: hg: jigsaw/jake/corba: Preparing makefiles for sjavac
Message-ID: <201511171531.tAHFV4Fc014660@aojmv0008.oracle.com>

Changeset: 341389d6ae08
Author:    erikj
Date:      2015-11-17 16:26 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/341389d6ae08

Preparing makefiles for sjavac

! make/gensrc/Gensrc-java.corba.gmk


From erik.joelsson at oracle.com  Tue Nov 17 15:31:24 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 17 Nov 2015 15:31:24 +0000
Subject: hg: jigsaw/jake/jdk: Preparing makefiles for sjavac
Message-ID: <201511171531.tAHFVO1v014927@aojmv0008.oracle.com>

Changeset: c40287b843b3
Author:    erikj
Date:      2015-11-17 16:26 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c40287b843b3

Preparing makefiles for sjavac

! make/CompileInterimRmic.gmk


From sundararajan.athijegannathan at oracle.com  Tue Nov 17 15:33:40 2015
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Tue, 17 Nov 2015 15:33:40 +0000
Subject: hg: jigsaw/jake/nashorn: 8142991: Re-examine
	jdk.scripting.nashorn.shell linked in JRE that drags in jdk.compiler
Message-ID: <201511171533.tAHFXe4M015859@aojmv0008.oracle.com>

Changeset: baa4d288d717
Author:    sundar
Date:      2015-11-17 16:33 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/baa4d288d717

8142991: Re-examine jdk.scripting.nashorn.shell linked in JRE that drags in jdk.compiler
Reviewed-by: jlaskey

! src/jdk.scripting.nashorn.shell/share/classes/module-info.java


From erik.joelsson at oracle.com  Tue Nov 17 15:38:22 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 17 Nov 2015 15:38:22 +0000
Subject: hg: jigsaw/jake: Jake part of JDK-8143141,
	makefile cleanup between jake and jdk9
Message-ID: <201511171538.tAHFcMEL016914@aojmv0008.oracle.com>

Changeset: 48e940c6eece
Author:    erikj
Date:      2015-11-17 16:38 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/48e940c6eece

Jake part of JDK-8143141, makefile cleanup between jake and jdk9

! common/autoconf/boot-jdk.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4
! common/bin/compare.sh
! make/CompileJavaModules.gmk
! make/HotspotWrapper.gmk
! make/StripBinaries.gmk
! make/common/JavaCompilation.gmk


From erik.joelsson at oracle.com  Tue Nov 17 15:38:51 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 17 Nov 2015 15:38:51 +0000
Subject: hg: jigsaw/jake/corba: Jake part of JDK-8143141,
	makefile cleanup between jake and jdk9
Message-ID: <201511171538.tAHFcp6o017026@aojmv0008.oracle.com>

Changeset: 355803ae4e8a
Author:    erikj
Date:      2015-11-17 16:38 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/355803ae4e8a

Jake part of JDK-8143141, makefile cleanup between jake and jdk9

! make/copy/Copy-java.corba.gmk


From erik.joelsson at oracle.com  Tue Nov 17 15:39:05 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 17 Nov 2015 15:39:05 +0000
Subject: hg: jigsaw/jake/hotspot: Jake part of JDK-8143141,
	makefile cleanup between jake and jdk9
Message-ID: <201511171539.tAHFd5Df017076@aojmv0008.oracle.com>

Changeset: 3cd01614795b
Author:    erikj
Date:      2015-11-17 16:38 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3cd01614795b

Jake part of JDK-8143141, makefile cleanup between jake and jdk9

! make/gensrc/Gensrc-jdk.vm.ci.gmk


From erik.joelsson at oracle.com  Tue Nov 17 15:39:44 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 17 Nov 2015 15:39:44 +0000
Subject: hg: jigsaw/jake/jdk: Jake part of JDK-8143141,
	makefile cleanup between jake and jdk9
Message-ID: <201511171539.tAHFdidf017325@aojmv0008.oracle.com>

Changeset: 2376cb553336
Author:    erikj
Date:      2015-11-17 16:38 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2376cb553336

Jake part of JDK-8143141, makefile cleanup between jake and jdk9

! make/copy/Copy-java.base.gmk
! make/copy/CopyCommon.gmk
! make/gensrc/Gensrc-java.management.gmk
! make/launcher/Launcher-java.base.gmk
! make/launcher/Launcher-java.corba.gmk
! make/launcher/Launcher-java.desktop.gmk
! make/launcher/Launcher-java.rmi.gmk
! make/launcher/Launcher-java.scripting.gmk
! make/launcher/Launcher-java.security.jgss.gmk
! make/launcher/Launcher-jdk.compiler.gmk
! make/launcher/Launcher-jdk.hotspot.agent.gmk
! make/launcher/Launcher-jdk.jartool.gmk
! make/launcher/Launcher-jdk.javadoc.gmk
! make/launcher/Launcher-jdk.jcmd.gmk
! make/launcher/Launcher-jdk.jconsole.gmk
! make/launcher/Launcher-jdk.jdeps.gmk
! make/launcher/Launcher-jdk.jdi.gmk
! make/launcher/Launcher-jdk.jlink.gmk
! make/launcher/Launcher-jdk.jshell.gmk
! make/launcher/Launcher-jdk.jvmstat.gmk
! make/launcher/Launcher-jdk.pack200.gmk
! make/launcher/Launcher-jdk.policytool.gmk
! make/launcher/Launcher-jdk.rmic.gmk
! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk
! make/launcher/Launcher-jdk.xml.bind.gmk
! make/launcher/Launcher-jdk.xml.ws.gmk
! make/launcher/LauncherCommon.gmk
! make/lib/CoreLibraries.gmk
! make/lib/Lib-java.instrument.gmk
! make/lib/Lib-jdk.crypto.ucrypto.gmk
! make/lib/Lib-jdk.internal.le.gmk
! make/lib/SecurityLibraries.gmk


From erik.joelsson at oracle.com  Tue Nov 17 15:40:06 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 17 Nov 2015 15:40:06 +0000
Subject: hg: jigsaw/jake/langtools: Jake part of JDK-8143141,
	makefile cleanup between jake and jdk9
Message-ID: <201511171540.tAHFe6dw017399@aojmv0008.oracle.com>

Changeset: d63276f7f746
Author:    erikj
Date:      2015-11-17 16:38 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d63276f7f746

Jake part of JDK-8143141, makefile cleanup between jake and jdk9

! make/gendata/Gendata-jdk.compiler.gmk


From mandy.chung at oracle.com  Tue Nov 17 16:58:04 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 17 Nov 2015 08:58:04 -0800
Subject: RFR: 8143126
In-Reply-To: <94617ED1-75DB-4CAA-99AA-06A2A74AEC42@oracle.com>
References: <94617ED1-75DB-4CAA-99AA-06A2A74AEC42@oracle.com>
Message-ID: <A6630923-9EB1-4806-A464-BCD767593115@oracle.com>


> On Nov 17, 2015, at 4:39 AM, Jean-Francois Denise <jean-francois.denise at oracle.com> wrote:
> 
> Hi,
> I removed a noisy call to System.out.
> Webrev http://cr.openjdk.java.net/~jfdenise/8143126

+1

Mandy


From mandy.chung at oracle.com  Tue Nov 17 23:13:18 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 17 Nov 2015 23:13:18 +0000
Subject: hg: jigsaw/jake/jdk: 2 new changesets
Message-ID: <201511172313.tAHNDJv8000592@aojmv0008.oracle.com>

Changeset: e5fcea3aa679
Author:    mchung
Date:      2015-11-17 15:12 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e5fcea3aa679

Enable the test case to verify unnamed module fails to load properties bundle from named module

! test/java/util/logging/modules/pkgs/p3/test/ResourceBundleTest.java

Changeset: 5aadb299a052
Author:    mchung
Date:      2015-11-17 15:13 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5aadb299a052

Merge



From pbenedict at apache.org  Wed Nov 18 01:18:43 2015
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 17 Nov 2015 19:18:43 -0600
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <564A081E.3010809@oracle.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
Message-ID: <CABLGb9w3YhmXUfROd04Mb-Dt_6M4zA0VgeXew-8QENQV5i9cvg@mail.gmail.com>

I don't see how this approach could ever work in an EE container. An
existing module can't guess who needs to reach inside to perform dependency
injection, annotation or class scanning. Can't there be some concept of a
"trusted" module (signed?) that gives it superuser access to any other
module? Obviously an EE container would fit this description.


Cheers,
Paul

On Mon, Nov 16, 2015 at 10:45 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 16/11/2015 12:28, Stephen Colebourne wrote:
>
>> Access to private members of classes by reflection is indeed very,
>> very common. I agree that JDK 9 needs to be cautious around this.
>>
>>
>> I think this thread is just highlighting the obvious tension between
> modules with encapsulation vs. serialization and other frameworks that need
> to break encapsulation. At this time then explicit modules have to opt-in
> to allow frameworks get access types in those packages. This can be done in
> the module declaration or at run-time via the API. The alternative is of
> course the all-powerful command line.
>
> As regards setAccessible(true) then it would be nice to have it eventually
> go away in some future release. This would clearly require coming up with
> solutions to some difficult problems and use-cases.
>
> -Alan
>

From peter.levart at gmail.com  Wed Nov 18 08:03:32 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 18 Nov 2015 09:03:32 +0100
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <564A2732.4030307@oracle.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<C05DAB25-7021-4AA7-8404-1A1FC3C57DFB@gmail.com>
	<564A2732.4030307@oracle.com>
Message-ID: <564C30D4.6080208@gmail.com>



On 11/16/2015 07:57 PM, Alan Bateman wrote:
> On 16/11/2015 17:48, Neil Bartlett wrote:
>> Alan,
>>
>> In your consideration does the following declaration break 
>> encapsulation of a module, assuming that package ?org.example.impl? 
>> is not exported?
>>
>>     module foo {
>>         provides org.example.api.ServiceInterface with 
>> org.example.impl.ServiceImpl;
>>     }
>>
>> This appears to allow the ServiceLoader to punch through 
>> encapsulation and obtain instances of a non-exported type.
> Sure, but this just part of the support for services. In this example 
> then the service provider is fully encapsulated. The consumer of the 
> service can't access ServiceImpl, it instead accesses it via 
> ServiceInterface (assuming of course that the consumer reads the 
> module with ServiceInterface and org.example.api is exported to the 
> consumer).
>
>> How does this differ from a declaration that one might see in a 
>> Dependency Injection framework such as Spring? I.e. something like:
>>
>>     <bean class=?org.example.impl.ServiceImpl?> ?
>>
> There isn't way to give Spring super powers so this needs foo to 
> export org.example.impl to Spring.
>
> -Alan.

Hi,

Just a thought (and I don't know yet if it is a good idea)...

ServiceLoader currently has the following method:

     public static <S> ServiceLoader<S> load(Class<S> service, 
ClassLoader loader)

With the following overload:

     public static <S> ServiceLoader<S> load(Class<S> service, 
ClassLoader loader, Function<Stream<Class<?>>, Stream<Class<?>>> 
streamManipulator)

We (or Spring) could use it like:

     ServiceLoader<ServiceInterface> loader = ServiceLoader.load(
         ServiceInterface.class,
         classLoader,
         stream -> stream.filter(implClass -> 
implClass.getName().equals("org.example.impl.ServiceImpl"))
     );

This could also be used to code various other strategies for service 
lookup, for example:

     public @interface Order {
         int value() default 100;
     }

     ServiceLoader<ServiceInterface> loader = ServiceLoader.load(
         ServiceInterface.class,
         classLoader,
         stream -> stream.sorted(
             comparing(implClass -> 
implClass.getAnnotation(Order.class), comparing(Order::value))
         )
     );


This way the powers of instantiating the implementation classes are left 
to ServiceLoader, but client can decide what implementation classes are 
chosen.


Regards, Peter


From Alan.Bateman at oracle.com  Wed Nov 18 09:17:36 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Nov 2015 09:17:36 +0000
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <CABLGb9w3YhmXUfROd04Mb-Dt_6M4zA0VgeXew-8QENQV5i9cvg@mail.gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<CABLGb9w3YhmXUfROd04Mb-Dt_6M4zA0VgeXew-8QENQV5i9cvg@mail.gmail.com>
Message-ID: <564C4230.1070802@oracle.com>


On 18/11/2015 01:18, Paul Benedict wrote:
> I don't see how this approach could ever work in an EE container. An 
> existing module can't guess who needs to reach inside to perform 
> dependency injection, annotation or class scanning. Can't there be 
> some concept of a "trusted" module (signed?) that gives it superuser 
> access to any other module? Obviously an EE container would fit this 
> description.
>
The EE container case might not be too bad as the EE container creates 
the configuration and so could arrange additional qualified exports when 
not using services. Details TBD, it might be that the container injects 
a helper into the application configuration, maybe it wraps the entry 
point so that code to export the otherwise internal packages to the 
framework/container. Modules are a fundamental change and it's important 
that we get it right. To that end, it's important to have a number of 
frameworks/containers working with us and helping to understand and work 
through the migration issues.

-Alan

From ali.ebrahimi1781 at gmail.com  Wed Nov 18 10:04:53 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Wed, 18 Nov 2015 13:34:53 +0330
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <564C4230.1070802@oracle.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<CABLGb9w3YhmXUfROd04Mb-Dt_6M4zA0VgeXew-8QENQV5i9cvg@mail.gmail.com>
	<564C4230.1070802@oracle.com>
Message-ID: <CAA0cW5DAYQFGGRhDQUT_+yTTBGjXx_BPyhAL4=BBnwt48d4_bw@mail.gmail.com>

Hi,
Currently only code inside java.base module can add (qualified)
exports programmatically.



On Wed, Nov 18, 2015 at 12:47 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
> On 18/11/2015 01:18, Paul Benedict wrote:
>
>> I don't see how this approach could ever work in an EE container. An
>> existing module can't guess who needs to reach inside to perform dependency
>> injection, annotation or class scanning. Can't there be some concept of a
>> "trusted" module (signed?) that gives it superuser access to any other
>> module? Obviously an EE container would fit this description.
>>
>> The EE container case might not be too bad as the EE container creates
> the configuration and so could arrange additional qualified exports when
> not using services. Details TBD, it might be that the container injects a
> helper into the application configuration, maybe it wraps the entry point
> so that code to export the otherwise internal packages to the
> framework/container. Modules are a fundamental change and it's important
> that we get it right. To that end, it's important to have a number of
> frameworks/containers working with us and helping to understand and work
> through the migration issues.
>
> -Alan
>



-- 

Best Regards,
Ali Ebrahimi

From Alan.Bateman at oracle.com  Wed Nov 18 10:23:08 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Nov 2015 10:23:08 +0000
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <CAA0cW5DAYQFGGRhDQUT_+yTTBGjXx_BPyhAL4=BBnwt48d4_bw@mail.gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<CABLGb9w3YhmXUfROd04Mb-Dt_6M4zA0VgeXew-8QENQV5i9cvg@mail.gmail.com>
	<564C4230.1070802@oracle.com>
	<CAA0cW5DAYQFGGRhDQUT_+yTTBGjXx_BPyhAL4=BBnwt48d4_bw@mail.gmail.com>
Message-ID: <564C518C.3050807@oracle.com>


On 18/11/2015 10:04, Ali Ebrahimi wrote:
> Hi,
> Currently only code inside java.base module can add (qualified) 
> exports programmatically.
>
Any module can export any of its packages to another module via the API.

In the EE container case then there are a number of options to explore. 
It would clearly be desirable to aim for services in the medium term. 
Failing that then the EE containers will be creating dynamic 
configurations and so should be able to arrange for the equivalent of 
the -XaddExports command-line option that we have for the boot layer.

-Alan

From ali.ebrahimi1781 at gmail.com  Wed Nov 18 10:55:23 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Wed, 18 Nov 2015 14:25:23 +0330
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <564C518C.3050807@oracle.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<CABLGb9w3YhmXUfROd04Mb-Dt_6M4zA0VgeXew-8QENQV5i9cvg@mail.gmail.com>
	<564C4230.1070802@oracle.com>
	<CAA0cW5DAYQFGGRhDQUT_+yTTBGjXx_BPyhAL4=BBnwt48d4_bw@mail.gmail.com>
	<564C518C.3050807@oracle.com>
Message-ID: <CAA0cW5BcxpSvXRxCQ2gbu7HcH2B-R3szD0f6eyWFP5NBYiKe+A@mail.gmail.com>

Hi,

On Wed, Nov 18, 2015 at 1:53 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
> On 18/11/2015 10:04, Ali Ebrahimi wrote:
>
> Hi,
> Currently only code inside java.base module can add (qualified)
> exports programmatically.
>
> Any module can export any of its packages to another module via the API.
>
> In the EE container case then there are a number of options to explore. It
> would clearly be desirable to aim for services in the medium term. Failing
> that then the EE containers will be creating dynamic configurations and so
> should be able to arrange for the equivalent of the -XaddExports
> command-line option that we have for the boot layer.
>
> -Alan
>
For adding exports as I know there is two options:

option 1: public

Module.addExports

@CallerSensitive
public Module addExports(String pn, Module target) {
    if (pn == null)
        throw new IllegalArgumentException("package is null");
    Objects.requireNonNull(target);

    if (isNamed()) {
        Module caller = Reflection.getCallerClass().getModule();
        if (caller != this) {
            throw new IllegalStateException(caller + " != " + this);
        }
        implAddExports(pn, target, true);
    }

    return this;
}



option 2: internal for java.base

jdk.internal.module.Modules.addExports(source, pn, target)



As you can see option 1 is useless, why?
because

/**
 * If the caller's module is this module then update this module to export
 * package {@code pn} to the given {@code target} module.

 I think for all use cases we would have caller's module != this module
So this don't work.

Option 2 will fail since that is internal for java.base purpose only.

Is there other options? (non-command-line options)

-- 

Best Regards,
Ali Ebrahimi

From Alan.Bateman at oracle.com  Wed Nov 18 11:08:19 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Nov 2015 11:08:19 +0000
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <CAA0cW5BcxpSvXRxCQ2gbu7HcH2B-R3szD0f6eyWFP5NBYiKe+A@mail.gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<CABLGb9w3YhmXUfROd04Mb-Dt_6M4zA0VgeXew-8QENQV5i9cvg@mail.gmail.com>
	<564C4230.1070802@oracle.com>
	<CAA0cW5DAYQFGGRhDQUT_+yTTBGjXx_BPyhAL4=BBnwt48d4_bw@mail.gmail.com>
	<564C518C.3050807@oracle.com>
	<CAA0cW5BcxpSvXRxCQ2gbu7HcH2B-R3szD0f6eyWFP5NBYiKe+A@mail.gmail.com>
Message-ID: <564C5C23.3050107@oracle.com>



On 18/11/2015 10:55, Ali Ebrahimi wrote:
> :
>
> Is there other options? (non-command-line options)
>
As I said in one of the previous mails, there are a number of things 
that can be explored. The EE container creating the configuration can 
control the exports, it can completely override module declarations if 
it really wants to. Another option might be wrapping the entry point so 
that the any additional exports are set when the container is launching 
the application. I think we should be confident that we can work through 
all these issues and come up with the right solutions.

-Alan

From erik.joelsson at oracle.com  Wed Nov 18 11:21:56 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 18 Nov 2015 11:21:56 +0000
Subject: hg: jigsaw/jake: Fixed compilation error when importing modules
Message-ID: <201511181121.tAIBLugr024112@aojmv0008.oracle.com>

Changeset: 677465fa89aa
Author:    erikj
Date:      2015-11-18 12:21 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/677465fa89aa

Fixed compilation error when importing modules

! make/CompileJavaModules.gmk


From erik.joelsson at oracle.com  Wed Nov 18 11:58:39 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 18 Nov 2015 11:58:39 +0000
Subject: hg: jigsaw/jake: Reverting unneeded jigsaw specific changes
Message-ID: <201511181158.tAIBwe4g005044@aojmv0008.oracle.com>

Changeset: 903bd87f9402
Author:    erikj
Date:      2015-11-18 12:52 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/903bd87f9402

Reverting unneeded jigsaw specific changes

! common/autoconf/buildjdk-spec.gmk.in
! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4
! make/CompileJavaModules.gmk
! make/CreateBuildJdkCopy.gmk
! make/CreateJmods.gmk
! make/GensrcModuleInfo.gmk
! make/Images.gmk
! make/Javadoc.gmk
! make/Main.gmk
! make/MainSupport.gmk
! make/ModuleWrapper.gmk
! make/StripBinaries.gmk
! make/ZipSource.gmk
! make/common/MakeBase.gmk


From erik.joelsson at oracle.com  Wed Nov 18 11:58:54 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 18 Nov 2015 11:58:54 +0000
Subject: hg: jigsaw/jake/corba: Reverting unneeded jigsaw specific changes
Message-ID: <201511181158.tAIBws8d005140@aojmv0008.oracle.com>

Changeset: 2cc9f6df4e50
Author:    erikj
Date:      2015-11-18 12:52 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/corba/rev/2cc9f6df4e50

Reverting unneeded jigsaw specific changes

! make/copy/Copy-java.corba.gmk
! make/gensrc/Gensrc-java.corba.gmk


From erik.joelsson at oracle.com  Wed Nov 18 11:59:08 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 18 Nov 2015 11:59:08 +0000
Subject: hg: jigsaw/jake/hotspot: Reverting unneeded jigsaw specific changes
Message-ID: <201511181159.tAIBx8mo005259@aojmv0008.oracle.com>

Changeset: 222c2519e1cb
Author:    erikj
Date:      2015-11-18 12:52 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/222c2519e1cb

Reverting unneeded jigsaw specific changes

! make/gensrc/Gensrc-jdk.vm.ci.gmk


From erik.joelsson at oracle.com  Wed Nov 18 11:59:46 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 18 Nov 2015 11:59:46 +0000
Subject: hg: jigsaw/jake/jdk: Reverting unneeded jigsaw specific changes
Message-ID: <201511181159.tAIBxkW6005763@aojmv0008.oracle.com>

Changeset: fa885780a428
Author:    erikj
Date:      2015-11-18 12:52 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fa885780a428

Reverting unneeded jigsaw specific changes

! make/Import.gmk
! make/copy/CopyCommon.gmk
! make/gendata/Gendata-java.base.gmk
! make/gendata/GendataBlacklistedCerts.gmk
! make/gendata/GendataFontConfig.gmk
! make/gendata/GendataPolicyJars.gmk
! make/gendata/GendataTZDB.gmk
! make/gensrc/Gensrc-jdk.charsets.gmk
! make/gensrc/Gensrc-jdk.jdi.gmk
! make/gensrc/GensrcBuffer.gmk
! make/gensrc/GensrcCLDR.gmk
! make/gensrc/GensrcCharacterData.gmk
! make/gensrc/GensrcCharsetCoder.gmk
! make/gensrc/GensrcCharsetMapping.gmk
! make/gensrc/GensrcExceptions.gmk
! make/gensrc/GensrcIcons.gmk
! make/gensrc/GensrcLocaleData.gmk
! make/gensrc/GensrcMisc.gmk
! make/gensrc/GensrcModuleLoaderMap.gmk
! make/gensrc/GensrcProperties.gmk
! make/gensrc/GensrcSwing.gmk
! make/gensrc/GensrcX11Wrappers.gmk
! make/launcher/Launcher-java.base.gmk
! make/launcher/Launcher-jdk.accessibility.gmk
! make/launcher/Launcher-jdk.pack200.gmk
! make/launcher/LauncherCommon.gmk
! make/lib/Awt2dLibraries.gmk
! make/lib/CoreLibraries.gmk
! make/lib/Lib-java.instrument.gmk
! make/lib/Lib-java.management.gmk
! make/lib/Lib-java.prefs.gmk
! make/lib/Lib-java.security.jgss.gmk
! make/lib/Lib-java.smartcardio.gmk
! make/lib/Lib-jdk.accessibility.gmk
! make/lib/Lib-jdk.attach.gmk
! make/lib/Lib-jdk.crypto.ec.gmk
! make/lib/Lib-jdk.crypto.mscapi.gmk
! make/lib/Lib-jdk.crypto.pkcs11.gmk
! make/lib/Lib-jdk.crypto.ucrypto.gmk
! make/lib/Lib-jdk.deploy.osx.gmk
! make/lib/Lib-jdk.internal.le.gmk
! make/lib/Lib-jdk.jdi.gmk
! make/lib/Lib-jdk.jdwp.agent.gmk
! make/lib/Lib-jdk.management.gmk
! make/lib/Lib-jdk.pack200.gmk
! make/lib/Lib-jdk.sctp.gmk
! make/lib/Lib-jdk.security.auth.gmk
! make/lib/LibCommon.gmk
! make/lib/NetworkingLibraries.gmk
! make/lib/NioLibraries.gmk
! make/lib/PlatformLibraries.gmk
! make/lib/SecurityLibraries.gmk
! make/lib/SoundLibraries.gmk


From erik.joelsson at oracle.com  Wed Nov 18 12:00:14 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 18 Nov 2015 12:00:14 +0000
Subject: hg: jigsaw/jake/langtools: Reverting unneeded jigsaw specific changes
Message-ID: <201511181200.tAIC0Ep5006077@aojmv0008.oracle.com>

Changeset: 70ad7a14ed9b
Author:    erikj
Date:      2015-11-18 12:52 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/70ad7a14ed9b

Reverting unneeded jigsaw specific changes

! make/CompileInterim.gmk
! make/gendata/Gendata-jdk.compiler.gmk
! make/gensrc/GensrcCommon.gmk


From forax at univ-mlv.fr  Wed Nov 18 12:18:37 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 18 Nov 2015 13:18:37 +0100 (CET)
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <C05DAB25-7021-4AA7-8404-1A1FC3C57DFB@gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<C05DAB25-7021-4AA7-8404-1A1FC3C57DFB@gmail.com>
Message-ID: <395283695.1610546.1447849117169.JavaMail.zimbra@u-pem.fr>

Hi Neil,

If you already have an instance of a non exported type, then there is no issue because applications only access this instance through an interface which is itself exported.

The main issue if how to create such instance, we need a factory which works in jigsaw mode.
You can not use reflection to automatically implement such factory because trying to call a constructor of a non exported class will be rejected by jigsaw.

Here, you have several solutions:
 - as Alan said, if you are a container you control the module configurations, so you control if package is exported or not but that's cheating,
   because the container changes the module configuration written by the user.
 - as you said you can use the mechanism of ServiceLoader or your favorite DI can use the ServiceLoader under the hood BTW,
 - you can re-implement a strawman version of the ServiceLoader by writing a code inside the implementation class that will add a factory
   (a lambda) inside a hashmap (a registry) which is globally accessible.
   
Or you can consider that an implementation that is globally available should be in an exported package because the configuration code (yes code, no XML and no annotation) should access it.

cheers,
R?mi

----- Mail original -----
> De: "Neil Bartlett" <njbartlett at gmail.com>
> ?: "Alan Bateman" <Alan.Bateman at oracle.com>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoy?: Lundi 16 Novembre 2015 18:48:54
> Objet: Re: A way to opt out of access restrictions on non-exported members.
> 
> Alan,
> 
> In your consideration does the following declaration break encapsulation of a
> module, assuming that package ?org.example.impl? is not exported?
> 
> 	module foo {
> 		provides org.example.api.ServiceInterface with
> 		org.example.impl.ServiceImpl;
> 	}
> 
> This appears to allow the ServiceLoader to punch through encapsulation and
> obtain instances of a non-exported type. How does this differ from a
> declaration that one might see in a Dependency Injection framework such as
> Spring? I.e. something like:
> 
> 	<bean class=?org.example.impl.ServiceImpl?> ?
> 
> Regards,
> Neil
> 
> 
> > On 16 Nov 2015, at 16:45, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> > 
> > 
> > 
> > On 16/11/2015 12:28, Stephen Colebourne wrote:
> >> Access to private members of classes by reflection is indeed very,
> >> very common. I agree that JDK 9 needs to be cautious around this.
> >> 
> >> 
> > I think this thread is just highlighting the obvious tension between
> > modules with encapsulation vs. serialization and other frameworks that
> > need to break encapsulation. At this time then explicit modules have to
> > opt-in to allow frameworks get access types in those packages. This can be
> > done in the module declaration or at run-time via the API. The alternative
> > is of course the all-powerful command line.
> > 
> > As regards setAccessible(true) then it would be nice to have it eventually
> > go away in some future release. This would clearly require coming up with
> > solutions to some difficult problems and use-cases.
> > 
> > -Alan
> 
> 

From ali.ebrahimi1781 at gmail.com  Wed Nov 18 12:27:58 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Wed, 18 Nov 2015 15:57:58 +0330
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <564C5C23.3050107@oracle.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<CABLGb9w3YhmXUfROd04Mb-Dt_6M4zA0VgeXew-8QENQV5i9cvg@mail.gmail.com>
	<564C4230.1070802@oracle.com>
	<CAA0cW5DAYQFGGRhDQUT_+yTTBGjXx_BPyhAL4=BBnwt48d4_bw@mail.gmail.com>
	<564C518C.3050807@oracle.com>
	<CAA0cW5BcxpSvXRxCQ2gbu7HcH2B-R3szD0f6eyWFP5NBYiKe+A@mail.gmail.com>
	<564C5C23.3050107@oracle.com>
Message-ID: <CAA0cW5DG5D9L=A8dQ6BrmCmvodU+btQA6RisVLAZmGBjZyAi5Q@mail.gmail.com>

Hi,

On Wed, Nov 18, 2015 at 2:38 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 18/11/2015 10:55, Ali Ebrahimi wrote:
>
> :
>
> Is there other options? (non-command-line options)
>
> As I said in one of the previous mails, there are a number of things that
> can be explored. The EE container creating the configuration can control
> the exports, it can completely override module declarations if it really
> wants to. Another option might be wrapping the entry point so that the any
> additional exports are set when the container is launching the application.
> I think we should be confident that we can work through all these issues
> and come up with the right solutions.
>
I think we need some friend (or privileged or trusted or bootstrapper)
module concept that have full access for all modules in configuration that
this module created.

bootstrapper module == configuration creator module
This can be used for all containers (EE or OSGI or Spring, ..., even my toy
jakecontainer ).

-- 

Best Regards,
Ali Ebrahimi

From erik.joelsson at oracle.com  Wed Nov 18 12:56:21 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 18 Nov 2015 12:56:21 +0000
Subject: hg: jigsaw/jake: Removed some more outdated jigsaw specifics parts
	from build files
Message-ID: <201511181256.tAICuLw3026267@aojmv0008.oracle.com>

Changeset: 7cf69b6b3538
Author:    erikj
Date:      2015-11-18 13:56 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/7cf69b6b3538

Removed some more outdated jigsaw specifics parts from build files

! common/autoconf/configure.ac
! common/autoconf/flags.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in


From harold.seigel at oracle.com  Wed Nov 18 15:00:47 2015
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Wed, 18 Nov 2015 15:00:47 +0000
Subject: hg: jigsaw/jake/hotspot: Add call to forName() so a class in package
	sun/invoke/util/ is referenced before requesting its location.
Message-ID: <201511181500.tAIF0l78005997@aojmv0008.oracle.com>

Changeset: 3f1ab53fc90d
Author:    hseigel
Date:      2015-11-18 09:38 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3f1ab53fc90d

Add call to forName() so a class in package sun/invoke/util/ is referenced before requesting its location.

! test/runtime/getSysPackage/GetSysPkgTest.java


From erik.joelsson at oracle.com  Wed Nov 18 16:15:50 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 18 Nov 2015 16:15:50 +0000
Subject: hg: jigsaw/jake: Refixed cross compilation
Message-ID: <201511181615.tAIGFo81003115@aojmv0008.oracle.com>

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

Refixed cross compilation

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


From alan.bateman at oracle.com  Wed Nov 18 16:49:29 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 18 Nov 2015 16:49:29 +0000
Subject: hg: jigsaw/jake/jdk: 2 new changesets
Message-ID: <201511181649.tAIGnTJs016512@aojmv0008.oracle.com>

Changeset: c1a46b310ca2
Author:    alanb
Date:      2015-11-18 15:15 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c1a46b310ca2

Using -limitmods so that it includes, but does not resolve, the modules
specified to -m and -addmods

! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/JlinkTask.java
! test/jdk/jigsaw/launcher/addmods/AddModsTest.java
! test/jdk/jigsaw/launcher/limitmods/LimitModsTest.java

Changeset: 1d2dd559597e
Author:    alanb
Date:      2015-11-18 16:47 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1d2dd559597e

Part 1 of Class::getPackageName

! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/sun/reflect/Reflection.java
+ test/java/lang/Class/getPackageName/Basic.java


From markus.gronlund at oracle.com  Wed Nov 18 17:45:23 2015
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 18 Nov 2015 09:45:23 -0800 (PST)
Subject: RFR(XS): 8143228: Update module exports for Java Flight Recorder
Message-ID: <d4430a57-609c-4015-af50-767d12994f47@default>

Greetings,

 

Looking for review of the following to update module exports for Java Flight Recorder:

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8143228

 

Change:

 

Patch is attached and also unrolled here:

 

# HG changeset patch

# User mgronlun

# Date 1447764614 -3600

#      Tue Nov 17 13:50:14 2015 +0100

# Node ID e452cc5ea183f4db155514a5ae6201e83ef70c95

# Parent  93f2a16f683dd52cbe08ab3aa277535db13473ee

[mq]: jdk_top_level

 

diff --git a/common/bin/compare_exceptions.sh.incl b/common/bin/compare_exceptions.sh.incl

--- a/common/bin/compare_exceptions.sh.incl

+++ b/common/bin/compare_exceptions.sh.incl

@@ -231,7 +231,6 @@

./lib/amd64/libjava.so

./lib/amd64/libjawt.so

./lib/amd64/libjdwp.so

-./lib/amd64/libjfr.so

./lib/amd64/libjpeg.so

./lib/amd64/libjsdt.so

./lib/amd64/libjsound.so

@@ -364,7 +363,6 @@

./lib/sparcv9/libjava.so

./lib/sparcv9/libjawt.so

./lib/sparcv9/libjdwp.so

-./lib/sparcv9/libjfr.so

./lib/sparcv9/libjpeg.so

./lib/sparcv9/libjsdt.so

./lib/sparcv9/libjsound.so

diff --git a/modules.xml b/modules.xml

--- a/modules.xml

+++ b/modules.xml

@@ -236,6 +236,22 @@

       <to>jdk.scripting.nashorn</to>

     </export>

     <export>

+      <name>jdk.internal.org.xml.sax</name>

+      <to>jdk.jfr</to>

+    </export>

+    <export>

+      <name>jdk.internal.org.xml.sax.helpers</name>

+      <to>jdk.jfr</to>

+    </export>

+    <export>

+      <name>jdk.internal.util.xml</name>

+      <to>jdk.jfr</to>

+    </export>

+    <export>

+      <name>jdk.internal.util.xml.impl</name>

+      <to>jdk.jfr</to>

+    </export>

+    <export>

       <name>jdk.internal.org.objectweb.asm</name>

       <to>java.instrument</to>

       <to>jdk.jfr</to>

@@ -287,6 +303,7 @@

       <to>jdk.httpserver</to>

       <to>jdk.jartool</to>

       <to>jdk.jconsole</to>

+      <to>jdk.jfr</to>

       <to>jdk.jvmstat</to>

       <to>jdk.management.resource</to>

       <to>jdk.pack200</to>

@@ -869,6 +886,7 @@

       <name>sun.management.spi</name>

       <to>jdk.management</to>

       <to>jdk.management.cmm</to>

+      <to>jdk.management.jfr</to>

     </export>

   </module>

   <module>

 

 

Thanks in advance
Markus

From Alan.Bateman at oracle.com  Wed Nov 18 19:25:05 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Nov 2015 19:25:05 +0000
Subject: RFR(XS): 8143228: Update module exports for Java Flight Recorder
In-Reply-To: <d4430a57-609c-4015-af50-767d12994f47@default>
References: <d4430a57-609c-4015-af50-767d12994f47@default>
Message-ID: <564CD091.4080509@oracle.com>



On 18/11/2015 17:45, Markus Gronlund wrote:
> Greetings,
>
>   
>
> Looking for review of the following to update module exports for Java Flight Recorder:
>
>   
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143228
>
>   
>
> Change:
>
>
The changes to modules.xml look okay although I think we should figure 
out a way to drop these dependences at some point.

-Alan

From markus.gronlund at oracle.com  Wed Nov 18 19:58:47 2015
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 18 Nov 2015 11:58:47 -0800 (PST)
Subject: RFR(XS): 8143228: Update module exports for Java Flight Recorder
In-Reply-To: <564CD091.4080509@oracle.com>
References: <d4430a57-609c-4015-af50-767d12994f47@default>
	<564CD091.4080509@oracle.com>
Message-ID: <12c349e5-d9c2-4849-899a-2be37935c386@default>

Thank you Alan.

I agree on coming up with a evolution path here. Thanks for now.

/Markus

-----Original Message-----
From: Alan Bateman 
Sent: den 18 november 2015 20:25
To: Markus Gronlund; jigsaw-dev at openjdk.java.net; serviceability-dev
Subject: Re: RFR(XS): 8143228: Update module exports for Java Flight Recorder



On 18/11/2015 17:45, Markus Gronlund wrote:
> Greetings,
>
>   
>
> Looking for review of the following to update module exports for Java Flight Recorder:
>
>   
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143228
>
>   
>
> Change:
>
>
The changes to modules.xml look okay although I think we should figure out a way to drop these dependences at some point.

-Alan

From amy.lu at oracle.com  Thu Nov 19 14:03:33 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 19 Nov 2015 22:03:33 +0800
Subject: [jake] RFR JDK-8132672: DGCDeadLock test needs to be updated to wok
	with update setAccessible
Message-ID: <564DD6B5.6090303@oracle.com>

java/rmi/transport/dgcDeadLock/DGCDeadLock.java is a white-box test that 
needs to access internal objects by purpose.

This patch is to add "-XaddExports" to the test. Please review.

bug: https://bugs.openjdk.java.net/browse/JDK-8132672
webrev: http://cr.openjdk.java.net/~amlu/8132672/webrev.00

Thanks,
Amy

--- old/test/ProblemList.jake.txt	2015-11-19 17:52:25.000000000 +0800
+++ new/test/ProblemList.jake.txt	2015-11-19 17:52:25.000000000 +0800
@@ -66,9 +66,6 @@
  # 8078484
  sun/rmi/rmic/newrmic/equivalence/run.sh				generic-all
  
-# 8132672
-java/rmi/transport/dgcDeadLock/DGCDeadLock.java			generic-all
-
  ############################################################################
  
  # jdk_other
--- old/test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java	2015-11-19 17:52:26.000000000 +0800
+++ new/test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java	2015-11-19 17:52:26.000000000 +0800
@@ -74,6 +74,10 @@
          try {
              String options = " -Djava.security.policy=" +
                  TestParams.defaultPolicy +
+                " -XaddExports:java.rmi/sun.rmi.registry=ALL-UNNAMED," +
+                "java.rmi/sun.rmi.server=ALL-UNNAMED," +
+                "java.rmi/sun.rmi.transport=ALL-UNNAMED," +
+                "java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED" +
                  " -Djava.rmi.dgc.leaseValue=500000" +
                  "  -Dsun.rmi.dgc.checkInterval=" +
                  (HOLD_TARGET_TIME - 5000) +



From Alan.Bateman at oracle.com  Thu Nov 19 14:27:28 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Nov 2015 14:27:28 +0000
Subject: [jake] RFR JDK-8132672: DGCDeadLock test needs to be updated to
	wok with update setAccessible
In-Reply-To: <564DD6B5.6090303@oracle.com>
References: <564DD6B5.6090303@oracle.com>
Message-ID: <564DDC50.1000106@oracle.com>

On 19/11/2015 14:03, Amy Lu wrote:
> java/rmi/transport/dgcDeadLock/DGCDeadLock.java is a white-box test 
> that needs to access internal objects by purpose.
>
> This patch is to add "-XaddExports" to the test. Please review.
This looks okay to me, thanks for taking this one.

-Alan.

From alan.bateman at oracle.com  Thu Nov 19 15:03:40 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 19 Nov 2015 15:03:40 +0000
Subject: hg: jigsaw/jake/jdk: 8132672: DGCDeadLock test needs to be updated to
	wok with modules
Message-ID: <201511191503.tAJF3eOa029854@aojmv0008.oracle.com>

Changeset: e8a58d7ea798
Author:    amlu
Date:      2015-11-19 15:03 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e8a58d7ea798

8132672: DGCDeadLock test needs to be updated to wok with modules

! test/ProblemList.jake.txt
! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java


From alexandre.iline at oracle.com  Thu Nov 19 16:40:17 2015
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Thu, 19 Nov 2015 08:40:17 -0800
Subject: RFR: 8139430
In-Reply-To: <D909E983-EEC8-44FF-A3FE-0F5619120A6C@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<564256C7.60905@oracle.com>
	<CBB16E61-EB4B-4BF1-9696-0D2A4DADEBA9@oracle.com>
	<14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com>
	<5649DC71.60106@oracle.com>
	<D909E983-EEC8-44FF-A3FE-0F5619120A6C@oracle.com>
Message-ID: <083D7050-8850-4D0E-B97B-7523857ABECC@oracle.com>

Yes, sorry.

Since the methods do not have any work to complete before interrupting and also methods are not used anywhere currently, I assume re-throwing the InterruptedException is a better choice.

http://cr.openjdk.java.net/~shurailine/8139430/webrev.07/test/lib/testlibrary/jdk/testlibrary/management/ThreadMXBeanTool.java.html

Shura

> On Nov 16, 2015, at 8:33 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> On Nov 16, 2015, at 5:38 AM, Alan Bateman <alan.bateman at oracle.com> wrote:
>> 
>> 
>> 
>> On 16/11/2015 13:01, Alexandre (Shura) Iline wrote:
>>> V6:
>>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/
>>> 
>>> 
>> This looks okay to me. For completeness then I assume the THreadMXBeanTool.waitUntilXXX methods should re-assert the interrupt status if interrupted when waiting.
> 
> +1
> 
> Mandy
> 


From Alan.Bateman at oracle.com  Thu Nov 19 17:49:38 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Nov 2015 17:49:38 +0000
Subject: RFR: 8139430
In-Reply-To: <083D7050-8850-4D0E-B97B-7523857ABECC@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<564256C7.60905@oracle.com>
	<CBB16E61-EB4B-4BF1-9696-0D2A4DADEBA9@oracle.com>
	<14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com>
	<5649DC71.60106@oracle.com>
	<D909E983-EEC8-44FF-A3FE-0F5619120A6C@oracle.com>
	<083D7050-8850-4D0E-B97B-7523857ABECC@oracle.com>
Message-ID: <564E0BB2.9050103@oracle.com>



On 19/11/2015 16:40, Alexandre (Shura) Iline wrote:
> Yes, sorry.
>
> Since the methods do not have any work to complete before interrupting and also methods are not used anywhere currently, I assume re-throwing the InterruptedException is a better choice.
>
> http://cr.openjdk.java.net/~shurailine/8139430/webrev.07/test/lib/testlibrary/jdk/testlibrary/management/ThreadMXBeanTool.java.html
>
>
If handling InterruptedException isn't a burden in these tests then it 
should be okay. Also this is probably a better anyway if you want to 
give jtreg a chance to kill a test when it goes bad (say where the 
target thread is looping and the waitXXX methods will not otherwise 
complete).

-Alan

From mandy.chung at oracle.com  Thu Nov 19 22:22:35 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 19 Nov 2015 22:22:35 +0000
Subject: hg: jigsaw/jake/jdk: 2 new changesets
Message-ID: <201511192222.tAJMMZAF002055@aojmv0008.oracle.com>

Changeset: e6921b23f45b
Author:    mchung
Date:      2015-11-19 14:03 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e6921b23f45b

ClassLoader::loadLocalClass should call findClass only if not loaded

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

Changeset: f1fff0daf868
Author:    mchung
Date:      2015-11-19 14:04 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f1fff0daf868

Rename BootLoader::getPackage to getDefinedPackage

! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/Package.java
! src/java.base/share/classes/jdk/internal/misc/BootLoader.java


From szegedia at gmail.com  Thu Nov 19 23:15:33 2015
From: szegedia at gmail.com (Attila Szegedi)
Date: Fri, 20 Nov 2015 00:15:33 +0100
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to
	jdk.dynalink
Message-ID: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>

Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for <https://bugs.openjdk.java.net/browse/JDK-8141338>. This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated.

The changes in this changeset fall into several categories:
- renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages
- changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it
- new tests

 I?m sending this webrev to several lists with the following rationales:
- nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar.
- jigsaw-dev because of modules.xml changes
- jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar)
- core-libs-dev since that?s the designated JEP 276 discussion list.

Nashorn changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9> 
top-level jdk9 changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top>

Thanks,
  Attila.


From weijun.wang at oracle.com  Fri Nov 20 00:40:59 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 20 Nov 2015 08:40:59 +0800
Subject: About 8056174: New APIs for jar signing
Message-ID: <252BB8E3-2C3B-453C-B6FA-479DA071B9AD@oracle.com>

I've just push the code change for this enhancement to jdk9/dev:

  http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce33c780cfbd
  http://hg.openjdk.java.net/jdk9/dev/rev/882c782d7d5a

In order to work with jake, these changes are needed:

diff --git a/src/jdk.jartool/share/classes/module-info.java b/src/jdk.jartool/share/classes/module-info.java
--- a/src/jdk.jartool/share/classes/module-info.java
+++ b/src/jdk.jartool/share/classes/module-info.java
@@ -25,5 +25,6 @@

 module jdk.jartool {
     exports com.sun.jarsigner;
+    exports jdk.security.jarsigner;
 }

diff --git a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
--- a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
+++ b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
@@ -1086,6 +1086,7 @@
         try {
             // attempt to find signer
             Class<?> signerClass = appClassLoader.loadClass(signerClassName);
+            JarSigner.class.getModule().addReads(signerClass.getModule());
             Object signer = signerClass.newInstance();
             return (ContentSigner) signer;
         } catch (ClassNotFoundException|InstantiationException|

Thanks
Max

From mandy.chung at oracle.com  Fri Nov 20 01:46:42 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Nov 2015 17:46:42 -0800
Subject: About 8056174: New APIs for jar signing
In-Reply-To: <252BB8E3-2C3B-453C-B6FA-479DA071B9AD@oracle.com>
References: <252BB8E3-2C3B-453C-B6FA-479DA071B9AD@oracle.com>
Message-ID: <4E5C3DA9-D48B-4A8F-A35A-0FF1CCA1001A@oracle.com>

This looks okay.  We will push this fix once we pull down your changeset to jake.

One question: is ?altsignerpath? and ?altsigner? properties are only for the existing jarsigner -altsigner option to work?  Is it the plan to deprecate this -altsigner option?

Mandy

> On Nov 19, 2015, at 4:40 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
> I've just push the code change for this enhancement to jdk9/dev:
> 
>  http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce33c780cfbd
>  http://hg.openjdk.java.net/jdk9/dev/rev/882c782d7d5a
> 
> In order to work with jake, these changes are needed:
> 
> diff --git a/src/jdk.jartool/share/classes/module-info.java b/src/jdk.jartool/share/classes/module-info.java
> --- a/src/jdk.jartool/share/classes/module-info.java
> +++ b/src/jdk.jartool/share/classes/module-info.java
> @@ -25,5 +25,6 @@
> 
> module jdk.jartool {
>     exports com.sun.jarsigner;
> +    exports jdk.security.jarsigner;
> }
> 
> diff --git a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
> --- a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
> +++ b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
> @@ -1086,6 +1086,7 @@
>         try {
>             // attempt to find signer
>             Class<?> signerClass = appClassLoader.loadClass(signerClassName);
> +            JarSigner.class.getModule().addReads(signerClass.getModule());
>             Object signer = signerClass.newInstance();
>             return (ContentSigner) signer;
>         } catch (ClassNotFoundException|InstantiationException|
> 
> Thanks
> Max


From weijun.wang at oracle.com  Fri Nov 20 01:51:40 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 20 Nov 2015 09:51:40 +0800
Subject: About 8056174: New APIs for jar signing
In-Reply-To: <4E5C3DA9-D48B-4A8F-A35A-0FF1CCA1001A@oracle.com>
References: <252BB8E3-2C3B-453C-B6FA-479DA071B9AD@oracle.com>
	<4E5C3DA9-D48B-4A8F-A35A-0FF1CCA1001A@oracle.com>
Message-ID: <CCADEF15-6365-4A94-B86C-2CD5CD8A2A50@oracle.com>


> On Nov 20, 2015, at 9:46 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> This looks okay.  We will push this fix once we pull down your changeset to jake.
> 
> One question: is ?altsignerpath? and ?altsigner? properties are only for the existing jarsigner -altsigner option to work?  

Yes, because jarsigner the tool now calls JarSigner the API. They are not described in the spec.

> Is it the plan to deprecate this -altsigner option?

Already deprecated (in the -help output), but not removed yet.

Thanks
Max

> 
> Mandy



From mandy.chung at oracle.com  Fri Nov 20 03:00:06 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Nov 2015 19:00:06 -0800
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
Message-ID: <19FE07FE-E742-4038-A604-789D114842FF@oracle.com>

I reviewed the top repo change.

modules.xml looks fine.

jdk.dynalink  should be in MAIN_MODULES since it has exported APIs.  jdk.scripting.nashorn should be moved too.  They are not sole service providers.  Since you are on this file, can you move jdk.scripting.nashorn to MAIN_MODULES as well?

Mandy

> On Nov 19, 2015, at 3:15 PM, Attila Szegedi <szegedia at gmail.com> wrote:
> 
> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for <https://bugs.openjdk.java.net/browse/JDK-8141338>. This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated.
> 
> The changes in this changeset fall into several categories:
> - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages
> - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it
> - new tests
> 
> I?m sending this webrev to several lists with the following rationales:
> - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar.
> - jigsaw-dev because of modules.xml changes
> - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar)
> - core-libs-dev since that?s the designated JEP 276 discussion list.
> 
> Nashorn changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9> 
> top-level jdk9 changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top>
> 
> Thanks,
>  Attila.
> 


From sundararajan.athijegannathan at oracle.com  Fri Nov 20 04:53:53 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 20 Nov 2015 05:53:53 +0100
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
Message-ID: <564EA761.8080602@oracle.com>

+1 on all changes.

-Sundar

On 11/20/2015 12:15 AM, Attila Szegedi wrote:
> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for <https://bugs.openjdk.java.net/browse/JDK-8141338>. This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated.
>
> The changes in this changeset fall into several categories:
> - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages
> - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it
> - new tests
>
>   I?m sending this webrev to several lists with the following rationales:
> - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar.
> - jigsaw-dev because of modules.xml changes
> - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar)
> - core-libs-dev since that?s the designated JEP 276 discussion list.
>
> Nashorn changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9>
> top-level jdk9 changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top>
>
> Thanks,
>    Attila.
>


From mandy.chung at oracle.com  Fri Nov 20 05:10:35 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Nov 2015 21:10:35 -0800
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <19FE07FE-E742-4038-A604-789D114842FF@oracle.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
	<19FE07FE-E742-4038-A604-789D114842FF@oracle.com>
Message-ID: <B455223D-5DB7-4933-871F-9BC2E5ADE44B@oracle.com>

jdk.scripting.nashorn is loaded by the extension class loader.  Is jdk.dynalink expected to be loaded by the ext. class loader?

You need to edit this file to include the new module:
   jdk/make/src/classes/build/tools/module/ext.modules

This is an interim file to map modules to class loader and we will fix it when the changeset propagates to jake.
Mandy

> On Nov 19, 2015, at 7:00 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> I reviewed the top repo change.
> 
> modules.xml looks fine.
> 
> jdk.dynalink  should be in MAIN_MODULES since it has exported APIs.  jdk.scripting.nashorn should be moved too.  They are not sole service providers.  Since you are on this file, can you move jdk.scripting.nashorn to MAIN_MODULES as well?
> 
> Mandy
> 
>> On Nov 19, 2015, at 3:15 PM, Attila Szegedi <szegedia at gmail.com> wrote:
>> 
>> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for <https://bugs.openjdk.java.net/browse/JDK-8141338>. This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated.
>> 
>> The changes in this changeset fall into several categories:
>> - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages
>> - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it
>> - new tests
>> 
>> I?m sending this webrev to several lists with the following rationales:
>> - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar.
>> - jigsaw-dev because of modules.xml changes
>> - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar)
>> - core-libs-dev since that?s the designated JEP 276 discussion list.
>> 
>> Nashorn changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9> 
>> top-level jdk9 changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top>
>> 
>> Thanks,
>> Attila.
>> 
> 


From Alan.Bateman at oracle.com  Fri Nov 20 15:10:01 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Nov 2015 15:10:01 +0000
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
Message-ID: <564F37C9.4000604@oracle.com>

On 19/11/2015 23:15, Attila Szegedi wrote:
> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for <https://bugs.openjdk.java.net/browse/JDK-8141338>. This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated.
>
> The changes in this changeset fall into several categories:
> - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages
> - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it
> - new tests
>
>   I?m sending this webrev to several lists
Probably build-dev instead of jdk9-dev.

I'm curious if it's strictly necessary for module jdk.dynalink to be in 
the nashorn repo now, I assume not but it's probably convenient when 
working Nashorn.

In any case, the module name and the changes to modules.xml look okay to 
me. As Mandy noted, this isn't a service provider API so in Images.gmk 
then you can add it to MAIN_MODULES rather than PROVIDER_MODULES.

Your webrevs don't have the changes to the jdk repo but I assume that 
make/src/classes/build/tools/module/ext.modules has been updated to list 
jdk.dynalink. That is, I assume it needs to be defined to the ext loader 
because jdk.scripting.nashorn uses it. The ext.modules file is temporary 
and goes away when we bring in the module system.

-Alan.



From szegedia at gmail.com  Fri Nov 20 15:41:19 2015
From: szegedia at gmail.com (Attila Szegedi)
Date: Fri, 20 Nov 2015 16:41:19 +0100
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <B455223D-5DB7-4933-871F-9BC2E5ADE44B@oracle.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
	<19FE07FE-E742-4038-A604-789D114842FF@oracle.com>
	<B455223D-5DB7-4933-871F-9BC2E5ADE44B@oracle.com>
Message-ID: <D09AC34F-B0D1-48D4-B5F5-AAC8D2525DD1@gmail.com>

Thanks for pointing out these, Mandy; I will make the changes you suggested.

Attila.

> On Nov 20, 2015, at 6:10 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> jdk.scripting.nashorn is loaded by the extension class loader.  Is jdk.dynalink expected to be loaded by the ext. class loader?
> 
> You need to edit this file to include the new module:
>   jdk/make/src/classes/build/tools/module/ext.modules
> 
> This is an interim file to map modules to class loader and we will fix it when the changeset propagates to jake.
> Mandy
> 
>> On Nov 19, 2015, at 7:00 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 
>> I reviewed the top repo change.
>> 
>> modules.xml looks fine.
>> 
>> jdk.dynalink  should be in MAIN_MODULES since it has exported APIs.  jdk.scripting.nashorn should be moved too.  They are not sole service providers.  Since you are on this file, can you move jdk.scripting.nashorn to MAIN_MODULES as well?
>> 
>> Mandy
>> 
>>> On Nov 19, 2015, at 3:15 PM, Attila Szegedi <szegedia at gmail.com> wrote:
>>> 
>>> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for <https://bugs.openjdk.java.net/browse/JDK-8141338>. This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated.
>>> 
>>> The changes in this changeset fall into several categories:
>>> - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages
>>> - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it
>>> - new tests
>>> 
>>> I?m sending this webrev to several lists with the following rationales:
>>> - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar.
>>> - jigsaw-dev because of modules.xml changes
>>> - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar)
>>> - core-libs-dev since that?s the designated JEP 276 discussion list.
>>> 
>>> Nashorn changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9> 
>>> top-level jdk9 changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top>
>>> 
>>> Thanks,
>>> Attila.
>>> 
>> 
> 


From szegedia at gmail.com  Fri Nov 20 15:42:34 2015
From: szegedia at gmail.com (Attila Szegedi)
Date: Fri, 20 Nov 2015 16:42:34 +0100
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <564F37C9.4000604@oracle.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
	<564F37C9.4000604@oracle.com>
Message-ID: <1B8AC6F2-0704-415A-ADDE-978D42CC4AE0@gmail.com>

On Nov 20, 2015, at 4:10 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 19/11/2015 23:15, Attila Szegedi wrote:
>> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for <https://bugs.openjdk.java.net/browse/JDK-8141338>. This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated.
>> 
>> The changes in this changeset fall into several categories:
>> - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages
>> - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it
>> - new tests
>> 
>>  I?m sending this webrev to several lists
> Probably build-dev instead of jdk9-dev.
> 
> I'm curious if it's strictly necessary for module jdk.dynalink to be in the nashorn repo now, I assume not but it's probably convenient when working Nashorn.

Exactly; it isn?t necessary, but it has been beneficial for now seeing how changes in Dynalink usually had changes in Nashorn to go with them, so having them in a single repo for atomic update is a nice property. I guess someone might eventually give a bit of a thought to the issue of how modularization relates to the JDK forest organization?

> In any case, the module name and the changes to modules.xml look okay to me. As Mandy noted, this isn't a service provider API so in Images.gmk then you can add it to MAIN_MODULES rather than PROVIDER_MODULES.

Yep, will do that as Mandy suggested.

> Your webrevs don't have the changes to the jdk repo but I assume that make/src/classes/build/tools/module/ext.modules has been updated to list jdk.dynalink.

Because I haven?t updated the webrevs since Mandy pointed out that this file also has to be changed :-). Will do it soon.

> That is, I assume it needs to be defined to the ext loader because jdk.scripting.nashorn uses it. The ext.modules file is temporary and goes away when we bring in the module system.

I too believe that having it in ext loader is correct. It will hopefully become moot once the module system is in.

Thanks,
  Attila.

> -Alan.


From jonathan.gibbons at oracle.com  Sat Nov 21 00:52:45 2015
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Sat, 21 Nov 2015 00:52:45 +0000
Subject: hg: jigsaw/jake/langtools: read target of symbolic links in JRT file
	system
Message-ID: <201511210052.tAL0qji7003890@aojmv0008.oracle.com>

Changeset: 2eea71812f91
Author:    jjg
Date:      2015-11-20 16:52 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2eea71812f91

read target of symbolic links in JRT file system

! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java


From sibabrata.sahoo at oracle.com  Mon Nov 23 11:26:19 2015
From: sibabrata.sahoo at oracle.com (Siba Sahoo)
Date: Mon, 23 Nov 2015 03:26:19 -0800 (PST)
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if
	they are in signed/unsigned modular JARs
Message-ID: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>

Hi,

 

Please help me with your review of this test for JBS: https://bugs.openjdk.java.net/browse/JDK-8130360, 

 

Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/

 

Description

Tests to verify 3rd party security providers if they are in signed/unsigned modular JARs. The test code checks the modular behavior with different combination of separate client & security provider, when available as modular(signed/unsigned) jar. It address total  of 72 test cases with the following criteria:

 

(Signed/Unsigned Jar) X (ClassLoader/ServiceLoader) X (combination of EXPLICIT/AUTO/UNAMED modules) X (With/Without Service descriptor) 

 

Thanks,

Siba

 

From sibabrata.sahoo at oracle.com  Mon Nov 23 13:14:47 2015
From: sibabrata.sahoo at oracle.com (Siba Sahoo)
Date: Mon, 23 Nov 2015 05:14:47 -0800 (PST)
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
Message-ID: <ddd22ece-13db-4838-a729-38dc1f79066c@default>

+HYPERLINK "mailto:security-dev at openjdk.java.net"security-dev at openjdk.java.net

 

From: Siba Sahoo 
Sent: Monday, November 23, 2015 4:56 PM
To: jigsaw-dev at openjdk.java.net; jdk-security-dev_ww_grp; Sean Mullan
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

 

Hi,

 

Please help me with your review of this test for JBS: https://bugs.openjdk.java.net/browse/JDK-8130360, 

 

Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/

 

Description

Tests to verify 3rd party security providers if they are in signed/unsigned modular JARs. The test code checks the modular behavior with different combination of separate client & security provider, when available as modular(signed/unsigned) jar. It address total  of 72 test cases with the following criteria:

 

(Signed/Unsigned Jar) X (ClassLoader/ServiceLoader) X (combination of EXPLICIT/AUTO/UNAMED modules) X (With/Without Service descriptor) 

 

Thanks,

Siba

 

From szegedia at gmail.com  Mon Nov 23 15:27:06 2015
From: szegedia at gmail.com (Attila Szegedi)
Date: Mon, 23 Nov 2015 16:27:06 +0100
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <D09AC34F-B0D1-48D4-B5F5-AAC8D2525DD1@gmail.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
	<19FE07FE-E742-4038-A604-789D114842FF@oracle.com>
	<B455223D-5DB7-4933-871F-9BC2E5ADE44B@oracle.com>
	<D09AC34F-B0D1-48D4-B5F5-AAC8D2525DD1@gmail.com>
Message-ID: <108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com>

Folks,

I integrated the changes Mandy suggested; please review these (build related) changes:
jdk9 top level: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html> 
jdk9/jdk: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html> 

For the sake of completeness, the jdk/nashorn changes are here: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9> but they have already been reviewed by Hannes and Sundar; only the above two (jdk9 and jdk9/jdk) have been modified compared to the original review request.

Sundar was kind enough to verify that JDK9 builds fine with these changes.

Thanks,
  Attila.

> On Nov 20, 2015, at 4:41 PM, Attila Szegedi <szegedia at gmail.com> wrote:
> 
> Thanks for pointing out these, Mandy; I will make the changes you suggested.
> 
> Attila.
> 
>> On Nov 20, 2015, at 6:10 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 
>> jdk.scripting.nashorn is loaded by the extension class loader.  Is jdk.dynalink expected to be loaded by the ext. class loader?
>> 
>> You need to edit this file to include the new module:
>>  jdk/make/src/classes/build/tools/module/ext.modules
>> 
>> This is an interim file to map modules to class loader and we will fix it when the changeset propagates to jake.
>> Mandy
>> 
>>> On Nov 19, 2015, at 7:00 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>> 
>>> I reviewed the top repo change.
>>> 
>>> modules.xml looks fine.
>>> 
>>> jdk.dynalink  should be in MAIN_MODULES since it has exported APIs.  jdk.scripting.nashorn should be moved too.  They are not sole service providers.  Since you are on this file, can you move jdk.scripting.nashorn to MAIN_MODULES as well?
>>> 
>>> Mandy
>>> 
>>>> On Nov 19, 2015, at 3:15 PM, Attila Szegedi <szegedia at gmail.com> wrote:
>>>> 
>>>> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for <https://bugs.openjdk.java.net/browse/JDK-8141338>. This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated.
>>>> 
>>>> The changes in this changeset fall into several categories:
>>>> - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages
>>>> - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it
>>>> - new tests
>>>> 
>>>> I?m sending this webrev to several lists with the following rationales:
>>>> - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar.
>>>> - jigsaw-dev because of modules.xml changes
>>>> - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar)
>>>> - core-libs-dev since that?s the designated JEP 276 discussion list.
>>>> 
>>>> Nashorn changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9> 
>>>> top-level jdk9 changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top>
>>>> 
>>>> Thanks,
>>>> Attila.
>>>> 
>>> 
>> 
> 


From Alan.Bateman at oracle.com  Mon Nov 23 15:40:10 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Nov 2015 15:40:10 +0000
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
	<19FE07FE-E742-4038-A604-789D114842FF@oracle.com>
	<B455223D-5DB7-4933-871F-9BC2E5ADE44B@oracle.com>
	<D09AC34F-B0D1-48D4-B5F5-AAC8D2525DD1@gmail.com>
	<108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com>
Message-ID: <5653335A.3070606@oracle.com>



On 23/11/2015 15:27, Attila Szegedi wrote:
> Folks,
>
> I integrated the changes Mandy suggested; please review these (build related) changes:
> jdk9 top level: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html>
> jdk9/jdk: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html>
>
> For the sake of completeness, the jdk/nashorn changes are here: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9> but they have already been reviewed by Hannes and Sundar; only the above two (jdk9 and jdk9/jdk) have been modified compared to the original review request.
>
> Sundar was kind enough to verify that JDK9 builds fine with these changes.
>
The jdk repo looks okay (just had to change your link to find it :-)

In the top-level repo then you've moved jdk.scripting.nashorn from 
PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in 
PROVIDER_MODULES is because we treat it as a service provider module (it 
provides an implementation of javax.script.ScriptEngineFactory).

-Alan.


From sundararajan.athijegannathan at oracle.com  Mon Nov 23 15:42:17 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 23 Nov 2015 21:12:17 +0530
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <5653335A.3070606@oracle.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
	<19FE07FE-E742-4038-A604-789D114842FF@oracle.com>
	<B455223D-5DB7-4933-871F-9BC2E5ADE44B@oracle.com>
	<D09AC34F-B0D1-48D4-B5F5-AAC8D2525DD1@gmail.com>
	<108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com>
	<5653335A.3070606@oracle.com>
Message-ID: <565333D9.1080508@oracle.com>

But, in addition to providing service, jdk.scripting.nashorn module also 
"exports" nashorn specific APIs in jdk.nashorn.api.* packages.

-Sundar

On 11/23/2015 9:10 PM, Alan Bateman wrote:
>
>
> On 23/11/2015 15:27, Attila Szegedi wrote:
>> Folks,
>>
>> I integrated the changes Mandy suggested; please review these (build 
>> related) changes:
>> jdk9 top level: 
>> <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html>
>> jdk9/jdk: 
>> <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html>
>>
>> For the sake of completeness, the jdk/nashorn changes are here: 
>> <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9> but they 
>> have already been reviewed by Hannes and Sundar; only the above two 
>> (jdk9 and jdk9/jdk) have been modified compared to the original 
>> review request.
>>
>> Sundar was kind enough to verify that JDK9 builds fine with these 
>> changes.
>>
> The jdk repo looks okay (just had to change your link to find it :-)
>
> In the top-level repo then you've moved jdk.scripting.nashorn from 
> PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in 
> PROVIDER_MODULES is because we treat it as a service provider module 
> (it provides an implementation of javax.script.ScriptEngineFactory).
>
> -Alan.
>


From sundararajan.athijegannathan at oracle.com  Mon Nov 23 15:43:20 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 23 Nov 2015 21:13:20 +0530
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <5653335A.3070606@oracle.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
	<19FE07FE-E742-4038-A604-789D114842FF@oracle.com>
	<B455223D-5DB7-4933-871F-9BC2E5ADE44B@oracle.com>
	<D09AC34F-B0D1-48D4-B5F5-AAC8D2525DD1@gmail.com>
	<108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com>
	<5653335A.3070606@oracle.com>
Message-ID: <56533418.1020002@oracle.com>

But, in addition to providing service, jdk.scripting.nashorn module also 
"exports" nashorn specific APIs in jdk.nashorn.api.* packages.

-Sundar

On 11/23/2015 9:10 PM, Alan Bateman wrote:
>
>
> On 23/11/2015 15:27, Attila Szegedi wrote:
>> Folks,
>>
>> I integrated the changes Mandy suggested; please review these (build 
>> related) changes:
>> jdk9 top level: 
>> <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html>
>> jdk9/jdk: 
>> <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html>
>>
>> For the sake of completeness, the jdk/nashorn changes are here: 
>> <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9> but they 
>> have already been reviewed by Hannes and Sundar; only the above two 
>> (jdk9 and jdk9/jdk) have been modified compared to the original 
>> review request.
>>
>> Sundar was kind enough to verify that JDK9 builds fine with these 
>> changes.
>>
> The jdk repo looks okay (just had to change your link to find it :-)
>
> In the top-level repo then you've moved jdk.scripting.nashorn from 
> PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in 
> PROVIDER_MODULES is because we treat it as a service provider module 
> (it provides an implementation of javax.script.ScriptEngineFactory).
>
> -Alan.
>


From mandy.chung at oracle.com  Mon Nov 23 15:45:12 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Nov 2015 07:45:12 -0800
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <5653335A.3070606@oracle.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
	<19FE07FE-E742-4038-A604-789D114842FF@oracle.com>
	<B455223D-5DB7-4933-871F-9BC2E5ADE44B@oracle.com>
	<D09AC34F-B0D1-48D4-B5F5-AAC8D2525DD1@gmail.com>
	<108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com>
	<5653335A.3070606@oracle.com>
Message-ID: <4CF6A889-AE24-4520-8884-319EA8EC18A4@oracle.com>


> On Nov 23, 2015, at 7:40 AM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> 
> 
> On 23/11/2015 15:27, Attila Szegedi wrote:
>> Folks,
>> 
>> I integrated the changes Mandy suggested; please review these (build related) changes:
>> jdk9 top level: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html>
>> jdk9/jdk: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html>
>> 
>> For the sake of completeness, the jdk/nashorn changes are here: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9> but they have already been reviewed by Hannes and Sundar; only the above two (jdk9 and jdk9/jdk) have been modified compared to the original review request.
>> 
>> Sundar was kind enough to verify that JDK9 builds fine with these changes.
>> 
> The jdk repo looks okay (just had to change your link to find it :-)
> 
> In the top-level repo then you've moved jdk.scripting.nashorn from PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in PROVIDER_MODULES is because we treat it as a service provider module (it provides an implementation of javax.script.ScriptEngineFactory).

jdk.scripting.nashorn now exports two API packages.  It is no longer a sole service provider and so I asked Attila to move it MAIN_MODULE.

Mandy

From Alan.Bateman at oracle.com  Mon Nov 23 15:46:49 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Nov 2015 15:46:49 +0000
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <56533418.1020002@oracle.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
	<19FE07FE-E742-4038-A604-789D114842FF@oracle.com>
	<B455223D-5DB7-4933-871F-9BC2E5ADE44B@oracle.com>
	<D09AC34F-B0D1-48D4-B5F5-AAC8D2525DD1@gmail.com>
	<108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com>
	<5653335A.3070606@oracle.com> <56533418.1020002@oracle.com>
Message-ID: <565334E9.7050908@oracle.com>


On 23/11/2015 15:43, Sundararajan Athijegannathan wrote:
> But, in addition to providing service, jdk.scripting.nashorn module 
> also "exports" nashorn specific APIs in jdk.nashorn.api.* packages.
Sure, it could go in either but we mostly treat it as a service provider.

-Alan.

From szegedia at gmail.com  Mon Nov 23 16:07:03 2015
From: szegedia at gmail.com (Attila Szegedi)
Date: Mon, 23 Nov 2015 17:07:03 +0100
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <5653335A.3070606@oracle.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
	<19FE07FE-E742-4038-A604-789D114842FF@oracle.com>
	<B455223D-5DB7-4933-871F-9BC2E5ADE44B@oracle.com>
	<D09AC34F-B0D1-48D4-B5F5-AAC8D2525DD1@gmail.com>
	<108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com>
	<5653335A.3070606@oracle.com>
Message-ID: <46DE1660-A471-4383-92F2-62369975C3D7@gmail.com>


> On Nov 23, 2015, at 4:40 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 23/11/2015 15:27, Attila Szegedi wrote:
>> Folks,
>> 
>> I integrated the changes Mandy suggested; please review these (build related) changes:
>> jdk9 top level: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html>
>> jdk9/jdk: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html>
>> 
>> For the sake of completeness, the jdk/nashorn changes are here: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9> but they have already been reviewed by Hannes and Sundar; only the above two (jdk9 and jdk9/jdk) have been modified compared to the original review request.
>> 
>> Sundar was kind enough to verify that JDK9 builds fine with these changes.
>> 
> The jdk repo looks okay (just had to change your link to find it :-)

D?oh. I was doublechecking those links few times and still managed to bungle it? thanks for figuring it out.
> 
> In the top-level repo then you've moved jdk.scripting.nashorn from PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in PROVIDER_MODULES is because we treat it as a service provider module (it provides an implementation of javax.script.ScriptEngineFactory).

Whichever is the stronger criteria for deciding whether to place it in MAIN or PROVIDER is fine with me. Intuitively ?provider? seems like a weaker category (exposes a service provider but doesn?t have its own API), so (without knowing the particulars of the use of these *_MODULES variables) it seems to me Mandy?s suggestion is correct to reclassify Nashorn into a MAIN module.

Attila.

> 
> -Alan.
> 


From hannes.wallnoefer at oracle.com  Mon Nov 23 09:09:23 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 23 Nov 2015 10:09:23 +0100
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
Message-ID: <5652D7C3.5060002@oracle.com>

+1 for the Nashorn/Dynalink changes.

The top level changes look good to me but I'd prefer to leave reviews to 
those who are more familiar with the build/modules infrastructure.

Hannes

Am 2015-11-20 um 00:15 schrieb Attila Szegedi:
> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for <https://bugs.openjdk.java.net/browse/JDK-8141338>. This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated.
>
> The changes in this changeset fall into several categories:
> - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages
> - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it
> - new tests
>
>   I?m sending this webrev to several lists with the following rationales:
> - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar.
> - jigsaw-dev because of modules.xml changes
> - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar)
> - core-libs-dev since that?s the designated JEP 276 discussion list.
>
> Nashorn changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9>
> top-level jdk9 changes: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top>
>
> Thanks,
>    Attila.
>


From Alan.Bateman at oracle.com  Mon Nov 23 16:42:59 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Nov 2015 16:42:59 +0000
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <46DE1660-A471-4383-92F2-62369975C3D7@gmail.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
	<19FE07FE-E742-4038-A604-789D114842FF@oracle.com>
	<B455223D-5DB7-4933-871F-9BC2E5ADE44B@oracle.com>
	<D09AC34F-B0D1-48D4-B5F5-AAC8D2525DD1@gmail.com>
	<108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com>
	<5653335A.3070606@oracle.com>
	<46DE1660-A471-4383-92F2-62369975C3D7@gmail.com>
Message-ID: <56534213.9070506@oracle.com>


On 23/11/2015 16:07, Attila Szegedi wrote:
> :
> Whichever is the stronger criteria for deciding whether to place it in MAIN or PROVIDER is fine with me. Intuitively ?provider? seems like a weaker category (exposes a service provider but doesn?t have its own API), so (without knowing the particulars of the use of these *_MODULES variables) it seems to me Mandy?s suggestion is correct to reclassify Nashorn into a MAIN module.
>
We need to do a bit of clean-up in Images.gmk to make things clearer as 
this MAIN vs. PROVIDER topic has caused confusion on a few cases. If we 
can keep the lists separate to the list of modules for the compact 
profile builds then there is no reason why they can't be combined as 
JRE_MODULES.

In this case then jdk.scripting.nashorn.shell is already listed in 
MAIN_MODULES so this will ensure than Nashorn is linked into any 
run-time image that has the the jjs tool/shell. It doesn't matter if 
jdk.scripting.nashorn is listed or not.

-Alan.




From javalists at cbfiddle.com  Mon Nov 23 17:58:12 2015
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 23 Nov 2015 09:58:12 -0800
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <CAA0cW5DG5D9L=A8dQ6BrmCmvodU+btQA6RisVLAZmGBjZyAi5Q@mail.gmail.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<CABLGb9w3YhmXUfROd04Mb-Dt_6M4zA0VgeXew-8QENQV5i9cvg@mail.gmail.com>
	<564C4230.1070802@oracle.com>
	<CAA0cW5DAYQFGGRhDQUT_+yTTBGjXx_BPyhAL4=BBnwt48d4_bw@mail.gmail.com>
	<564C518C.3050807@oracle.com>
	<CAA0cW5BcxpSvXRxCQ2gbu7HcH2B-R3szD0f6eyWFP5NBYiKe+A@mail.gmail.com>
	<564C5C23.3050107@oracle.com>
	<CAA0cW5DG5D9L=A8dQ6BrmCmvodU+btQA6RisVLAZmGBjZyAi5Q@mail.gmail.com>
Message-ID: <9A22B32F-0036-4EF1-91C2-B8FCF4B0CFA4@cbfiddle.com>

> There are rather a lot of libraries out there that access private
> members via reflection. I posit that almost all such libraries break
> without an easy way to fix the problem, if there is no way to use
> reflection to access non-exported members.

I agree with Reinier that there are situations where it makes sense to bypass module encapsulation and the existing access rules. Encapsulation is a good thing, but unless it is needed for security, Java should not be totally rigid about it.

My use case is a platform specific Swing look and feel. To work, it needs access to platform specific features of the AWT. I?m trying not to be pessimistic or cynical, but I cannot assume that Oracle/OpenJDK will be motivated to create a public API for all of the platform specific features that I need, or if they do, that the API will be available in a timely manner. I understand that my library will have dependencies on specific JDK versions as it does on specific platform versions.

I was unpleasantly surprised to learn (via the recent Java One talks) that the module encapsulation rules apply to reflection, as I had understood that they did not.

Using command line arguments as an escape mechanism is not a good fit for this use. The main reason is that it places a burden on all users of the library, both direct and indirect. Every application in which this library is used must define the appropriate command line arguments. The other reason is that the command line argument solution is too broad. Using reflection, each specific need to penetrate encapsulation is identified. Using the command line argument, entire packages are opened up.

Which brings me to a question... How is native code access to classes and methods via JNI affected by module encapsulation?

  Alan


From mandy.chung at oracle.com  Mon Nov 23 19:54:58 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Nov 2015 11:54:58 -0800
Subject: Review request for JDK-8141338: Move jdk.internal.dynalink
	package to jdk.dynalink
In-Reply-To: <56534213.9070506@oracle.com>
References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com>
	<19FE07FE-E742-4038-A604-789D114842FF@oracle.com>
	<B455223D-5DB7-4933-871F-9BC2E5ADE44B@oracle.com>
	<D09AC34F-B0D1-48D4-B5F5-AAC8D2525DD1@gmail.com>
	<108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com>
	<5653335A.3070606@oracle.com>
	<46DE1660-A471-4383-92F2-62369975C3D7@gmail.com>
	<56534213.9070506@oracle.com>
Message-ID: <0865324C-A221-493B-BC7A-2109380F66DC@oracle.com>


> On Nov 23, 2015, at 8:42 AM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> We need to do a bit of clean-up in Images.gmk to make things clearer as this MAIN vs. PROVIDER topic has caused confusion on a few cases. If we can keep the lists separate to the list of modules for the compact profile builds then there is no reason why they can't be combined as JRE_MODULES.

Agree and we should clean that up to remove the confusion.

Mandy

From mandy.chung at oracle.com  Mon Nov 23 22:38:10 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Nov 2015 14:38:10 -0800
Subject: RFR: 8139430
In-Reply-To: <083D7050-8850-4D0E-B97B-7523857ABECC@oracle.com>
References: <C31ACF4A-7342-4060-9CE5-96EA774C47D6@oracle.com>
	<8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com>
	<564256C7.60905@oracle.com>
	<CBB16E61-EB4B-4BF1-9696-0D2A4DADEBA9@oracle.com>
	<14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com>
	<5649DC71.60106@oracle.com>
	<D909E983-EEC8-44FF-A3FE-0F5619120A6C@oracle.com>
	<083D7050-8850-4D0E-B97B-7523857ABECC@oracle.com>
Message-ID: <BCBD48E2-4357-4802-8934-2AB1980A5E7F@oracle.com>

Hi Shura,

I have pushed the changeset to jdk9/dev.

Mandy

> On Nov 19, 2015, at 8:40 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
> 
> Yes, sorry.
> 
> Since the methods do not have any work to complete before interrupting and also methods are not used anywhere currently, I assume re-throwing the InterruptedException is a better choice.
> 
> http://cr.openjdk.java.net/~shurailine/8139430/webrev.07/test/lib/testlibrary/jdk/testlibrary/management/ThreadMXBeanTool.java.html
> 
> Shura
> 
>> On Nov 16, 2015, at 8:33 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 
>> 
>>> On Nov 16, 2015, at 5:38 AM, Alan Bateman <alan.bateman at oracle.com> wrote:
>>> 
>>> 
>>> 
>>> On 16/11/2015 13:01, Alexandre (Shura) Iline wrote:
>>>> V6:
>>>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/
>>>> 
>>>> 
>>> This looks okay to me. For completeness then I assume the THreadMXBeanTool.waitUntilXXX methods should re-assert the interrupt status if interrupted when waiting.
>> 
>> +1
>> 
>> Mandy
>> 
> 


From alex.buckley at oracle.com  Tue Nov 24 00:24:34 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 23 Nov 2015 16:24:34 -0800
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <9A22B32F-0036-4EF1-91C2-B8FCF4B0CFA4@cbfiddle.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>	<564A081E.3010809@oracle.com>	<CABLGb9w3YhmXUfROd04Mb-Dt_6M4zA0VgeXew-8QENQV5i9cvg@mail.gmail.com>	<564C4230.1070802@oracle.com>	<CAA0cW5DAYQFGGRhDQUT_+yTTBGjXx_BPyhAL4=BBnwt48d4_bw@mail.gmail.com>	<564C518C.3050807@oracle.com>	<CAA0cW5BcxpSvXRxCQ2gbu7HcH2B-R3szD0f6eyWFP5NBYiKe+A@mail.gmail.com>	<564C5C23.3050107@oracle.com>	<CAA0cW5DG5D9L=A8dQ6BrmCmvodU+btQA6RisVLAZmGBjZyAi5Q@mail.gmail.com>
	<9A22B32F-0036-4EF1-91C2-B8FCF4B0CFA4@cbfiddle.com>
Message-ID: <5653AE42.4030809@oracle.com>

On 11/23/2015 9:58 AM, Alan Snyder wrote:
> My use case is a platform specific Swing look and feel. To work, it
> needs access to platform specific features of the AWT. I?m trying not
> to be pessimistic or cynical, but I cannot assume that Oracle/OpenJDK
> will be motivated to create a public API for all of the platform
> specific features that I need, or if they do, that the API will be
> available in a timely manner. I understand that my library will have
> dependencies on specific JDK versions as it does on specific platform
> versions.

I know there is considerable effort going into replacement public APIs 
for JavaFX -- see http://openjdk.java.net/jeps/253 from May and the 
openjfx-dev thread "Understanding the com.sun.* APIs being (ab)used by 
the community" from June -- you could inquire about equivalents on 
swing-dev.

Alex

> I was unpleasantly surprised to learn (via the recent Java One talks)
> that the module encapsulation rules apply to reflection, as I had
> understood that they did not.
>
> Using command line arguments as an escape mechanism is not a good fit
> for this use. The main reason is that it places a burden on all users
> of the library, both direct and indirect. Every application in which
> this library is used must define the appropriate command line
> arguments. The other reason is that the command line argument
> solution is too broad. Using reflection, each specific need to
> penetrate encapsulation is identified. Using the command line
> argument, entire packages are opened up.
>
> Which brings me to a question... How is native code access to classes
> and methods via JNI affected by module encapsulation?
>
> Alan
>

From sergei.pikalev at oracle.com  Tue Nov 24 00:37:26 2015
From: sergei.pikalev at oracle.com (Sergei Pikalev)
Date: Tue, 24 Nov 2015 03:37:26 +0300
Subject: RFR 8135972: Implement new tests for native libjimage library
In-Reply-To: <5645EFBE.1060903@oracle.com>
References: <5645EA93.5040102@oracle.com> <5645EFBE.1060903@oracle.com>
Message-ID: <5653B146.9030408@oracle.com>


Hi All,

http://cr.openjdk.java.net/~jlaskey/8135972/webrev.01/index.html

There are a minimal set of passing cleanly tests which does not explore
bad values touching memory addresses.

Please review.

Thanks,
     Sergi

On 13.11.2015 17:12, Alan Bateman wrote:
> On 13/11/2015 13:50, Sergei Pikalev wrote:
>>
>> Hello,
>>
>> This is the code with new tests for libjimage native library.
>>
>> A webrev with the tests is here:
>>
>> http://cr.openjdk.java.net/~jlaskey/8135972/webrev.00/index.html
>
> Are there tests passing cleanly on all platforms? At least some of 
> them seems to be passing bad values to native methods that take memory 
> addresses.
>
> Are the tests tied to changes in jigsaw/jake or can these tests go 
> into jdk9/dev to follow the jimage changes that are also going in via 
> that route?
>
> -Alan


From javalists at cbfiddle.com  Tue Nov 24 00:50:04 2015
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 23 Nov 2015 16:50:04 -0800
Subject: A way to opt out of access restrictions on non-exported members.
In-Reply-To: <5653AE42.4030809@oracle.com>
References: <CAK6PxWNCxmpnoO4XxdDUTNSqkbLCHxWtTxENxAnRx4iRkznxMw@mail.gmail.com>
	<CACzrW9Au-3ZORqBOoa4yrd0e9VW=5WFR=zh02+DaWSd++b=_1A@mail.gmail.com>
	<564A081E.3010809@oracle.com>
	<CABLGb9w3YhmXUfROd04Mb-Dt_6M4zA0VgeXew-8QENQV5i9cvg@mail.gmail.com>
	<564C4230.1070802@oracle.com>
	<CAA0cW5DAYQFGGRhDQUT_+yTTBGjXx_BPyhAL4=BBnwt48d4_bw@mail.gmail.com>
	<564C518C.3050807@oracle.com>
	<CAA0cW5BcxpSvXRxCQ2gbu7HcH2B-R3szD0f6eyWFP5NBYiKe+A@mail.gmail.com>
	<564C5C23.3050107@oracle.com>
	<CAA0cW5DG5D9L=A8dQ6BrmCmvodU+btQA6RisVLAZmGBjZyAi5Q@mail.gmail.com>
	<9A22B32F-0036-4EF1-91C2-B8FCF4B0CFA4@cbfiddle.com>
	<5653AE42.4030809@oracle.com>
Message-ID: <1681644E-F46C-4050-87C3-0106A595B9CF@cbfiddle.com>


> On Nov 23, 2015, at 4:24 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> I know there is considerable effort going into replacement public APIs for JavaFX -- see http://openjdk.java.net/jeps/253 <http://openjdk.java.net/jeps/253> from May and the openjfx-dev thread "Understanding the com.sun.* APIs being (ab)used by the community" from June -- you could inquire about equivalents on swing-dev.

Yes, I have already proposed some and some are under development. I have not proposed low level ones yet.

  Alan


From mandy.chung at oracle.com  Tue Nov 24 03:22:32 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 24 Nov 2015 03:22:32 +0000
Subject: hg: jigsaw/jake/jdk: Throw IAE if the proxy module can't access
	interface
Message-ID: <201511240322.tAO3MWYd019011@aojmv0008.oracle.com>

Changeset: 89fb05b6e864
Author:    mchung
Date:      2015-11-23 19:22 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/89fb05b6e864

Throw IAE if the proxy module can't access interface

! src/java.base/share/classes/java/lang/reflect/Proxy.java
! test/jdk/jigsaw/reflect/Proxy/ProxyClassAccessTest.java
! test/jdk/jigsaw/reflect/Proxy/ProxyLayerTest.java
! test/jdk/jigsaw/reflect/Proxy/ProxyModuleMapping.java
+ test/jdk/jigsaw/reflect/Proxy/q/NP.java


From mandy.chung at oracle.com  Tue Nov 24 06:02:40 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 24 Nov 2015 06:02:40 +0000
Subject: hg: jigsaw/jake/langtools: Fix langtools/tools/jdeps/APIDeps.java to
	reference internal type
Message-ID: <201511240602.tAO62esK019732@aojmv0008.oracle.com>

Changeset: f7876cd903aa
Author:    mchung
Date:      2015-11-23 22:02 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f7876cd903aa

Fix langtools/tools/jdeps/APIDeps.java to reference internal type

! test/tools/jdeps/APIDeps.java
! test/tools/jdeps/VerboseFormat/JdepsDependencyClosure.java
! test/tools/jdeps/VerboseFormat/use/internal/UseJdkInternalClass.java
! test/tools/jdeps/VerboseFormat/use/internal/UseJdkInternalClass2.java
! test/tools/jdeps/f/F.java


From Alan.Bateman at oracle.com  Tue Nov 24 08:29:50 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Nov 2015 08:29:50 +0000
Subject: RFR 8135972: Implement new tests for native libjimage library
In-Reply-To: <5653B146.9030408@oracle.com>
References: <5645EA93.5040102@oracle.com> <5645EFBE.1060903@oracle.com>
	<5653B146.9030408@oracle.com>
Message-ID: <56541FFE.7020707@oracle.com>

On 24/11/2015 00:37, Sergei Pikalev wrote:
>
> Hi All,
>
> http://cr.openjdk.java.net/~jlaskey/8135972/webrev.01/index.html
>
> There are a minimal set of passing cleanly tests which does not explore
> bad values touching memory addresses.
>
> Please review.
I assume Jim or Jean-Francois will sponsor this for you. Is 
JImagePackageToModuleTest the only test that is unique to jake? I'm just 
wondering if we can get these tests into via jdk9/dev.

One thing that isn't clear to me is the multipleOpenTest, I would have 
expected a second call to JIMAGE_Open to return a unique handle.

A small comment on JImageOpenCloseTest - I assume this should create the 
0-length or bad-magic jimage file rather than checking in binary files.

-Alan

From erik.joelsson at oracle.com  Tue Nov 24 10:04:00 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 24 Nov 2015 10:04:00 +0000
Subject: hg: jigsaw/jake: Fixed images target to properly also build the
	exploded-image target
Message-ID: <201511241004.tAOA416u017813@aojmv0008.oracle.com>

Changeset: d18e85f68fe3
Author:    erikj
Date:      2015-11-24 11:03 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/d18e85f68fe3

Fixed images target to properly also build the exploded-image target

! common/autoconf/generated-configure.sh
! make/Main.gmk


From erik.joelsson at oracle.com  Tue Nov 24 13:02:39 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 24 Nov 2015 13:02:39 +0000
Subject: hg: jigsaw/jake: More build unification with jdk9
Message-ID: <201511241302.tAOD2dZ3014512@aojmv0008.oracle.com>

Changeset: 5165085d2c54
Author:    erikj
Date:      2015-11-24 14:01 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/rev/5165085d2c54

More build unification with jdk9

! make/CompileJavaModules.gmk


From erik.joelsson at oracle.com  Tue Nov 24 13:03:44 2015
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 24 Nov 2015 13:03:44 +0000
Subject: hg: jigsaw/jake/jdk: More build unification with jdk9
Message-ID: <201511241303.tAOD3iuR014957@aojmv0008.oracle.com>

Changeset: 33d87582d833
Author:    erikj
Date:      2015-11-24 14:01 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/33d87582d833

More build unification with jdk9

! make/launcher/Launcher-jdk.jcmd.gmk
! make/launcher/LauncherCommon.gmk


From lois.foltan at oracle.com  Tue Nov 24 14:21:55 2015
From: lois.foltan at oracle.com (lois.foltan at oracle.com)
Date: Tue, 24 Nov 2015 14:21:55 +0000
Subject: hg: jigsaw/jake/hotspot: JVM changes to record the j.l.r.Module for
	unnamed modules
Message-ID: <201511241421.tAOELtfJ012414@aojmv0008.oracle.com>

Changeset: f4f2580e950a
Author:    lfoltan
Date:      2015-11-24 09:00 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f4f2580e950a

JVM changes to record the j.l.r.Module for unnamed modules

! make/aix/makefiles/mapfile-vers-debug
! make/aix/makefiles/mapfile-vers-product
! make/bsd/makefiles/mapfile-vers-darwin-debug
! make/bsd/makefiles/mapfile-vers-darwin-product
! make/bsd/makefiles/mapfile-vers-debug
! make/bsd/makefiles/mapfile-vers-product
! make/linux/makefiles/mapfile-vers-debug
! make/linux/makefiles/mapfile-vers-product
! make/share/makefiles/mapfile-vers
! make/solaris/makefiles/mapfile-vers
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/moduleEntry.cpp
! src/share/vm/classfile/moduleEntry.hpp
! src/share/vm/classfile/modules.cpp
! src/share/vm/classfile/modules.hpp
! src/share/vm/classfile/packageEntry.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h
! src/share/vm/runtime/globals.hpp
! test/runtime/modules/JVMDefineModule.java


From lois.foltan at oracle.com  Tue Nov 24 14:23:37 2015
From: lois.foltan at oracle.com (lois.foltan at oracle.com)
Date: Tue, 24 Nov 2015 14:23:37 +0000
Subject: hg: jigsaw/jake/jdk: Changes to communicate the j.l.r.Module for the
	boot loader's unnamed module to the JVM
Message-ID: <201511241423.tAOENbe9012739@aojmv0008.oracle.com>

Changeset: fa97a65164bc
Author:    lfoltan
Date:      2015-11-24 09:02 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fa97a65164bc

Changes to communicate the j.l.r.Module for the boot loader's unnamed module to the JVM

! make/mapfiles/libjava/mapfile-vers
! src/java.base/share/classes/jdk/internal/misc/BootLoader.java
! src/java.base/share/native/include/jvm.h
! src/java.base/share/native/libjava/BootLoader.c
! src/java.base/share/native/libjava/Module.c


From sundararajan.athijegannathan at oracle.com  Tue Nov 24 14:46:18 2015
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Tue, 24 Nov 2015 14:46:18 +0000
Subject: hg: jigsaw/jake/jdk: 8142959: Remove dependency on
	sun.boot.class.path property
Message-ID: <201511241446.tAOEkIBt017931@aojmv0008.oracle.com>

Changeset: 5098cced084a
Author:    sundar
Date:      2015-11-24 20:14 +0530
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5098cced084a

8142959: Remove dependency on sun.boot.class.path property
Reviewed-by: alanb

! src/jdk.rmic/share/classes/sun/rmi/rmic/BatchEnvironment.java
! src/jdk.rmic/share/classes/sun/tools/java/ClassPath.java


From mik3hall at gmail.com  Wed Nov 25 00:11:57 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 24 Nov 2015 18:11:57 -0600
Subject: OS X application won't launch with jigsaw
Message-ID: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com>

Up to now I have been able to take java 9 builds and paste the appropriate contents into a OS X javapackager produced application and have it run with the embedded jdk.
I just got a jigsaw build instead of the main 9 forest and it does not launch. 
I get?
11/24/15 5:54:16.326 PM com.apple.xpc.launchd[1]: (us.hall.hp.common.86368[4137]) Service exited with abnormal code: 1
What is different, and not quite so good, with the jake build?

Previously I noticed the lib/modules directory contained individual modules like java.base. I notice the jake build now has only bootmodules.jimage.
I assume this is the current correct container for all modules? This sort of rhetorical, if true.

I watched some of the java9 videos off of the provided links. It was mentioned that the modules no longer use jar/zip. A more efficient way to package the modules has been developed. Is this file format available for use outside the jdk? Are there any tools that work with jimage now or in the works?

Michael Hall





From mandy.chung at oracle.com  Wed Nov 25 00:58:50 2015
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Wed, 25 Nov 2015 00:58:50 +0000
Subject: hg: jigsaw/jake/jdk: 8139430: Refactor test library to decrease
	module dependencies of tests
Message-ID: <201511250058.tAP0wo2s000607@aojmv0008.oracle.com>

Changeset: 45cb94eef0ec
Author:    shurailine
Date:      2015-11-23 11:49 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/45cb94eef0ec

8139430: Refactor test library to decrease module dependencies of tests
Reviewed-by: mchung, alanb

! test/java/util/logging/TestLoggerWeakRefLeak.java
- test/lib/testlibrary/jdk/testlibrary/InputArguments.java
! test/lib/testlibrary/jdk/testlibrary/JcmdBase.java
! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java
! test/lib/testlibrary/jdk/testlibrary/TestThread.java
+ test/lib/testlibrary/jdk/testlibrary/management/InputArguments.java
+ test/lib/testlibrary/jdk/testlibrary/management/ThreadMXBeanTool.java
! test/sun/tools/jcmd/TestJcmdSanity.java
! test/sun/tools/jinfo/JInfoHelper.java
! test/sun/tools/jmap/BasicJMapTest.java
! test/sun/tools/jps/JpsBase.java
! test/sun/tools/jstack/BasicJStackTest.java


From mik3hall at gmail.com  Wed Nov 25 00:59:26 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 24 Nov 2015 18:59:26 -0600
Subject: OS X application won't launch with jigsaw
In-Reply-To: <BE24DC91-29C2-453D-BFBC-05C36BB3C4AC@gmail.com>
References: <BE24DC91-29C2-453D-BFBC-05C36BB3C4AC@gmail.com>
Message-ID: <B64DF998-C20C-4A4F-A2CD-551E7FC7A08D@gmail.com>

> On Nov 24, 2015, at 6:11 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Up to now I have been able to take java 9 builds and paste the appropriate contents into a OS X javapackager produced application and have it run with the embedded jdk.

Sorry, to reply to my own. But I notice the install layout is somewhat different. There is now a MacOS directory along with the Home directory with what looks like a symbolic link to libjli.dylib. (I tried copying that into my app framework, still no go).
Would the javafx list be a more appropriate place to ask about this? 
Is javapackager supposed to currently be working or would that be pending jigsaw becoming more stable?

Michael Hall





From mik3hall at gmail.com  Wed Nov 25 01:52:11 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 24 Nov 2015 19:52:11 -0600
Subject: Apple internal api's
Message-ID: <F07E7C52-2972-4AA6-96FF-8E88CD6CDFD0@gmail.com>

I know these are being addressed as part of JEP 272 [1], but for now.
I have a shell script that will launch my OS X app with most of it?s functionality. I think some appleevent related won?t work as less than a full app, but the app should run. It is completely unmodularized at this point though.
I get?
./halfpipe9.sh
Exception in thread "main" java.lang.IllegalAccessError: class us.hall.osx.OSXApplication (in module: Unnamed Module) cannot access class com.apple.eawt.Application (in module: java.desktop), com.apple.eawt is not exported to Unnamed Module

I found documentation for the addExports ?get out of jail free? option at JEP 261.
I tried...
java -XaddExports:us.hall.osx/com.apple.eawt=ALL-UNNAMED 

getting?
/halfpipe9.sh
Error occurred during initialization of VM
java.lang.RuntimeException: Unknown source module: us.hall.osx.OSXApplication

This is not in a module yet. addExports is not available?

[1] http://openjdk.java.net/jeps/272
[2] http://openjdk.java.net/jeps/261 <http://openjdk.java.net/jeps/261>

Michael Hall





From mandy.chung at oracle.com  Wed Nov 25 03:18:32 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 24 Nov 2015 19:18:32 -0800
Subject: Apple internal api's
In-Reply-To: <F07E7C52-2972-4AA6-96FF-8E88CD6CDFD0@gmail.com>
References: <F07E7C52-2972-4AA6-96FF-8E88CD6CDFD0@gmail.com>
Message-ID: <2A18D261-FB25-4AC4-85E5-ADE899E1819E@oracle.com>

com.apple.eawt is in java.desktop module.  Try this:

java -XaddExports:java.desktop/com.apple.eawt=ALL-UNNAMED 

Mandy

> On Nov 24, 2015, at 5:52 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> I know these are being addressed as part of JEP 272 [1], but for now.
> I have a shell script that will launch my OS X app with most of it?s functionality. I think some appleevent related won?t work as less than a full app, but the app should run. It is completely unmodularized at this point though.
> I get?
> ./halfpipe9.sh
> Exception in thread "main" java.lang.IllegalAccessError: class us.hall.osx.OSXApplication (in module: Unnamed Module) cannot access class com.apple.eawt.Application (in module: java.desktop), com.apple.eawt is not exported to Unnamed Module
> 
> I found documentation for the addExports ?get out of jail free? option at JEP 261.
> I tried...
> java -XaddExports:us.hall.osx/com.apple.eawt=ALL-UNNAMED 
> 
> getting?
> /halfpipe9.sh
> Error occurred during initialization of VM
> java.lang.RuntimeException: Unknown source module: us.hall.osx.OSXApplication
> 
> This is not in a module yet. addExports is not available?
> 
> [1] http://openjdk.java.net/jeps/272
> [2] http://openjdk.java.net/jeps/261 <http://openjdk.java.net/jeps/261>
> 
> Michael Hall
> 
> 
> 
> 


From sundararajan.athijegannathan at oracle.com  Wed Nov 25 04:52:25 2015
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Wed, 25 Nov 2015 04:52:25 +0000
Subject: hg: jigsaw/jake/nashorn: 8139106: ant build/test fails with
	jigsaw/jake/nashorn
Message-ID: <201511250452.tAP4qPwT020288@aojmv0008.oracle.com>

Changeset: e2e713228703
Author:    sundar
Date:      2015-11-25 10:21 +0530
URL:       http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e2e713228703

8139106: ant build/test fails with jigsaw/jake/nashorn

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java


From sergei.pikalev at oracle.com  Wed Nov 25 05:02:30 2015
From: sergei.pikalev at oracle.com (Sergei Pikalev)
Date: Wed, 25 Nov 2015 08:02:30 +0300
Subject: RFR 8135972: Implement new tests for native libjimage library
In-Reply-To: <56541FFE.7020707@oracle.com>
References: <5645EA93.5040102@oracle.com> <5645EFBE.1060903@oracle.com>
	<5653B146.9030408@oracle.com> <56541FFE.7020707@oracle.com>
Message-ID: <565540E6.4060808@oracle.com>


Hi Alan,

I've attached the diff with minor changes:

* multipleOpenTest - check on second call of JIMAGE_Open
* removed corrupted data files from patch and create them in @BeforeTest 
block

Should I create new webrev or could I contact Jim or Jean-Francois directly?

Answers on your question:

Yes, the tests could be used in jdk9/dev as well with minor tuning.

Thanks,
     Sergi

On 24.11.2015 11:29, Alan Bateman wrote:
> On 24/11/2015 00:37, Sergei Pikalev wrote:
>>
>> Hi All,
>>
>> http://cr.openjdk.java.net/~jlaskey/8135972/webrev.01/index.html
>>
>> There are a minimal set of passing cleanly tests which does not explore
>> bad values touching memory addresses.
>>
>> Please review.
> I assume Jim or Jean-Francois will sponsor this for you. Is 
> JImagePackageToModuleTest the only test that is unique to jake? I'm 
> just wondering if we can get these tests into via jdk9/dev.
>
> One thing that isn't clear to me is the multipleOpenTest, I would have 
> expected a second call to JIMAGE_Open to return a unique handle.
>
> A small comment on JImageOpenCloseTest - I assume this should create 
> the 0-length or bad-magic jimage file rather than checking in binary 
> files.
>
> -Alan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libjimage_min_tests.diff
Type: text/x-patch
Size: 22179 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/jigsaw-dev/attachments/20151125/aa352b5c/libjimage_min_tests.diff>

From Alan.Bateman at oracle.com  Wed Nov 25 08:27:05 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Nov 2015 08:27:05 +0000
Subject: OS X application won't launch with jigsaw
In-Reply-To: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com>
References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com>
Message-ID: <565570D9.4070302@oracle.com>

On 25/11/2015 00:11, Michael Hall wrote:
> Up to now I have been able to take java 9 builds and paste the appropriate contents into a OS X javapackager produced application and have it run with the embedded jdk.
> I just got a jigsaw build instead of the main 9 forest and it does not launch.
> I get?
> 11/24/15 5:54:16.326 PM com.apple.xpc.launchd[1]: (us.hall.hp.common.86368[4137]) Service exited with abnormal code: 1
> What is different, and not quite so good, with the jake build?
>
> Previously I noticed the lib/modules directory contained individual modules like java.base. I notice the jake build now has only bootmodules.jimage.
> I assume this is the current correct container for all modules? This sort of rhetorical, if true.
Yes, this is the container file. If you previously saw a directory named 
modules/java.base then I assume you must have been looking at an 
exploded build rather than an images build. I think we touched on this 
in your other thread where you used the build <build-output>/jdk tree 
rather than <build-output>/images/jdk.

>
> I watched some of the java9 videos off of the provided links. It was mentioned that the modules no longer use jar/zip. A more efficient way to package the modules has been developed. Is this file format available for use outside the jdk? Are there any tools that work with jimage now or in the works?
>
The jimage file that you see in the JDK image is internal to the 
run-time image. The format is not meant to be documented as it is likely 
to change frequently. Application and library modules can be packaged as 
modular JAR files, these are just regular JAR files but with a compiled 
module declaration (module-info.class) in the top-level directory of the 
JAR file. The jar tool is updated in the jake builds to support modular 
JARs.

-Alan

From mik3hall at gmail.com  Wed Nov 25 09:17:27 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 25 Nov 2015 03:17:27 -0600
Subject: OS X application won't launch with jigsaw
In-Reply-To: <565570D9.4070302@oracle.com>
References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com>
	<565570D9.4070302@oracle.com>
Message-ID: <2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com>

> On Nov 25, 2015, at 2:27 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>  I think we touched on this in your other thread where you used the build <build-output>/jdk tree rather than <build-output>/images/jdk.

Sorry, you are correct on this. Once I had correctly built the images version the modules are no longer individual/exploded.
I notice there are three images when built from source?
appmodules.jimage
bootmodules.jimage
extmodules.jimage

For the jake ea version I downloaded from the URL provided at the talks there is only bootmodules.jimage if that matters.

Copying the other two images into the embedded application jdk still does not seem to launch. Although even command line showed that it should get the internals error. 
It might be the same problem for the app and I?m just not seeing the more meaningful error messages. 

Is there any way around the internals for a non-modularized application? A fair percentage of OS X applications might have these particular ?internals?. There is JEP 272 so if I just wait, and change some code, that should go away. 

But in general, if you have other applications looking to migrate to 9 that have any of these who want to start out by just getting their application up and running they are not going to work. They will be forced to either eliminate the internal use or go modular from the start? Then the addExports will work. If I?m understanding that error message correctly.

Michael Hall






From karlsanders75 at gmail.com  Wed Nov 25 11:59:32 2015
From: karlsanders75 at gmail.com (Karl Sanders)
Date: Wed, 25 Nov 2015 12:59:32 +0100
Subject: Current plans for a new Java access modifier
Message-ID: <CABHMDwj7vHE6VwdtesJRX3gZtrje8BRCdqighdWkJYzCOGL_Kw@mail.gmail.com>

Hi,

after a quick search in the Jigsaw docs and mailing list archives I
came to the conclusion that there won't be a new Java access modifier
between public and Package-Access, to allow visibility and access from
other packages but only if inside the same module.
Is this correct?

Regards,
Karl

From Alan.Bateman at oracle.com  Wed Nov 25 15:56:52 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Nov 2015 15:56:52 +0000
Subject: OS X application won't launch with jigsaw
In-Reply-To: <2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com>
References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com>
	<565570D9.4070302@oracle.com>
	<2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com>
Message-ID: <5655DA44.1050206@oracle.com>


On 25/11/2015 09:17, Michael Hall wrote:
> I notice there are three images when built from source?
> appmodules.jimage
> bootmodules.jimage
> extmodules.jimage
>
> For the jake ea version I downloaded from the URL provided at the talks there is only bootmodules.jimage if that matters.
>
> Copying the other two images into the embedded application jdk still does not seem to launch. Although even command line showed that it should get the internals error.
> It might be the same problem for the app and I?m just not seeing the more meaningful error messages.
There are a lot of changes in the jake forest, one of which is storing 
the classes/resources for all modules in one jimage container. This 
should transparent to you, there is no need to every look in the lib/** 
tree. In particular, it will break things really badly if you copy or 
move jimage files between builds.

>
> Is there any way around the internals for a non-modularized application? A fair percentage of OS X applications might have these particular ?internals?. There is JEP 272 so if I just wait, and change some code, that should go away.
>
> But in general, if you have other applications looking to migrate to 9 that have any of these who want to start out by just getting their application up and running they are not going to work. They will be forced to either eliminate the internal use or go modular from the start? Then the addExports will work. If I?m understanding that error message correctly.
>
If you feel strongly that the com.apple.eawt APIs should be exported in 
JDK 9 then you need to read JEP 260 [1] and make a case for adding the 
Apple APIs to the list.

-Alan.

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

From kevin.rushforth at oracle.com  Wed Nov 25 16:13:07 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 25 Nov 2015 08:13:07 -0800
Subject: OS X application won't launch with jigsaw
In-Reply-To: <5655DA44.1050206@oracle.com>
References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com>	<565570D9.4070302@oracle.com>	<2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com>
	<5655DA44.1050206@oracle.com>
Message-ID: <5655DE13.2070102@oracle.com>

The com.apple.eawt APIs are already being replaced by public API as part 
of JEP 272 (which Michael already noted). I think he's just wondering 
what to do in the mean time; "-XaddExports" should do the trick.

-- Kevin


Alan Bateman wrote:
>
> On 25/11/2015 09:17, Michael Hall wrote:
>> I notice there are three images when built from source?
>> appmodules.jimage
>> bootmodules.jimage
>> extmodules.jimage
>>
>> For the jake ea version I downloaded from the URL provided at the 
>> talks there is only bootmodules.jimage if that matters.
>>
>> Copying the other two images into the embedded application jdk still 
>> does not seem to launch. Although even command line showed that it 
>> should get the internals error.
>> It might be the same problem for the app and I?m just not seeing the 
>> more meaningful error messages.
> There are a lot of changes in the jake forest, one of which is storing 
> the classes/resources for all modules in one jimage container. This 
> should transparent to you, there is no need to every look in the 
> lib/** tree. In particular, it will break things really badly if you 
> copy or move jimage files between builds.
>
>>
>> Is there any way around the internals for a non-modularized 
>> application? A fair percentage of OS X applications might have these 
>> particular ?internals?. There is JEP 272 so if I just wait, and 
>> change some code, that should go away.
>>
>> But in general, if you have other applications looking to migrate to 
>> 9 that have any of these who want to start out by just getting their 
>> application up and running they are not going to work. They will be 
>> forced to either eliminate the internal use or go modular from the 
>> start? Then the addExports will work. If I?m understanding that error 
>> message correctly.
>>
> If you feel strongly that the com.apple.eawt APIs should be exported 
> in JDK 9 then you need to read JEP 260 [1] and make a case for adding 
> the Apple APIs to the list.
>
> -Alan.
>
> [1] http://openjdk.java.net/jeps/260

From danno.ferrin at oracle.com  Wed Nov 25 16:45:07 2015
From: danno.ferrin at oracle.com (Danno Ferrin)
Date: Wed, 25 Nov 2015 09:45:07 -0700
Subject: OS X application won't launch with jigsaw
In-Reply-To: <2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com>
References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com>
	<565570D9.4070302@oracle.com>
	<2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com>
Message-ID: <13108C67-EF00-4B7E-86C4-97791489A425@oracle.com>

JEP275 [1] is updating the javapackager to use and create modular runtimes.  I have just posted a webrev with the last features to the openjfx list.  A prior version is in the sandbox-9-jake repo [2] and the webrev will go there.  Except for needing to specify where your jmods are stored, the API and CLI should be 100% compatible with the Java 8 version.  And if it's not, post a bug, we should fix any incompatibilities that are not necessary for Jake integration.  And if they are necessary we should be able to defend the decision in the bug post. 

However, we fully expect that the Java 8 packager will not be able to make bundles holding a Java 9 runtime, and I think this is what you are encountering.

[1] http://openjdk.java.net/jeps/275 <http://openjdk.java.net/jeps/275>
[2] http://hg.openjdk.java.net/openjfx/sandbox-9-jake/rt <http://hg.openjdk.java.net/openjfx/sandbox-9-jake/rt> 

> On Nov 25, 2015, at 2:17 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> On Nov 25, 2015, at 2:27 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> I think we touched on this in your other thread where you used the build <build-output>/jdk tree rather than <build-output>/images/jdk.
> 
> Sorry, you are correct on this. Once I had correctly built the images version the modules are no longer individual/exploded.
> I notice there are three images when built from source?
> appmodules.jimage
> bootmodules.jimage
> extmodules.jimage
> 
> For the jake ea version I downloaded from the URL provided at the talks there is only bootmodules.jimage if that matters.
> 
> Copying the other two images into the embedded application jdk still does not seem to launch. Although even command line showed that it should get the internals error. 
> It might be the same problem for the app and I?m just not seeing the more meaningful error messages. 
> 
> Is there any way around the internals for a non-modularized application? A fair percentage of OS X applications might have these particular ?internals?. There is JEP 272 so if I just wait, and change some code, that should go away. 
> 
> But in general, if you have other applications looking to migrate to 9 that have any of these who want to start out by just getting their application up and running they are not going to work. They will be forced to either eliminate the internal use or go modular from the start? Then the addExports will work. If I?m understanding that error message correctly.
> 
> Michael Hall
> 
> 
> 
> 
> 


From alex.buckley at oracle.com  Wed Nov 25 18:58:06 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 25 Nov 2015 10:58:06 -0800
Subject: Current plans for a new Java access modifier
In-Reply-To: <CABHMDwj7vHE6VwdtesJRX3gZtrje8BRCdqighdWkJYzCOGL_Kw@mail.gmail.com>
References: <CABHMDwj7vHE6VwdtesJRX3gZtrje8BRCdqighdWkJYzCOGL_Kw@mail.gmail.com>
Message-ID: <565604BE.5080104@oracle.com>

There is no new modifier for class/field/method declarations, but the 
effect of 'exports' in a module declaration is to limit the 
accessibility of 'public' class/field/method declarations. You also 
mentioned visibility, but that's a separate topic related to class 
loaders. Suggest you watch my "Project Jigsaw: Under the Hood" video 
linked from the Jigsaw project page.

Alex

On 11/25/2015 3:59 AM, Karl Sanders wrote:
> Hi,
>
> after a quick search in the Jigsaw docs and mailing list archives I
> came to the conclusion that there won't be a new Java access modifier
> between public and Package-Access, to allow visibility and access from
> other packages but only if inside the same module.
> Is this correct?
>
> Regards,
> Karl
>

From mik3hall at gmail.com  Wed Nov 25 22:54:04 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 25 Nov 2015 16:54:04 -0600
Subject: OS X application won't launch with jigsaw
In-Reply-To: <13108C67-EF00-4B7E-86C4-97791489A425@oracle.com>
References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com>
	<565570D9.4070302@oracle.com>
	<2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com>
	<13108C67-EF00-4B7E-86C4-97791489A425@oracle.com>
Message-ID: <A48475B0-72CF-4893-8CB6-C0740CF8BFC3@gmail.com>


Michael Hall




> On Nov 25, 2015, at 10:45 AM, Danno Ferrin <danno.ferrin at oracle.com> wrote:
> 
> However, we fully expect that the Java 8 packager will not be able to make bundles holding a Java 9 runtime, and I think this is what you are encountering.
> 

What I had done was use javapackager to generate an application bundle for 7 or 8. Not sure which anymore, I?ve been reusing the same one for a while.
Then I take the output of jdk 9 builds and paste it into the plugins directory of that same application.

This has been working fine until I tried a jigsaw specific ea.

Now the application doesn?t launch.

The launch errors output a single message to the console log that the application failed to launch.

I have a shell script that launches the application that way. This fails indicating it is trying to access the apple legacy api?s. Which it should. Access them that  is, not should fail. It does fail because these classes have been classified ?internal? and are inaccessible with the current jake builds.

_________
Exception in thread "main" java.lang.IllegalAccessError: class us.hall.osx.OSXApplication (in module: Unnamed Module) cannot access class com.apple.eawt.Application (in module: java.desktop), com.apple.eawt is not exported to Unnamed Module
___________

My understanding is that JEP 272 out of the awt group is addressing these classes. Converting them to a Desktop api that will be supported going forward. It will I?m assuming require changes on the part of any current OS X applications using the apple api?s to instead use the new Desktop api?s. I am ok with this. As long as I know about it and the changes aren?t massive. 

However, for any OS X developers not actively following the java 9 project this may become a problem in migration. javapackager, or whatever tool the developers use to create their application bundles could work fine but due to use of these api?s their applications won?t launch.

I?m sort of guessing javapackager might be the only tool at that point that will create valid application bundles. That or my way, guessing how a pasted in embedded jdk should work and just manually copying it in. As long as the changes don?t develop any other complications before the project completes so that by itself doesn?t work.

Anyhow I don?t believe the issues are javapackager, they are making formerly public apple ?extra? api?s now ?internal? ones whose use causes the application to fail.



From michael.rasmussen at zeroturnaround.com  Wed Nov 25 22:56:20 2015
From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen)
Date: Thu, 26 Nov 2015 00:56:20 +0200
Subject: Instrumentation best practices question, and more
Message-ID: <CAPMkJWY+APqF8z1Wzsp24QxEwHPpotSb8bStkex6f4oOOeL_Aw@mail.gmail.com>

Hi

Having recently started looking into the JDK9-jigsaw builds, and the
numerous changes that it entails, to see what impact it has on our
software, I have some initial questions that I haven't been able to
find the answers to so far.

1) There have been some discussions on this mailing list already
regarding escaping the encaptulation of the modules, but I haven't
found anything regarding what the best/recommended practice is for
something like profilers, trace advices, etc or anything else that
instruments classes throughout the system, inserting calls to methods
to perform various tasks.
In JDK8, adding this using a javaagent, my classes were on the boot
classpath, thus accessible to the entire system. But this is no longer
the case in jigsaw -- so how am I supposed to do this in a module-aware
system?
Am I just supposed to hack into the module system, to add edges from
every single module in the system to my agent? While that is doable,
it doesn't sounds very nice, requiring poking a lot of holes using
reflection to bypass the "in-same-module" checks etc.
These kind of instrumentations are not that uncommon in the Java
ecosystem, so I assume there must have been some considerations how
this should be accompliced?
Or is there no recommended way for doing this?

2) Why the backwards-incompatible change to getResourceAsStream
family of methods? Sure, the methods are binary compatible, but
behave very differently than previously!
Object.class.getResourceAsStream("Object.class") now returns null,
apparently just for the sake of it, as the InputStream can easily
be obtained from the Module, without any in-same-module checks, via:
Object.class.getModule().getResourceAsStream("java/lang/Object.class")
But, accessing this through the Module requires the code to be
compiled against JDK9, having to keep multiple different codepaths in
the code depending on which JDK version I'm loading the resources on!

3) Why was the implementation of java.lang.Package changed, so it no
longer returns the content of the Manifest file?
Previously, doing MyClass.class.getPackage().getImplementationTitle()
would return the "Implementation-Title" entry from the manifest file,
but now it returns null instead.
The documentation in JDK8 even mentions that this information is
typically stored in the manifest, where as the JDK9 now states that
these values are unspecified.


Best regards
Michael Rasmussen
ZeroTurnaround

From mik3hall at gmail.com  Wed Nov 25 23:06:53 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 25 Nov 2015 17:06:53 -0600
Subject: OS X application won't launch with jigsaw
In-Reply-To: <5655DA44.1050206@oracle.com>
References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com>
	<565570D9.4070302@oracle.com>
	<2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com>
	<5655DA44.1050206@oracle.com>
Message-ID: <CD321757-FF67-4CA7-8643-77EBF96F39A5@gmail.com>

> On Nov 25, 2015, at 9:56 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> If you feel strongly that the com.apple.eawt APIs should be exported in JDK 9 then you need to read JEP 260 [1] and make a case for adding the Apple APIs to the list.

I understand that knowing what impact a change will have is difficult to determine. I don?t think I could argue reversing that change solely on the basis of my own application. I can?t say how many applications it will affect. Probably most that have attempted to do any OS X customization. I myself am OK with these becoming supported going forward as part of the awt Desktop api?s. The question would be how many developers aren?t going to even be aware this has been done? I don?t have any estimate for that.

My questions mostly concerned my own application. I was trying to figure out if I could get addExports to work without any other changes to my current application. Not modularizing. 
My use of addExports may of been incorrect for this use case. Unmodularized application using ?internal? api?s and trying to addExports around it.
Does this work? What would be an example of the addExports for this situation?
I not only wanted a free get out of jail card, I wanted a free lunch. If this doesn?t work I will probably try to isolate out the startup code that use the apple api?s and just modularize that. 
Or if worse comes to worse I?ll just kill the functionality that uses the api?s in order to test with jake until JEP 272 is in fact ready and I can change api's. 

Michael Hall






From Alan.Bateman at oracle.com  Thu Nov 26 07:33:08 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Nov 2015 07:33:08 +0000
Subject: Instrumentation best practices question, and more
In-Reply-To: <CAPMkJWY+APqF8z1Wzsp24QxEwHPpotSb8bStkex6f4oOOeL_Aw@mail.gmail.com>
References: <CAPMkJWY+APqF8z1Wzsp24QxEwHPpotSb8bStkex6f4oOOeL_Aw@mail.gmail.com>
Message-ID: <5656B5B4.3090504@oracle.com>

On 25/11/2015 22:56, Michael Rasmussen wrote:
> :
>
> 1) There have been some discussions on this mailing list already
> regarding escaping the encaptulation of the modules, but I haven't
> found anything regarding what the best/recommended practice is for
> something like profilers, trace advices, etc or anything else that
> instruments classes throughout the system, inserting calls to methods
> to perform various tasks.
> In JDK8, adding this using a javaagent, my classes were on the boot
> classpath, thus accessible to the entire system. But this is no longer
> the case in jigsaw -- so how am I supposed to do this in a module-aware
> system?
> Am I just supposed to hack into the module system, to add edges from
> every single module in the system to my agent? While that is doable,
> it doesn't sounds very nice, requiring poking a lot of holes using
> reflection to bypass the "in-same-module" checks etc.
> These kind of instrumentations are not that uncommon in the Java
> ecosystem, so I assume there must have been some considerations how
> this should be accompliced?
> Or is there no recommended way for doing this?
Not in the current EA builds but in time there will be support for 
"module aware" agents.

In the mean-time then agents developed for JDK 8 and older should mostly 
just work. If you do load time or dynamic instrumentation via JVM TI or 
java.lang.instrument then you get some "readability for free", 
specifically there will be read edges automatically added so that when 
you instrument code in named module M then M will read the unnamed 
modules of the both the boot and application class loader. So if you 
instrument code in a named module to call your into your supporting 
classes on the boot class path or class path then it should continue to 
work.

I don't think I understand your point about being on the boot class path 
and get access "to the entire system". Being on the boot class path will 
limit visibility but doesn't change accessibility. Perhaps you mean that 
you get all permissions when running with a security manager?

>
> 2) Why the backwards-incompatible change to getResourceAsStream
> family of methods? Sure, the methods are binary compatible, but
> behave very differently than previously!
> Object.class.getResourceAsStream("Object.class") now returns null,
> apparently just for the sake of it, as the InputStream can easily
> be obtained from the Module, without any in-same-module checks, via:
> Object.class.getModule().getResourceAsStream("java/lang/Object.class")
> But, accessing this through the Module requires the code to be
> compiled against JDK9, having to keep multiple different codepaths in
> the code depending on which JDK version I'm loading the resources on!
Mark has summarized the current state of affairs here:

http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-October/000163.html

>
> 3) Why was the implementation of java.lang.Package changed, so it no
> longer returns the content of the Manifest file?
> Previously, doing MyClass.class.getPackage().getImplementationTitle()
> would return the "Implementation-Title" entry from the manifest file,
> but now it returns null instead.
> The documentation in JDK8 even mentions that this information is
> typically stored in the manifest, where as the JDK9 now states that
> these values are unspecified.
If MyClass is packaged as a JAR file with an Implementation-Title 
attribute then this should continue to work. I just checked and I don't 
see any issues but it's possible my test case doesn't match what you 
have. If you can create a short test case then that would be useful to 
help us see whether there is a bug here.

-Alan


From michael.rasmussen at zeroturnaround.com  Thu Nov 26 10:13:13 2015
From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen)
Date: Thu, 26 Nov 2015 12:13:13 +0200
Subject: Instrumentation best practices question, and more
In-Reply-To: <5656B5B4.3090504@oracle.com>
References: <CAPMkJWY+APqF8z1Wzsp24QxEwHPpotSb8bStkex6f4oOOeL_Aw@mail.gmail.com>
	<5656B5B4.3090504@oracle.com>
Message-ID: <CAPMkJWYzChh-5M1p_Ev-zL71JPG5MhUgp=Zh+s_PLPoxRjztfA@mail.gmail.com>

On 26 November 2015 at 09:33, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 25/11/2015 22:56, Michael Rasmussen wrote:
>>
>>
>> 3) Why was the implementation of java.lang.Package changed, so it no
>> longer returns the content of the Manifest file?
>> Previously, doing MyClass.class.getPackage().getImplementationTitle()
>> would return the "Implementation-Title" entry from the manifest file,
>> but now it returns null instead.
>> The documentation in JDK8 even mentions that this information is
>> typically stored in the manifest, where as the JDK9 now states that
>> these values are unspecified.
>
> If MyClass is packaged as a JAR file with an Implementation-Title attribute
> then this should continue to work. I just checked and I don't see any issues
> but it's possible my test case doesn't match what you have. If you can
> create a short test case then that would be useful to help us see whether
> there is a bug here.
>

Yeah, I should have been more specific -- the issue is when the package
is loaded from the boot loader, for instance when you have an agent that
has itself on the Boot-Class-Path in the manifest.

Sample code: https://gist.github.com/anonymous/d4f591fc041e676eb8d9

Output:
$ java -javaagent:target\test-1.0-SNAPSHOT.jar -version
test
null
1.0-SNAPSHOT
test
null
1.0-SNAPSHOT
test
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

$ java -javaagent:target\test-1.0-SNAPSHOT.jar -version
null
null
null
null
null
null
null
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build
1.9.0-ea-jigsaw-nightly-h3660-20151022-b86)
Java HotSpot(TM) 64-Bit Server VM (build
1.9.0-ea-jigsaw-nightly-h3660-20151022-b86, mixed mode)

From Alan.Bateman at oracle.com  Thu Nov 26 10:54:06 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Nov 2015 10:54:06 +0000
Subject: Instrumentation best practices question, and more
In-Reply-To: <CAPMkJWYzChh-5M1p_Ev-zL71JPG5MhUgp=Zh+s_PLPoxRjztfA@mail.gmail.com>
References: <CAPMkJWY+APqF8z1Wzsp24QxEwHPpotSb8bStkex6f4oOOeL_Aw@mail.gmail.com>
	<5656B5B4.3090504@oracle.com>
	<CAPMkJWYzChh-5M1p_Ev-zL71JPG5MhUgp=Zh+s_PLPoxRjztfA@mail.gmail.com>
Message-ID: <5656E4CE.10402@oracle.com>


On 26/11/2015 10:13, Michael Rasmussen wrote:
> Yeah, I should have been more specific -- the issue is when the package
> is loaded from the boot loader, for instance when you have an agent that
> has itself on the Boot-Class-Path in the manifest.
>
>
Thanks for clarifying.

What you are seeing is specific to JAR files added to the (otherwise 
does not exist) boot class path via -Xbootclasspath/a or agent 
equivalent. It's not a general issue. We've ignored this case in the 
current EA builds on the assumption that it should be very rare, we will 
probably need to look at it again.

-Alan.

From alan.bateman at oracle.com  Thu Nov 26 18:32:25 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 26 Nov 2015 18:32:25 +0000
Subject: hg: jigsaw/jake/jdk: ProxyClassAccessTest.java failing in agentvm mode
Message-ID: <201511261832.tAQIWPdG017018@aojmv0008.oracle.com>

Changeset: 7ca5833e24a0
Author:    alanb
Date:      2015-11-26 18:31 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7ca5833e24a0

ProxyClassAccessTest.java failing in agentvm mode

! test/jdk/jigsaw/reflect/Proxy/ProxyClassAccessTest.java


From alan.bateman at oracle.com  Thu Nov 26 18:40:37 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 26 Nov 2015 18:40:37 +0000
Subject: hg: jigsaw/jake/jdk: 8143583: Several tests don't work with latest
	jtreg due to non-existing files in @build
Message-ID: <201511261840.tAQIecQw018745@aojmv0008.oracle.com>

Changeset: 8fde59315381
Author:    amlu
Date:      2015-11-23 16:14 +0800
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8fde59315381

8143583: Several tests don't work with latest jtreg due to non-existing files in @build
Reviewed-by: alanb, sla

! test/com/sun/jdi/DoubleAgentTest.java
! test/com/sun/jdi/SuspendNoFlagTest.java
! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java
! test/sun/tools/jmap/BasicJMapTest.java


From alan.bateman at oracle.com  Thu Nov 26 19:33:55 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 26 Nov 2015 19:33:55 +0000
Subject: hg: jigsaw/jake/jdk: Remove invalid negative test
Message-ID: <201511261933.tAQJXtTk028606@aojmv0008.oracle.com>

Changeset: be2e47bf00ce
Author:    alanb
Date:      2015-11-26 19:33 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/be2e47bf00ce

Remove invalid negative test

! test/jdk/jigsaw/tools/jlink/JLinkNegativeTest.java


From stef at epardaud.fr  Fri Nov 27 13:51:05 2015
From: stef at epardaud.fr (Stephane Epardaud)
Date: Fri, 27 Nov 2015 14:51:05 +0100
Subject: Questions about the Jigsaw EA builds
Message-ID: <56585FC9.3070400@epardaud.fr>

Hi,

I work on Ceylon, a JVM language, using a fork of javac 7 with backports
from javac 8, and currently trying to see how to make it work with Java
9, which is interesting in our case as Ceylon already has modularity and
adopted the JDK modularisation (as it was planned in Jigsaw) since Java 7.

I downloaded the EA builds from https://jdk9.java.net/ and it lists two:

- https://jdk9.java.net/download/ (build 93)
- https://jdk9.java.net/jigsaw/ (build 86)

Leading me to believe that the first was more recent, but it does not
appear to include the java.annotations.common module in its lib/modules
jimages. The second one has it, but has other differences such as having
a jmods/ folder with ZIP module files (the format seems to be
straightforward, but is there a specification somewhere?), and having
only a single .jimage in lib/modules (but with more modules there).

Am I right that I should use the second one?

How do the build numbers relate? Are they independent ?

Is the lib/modules supposed to contain one or three .jimage files?

How does that relate to the jmods/ folder? Will/should javac use the
.jimage or the jmods files? They seem to offer the same contents.

Is there any documentation as to the format of the "jrt:/" NIO
FileSystem? I've figured some things out to extract class file data from
there, but a specification (even WIP) would be useful to verify my
observations.

Thanks for you help, cheers.


From Alan.Bateman at oracle.com  Fri Nov 27 14:28:32 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Nov 2015 14:28:32 +0000
Subject: Questions about the Jigsaw EA builds
In-Reply-To: <56585FC9.3070400@epardaud.fr>
References: <56585FC9.3070400@epardaud.fr>
Message-ID: <56586890.7010504@oracle.com>

On 27/11/2015 13:51, Stephane Epardaud wrote:
> Hi,
>
> I work on Ceylon, a JVM language, using a fork of javac 7 with backports
> from javac 8, and currently trying to see how to make it work with Java
> 9, which is interesting in our case as Ceylon already has modularity and
> adopted the JDK modularisation (as it was planned in Jigsaw) since Java 7.
>
> I downloaded the EA builds from https://jdk9.java.net/ and it lists two:
>
> - https://jdk9.java.net/download/ (build 93)
> - https://jdk9.java.net/jigsaw/ (build 86)
>
> Leading me to believe that the first was more recent, but it does not
> appear to include the java.annotations.common module in its lib/modules
> jimages. The second one has it, but has other differences such as having
> a jmods/ folder with ZIP module files (the format seems to be
> straightforward, but is there a specification somewhere?), and having
> only a single .jimage in lib/modules (but with more modules there).
>
> Am I right that I should use the second one?
>
> How do the build numbers relate? Are they independent ?
>
> Is the lib/modules supposed to contain one or three .jimage files?
>
> How does that relate to the jmods/ folder? Will/should javac use the
> .jimage or the jmods files? They seem to offer the same contents.
>
> Is there any documentation as to the format of the "jrt:/" NIO
> FileSystem? I've figured some things out to extract class file data from
> there, but a specification (even WIP) would be useful to verify my
> observations.
>

The JDK 9 EA builds are built from the JDK 9 master forest and are 
published weekly. The module system is not in JDK 9 yet but there are a 
multitude of other features and bug fixes going into JDK 9 each week. 
The weekly builds are tagged with a build number, the current build that 
is on the java.net download site is build 93.

The module system (as in the prototype for JSR 376 and the JDK-specific 
enhancements in JEP 261) is being developed here, in Project Jigsaw. The 
development is based on JDK 9. We periodically sync up the development 
forest with the changes from JDK 9, we also make EA builds available. At 
this time then the jigsaw/jake forest is JDK 9 build 92 + module system. 
The current EA download is a bit older, it is based on JDK 9 build 86. 
The module system changes a lot of things and it's often a lot a bit of 
work to sync up the jigsaw/jake forest (lots of merging and adjustments 
to get everything working after a big sync up). Once the design has 
settled then we will integrate the module system into JDK 9 so that 
should reduce the work (and the confusion with having different EA 
downloads).

As regards the jrt file system then you need to start with JEP 220 [1]. 
I don't think there is other documentation at this time.

The jrt file system provider is in JDK 9 since late 2014. There are 
several changes and bug fixes that are in the jigsaw/jake forest that 
are not in JDK 9 and might not be in JDK 9 until the module system goes 
in. The reason for this is that underlying jimage container is used 
differently in JDK 9 vs. jigsaw/jake. We have moved to a single jimage 
container file in jigsaw/jake where the classes/resources are addressed 
by module. javac and other tools are using the file system API and 
should not care how many container files are used in the run-time image.

The jmod files that you seeing are just packaged modules. I don't expect 
you will need to be concerned with these at this point. There are many 
open questions about the JMOD format so no documents to point at just 
now. The linker tool consumes these packaged modules when creating 
run-time images. The reason for the jmods/ directory in the EA builds is 
to put everything in a single download rather than having separate 
downloads and risk getting out of sync. This does make the EA downloads 
bigger for the moment (much bigger because the packages modules have the 
debug symbols).

-Alan.

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



From stef at epardaud.fr  Fri Nov 27 14:51:25 2015
From: stef at epardaud.fr (Stephane Epardaud)
Date: Fri, 27 Nov 2015 15:51:25 +0100
Subject: Questions about the Jigsaw EA builds
In-Reply-To: <56586890.7010504@oracle.com>
References: <56585FC9.3070400@epardaud.fr> <56586890.7010504@oracle.com>
Message-ID: <56586DED.6050203@epardaud.fr>

OK thanks a lot for all these answers, it's much clearer for me now :)

From alan.bateman at oracle.com  Fri Nov 27 15:46:06 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 27 Nov 2015 15:46:06 +0000
Subject: hg: jigsaw/jake/hotspot: Change Configuration.resolve to take a
	parent Configuration rather than parent Layer
Message-ID: <201511271546.tARFk6K7006746@aojmv0008.oracle.com>

Changeset: 5d9fe269bb7a
Author:    alanb
Date:      2015-11-27 15:25 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5d9fe269bb7a

Change Configuration.resolve to take a parent Configuration rather than parent Layer
Change Configuration.reads to read a set of read dependences rather than descriptors

! test/runtime/modules/AccessCheck/ExportAllUnnamed.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_CheckRead.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpQualOther.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpQualToM1.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpUnqual.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgNotExp.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_UmodNpkg.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_UmodUpkg.java
! test/runtime/modules/AccessCheck/NmodNpkg_CheckRead.java
! test/runtime/modules/AccessCheck/NmodNpkg_PkgExpQualOther.java
! test/runtime/modules/AccessCheck/NmodNpkg_PkgExpQualToM1.java
! test/runtime/modules/AccessCheck/NmodNpkg_PkgExpUnqual.java
! test/runtime/modules/AccessCheck/NmodNpkg_PkgNotExp.java
! test/runtime/modules/AccessCheck/NmodNpkg_UmodNpkg.java
! test/runtime/modules/AccessCheck/NmodNpkg_UmodUPkg.java
! test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgExpQualOther.java
! test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgExpUnqual.java
! test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgNotExp.java
! test/runtime/modules/AccessCheck/UmodNpkg_PkgExpQualOther.java
! test/runtime/modules/AccessCheck/UmodNpkg_PkgExpUnqual.java
! test/runtime/modules/AccessCheck/UmodNpkg_PkgNotExp.java
! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_PkgExpQualOther.java
! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_PkgNotExp.java
! test/runtime/modules/AccessCheck/UmodUpkg_PkgExpQualOther.java
! test/runtime/modules/AccessCheck/UmodUpkg_PkgNotExp.java


From alan.bateman at oracle.com  Fri Nov 27 15:46:23 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 27 Nov 2015 15:46:23 +0000
Subject: hg: jigsaw/jake/langtools: Change Configuration.resolve to take a
	parent Configuration rather than parent Layer
Message-ID: <201511271546.tARFkNRW006944@aojmv0008.oracle.com>

Changeset: 39f04bde0b71
Author:    alanb
Date:      2015-11-27 15:25 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/39f04bde0b71

Change Configuration.resolve to take a parent Configuration rather than parent Layer
Change Configuration.reads to read a set of read dependences rather than descriptors

! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleWrappers.java


From alan.bateman at oracle.com  Fri Nov 27 15:46:50 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 27 Nov 2015 15:46:50 +0000
Subject: hg: jigsaw/jake/jdk: Change Configuration.resolve to take a parent
	Configuration rather than parent Layer
Message-ID: <201511271546.tARFkoa3007069@aojmv0008.oracle.com>

Changeset: 85e0957f1d06
Author:    alanb
Date:      2015-11-27 15:34 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/85e0957f1d06

Change Configuration.resolve to take a parent Configuration rather than parent Layer
Change Configuration.reads to read a set of read dependences rather than descriptors

! make/src/classes/build/tools/jigsaw/GenGraphs.java
! make/src/classes/build/tools/jigsaw/ModuleSummary.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/module/Configuration.java
! src/java.base/share/classes/java/lang/module/Resolver.java
! src/java.base/share/classes/java/lang/reflect/Layer.java
! src/java.base/share/classes/java/lang/reflect/Module.java
! src/java.base/share/classes/java/util/ServiceLoader.java
! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
! src/java.base/share/classes/sun/launcher/LauncherHelper.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/JlinkTask.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/TaskHelper.java
! test/java/lang/Class/getResource/Main.java
! test/java/lang/ModuleClassLoader/Basic.java
! test/jdk/jigsaw/module/AutomaticModulesTest.java
! test/jdk/jigsaw/module/ConfigurationTest.java
! test/jdk/jigsaw/reflect/Layer/LayerTest.java
! test/jdk/jigsaw/reflect/Module/BasicModuleTest.java
! test/jdk/jigsaw/reflect/Proxy/ProxyClassAccessTest.java
! test/jdk/jigsaw/reflect/Proxy/ProxyLayerTest.java
! test/jdk/jigsaw/scenarios/automaticmodules/src/basictest/test/Main.java
! test/jdk/jigsaw/scenarios/container/src/container/container/Main.java
! test/jdk/jigsaw/util/ServiceLoader/ServicesTest.java


From alan.bateman at oracle.com  Fri Nov 27 16:14:46 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 27 Nov 2015 16:14:46 +0000
Subject: hg: jigsaw/jake/jdk: Change IllegalAccessException messages to align
	with IllegalAccessError messages
Message-ID: <201511271614.tARGEkGr017398@aojmv0008.oracle.com>

Changeset: a92829ff8629
Author:    alanb
Date:      2015-11-27 16:14 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a92829ff8629

Change IllegalAccessException messages to align with IllegalAccessError messages

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


From simon at ochsenreither.de  Fri Nov 27 19:52:44 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Fri, 27 Nov 2015 20:52:44 +0100
Subject: Creating modules with JDK8
Message-ID: <5658B48C.5040808@ochsenreither.de>

Hi everyone,

sorry if this has been asked already, I couldn't find it in the
documentation.

Will the code that creates *.jmod files from *.class files be runnable
on earlier versions of the JDK, or available via Maven Central?

Thanks,

Simon

From forax at univ-mlv.fr  Sat Nov 28 13:46:27 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 28 Nov 2015 14:46:27 +0100 (CET)
Subject: Creating modules with JDK8
In-Reply-To: <5658B48C.5040808@ochsenreither.de>
References: <5658B48C.5040808@ochsenreither.de>
Message-ID: <1266968111.403122.1448718387586.JavaMail.zimbra@u-pem.fr>

Hi Simon, the jmod file format is special file format,
compared to the jar file format, jmod allows to embed native code in the archive.

Apart if you want to embed native code, a module is just a jar with a module-info.class at its root.

regards,
R?mi

----- Mail original -----
> De: "Simon Ochsenreither" <simon at ochsenreither.de>
> ?: jigsaw-dev at openjdk.java.net
> Envoy?: Vendredi 27 Novembre 2015 20:52:44
> Objet: Creating modules with JDK8
> 
> Hi everyone,
> 
> sorry if this has been asked already, I couldn't find it in the
> documentation.
> 
> Will the code that creates *.jmod files from *.class files be runnable
> on earlier versions of the JDK, or available via Maven Central?
> 
> Thanks,
> 
> Simon
> 

From alan.bateman at oracle.com  Sun Nov 29 07:58:52 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sun, 29 Nov 2015 07:58:52 +0000
Subject: hg: jigsaw/jake/hotspot: ModuleReference does not need to be abstract
	class
Message-ID: <201511290758.tAT7wqGN009776@aojmv0008.oracle.com>

Changeset: 3263a98ebab2
Author:    alanb
Date:      2015-11-29 07:55 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3263a98ebab2

ModuleReference does not need to be abstract class

! test/runtime/modules/AccessCheck/ExportAllUnnamed.java
! test/runtime/modules/AccessCheck/ModuleLibrary.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_CheckRead.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpQualOther.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpQualToM1.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpUnqual.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgNotExp.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_UmodNpkg.java
! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_UmodUpkg.java
! test/runtime/modules/AccessCheck/NmodNpkg_CheckRead.java
! test/runtime/modules/AccessCheck/NmodNpkg_PkgExpQualOther.java
! test/runtime/modules/AccessCheck/NmodNpkg_PkgExpQualToM1.java
! test/runtime/modules/AccessCheck/NmodNpkg_PkgExpUnqual.java
! test/runtime/modules/AccessCheck/NmodNpkg_PkgNotExp.java
! test/runtime/modules/AccessCheck/NmodNpkg_UmodNpkg.java
! test/runtime/modules/AccessCheck/NmodNpkg_UmodUPkg.java
! test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgExpQualOther.java
! test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgExpUnqual.java
! test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgNotExp.java
! test/runtime/modules/AccessCheck/UmodNpkg_PkgExpQualOther.java
! test/runtime/modules/AccessCheck/UmodNpkg_PkgExpUnqual.java
! test/runtime/modules/AccessCheck/UmodNpkg_PkgNotExp.java
! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_PkgExpQualOther.java
! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_PkgNotExp.java
! test/runtime/modules/AccessCheck/UmodUpkg_PkgExpQualOther.java
! test/runtime/modules/AccessCheck/UmodUpkg_PkgNotExp.java


From alan.bateman at oracle.com  Sun Nov 29 07:59:27 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sun, 29 Nov 2015 07:59:27 +0000
Subject: hg: jigsaw/jake/jdk: 2 new changesets
Message-ID: <201511290759.tAT7xREI010077@aojmv0008.oracle.com>

Changeset: 23fa3594a1d4
Author:    alanb
Date:      2015-11-27 16:27 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/23fa3594a1d4

Fix imports

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

Changeset: a3683eec0092
Author:    alanb
Date:      2015-11-29 07:55 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a3683eec0092

ModuleReference does not need to be abstract class

! src/java.base/share/classes/java/lang/module/InstalledModuleFinder.java
! src/java.base/share/classes/java/lang/module/ModuleReference.java
! src/java.base/share/classes/java/lang/module/ModuleReferences.java
! test/jdk/jigsaw/lib/ModuleUtils.java
! test/jdk/jigsaw/module/ModuleReferenceTest.java
! test/jdk/jigsaw/reflect/Proxy/ProxyLayerTest.java


From Alan.Bateman at oracle.com  Sun Nov 29 08:18:24 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 29 Nov 2015 08:18:24 +0000
Subject: Creating modules with JDK8
In-Reply-To: <5658B48C.5040808@ochsenreither.de>
References: <5658B48C.5040808@ochsenreither.de>
Message-ID: <565AB4D0.3040702@oracle.com>

On 27/11/2015 19:52, Simon Ochsenreither wrote:
> Hi everyone,
>
> sorry if this has been asked already, I couldn't find it in the
> documentation.
>
> Will the code that creates *.jmod files from *.class files be runnable
> on earlier versions of the JDK, or available via Maven Central?
>
I suspect there is a more general question here as to how you might 
release a library that works on JDK 8 but can also work as a module with 
JDK 9, is that right?

If so then check out modular JARs (as R?mi suggested) as they are just 
regular JAR files with a compiled module declaration in the top-level 
directory of the JAR file. If the code that is packaged in the JAR file 
is compiled for JDK 8 then it creates the potential for the library to 
work as a regular JAR file on the class path with JDK 8 (or 9) or as a 
module on the module path with JDK 9+.

There is clearly a lot of opportunity for tooling. I think most builds 
today compile with an older JDK whereas the transition to modules brings 
up the question as to whether to compile with JDK 9 and use the new 
javac -release option to compile the code JDK 8, and compile the module 
declaration for JDK 9. Also with multi-release JAR files coming in JDK 9 
(JEP 238) then it's possible to have release specific code in the JAR 
file too. All told, it could complicates the build a bit and this is 
where good tooling could help a lot.

As you bring up JMOD files then it's just an alternative packaging 
format. At this time then it's mostly for modules that are intended to 
be linked into a run-time image (meaning a JRE, JDK or custom run-time) 
- it isn't currently an execution format. I could imagine Maven plugins 
supporting it as a new artifact type in the future.

-Alan

From weijun.wang at oracle.com  Sun Nov 29 09:23:45 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Sun, 29 Nov 2015 17:23:45 +0800
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <ddd22ece-13db-4838-a729-38dc1f79066c@default>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
Message-ID: <FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>

Some comments:

1. Maybe use jdk/testlibrary/JDKToolLauncher.java to launch jarsigner?

2. You mentioned it's difficult to set a security provider in java.security file. Have you tried "-Djava.security.properties=="? It is described at the beginning of java.security.

Thanks
Max

> On Nov 23, 2015, at 9:14 PM, Siba Sahoo <sibabrata.sahoo at oracle.com> wrote:
> 
> +HYPERLINK "mailto:security-dev at openjdk.java.net"security-dev at openjdk.java.net
> 
> 
> 
> From: Siba Sahoo 
> Sent: Monday, November 23, 2015 4:56 PM
> To: jigsaw-dev at openjdk.java.net; jdk-security-dev_ww_grp; Sean Mullan
> Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs
> 
> 
> 
> Hi,
> 
> 
> 
> Please help me with your review of this test for JBS: https://bugs.openjdk.java.net/browse/JDK-8130360, 
> 
> 
> 
> Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/
> 
> 
> 
> Description
> 
> Tests to verify 3rd party security providers if they are in signed/unsigned modular JARs. The test code checks the modular behavior with different combination of separate client & security provider, when available as modular(signed/unsigned) jar. It address total  of 72 test cases with the following criteria:
> 
> 
> 
> (Signed/Unsigned Jar) X (ClassLoader/ServiceLoader) X (combination of EXPLICIT/AUTO/UNAMED modules) X (With/Without Service descriptor) 
> 
> 
> 
> Thanks,
> 
> Siba
> 
> 


From simon at ochsenreither.de  Sun Nov 29 14:21:57 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Sun, 29 Nov 2015 15:21:57 +0100
Subject: Creating modules with JDK8
In-Reply-To: <1266968111.403122.1448718387586.JavaMail.zimbra@u-pem.fr>
References: <5658B48C.5040808@ochsenreither.de>
	<1266968111.403122.1448718387586.JavaMail.zimbra@u-pem.fr>
Message-ID: <565B0A05.3050609@ochsenreither.de>

Thanks for these details, they help a lot!

From mik3hall at gmail.com  Sun Nov 29 16:03:58 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 29 Nov 2015 10:03:58 -0600
Subject: jdeps command
In-Reply-To: <5542B8F0.5080003@oracle.com>
References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>
	<8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>
	<1C429076-EAD9-4E9F-9F46-0CBEC5FCAF55@apple.com>
	<4003789C-4821-439B-9E57-88837D6B55B2@gmail.com>
	<5542AF10.2000500@oracle.com>
	<E0E9DAF6-7497-4A2F-B2BE-85A73B114392@gmail.com>
	<5542B8F0.5080003@oracle.com>
Message-ID: <1647CC9C-AFA9-4BF4-BE2C-B7D81C8DF4B7@gmail.com>

> On Apr 30, 2015, at 6:21 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 
> 
> Right - things may change during JDK 9 development and should wait until GA.  My main point is that the list of JDK tools could be different for any release.
> 
> Mandy

Just remembered this one.
I?m not sure who maintains the production installers and links. But it seems to me the correct way to do this is sort of what I have been doing lately for java 9 early access. You need to know what version links are currently in place and run an uninstaller script that deletes those. You can get the correct list of commands by listing the prior jvm's bin directory. Then you run an installer script that sets up links to the new jvm?s bin directory, this time listing against that directory first to get the correct list of commands that need linking. 

Michael Hall






From alan.bateman at oracle.com  Sun Nov 29 19:44:09 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sun, 29 Nov 2015 19:44:09 +0000
Subject: hg: jigsaw/jake/jdk: 2 new changesets
Message-ID: <201511291944.tATJi9dI002947@aojmv0008.oracle.com>

Changeset: ab5b6e7e9db6
Author:    alanb
Date:      2015-11-29 10:55 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ab5b6e7e9db6

ModuleReference hashCode no longer cached

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

Changeset: 5dbfdd461d03
Author:    alanb
Date:      2015-11-29 19:43 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5dbfdd461d03

Change -listmods to list observable modules

! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
! src/java.base/share/classes/sun/launcher/LauncherHelper.java
! src/java.base/share/classes/sun/launcher/resources/launcher.properties
! src/java.base/share/native/libjli/java.c
! test/jdk/jigsaw/launcher/listmods/ListModsTest.java
+ test/jdk/jigsaw/launcher/listmods/src/java.transaction/javax/transaction/Transaction.java
+ test/jdk/jigsaw/launcher/listmods/src/java.transaction/javax/transaction/atomic/Atomic.java
+ test/jdk/jigsaw/launcher/listmods/src/java.transaction/module-info.java
+ test/jdk/jigsaw/launcher/listmods/src/m1/module-info.java


From simon at ochsenreither.de  Sun Nov 29 20:26:53 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Sun, 29 Nov 2015 21:26:53 +0100
Subject: Creating modules with JDK8
In-Reply-To: <565AB4D0.3040702@oracle.com>
References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com>
Message-ID: <565B5F8D.1060606@ochsenreither.de>

Hi,

> All told, it could complicates the build a bit and this is
> where good tooling could help a lot.

is there anything planned in this direction yet? Because the rest of the
JVM ecosystem seems to remain largely apathetic towards it.

A small list of issues which remain to be tackled:

- No usable separation between runtime of the build tool and runtime of
the code to be compiled. (You can do it, but it's annoying and hard to
setup.)
- No support for runtime versioning in Maven/Ivy. (Currently people seem
to use horrible hacks like using one major version for e.g. Java 6, and
another major version with Java 8), meaning it is completely impossible
to specify currently "I want to have versions of my dependencies that
run on JDK X".
- Versioning/artifact structure differences between major tools like
Maven and Ivy cause a lot of unnecessary churn and complexity.
- JDK artifacts are not available through dependency resolution tools,
meaning installing the JVM/JDK is a separate step which needs to be
handled outside of the usual build tools. (Which in turn makes
reproducible builds across different machines annoying.)
- No small enough _supported_ JVM runtime which could be bundled with
build tools, meaning the setup is yet-another step beginners have to
deal with.
- The two things above combined mean that it's currently not possible to
have a build tool which can bootstrap itself properly.

While I understand that Oracle doesn't make money with developer
happiness or ease-of-use it holds some of the important keys to
improvements in its hand.

> As you bring up JMOD files then it's just an alternative packaging
> format. At this time then it's mostly for modules that are intended to
> be linked into a run-time image (meaning a JRE, JDK or custom run-time)
> - it isn't currently an execution format. I could imagine Maven plugins
> supporting it as a new artifact type in the future.

How would we read these files when running on earlier JDK versions?

Thanks,

Simon


From mik3hall at gmail.com  Sun Nov 29 20:28:35 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 29 Nov 2015 14:28:35 -0600
Subject: Apple internal api's
In-Reply-To: <2A18D261-FB25-4AC4-85E5-ADE899E1819E@oracle.com>
References: <F07E7C52-2972-4AA6-96FF-8E88CD6CDFD0@gmail.com>
	<2A18D261-FB25-4AC4-85E5-ADE899E1819E@oracle.com>
Message-ID: <7A423D82-BF29-45ED-A908-45382CAEF368@gmail.com>

> On Nov 24, 2015, at 9:18 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> com.apple.eawt is in java.desktop module.  Try this:
> 
> java -XaddExports:java.desktop/com.apple.eawt=ALL-UNNAMED 

This one I had almost missed. For me, more fully, this had to be?

-XaddExports:java.desktop/com.apple.eawt=ALL-UNNAMED,java.desktop/com.apple.eio=ALL-UNNAMED

It then works and launches the application with some exceptions I have to look at.

For OS X customized apps just wanting to get up and running with java 9 this seems the way to go.

If you start hearing from people that their OS X applications won?t launch you might suggest that to them.

Michael Hall






From mik3hall at gmail.com  Sun Nov 29 21:20:10 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 29 Nov 2015 15:20:10 -0600
Subject: OS X application won't launch with jigsaw
In-Reply-To: <A48475B0-72CF-4893-8CB6-C0740CF8BFC3@gmail.com>
References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com>
	<565570D9.4070302@oracle.com>
	<2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com>
	<13108C67-EF00-4B7E-86C4-97791489A425@oracle.com>
	<A48475B0-72CF-4893-8CB6-C0740CF8BFC3@gmail.com>
Message-ID: <BE9E295D-80AD-4A27-B1C9-340D6BE589FC@gmail.com>


>> On Nov 25, 2015, at 10:45 AM, Danno Ferrin <danno.ferrin at oracle.com <mailto:danno.ferrin at oracle.com>> wrote:
>> 
>> However, we fully expect that the Java 8 packager will not be able to make bundles holding a Java 9 runtime, and I think this is what you are encountering.

I got past the original, jigsaw problem with internal apple api?s, running with a command line launch from a shell script. 
when I tried applying the same change, addition of a new -X jvmoption to my application bundle by changing the Info.plist file with Xcode, I get this?

11/29/15 3:00:35.131 PM sandboxd[277]: ([6613]) mdworker(6613) deny file-read-data /Users/mjh/Library/Preferences/com.apple.security.plist (import fstype:hfs fsflag:480D000 flags:250000025E diag:0 isXCode:0 uti:com.apple.application-bundle plugin:/Library/Spotlight/Application.mdimporter - find suspect file using: sudo mdutil -t 12638960)
11/29/15 3:01:14.467 PM amfid[104]: /Users/mjh/HalfPipe/bundles/HalfPipe9/HalfPipe9.app/Contents/MacOS/HalfPipe9 signature not valid: 0xfffefa2a
11/29/15 3:01:14.000 PM kernel[0]: proc 6707: load code signature error 4 for file ?HalfPipe9"

It might be that changing the application bundle doesn?t invalidate the signed application signature but changing the Info.plist does?
I might try regenerating the application including the -X option.

I assume from your message javapackager support for Java 9 isn?t considered complete yet? So I might have to try the same trick of generating a earlier version and then copying in the java 9 jvm. My use of javapackager is still rather limited as for this application reusing the same one has seemed to work best up to now. 

Michael Hall



From mic at micdev.net  Sun Nov 29 22:16:18 2015
From: mic at micdev.net (Michael Mayne (micdev))
Date: Sun, 29 Nov 2015 22:16:18 +0000
Subject: hg: jigsaw/jake/jdk: Change IllegalAccessException messages to
	align with IllegalAccessError messages
In-Reply-To: <201511271614.tARGEkGr017398@aojmv0008.oracle.com>
References: <201511271614.tARGEkGr017398@aojmv0008.oracle.com>
Message-ID: <CAEL23DXdr6yAdPBtKygfZX4F6iC2qLKQZ9vBmnRDuZXSBW_+fA@mail.gmail.com>

unsubscribe

On 27 November 2015 at 16:14, <alan.bateman at oracle.com> wrote:

> Changeset: a92829ff8629
> Author:    alanb
> Date:      2015-11-27 16:14 +0000
> URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a92829ff8629
>
> Change IllegalAccessException messages to align with IllegalAccessError
> messages
>
> ! src/java.base/share/classes/java/lang/reflect/Module.java
> ! src/java.base/share/classes/sun/reflect/Reflection.java
>
>

From cedric.champeau at gmail.com  Mon Nov 30 08:50:56 2015
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Mon, 30 Nov 2015 09:50:56 +0100
Subject: Creating modules with JDK8
In-Reply-To: <565B5F8D.1060606@ochsenreither.de>
References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com>
	<565B5F8D.1060606@ochsenreither.de>
Message-ID: <CADQzvm=DQA1jsuPUV+OR1GuVGwEC1S2zV87CY7Q-QqEHd0RXWA@mail.gmail.com>

2015-11-29 21:26 GMT+01:00 Simon Ochsenreither <simon at ochsenreither.de>:

> Hi,
>
> > All told, it could complicates the build a bit and this is
> > where good tooling could help a lot.
>
> is there anything planned in this direction yet? Because the rest of the
> JVM ecosystem seems to remain largely apathetic towards it.
>
>
Not all the JVM ecosystem is apathic about this. Gradle already
demonstrated support for building for Jigsaw during JavaOne,
with our software model. It's still under heavy development but we plan to
have something testable for general public by early
next year (it is already testable by "power users"). Basically you can
already have build scripts that contain configuration like this:


model {
    myLib(JvmLibrarySpec) {
         targetPlatform 'java8'
         targetPlatform 'java9'
         api {
            exports 'com.acme.mylib.util'
            exports 'com.acme.mylib.client'
         }
    }
}

And we're building the Java 8 and Java 9 versions separately for this
specification. By separately, we mean that it's really 2 different jars.
Also this modelling allows us
to check *at compile time* today if a dependent component makes use of
non-exported (internal) APIs, and this works for pre-Jigsaw platforms. We
want to get away
from the traditional "Maven" way of things which is not good enough for
what we want to do, and doesn't scale to real industrial challenges. In
particular, we
want to express that the dependencies for a platform (Java 8) are different
from the dependencies for a different platform (Java 9). As well, runtime
dependencies
are very different from compile time dependencies. Depending on your target
deployment environment, you would want to express different dependencies
(targetting
WildFly is not the same as targetting Tomcat, but one model can describe
both). This also means that while for us it is pretty easy to support
"multi-version jars", this
is definitely not something we will ever recommend to do, because it's a
very weak model. It doesn't allow you to have different dependencies for
the same library. We
think that support for this problem of separating the runtime from the
compile process is something that the build tools have to deal with, not
the JVM. So because
we're a generic build tool we will support multi-version jars, but not by
default.

Eventually, I would also not recommend to put a module-info class (jdk 9
format) into a jar built for java 8. Just because there are tons of changes
that it will blow up
at runtime for legacy applications that use classpath scanning, and will
fail when they see an unrecognized class format.

I won't want to dig more into the details here, but no, the JVM world is
not apathic about this, it's not just Maven and Ivy.


> A small list of issues which remain to be tackled:
>
> - No usable separation between runtime of the build tool and runtime of
> the code to be compiled. (You can do it, but it's annoying and hard to
> setup.)
> - No support for runtime versioning in Maven/Ivy. (Currently people seem
> to use horrible hacks like using one major version for e.g. Java 6, and
> another major version with Java 8), meaning it is completely impossible
> to specify currently "I want to have versions of my dependencies that
> run on JDK X".
> - Versioning/artifact structure differences between major tools like
> Maven and Ivy cause a lot of unnecessary churn and complexity.
> - JDK artifacts are not available through dependency resolution tools,
> meaning installing the JVM/JDK is a separate step which needs to be
> handled outside of the usual build tools. (Which in turn makes
> reproducible builds across different machines annoying.)
> - No small enough _supported_ JVM runtime which could be bundled with
> build tools, meaning the setup is yet-another step beginners have to
> deal with.
> - The two things above combined mean that it's currently not possible to
> have a build tool which can bootstrap itself properly.
>
> While I understand that Oracle doesn't make money with developer
> happiness or ease-of-use it holds some of the important keys to
> improvements in its hand.
>
> > As you bring up JMOD files then it's just an alternative packaging
> > format. At this time then it's mostly for modules that are intended to
> > be linked into a run-time image (meaning a JRE, JDK or custom run-time)
> > - it isn't currently an execution format. I could imagine Maven plugins
> > supporting it as a new artifact type in the future.
>
> How would we read these files when running on earlier JDK versions?
>
> Thanks,
>
> Simon
>
>

From Alan.Bateman at oracle.com  Mon Nov 30 09:30:14 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Nov 2015 09:30:14 +0000
Subject: Creating modules with JDK8
In-Reply-To: <565B5F8D.1060606@ochsenreither.de>
References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com>
	<565B5F8D.1060606@ochsenreither.de>
Message-ID: <565C1726.40303@oracle.com>


On 29/11/2015 20:26, Simon Ochsenreither wrote:
> :
> How would we read these files when running on earlier JDK versions?
>
It depends on what the eventual format will be. In the current prototype 
then JMOD files are zip format so they can be easily opened with with 
the java.util.zip APIs and many tools.

In the case of module-info.class then ASM makes it easy. That is what 
the jar and jmod tools use to read and re-write it with additional 
attributes.

-Alan.

From Alan.Bateman at oracle.com  Mon Nov 30 09:43:19 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Nov 2015 09:43:19 +0000
Subject: Creating modules with JDK8
In-Reply-To: <CADQzvm=DQA1jsuPUV+OR1GuVGwEC1S2zV87CY7Q-QqEHd0RXWA@mail.gmail.com>
References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com>
	<565B5F8D.1060606@ochsenreither.de>
	<CADQzvm=DQA1jsuPUV+OR1GuVGwEC1S2zV87CY7Q-QqEHd0RXWA@mail.gmail.com>
Message-ID: <565C1A37.4060804@oracle.com>


On 30/11/2015 08:50, C?dric Champeau wrote:
> :
>
> Eventually, I would also not recommend to put a module-info class (jdk 9
> format) into a jar built for java 8. Just because there are tons of changes
> that it will blow up
> at runtime for legacy applications that use classpath scanning, and will
> fail when they see an unrecognized class format.
>
>
Out of curiosity,  you have examples of this? The hyphen makes it an 
invalid identifier so I would expect it should be ignored. At this time 
then the class file version is still 52.0 but maybe you've seen examples 
where something scanning the class path barfs on the new access_flags?

-Alan

From cedric.champeau at gmail.com  Mon Nov 30 10:34:10 2015
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Mon, 30 Nov 2015 11:34:10 +0100
Subject: Creating modules with JDK8
In-Reply-To: <565C1A37.4060804@oracle.com>
References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com>
	<565B5F8D.1060606@ochsenreither.de>
	<CADQzvm=DQA1jsuPUV+OR1GuVGwEC1S2zV87CY7Q-QqEHd0RXWA@mail.gmail.com>
	<565C1A37.4060804@oracle.com>
Message-ID: <CADQzvmkm+H5inU754cqTHZ+VBt539LGhXrfLcoiayKqvkN2r3w@mail.gmail.com>

Actually no, you made me realize that the module-info.class file uses the
same class format as in Java 8, so it should be ok with existing tools I
guess, as long as they don't rewrite classes. So it's unlikely to happen
for classpath scanning, but at compile time more likely (think of ProGuard).

2015-11-30 10:43 GMT+01:00 Alan Bateman <Alan.Bateman at oracle.com>:

>
> On 30/11/2015 08:50, C?dric Champeau wrote:
>
>> :
>>
>> Eventually, I would also not recommend to put a module-info class (jdk 9
>> format) into a jar built for java 8. Just because there are tons of
>> changes
>> that it will blow up
>> at runtime for legacy applications that use classpath scanning, and will
>> fail when they see an unrecognized class format.
>>
>>
>> Out of curiosity,  you have examples of this? The hyphen makes it an
> invalid identifier so I would expect it should be ignored. At this time
> then the class file version is still 52.0 but maybe you've seen examples
> where something scanning the class path barfs on the new access_flags?
>
> -Alan
>

From forax at univ-mlv.fr  Mon Nov 30 10:39:58 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 30 Nov 2015 11:39:58 +0100 (CET)
Subject: Creating modules with JDK8
In-Reply-To: <565C1A37.4060804@oracle.com>
References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com>
	<565B5F8D.1060606@ochsenreither.de>
	<CADQzvm=DQA1jsuPUV+OR1GuVGwEC1S2zV87CY7Q-QqEHd0RXWA@mail.gmail.com>
	<565C1A37.4060804@oracle.com>
Message-ID: <630584809.173373.1448879998683.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> ?: "C?dric Champeau" <cedric.champeau at gmail.com>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoy?: Lundi 30 Novembre 2015 10:43:19
> Objet: Re: Creating modules with JDK8
> 
> 
> On 30/11/2015 08:50, C?dric Champeau wrote:
> > :
> >
> > Eventually, I would also not recommend to put a module-info class (jdk 9
> > format) into a jar built for java 8. Just because there are tons of changes
> > that it will blow up
> > at runtime for legacy applications that use classpath scanning, and will
> > fail when they see an unrecognized class format.
> >
> >
> Out of curiosity,  you have examples of this? The hyphen makes it an
> invalid identifier so I would expect it should be ignored. At this time
> then the class file version is still 52.0 but maybe you've seen examples
> where something scanning the class path barfs on the new access_flags?

Cedric as a point here,
A hypen is valid in class name otherwise you will not decode package-info.class correctly.
If the application uses ASM to parse the bytecode, ASM will blow up on the unrecognized class file version.

> 
> -Alan
> 

R?mi

From sibabrata.sahoo at oracle.com  Mon Nov 30 11:13:11 2015
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Mon, 30 Nov 2015 03:13:11 -0800 (PST)
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
Message-ID: <bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>

Here is the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/

I have one question:
What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*" & working with <= JDK8) configured by "java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using Security.getProvider() to look for the provider?

Currently the scenario fails to find the JCE provider. Is this right behavior? If it is, then jdk9 is not backward compatible to find the security provider provided through older jar files from CLASS_PATH.

Thanks,
Siba

-----Original Message-----
From: Wang Weijun 
Sent: Sunday, November 29, 2015 2:54 PM
To: Siba Sahoo
Cc: security-dev at openjdk.java.net; jigsaw-dev at openjdk.java.net; Sean Mullan
Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Some comments:

1. Maybe use jdk/testlibrary/JDKToolLauncher.java to launch jarsigner?

2. You mentioned it's difficult to set a security provider in java.security file. Have you tried "-Djava.security.properties=="? It is described at the beginning of java.security.

Thanks
Max

> On Nov 23, 2015, at 9:14 PM, Siba Sahoo <sibabrata.sahoo at oracle.com> wrote:
> 
> +HYPERLINK "mailto:security-dev at openjdk.java.net"security-dev at openjdk.java.net
> 
> 
> 
> From: Siba Sahoo 
> Sent: Monday, November 23, 2015 4:56 PM
> To: jigsaw-dev at openjdk.java.net; Sean Mullan
> Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs
> 
> 
> 
> Hi,
> 
> 
> 
> Please help me with your review of this test for JBS: https://bugs.openjdk.java.net/browse/JDK-8130360, 
> 
> 
> 
> Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/
> 
> 
> 
> Description
> 
> Tests to verify 3rd party security providers if they are in signed/unsigned modular JARs. The test code checks the modular behavior with different combination of separate client & security provider, when available as modular(signed/unsigned) jar. It address total  of 72 test cases with the following criteria:
> 
> 
> 
> (Signed/Unsigned Jar) X (ClassLoader/ServiceLoader) X (combination of EXPLICIT/AUTO/UNAMED modules) X (With/Without Service descriptor) 
> 
> 
> 
> Thanks,
> 
> Siba
> 
> 


From simon at ochsenreither.de  Mon Nov 30 11:23:47 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Mon, 30 Nov 2015 12:23:47 +0100
Subject: Creating modules with JDK8
In-Reply-To: <CADQzvmkm+H5inU754cqTHZ+VBt539LGhXrfLcoiayKqvkN2r3w@mail.gmail.com>
References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com>
	<565B5F8D.1060606@ochsenreither.de>
	<CADQzvm=DQA1jsuPUV+OR1GuVGwEC1S2zV87CY7Q-QqEHd0RXWA@mail.gmail.com>
	<565C1A37.4060804@oracle.com>
	<CADQzvmkm+H5inU754cqTHZ+VBt539LGhXrfLcoiayKqvkN2r3w@mail.gmail.com>
Message-ID: <565C31C3.9050203@ochsenreither.de>

This sounds reasonable. Emitting Java 8 class files plus the Java 9
module class should be runnable on Java 8 as long as nothing references
the module class at runtime.

I think that's a good approach, given that adoption of Java >= 9 is
probably 4-6 years away from now.

From Alan.Bateman at oracle.com  Mon Nov 30 11:24:26 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Nov 2015 11:24:26 +0000
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
Message-ID: <565C31EA.4050709@oracle.com>

On 30/11/2015 11:13, Sibabrata Sahoo wrote:
> Here is the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>
> I have one question:
> What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*" & working with <= JDK8) configured by "java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using Security.getProvider() to look for the provider?
>
> Currently the scenario fails to find the JCE provider. Is this right behavior? If it is, then jdk9 is not backward compatible to find the security provider provided through older jar files from CLASS_PATH.
>
The JCE work in JDK 9 (via JDK-7191662) was meant to address this point 
by falling back and attempting to load the class name specified via the 
security.provider.<N> properties in the java.security file. I'm sure 
Valerie can say more about this.

-Alan

From sibabrata.sahoo at oracle.com  Mon Nov 30 14:47:53 2015
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Mon, 30 Nov 2015 06:47:53 -0800 (PST)
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <565C31EA.4050709@oracle.com>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
	<565C31EA.4050709@oracle.com>
Message-ID: <0bea66aa-c1ab-486c-88f1-1791719c2c54@default>

I would like to know more about this. As far, I can see the "java.security" provider configuration available with JDK9, it holds provider names instead of provider class names. In that case how it resolve the fall back?

Thanks,
Siba

-----Original Message-----
From: Alan Bateman 
Sent: Monday, November 30, 2015 4:54 PM
To: Sibabrata Sahoo; security-dev at openjdk.java.net; jigsaw-dev at openjdk.java.net
Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

On 30/11/2015 11:13, Sibabrata Sahoo wrote:
> Here is the updated webrev: 
> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>
> I have one question:
> What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*" & working with <= JDK8) configured by "java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using Security.getProvider() to look for the provider?
>
> Currently the scenario fails to find the JCE provider. Is this right behavior? If it is, then jdk9 is not backward compatible to find the security provider provided through older jar files from CLASS_PATH.
>
The JCE work in JDK 9 (via JDK-7191662) was meant to address this point by falling back and attempting to load the class name specified via the security.provider.<N> properties in the java.security file. I'm sure Valerie can say more about this.

-Alan

From stef at epardaud.fr  Mon Nov 30 15:35:31 2015
From: stef at epardaud.fr (Stephane Epardaud)
Date: Mon, 30 Nov 2015 16:35:31 +0100
Subject: So long bootclasspath!
Message-ID: <565C6CC3.4000004@epardaud.fr>

Well? turns out we were using it :(

We have a weird situation with Ceylon which is that we include a forked
javac (based on 1.7 with backports from 1.8), along with
javax.lang.model, which allow us to both compile and run in Java 7 and
Java 8. And we use the bootclasspath to tell the JVM to use ours when we
run the Ceylon compiler. Now, I understand that's bad form to fork and
keep the package name, and that it hides the real javac but in practice
that has never been a problem to us. And it allows us to rebase on new
JDKs much more easily than if we rename.

I tried to compile our code with Java 9 + Jigsaw and gave up after a
day, because the boot classpath is gone, so I figured well, let's bite
the bullet and rename our fork, but now our javac code is in
com.foo.javac and it can't see sun.reflect.annotation that javac uses. I
also had to remove the javax.lang.model classes we used to ship, but
that means we can't retrofit it so that our javac fork compiles in both
Java 7 and 8 (since it requires new APIs only available to Java 9 users).

I understand that's an uncommon situation (the fork), but that's what it
is, because we had to make tweaks here and there that would not make any
sense to push upstream.

Under Jigsaw, would it still be possible for us to ship javac and
javax.lang.model packages unrenamed? If yes, how? If no, do you have any
idea how else we could do? I suppose we could fork+rename both the
jdk.compiler and java.compiler modules (holds javax.lang.model), but
that won't let us access APIs such as sun.reflect.annotation which is
only granted to jdk.compiler?

On the brighter side, I've managed to make our javac fork work with
jimage pretty easily thanks to that "jrt:/" FS, that was a pretty good
idea guys (but then again, I've found most of the javac code to be quite
clever).

Cheers.

From harold.seigel at oracle.com  Mon Nov 30 16:02:58 2015
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Mon, 30 Nov 2015 16:02:58 +0000
Subject: hg: jigsaw/jake/hotspot: Fix issue with two modules having the same
	package by adding -Xmodule:<module-name> option for javac.
Message-ID: <201511301602.tAUG2w4F029522@aojmv0008.oracle.com>

Changeset: 465142d1190a
Author:    jlahoda
Date:      2015-11-30 10:41 -0500
URL:       http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/465142d1190a

Fix issue with two modules having the same package by adding -Xmodule:<module-name> option for javac.

! test/runtime/modules/Xpatch/Xpatch2Dirs.java
! test/runtime/modules/Xpatch/XpatchTest.java
! test/runtime/modules/Xpatch/XpatchTraceCL.java
! test/testlibrary/jdk/test/lib/InMemoryJavaCompiler.java


From Alan.Bateman at oracle.com  Mon Nov 30 16:14:01 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Nov 2015 16:14:01 +0000
Subject: So long bootclasspath!
In-Reply-To: <565C6CC3.4000004@epardaud.fr>
References: <565C6CC3.4000004@epardaud.fr>
Message-ID: <565C75C9.5010905@oracle.com>

On 30/11/2015 15:35, Stephane Epardaud wrote:
> :
>
> I tried to compile our code with Java 9 + Jigsaw and gave up after a
> day, because the boot classpath is gone, so I figured well, let's bite
> the bullet and rename our fork, but now our javac code is in
> com.foo.javac and it can't see sun.reflect.annotation that javac uses.
I assume you mean it can't access the types in sun.reflection.annotation 
rather than can't see them. In any case, it is a shame that there are 
types here that are used in annotation serialization. You can workaround 
it by using -XaddExports, documented in JEP 261.

JEP 261 also introduces the upgrade module path. There are still some 
TBD on which modules will be upgradeable, I don't know if modules 
java.compiler and jdk.compiler will be upgradeable.

-Alan

From joelbars at gmail.com  Mon Nov 30 16:19:41 2015
From: joelbars at gmail.com (joelbars at gmail.com)
Date: Mon, 30 Nov 2015 13:19:41 -0300
Subject: Help directions
Message-ID: <CAGwKg5On=ZOu0Xo2OrVytuUQseTQQ-GaBaLJ7Vx_dfEG1_pUuw@mail.gmail.com>

Hi everyone,

It's been sometime since I started to participate but in a passive way just
watching the list and trying to understand everything, now I wanted to be
more active. I already followed the quickstart guide and used some
tutorials do clone the source code and build it but in my forest I can't
see the jigsaw repository I just wanted some directions on how to build the
jigsaw project with jdk, I really appreciate if someone could help me. So
far I:

* Cloned http://hg.openjdk.java.net/jdk9/jdk9
* Followed the instructions to build the code
* Created a linux and mac build of the jdk9

But when I try the quickstart guide with this build I receive:

javac -d mods/com.greetings/ src/com.greetings/module-info.java
src/com.greetings/com/greetings/Main.java
src/com.greetings/module-info.java:1: error: class, interface, or enum
expected
module com.greetings { }
^
1 error

I'm presuming that's because I didn't compiled with jigsaw.

Thanks to everyone on this list and sorry if I bother someone, I'm just
someone trying to learn something new.

Best regards
Joel

From claes.redestad at oracle.com  Mon Nov 30 16:24:16 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 30 Nov 2015 17:24:16 +0100
Subject: Help directions
In-Reply-To: <CAGwKg5On=ZOu0Xo2OrVytuUQseTQQ-GaBaLJ7Vx_dfEG1_pUuw@mail.gmail.com>
References: <CAGwKg5On=ZOu0Xo2OrVytuUQseTQQ-GaBaLJ7Vx_dfEG1_pUuw@mail.gmail.com>
Message-ID: <565C7830.8080307@oracle.com>

Hi,

you might have more luck with http://hg.openjdk.java.net/jigsaw/jake

Building etc should be more or less the same as for jdk9/jdk9

Hope this helps!

/Claes

On 2015-11-30 17:19, joelbars at gmail.com wrote:
> Hi everyone,
>
> It's been sometime since I started to participate but in a passive way just
> watching the list and trying to understand everything, now I wanted to be
> more active. I already followed the quickstart guide and used some
> tutorials do clone the source code and build it but in my forest I can't
> see the jigsaw repository I just wanted some directions on how to build the
> jigsaw project with jdk, I really appreciate if someone could help me. So
> far I:
>
> * Cloned http://hg.openjdk.java.net/jdk9/jdk9
> * Followed the instructions to build the code
> * Created a linux and mac build of the jdk9
>
> But when I try the quickstart guide with this build I receive:
>
> javac -d mods/com.greetings/ src/com.greetings/module-info.java
> src/com.greetings/com/greetings/Main.java
> src/com.greetings/module-info.java:1: error: class, interface, or enum
> expected
> module com.greetings { }
> ^
> 1 error
>
> I'm presuming that's because I didn't compiled with jigsaw.
>
> Thanks to everyone on this list and sorry if I bother someone, I'm just
> someone trying to learn something new.
>
> Best regards
> Joel


From alan.bateman at oracle.com  Mon Nov 30 19:13:07 2015
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 30 Nov 2015 19:13:07 +0000
Subject: hg: jigsaw/jake/jdk: 3 new changesets
Message-ID: <201511301913.tAUJD847019023@aojmv0008.oracle.com>

Changeset: 8898f03465f2
Author:    alanb
Date:      2015-11-30 11:25 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8898f03465f2

Make java -listmods usage message a bit clearer

! src/java.base/share/classes/sun/launcher/resources/launcher.properties

Changeset: 02c750fa92d2
Author:    alanb
Date:      2015-11-30 11:38 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/02c750fa92d2

Don't set cached hash value when computed hash is 0

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

Changeset: e45ef8281247
Author:    alanb
Date:      2015-11-30 13:58 +0000
URL:       http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e45ef8281247

Make use of Class::getPackageName in access checks

! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java
! src/java.base/share/classes/sun/reflect/Reflection.java


From joelbars at gmail.com  Mon Nov 30 19:28:09 2015
From: joelbars at gmail.com (joelbars at gmail.com)
Date: Mon, 30 Nov 2015 16:28:09 -0300
Subject: Help directions
In-Reply-To: <565C7830.8080307@oracle.com>
References: <CAGwKg5On=ZOu0Xo2OrVytuUQseTQQ-GaBaLJ7Vx_dfEG1_pUuw@mail.gmail.com>
	<565C7830.8080307@oracle.com>
Message-ID: <CAGwKg5NRjMLtsq5xzCDF9+g9HXmwvogdNF5-SY9OgfSdKsfiqg@mail.gmail.com>

Hi Claes,

Thanks for your fast feedback, I made the new build like I did with jdk9
and it's working perfectly. I think I can see the code now and start to be
more active.

Thanks again.

Muito obrigado.
Joel

2015-11-30 13:24 GMT-03:00 Claes Redestad <claes.redestad at oracle.com>:

> Hi,
>
> you might have more luck with http://hg.openjdk.java.net/jigsaw/jake
>
> Building etc should be more or less the same as for jdk9/jdk9
>
> Hope this helps!
>
> /Claes
>
>
> On 2015-11-30 17:19, joelbars at gmail.com wrote:
>
>> Hi everyone,
>>
>> It's been sometime since I started to participate but in a passive way
>> just
>> watching the list and trying to understand everything, now I wanted to be
>> more active. I already followed the quickstart guide and used some
>> tutorials do clone the source code and build it but in my forest I can't
>> see the jigsaw repository I just wanted some directions on how to build
>> the
>> jigsaw project with jdk, I really appreciate if someone could help me. So
>> far I:
>>
>> * Cloned http://hg.openjdk.java.net/jdk9/jdk9
>> * Followed the instructions to build the code
>> * Created a linux and mac build of the jdk9
>>
>> But when I try the quickstart guide with this build I receive:
>>
>> javac -d mods/com.greetings/ src/com.greetings/module-info.java
>> src/com.greetings/com/greetings/Main.java
>> src/com.greetings/module-info.java:1: error: class, interface, or enum
>> expected
>> module com.greetings { }
>> ^
>> 1 error
>>
>> I'm presuming that's because I didn't compiled with jigsaw.
>>
>> Thanks to everyone on this list and sorry if I bother someone, I'm just
>> someone trying to learn something new.
>>
>> Best regards
>> Joel
>>
>
>