Hi,
Just minor stuff in the JDK area (i browsed quickly through the tests).
Paul.
java.lang.module.Configuration
—
321 * @implNote In the implementation then observability of modules may
depend
s/then/the
ModuleDescriptor
—
2662 private static >
2663 int compare(Set s1, Set
Hotspot changes look good to me.
Lois
On 2/7/2017 8:23 AM, Alan Bateman wrote:
We've been accumulating changes in the jake forest for the last few
weeks and it's time to bring the changes to jdk9/dev, to make
jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so
this update will n
Changeset: 5c4843cc0b4b
Author:mchung
Date: 2017-02-07 12:50 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c4843cc0b4b
Module created dynamically should have synthetic modifier
! src/java.base/share/classes/java/lang/reflect/Proxy.java
!
src/java.management/share/clas
Changeset: 22eecb4b45d7
Author:mchung
Date: 2017-02-07 12:51 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/22eecb4b45d7
Module created dynamically should have synthetic modifier
!
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.jav
Changeset: ecce006f9a20
Author:mchung
Date: 2017-02-07 12:50 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ecce006f9a20
Module created dynamically should have synthetic modifier
!
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.ja
If the test is in the FX repo then it wouldn't be able to check the
jmod, but would have to check some intermediate data that feeds into the
jmod. That might be OK, but is seems easy enough to check for the
existence of the jdk.packager module and skip the test if not present.
-- Kevin
Mandy
It can’t live in FX. FX can be built with an open, closed or custom JDK without
FX so this test needs to be in the JDK but it would be best if we can only
attempt to run it if FX is imported.
Chris
> On Feb 7, 2017, at 11:37 AM, Mandy Chung wrote:
>
> Should this test be in the FX repo where
Should this test be in the FX repo where jdk.packager resides? I would think
so. This test should only run with the build with FX modules.
Mandy
> On Feb 7, 2017, at 10:32 AM, Victor Drozdov wrote:
>
> Kevin, Mandy,
>
> Please review my new unit test for javapackager. It reads redistributabl
On 2/7/2017 1:11 AM, Gunnar Morling wrote:
---
package com.example;
public interface SomeService {
public void foo();
}
---
package com.example.internal;
class Outer {
public static class ServiceImpl implements com.example.SomeService {
This is included in the module system refresh discussion [1] to avoid the merge
conflict if it were separated from it. Your feedback is welcome and
appreciated.
Mandy
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-February/011231.html
> On Feb 7, 2017, at 6:05 AM, David M. Lloyd
It will fail to compile. Is there a way to test if jdk.packager is present
before compiling?
Chris
> On Feb 7, 2017, at 10:38 AM, David DeHaven wrote:
>
>
>> Kevin, Mandy,
>>
>> Please review my new unit test for javapackager. It reads redistributable
>> module list from jdk.packager, if a
> Kevin, Mandy,
>
> Please review my new unit test for javapackager. It reads redistributable
> module list from jdk.packager, if a module in the list doesn't exist, then
> the test fails.
>
> JIRA: https://bugs.openjdk.java.net/browse/JDK-8170200
> Webrev: http://cr.openjdk.java.net/~vdrozdov
I've coded such kind of tool [1] :)
It uses Maven (Aether) to download the dependencies then do a simple static
analysis on the downloaded jars to calculate the dependencies and inject the
module-info.class.
Because of the runtime dependencies, annotations, Class.forName etc, you also
have to p
Hi Alan,
jaxp and stack walking class (and test) changes look OK to me.
best regards,
-- daniel
On 07/02/17 13:23, Alan Bateman wrote:
We've been accumulating changes in the jake forest for the last few
weeks and it's time to bring the changes to jdk9/dev, to make jdk-9+157
if possible. JDK
Langtools changes look good to me.
Maurizio
On 07/02/17 13:23, Alan Bateman wrote:
We've been accumulating changes in the jake forest for the last few
weeks and it's time to bring the changes to jdk9/dev, to make
jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so
this update
I don't recall any corresponding discussion of this, but the change
looks like a good idea to me.
On 02/04/2017 05:41 PM, mandy.ch...@oracle.com wrote:
Changeset: 335657c73d0b
Author:mchung
Date: 2017-02-04 15:41 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/335657c73
On 02/06/2017 12:51 PM, Alan Bateman wrote:
On 06/02/2017 18:25, David M. Lloyd wrote:
I don't think there is really a substantial increase in risk between
manually modularizing a library and relying on automatic modules.
If several projects take on the responsibility to modularize a library
On Tue, 07 Feb 2017 14:20:07 +0100, Brian Fox wrote:
On Fri, Feb 3, 2017 at 10:40 AM, Alan Bateman
wrote:
As regards the example naming clash then these two projects might
already
get complaints over their poor choice of artifacts, esp. when artifacts
for
both projects are in same directo
On 07/02/2017 13:20, Brian Fox wrote:
:
This is an incorrect assumption.
At present these artifact names do not conflict, neither in the repository
coordinates, nor in the the class package. It's in fact the auto module
algorithm which ignores both the project's self chosen full coordinate, as
We've been accumulating changes in the jake forest for the last few
weeks and it's time to bring the changes to jdk9/dev, to make jdk-9+157
if possible. JDK 9 is the first phase of rampdown and so this update
will need to get approval via the FC-extension process.
The changes this time are sig
On Fri, Feb 3, 2017 at 10:40 AM, Alan Bateman
wrote:
> As regards the example naming clash then these two projects might already
> get complaints over their poor choice of artifacts, esp. when artifacts for
> both projects are in same directory (say where someone distributes with all
> JAR files
Changeset: c76282450dce
Author:alanb
Date: 2017-02-07 13:11 +
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c76282450dce
More javadoc cleanup
! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
! src/java.base/share/classes/java/lang/module/ModuleReader.j
Hi Alex,
Yes, I meant a nested class and default access, sorry for not being
precise with the terms. These are the concerned types:
---
package com.example;
public interface SomeService {
public void foo();
}
---
package com.example.internal;
class Outer {
23 matches
Mail list logo
