hg: jigsaw/jake/langtools: fix long broken test

[jonathan . gibbons]

Changeset: 2894246c04e2
Author:jjg
Date:  2016-04-08 16:54 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2894246c04e2

fix long broken test

! make/tools/crules/CodingRulesAnalyzerPlugin.java
! make/tools/crules/MutableFieldsAnalyzer.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/file/Locations.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleWrappers.java
! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java
! src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java
! test/tools/all/RunCodingRules.java

Re: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages

[Kevin Rushforth]

There are no public types exported by javafx.deploy so the change to use 
that module seems unneeded (I see that you used to include the SWT 
classes, which is likely what you want, but for which we don't yet have 
a solution in JDK 9).


Everything else looks good to me.

+1

-- Kevin


Jim Laskey (Oracle) wrote:

The code was reworked to use jrtfs: instead of reading from javafx.jar.

http://cr.openjdk.java.net/~jlaskey/8075550/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8075550



  

hg: jigsaw/jake/langtools: 3 new changesets

[jonathan . gibbons]

Changeset: f896cf730e26
Author:jjg
Date:  2016-04-08 13:56 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f896cf730e26

fix broken test (bad -addmods)

! test/tools/javac/processing/model/testgetallmembers/Main.java

Changeset: f32fdd9422b5
Author:jjg
Date:  2016-04-08 13:57 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f32fdd9422b5

update -XaddExports in tests

! test/tools/all/RunCodingRules.java
! test/tools/javac/T6358024.java
! test/tools/javac/T6358166.java
! test/tools/javac/T6406771.java
! test/tools/javac/T8010737/ParameterNamesAreNotCopiedToAnonymousInitTest.java
! test/tools/javac/api/TestJavacTaskScanner.java
! test/tools/javac/file/T7018098.java
! test/tools/javac/processing/loader/testClose/TestClose.java
! test/tools/javac/processing/loader/testClose/TestClose2.java
! test/tools/javac/util/T6597678.java
! test/tools/jdeps/APIDeps.java

Changeset: efafd3965869
Author:jjg
Date:  2016-04-08 13:57 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/efafd3965869

remove javac support for old-style -XaddExports -XaddReads

! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java

hg: jigsaw/jake/hotspot: Look for class jdk.nio.zipfs.ZipPath" because class "javax.activation.DataHandler" is no longer observable.

[harold . seigel]

Changeset: 46491264f585
Author:hseigel
Date:  2016-04-08 15:37 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/46491264f585

Look for class jdk.nio.zipfs.ZipPath" because class 
"javax.activation.DataHandler" is no longer observable.

! test/runtime/getSysPackage/GetSysPkgTest.java

RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages

[Jim Laskey (Oracle)]

The code was reworked to use jrtfs: instead of reading from javafx.jar.

http://cr.openjdk.java.net/~jlaskey/8075550/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8075550

Re: Proxy classes and reflection (IllegalAccessException)

[Mandy Chung]

> On Apr 8, 2016, at 4:58 AM, Dawid Weiss  wrote:
> 
> Thank you for the magic switch, Mandy! Here's the full output,
> including stack traces:
> 
> http://pastebin.com/uUb3aLwq
> 
> The one referencing the problematic class is:
> 
> PROXY: jdk.proxy2/com.sun.proxy.jdk.proxy2.$Proxy65 defined by
> jdk.internal.loader.ClassLoaders$PlatformClassLoader@523884b2
>   java.annotations.common/javax.ws.rs.ext.Providers module-private
> loader jdk.internal.loader.ClassLoaders$PlatformClassLoader@523884b2
> 

I see Alan has explained this and the issue is now understood.

One thing to add is that a proxy class is only generated in dynamic module if 
one of the proxy interface is in a named module and not exported.  If you see a 
proxy class generated in a dynamic module and you run your applications as it 
is today, it would likely invoke creating a proxy class with some interface in 
JDK modules, like java.annotations.common module in this case.

If all proxy interfaces are either in unnamed module, or exported from named 
modules, the proxy class will be generated in unnamed module and existing code 
should work as it is today.

> RestEasy creates this proxy class in
> InjectorFactoryImpl.createContextProxy, but its only reason to exist
> is (presumably) to keep a cache of proxy classes for the same set of
> interfaces (it later calls ContextParameterInjector with a cached
> proxy class). This doesn't look correct to me as newProxyInstance
> reuses proxy classes internally (although the javadoc here could be
> improved).
> 

A related note to caching of proxy classes:  The performance of 
Proxy::newProxyInstance has been improved in JDK 8 and Peter has a patch that 
brings jdk9 proxy performance even better than JDK 8 [1].

Mandy
[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040015.html

hg: jigsaw/jake: Fixed cross compile build

[erik . joelsson]

Changeset: cb835147c8af
Author:erikj
Date:  2016-04-08 18:00 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/cb835147c8af

Fixed cross compile build

! make/CreateBuildJdkCopy.gmk

Re: Proxy classes and reflection (IllegalAccessException)

[Alan Bateman]

On 08/04/2016 15:01, Dawid Weiss wrote:

:

This jar contains:
javax.annotation.Priority
javax.ws.rs.* (subpackages and classes)

So it's definitely not consistent. I added the following to command
line to make it all run:

-Xpatch:java.annotations.common=[...]/jaxrs-api-3.0.10.Final.jar
-XaddExports:java.annotations.common/javax.ws.rs=ALL-UNNAMED
-XaddExports:java.annotations.common/javax.ws.rs.client=ALL-UNNAMED
... (other subpackages from javax.ws.rs.*)

The javax.annotation package should be renamed to javax.anarchy :-)

Hopefully we will have builds soon that implement the new policy for the 
root modules when the initial class is on the class path. That will mean 
that java.annotations.common will not be resolved by default and should 
help here.




:
The interface is available outside of the module -- it is used (and is
visible) to all classes. The proxy class created for this interface
isn't (or rather: the reflective call to the proxy's constructor
fails, like explained in the javadoc you pointed to).
The interface is visible but its package isn't exported by the module to 
everyone that potentially reads the module. This is subtle but 
-XaddExports exports packages to specific targets. The "ALL-UNNAMED" 
token is all unnamed modules, it's not all modules.


-Alan.

Re: Proxy classes and reflection (IllegalAccessException)

[Jochen Theodorou]

On 08.04.2016 13:58, Dawid Weiss wrote:
[...]

I modified this locally and removed the proxy cache. On subsequent run
everything worked until I hit another problem, this time somewhere
inside Groovy (reflective scan of all fields, very likely).

java.lang.reflect.InaccessibleObjectException: Unable to make member
of class sun.net.spi.DefaultProxySelector accessible: module java.base
does not export sun.net.spi to unnamed module @124c278f
at 
sun.reflect.Reflection.throwInaccessibleObjectException(java.base@9-ea/Reflection.java:420)
at 
java.lang.reflect.AccessibleObject.checkCanSetAccessible(java.base@9-ea/AccessibleObject.java:174)
at 
java.lang.reflect.Constructor.checkCanSetAccessible(java.base@9-ea/Constructor.java:183)
at 
java.lang.reflect.Constructor.setAccessible(java.base@9-ea/Constructor.java:176)
at 
org.codehaus.groovy.reflection.CachedConstructor$1.run(CachedConstructor.java:41)
at java.security.AccessController.doPrivileged(java.base@9-ea/Native Method)
at 
org.codehaus.groovy.reflection.CachedConstructor.(CachedConstructor.java:39)
at org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:74)
at org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:64)
at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:33)
at 
org.codehaus.groovy.reflection.CachedClass.getConstructors(CachedClass.java:258)
at groovy.lang.MetaClassImpl.(MetaClassImpl.java:213)
at groovy.lang.MetaClassImpl.(MetaClassImpl.java:223)
at 
groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createNormalMetaClass(MetaClassRegistry.java:168)
at 
groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLookup(MetaClassRegistry.java:158)
at 
groovy.lang.MetaClassRegistry$MetaClassCreationHandle.create(MetaClassRegistry.java:141)
...

This is going to be an uphill battle with so many dependencies in the stack...


please see https://issues.apache.org/jira/browse/GROOVY-7587 and use 
Groovy 2.4.6


bye Jochen

Re: Proxy classes and reflection (IllegalAccessException)

[Dawid Weiss]

> Just so I have it clear. Someone has packaged the annotations with the
> JAX-RS classes and -Xpatch:java.annotations.common= is used to patch
> them into java.annotations.common module, is that right?

The jar with annotations is a maven dependency, here:
http://repo1.maven.org/maven2/org/jboss/resteasy/jaxrs-api/3.0.10.Final/

This jar contains:
javax.annotation.Priority
javax.ws.rs.* (subpackages and classes)

So it's definitely not consistent. I added the following to command
line to make it all run:

-Xpatch:java.annotations.common=[...]/jaxrs-api-3.0.10.Final.jar
-XaddExports:java.annotations.common/javax.ws.rs=ALL-UNNAMED
-XaddExports:java.annotations.common/javax.ws.rs.client=ALL-UNNAMED
... (other subpackages from javax.ws.rs.*)

> I think explains things as the interface will not be accessible outside of 
> that module and
> why the generated Proxy class is not accessible.

The interface is available outside of the module -- it is used (and is
visible) to all classes. The proxy class created for this interface
isn't (or rather: the reflective call to the proxy's constructor
fails, like explained in the javadoc you pointed to).

> URLClassLoader does parent delegation so I assume the types in package
> javax.annotation are being split between loaders. This is not going to work
> if there package private access is required.

These are annotations only, so no package private access is required.
It certainly works, unlike the tests (because I can run it and see
that it does).

Dawid

Re: trouble with java -Xpatch

[Michael Rasmussen]

On 8 April 2016 at 15:58, Alan Bateman  wrote:
> I think it would be better if we could post CFLH events in the primordial
> phase but this is only possible if agents opt-in via a new capability, maybe
> can_generate_early_class_hook_events that would have to be added along with
> can_generate_all_class_hook_events. This would nicely complement
> can_generate_early_vmstart so that suitably prepared agents would get CLFH,
> CompiledMethodLoad and other events during VM startup.

So this would mean the agent would be able to get CLFH for _all_ classes,
even Object, String, Class etc, that are the very first to be loaded, and
potentially instrument the bytes for those classes as well?
Of course still following the rules about not introducing any new packages
etc at the time, since it would cause the module system verification to
fail (yeah, been there, done that).

If that is the case, that also seems like a good solution for me, which
should still give me access to what I'm looking for. Also, it would
basically mean that can_generate_all_class_hook_events would make CLFH
work similar to how it does on previous versions.

/Michael

Re: Proxy classes and reflection (IllegalAccessException)

[Alan Bateman]

On 08/04/2016 14:02, Dawid Weiss wrote:

I don't have time to look it just now but
java.annotations.common/javax.ws.rs.ext.Providers is
/ and I wouldn't have expected to see this type
javax.ws.rs.ext.Providers in this module.

Yes, it's a mess, I agree. It comes from the patched module. Why is
this such a mess -- I've no idea, I'm just the user of the library. :)
Just so I have it clear. Someone has packaged the annotations with the 
JAX-RS classes and -Xpatch:java.annotations.common= is used to 
patch them into java.annotations.common module, is that right? I think 
explains things as the interface will not be accessible outside of that 
module and why the generated Proxy class is not accessible.



:
I remember this discussion. For now I disabled the tests that involve
RestEast on Java9 and everything else passes. What's interesting is
that our application (not the individual tests, the whole thing) works
out of the box even without all these module-related hacks -- we use a
tiny launcher that in turn collects dependencies into a single
URLClassLoader, then runs the application from there. I found this out
by accident, but I can already see how people may try to abuse this
instead of going through the struggle of finding correct JVM switches
for modules (until they become more widespread)...

URLClassLoader does parent delegation so I assume the types in package 
javax.annotation are being split between loaders. This is not going to 
work if there package private access is required.


-Alan

Re: Proxy classes and reflection (IllegalAccessException)

[Dawid Weiss]

> I don't have time to look it just now but
> java.annotations.common/javax.ws.rs.ext.Providers is
> / and I wouldn't have expected to see this type
> javax.ws.rs.ext.Providers in this module.

Yes, it's a mess, I agree. It comes from the patched module. Why is
this such a mess -- I've no idea, I'm just the user of the library. :)

> There was some discussion on Groovy here a few months ago and it will be
> challenge.

I remember this discussion. For now I disabled the tests that involve
RestEast on Java9 and everything else passes. What's interesting is
that our application (not the individual tests, the whole thing) works
out of the box even without all these module-related hacks -- we use a
tiny launcher that in turn collects dependencies into a single
URLClassLoader, then runs the application from there. I found this out
by accident, but I can already see how people may try to abuse this
instead of going through the struggle of finding correct JVM switches
for modules (until they become more widespread)...

Dawid

Re: trouble with java -Xpatch

[Alan Bateman]

On 04/04/2016 12:47, Michael Rasmussen wrote:


But retransform in this phase would still be subject to the same 
limitations about no structural changes I assume? Meaning no adding of 
members etc.


My preferred solution would still be if adding (and changing) Xpatch 
would be possible during OnLoad, as that should solve all my problems.


I think it would be better if we could post CFLH events in the 
primordial phase but this is only possible if agents opt-in via a new 
capability, maybe can_generate_early_class_hook_events that would have 
to be added along with can_generate_all_class_hook_events. This would 
nicely complement can_generate_early_vmstart so that suitably prepared 
agents would get CLFH, CompiledMethodLoad and other events during VM 
startup.


-Alan

Re: Proxy classes and reflection (IllegalAccessException)

[Alan Bateman]

On 08/04/2016 12:58, Dawid Weiss wrote:

:

The one referencing the problematic class is:

PROXY: jdk.proxy2/com.sun.proxy.jdk.proxy2.$Proxy65 defined by
jdk.internal.loader.ClassLoaders$PlatformClassLoader@523884b2
java.annotations.common/javax.ws.rs.ext.Providers module-private
loader jdk.internal.loader.ClassLoaders$PlatformClassLoader@523884b2
I don't have time to look it just now but 
java.annotations.common/javax.ws.rs.ext.Providers is 
/ and I wouldn't have expected to see this type 
javax.ws.rs.ext.Providers in this module. It makes me wonder if JAX-RS 
classes have been added or patched into this module. If added to the 
module then javax.ws.rs.ext won't be exported by default, hence 
interface javax.ws.rs.ext.Providers is not accessible to anything 
outside of this module, hence the dynamic module.



:

I modified this locally and removed the proxy cache. On subsequent run
everything worked until I hit another problem, this time somewhere
inside Groovy (reflective scan of all fields, very likely).
There was some discussion on Groovy here a few months ago and it will be 
challenge. There were originally a few challenges getting Nashorn 
(JavaScript) to run too but nothing like this.


-Alan

Re: Automatic modules and services

[Paul Bakker]

Excellent, thanks for the reply!

Paul


> On 08 Apr 2016, at 14:15, Alan Bateman  wrote:
> 
> On 08/04/2016 13:01, Paul Bakker wrote:
>> Hi,
>> 
>> I found an interesting issue with automatic modules that contain services. I 
>> have a small application that depends on jackson-core, jackson-databind and 
>> jackson-annotations.
>> As an experiment I started the app with only the jackson-databind jar file 
>> on the modulepath, which turns it into an automatic module. The application 
>> code, and the other two Jackson libs are still on the classpath.
>> 
>>  java -cp 
>> out:lib/jackson-annotations-2.7.3.jar:lib/jackson-core-2.7.3.jar -mp mods 
>> -addmods jackson.databind com.javamodularity.demonstrator.Demo
>>  This gives the following exception:
>>  java.lang.module.ResolutionException: Module jackson.databind does not 
>> read a module that exports com.fasterxml.jackson.core
>> 
>> This is surprising, because jackson-databind is an automatic module, which 
>> should read the unnamed module. The unnamed module should contain 
>> jackson-core because it's on the classpath.
>> The real surprise is that this seems to be caused by jackson-databind having 
>> a service declaration in it's META-INF of type 
>> "com.fasterxml.jackson.core.ObjectCodec". It looks like an automatic module 
>> can't declare a service of a type declared in the unnamed module.
>> When I remove the service declaration from the jackson-databind JAR, it runs 
>> without exceptions.
>> 
>> Is this a bug or desired behaviour? When placing jackson-core on the 
>> modulepath as well everything works as expected, but that's besides the 
>> point I think.
>> 
> Thanks for the mail. This is (or rather was) a bug. It's fixed in the jake 
> forest but hasn't been brought to JDK 9 yet. We hope to have the EA builds 
> [1] publishing again soon, in which case there will be daily builds for those 
> that don't build from sources.
> 
> -Alan
> 
> [1] https://jdk9.java.net/jigsaw/

Re: Automatic modules and services

[Alan Bateman]

On 08/04/2016 13:01, Paul Bakker wrote:

Hi,

I found an interesting issue with automatic modules that contain services. I 
have a small application that depends on jackson-core, jackson-databind and 
jackson-annotations.
As an experiment I started the app with only the jackson-databind jar file on 
the modulepath, which turns it into an automatic module. The application code, 
and the other two Jackson libs are still on the classpath.

java -cp 
out:lib/jackson-annotations-2.7.3.jar:lib/jackson-core-2.7.3.jar -mp mods 
-addmods jackson.databind com.javamodularity.demonstrator.Demo
  
This gives the following exception:

java.lang.module.ResolutionException: Module jackson.databind does not 
read a module that exports com.fasterxml.jackson.core

This is surprising, because jackson-databind is an automatic module, which 
should read the unnamed module. The unnamed module should contain jackson-core 
because it's on the classpath.
The real surprise is that this seems to be caused by jackson-databind having a service 
declaration in it's META-INF of type "com.fasterxml.jackson.core.ObjectCodec". 
It looks like an automatic module can't declare a service of a type declared in the 
unnamed module.
When I remove the service declaration from the jackson-databind JAR, it runs 
without exceptions.

Is this a bug or desired behaviour? When placing jackson-core on the modulepath 
as well everything works as expected, but that's besides the point I think.

Thanks for the mail. This is (or rather was) a bug. It's fixed in the 
jake forest but hasn't been brought to JDK 9 yet. We hope to have the EA 
builds [1] publishing again soon, in which case there will be daily 
builds for those that don't build from sources.


-Alan

[1] https://jdk9.java.net/jigsaw/

Automatic modules and services

[Paul Bakker]

Hi,

I found an interesting issue with automatic modules that contain services. I 
have a small application that depends on jackson-core, jackson-databind and 
jackson-annotations.
As an experiment I started the app with only the jackson-databind jar file on 
the modulepath, which turns it into an automatic module. The application code, 
and the other two Jackson libs are still on the classpath.

java -cp 
out:lib/jackson-annotations-2.7.3.jar:lib/jackson-core-2.7.3.jar -mp mods 
-addmods jackson.databind com.javamodularity.demonstrator.Demo
 
This gives the following exception:
java.lang.module.ResolutionException: Module jackson.databind does not 
read a module that exports com.fasterxml.jackson.core

This is surprising, because jackson-databind is an automatic module, which 
should read the unnamed module. The unnamed module should contain jackson-core 
because it's on the classpath.
The real surprise is that this seems to be caused by jackson-databind having a 
service declaration in it's META-INF of type 
"com.fasterxml.jackson.core.ObjectCodec". It looks like an automatic module 
can't declare a service of a type declared in the unnamed module.
When I remove the service declaration from the jackson-databind JAR, it runs 
without exceptions. 

Is this a bug or desired behaviour? When placing jackson-core on the modulepath 
as well everything works as expected, but that's besides the point I think.

Best regards,

Paul Bakker

 

Re: Proxy classes and reflection (IllegalAccessException)

[Dawid Weiss]

Thank you for the magic switch, Mandy! Here's the full output,
including stack traces:

http://pastebin.com/uUb3aLwq

The one referencing the problematic class is:

PROXY: jdk.proxy2/com.sun.proxy.jdk.proxy2.$Proxy65 defined by
jdk.internal.loader.ClassLoaders$PlatformClassLoader@523884b2
   java.annotations.common/javax.ws.rs.ext.Providers module-private
loader jdk.internal.loader.ClassLoaders$PlatformClassLoader@523884b2

RestEasy creates this proxy class in
InjectorFactoryImpl.createContextProxy, but its only reason to exist
is (presumably) to keep a cache of proxy classes for the same set of
interfaces (it later calls ContextParameterInjector with a cached
proxy class). This doesn't look correct to me as newProxyInstance
reuses proxy classes internally (although the javadoc here could be
improved).

I modified this locally and removed the proxy cache. On subsequent run
everything worked until I hit another problem, this time somewhere
inside Groovy (reflective scan of all fields, very likely).

java.lang.reflect.InaccessibleObjectException: Unable to make member
of class sun.net.spi.DefaultProxySelector accessible: module java.base
does not export sun.net.spi to unnamed module @124c278f
at 
sun.reflect.Reflection.throwInaccessibleObjectException(java.base@9-ea/Reflection.java:420)
at 
java.lang.reflect.AccessibleObject.checkCanSetAccessible(java.base@9-ea/AccessibleObject.java:174)
at 
java.lang.reflect.Constructor.checkCanSetAccessible(java.base@9-ea/Constructor.java:183)
at 
java.lang.reflect.Constructor.setAccessible(java.base@9-ea/Constructor.java:176)
at 
org.codehaus.groovy.reflection.CachedConstructor$1.run(CachedConstructor.java:41)
at java.security.AccessController.doPrivileged(java.base@9-ea/Native Method)
at 
org.codehaus.groovy.reflection.CachedConstructor.(CachedConstructor.java:39)
at org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:74)
at org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:64)
at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:33)
at 
org.codehaus.groovy.reflection.CachedClass.getConstructors(CachedClass.java:258)
at groovy.lang.MetaClassImpl.(MetaClassImpl.java:213)
at groovy.lang.MetaClassImpl.(MetaClassImpl.java:223)
at 
groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createNormalMetaClass(MetaClassRegistry.java:168)
at 
groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLookup(MetaClassRegistry.java:158)
at 
groovy.lang.MetaClassRegistry$MetaClassCreationHandle.create(MetaClassRegistry.java:141)
...

This is going to be an uphill battle with so many dependencies in the stack...

Dawid


On Thu, Apr 7, 2016 at 10:47 PM, Alan Bateman  wrote:
> On 07/04/2016 21:22, David M. Lloyd wrote:
>>
>> Having the proxy class be public in most circumstances is a
>> 15-plus-year-old contract.
>
> Proxy classes were specified to be public up to Java SE 7. There was a
> significant update in Java SE 8 to specify that the proxy classes be
> non-public when any of the interfaces is not public. The draft changes in
> JDK 9 is further evolution to specify the proxy class accessibility based on
> the least accessible interface.
>
>
>> :
>>
>> The first problem is that a magic dynamic module is created for proxy
>> classes.  This is a bit of a punt because of the natural dissonance/chaos
>> that arises from decoupling the module from the class loader; however
>> there's possibly a better way to mitigate this: let the layer decide how to
>> place the proxy class into a *real* module the same way that in the past,
>> the proxy class was placed into the real class loader as a normal (usually
>> public) class.
>
> There are cases where the proxy class will be generated in the same
> package/module as the proxy interface. Hopefully the "Package and Module
> Membership of Proxy Class" section in the javadoc is clear on all the cases.
>
>>
>>
>> The second problem is that the requirement for adding read edges all over
>> the place for reflection is unreasonable (and has already been recognized as
>> such by the EG).
>
> This is #ReflectionWithoutReadability on the issues list and has already
> been resolved [1].
>
> -Alan
>
> [1]
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-March/000248.html
>
>

hg: jigsaw/jake/hotspot: Drop -addmods ALL-SYSTEM from -javaagent usages

[alan . bateman]

Changeset: 99c248ee81f2
Author:alanb
Date:  2016-04-08 10:55 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/99c248ee81f2

Drop -addmods ALL-SYSTEM from -javaagent usages

! src/share/vm/runtime/arguments.cpp

hg: jigsaw/jake/jdk: Re-apply 8153261

[alan . bateman]

Changeset: 38e013bf9e9b
Author:alanb
Date:  2016-04-08 10:54 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/38e013bf9e9b

Re-apply 8153261

! make/gensrc/GensrcModuleLoaderMap.gmk

hg: jigsaw/jake: Re-apply 8153261

[alan . bateman]

Changeset: 108a18872c67
Author:alanb
Date:  2016-04-08 10:53 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/108a18872c67

Re-apply 8153261

! make/Images.gmk

hg: jigsaw/jake/jdk: Nimbus generator needs to run with -addmods java.xml.bind in boot cycle builds

[alan . bateman]

Changeset: d093dce37ffd
Author:alanb
Date:  2016-04-08 10:43 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d093dce37ffd

Nimbus generator needs to run with -addmods java.xml.bind in boot cycle builds

! make/Tools.gmk

hg: jigsaw/jake/langtools: Adjusting AddLimitMods to recent change in ToolBox.

[jan . lahoda]

Changeset: eb0210d6eefd
Author:jlahoda
Date:  2016-04-08 11:26 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/eb0210d6eefd

Adjusting AddLimitMods to recent change in ToolBox.

! test/tools/javac/modules/AddLimitMods.java

hg: jigsaw/jake/hotspot: 2 new changesets

[alan . bateman]

Changeset: 7d9d8ad32fe6
Author:lana
Date:  2016-04-07 10:06 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7d9d8ad32fe6

Added tag jdk-9+113 for changeset c569f8d89269

! .hgtags

Changeset: fd63df887f7e
Author:alanb
Date:  2016-04-08 07:33 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fd63df887f7e

Merge

! .hgtags

hg: jigsaw/jake/jdk: 31 new changesets

[alan . bateman]

Changeset: 9e73bdac39ec
Author:aefimov
Date:  2016-03-28 17:12 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9e73bdac39ec

8073872: Schemagen fails with StackOverflowError if element references 
containing class
Reviewed-by: lancea

+ test/javax/xml/bind/jxc/8073872/Foo.java
+ test/javax/xml/bind/jxc/8073872/SchemagenStackOverflow.java

Changeset: 93230508687d
Author:dl
Date:  2016-03-28 08:53 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/93230508687d

8152083: Optimize TimeUnit conversions
Reviewed-by: martin, shade, forax

! src/java.base/share/classes/java/util/concurrent/TimeUnit.java
+ test/java/util/concurrent/tck/TimeUnit8Test.java
! test/java/util/concurrent/tck/TimeUnitTest.java

Changeset: 91a26000bfb5
Author:rgoel
Date:  2016-03-28 12:36 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/91a26000bfb5

8150432: LocaleProviders.sh fails
Summary: Updated Windows 10 kernel name.
Reviewed-by: okutsu

! test/java/util/Locale/LocaleProviders.sh

Changeset: faf6d930aef4
Author:redestad
Date:  2016-03-28 22:25 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/faf6d930aef4

8152733: Avoid creating Manifest when checking for Multi-Release attribute
Reviewed-by: psandoz, alanb
Contributed-by: claes.redes...@oracle.com, steve.dr...@oracle.com

! src/java.base/share/classes/java/util/jar/JarFile.java
! test/java/util/jar/JarFile/MultiReleaseJarAPI.java

Changeset: ff721bdc4c68
Author:amlu
Date:  2016-03-29 10:47 +0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ff721bdc4c68

8152873: java/util/Locale/LocaleProviders.sh fails after JDK-8150432
Reviewed-by: darcy

! test/java/util/Locale/LocaleProviders.sh

Changeset: 271faffbe204
Author:okutsu
Date:  2016-03-29 18:04 +0900
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/271faffbe204

8152077: (cal) Calendar.roll does not always roll the hours during daylight 
savings
Reviewed-by: peytoia

! src/java.base/share/classes/java/util/GregorianCalendar.java
+ test/java/util/Calendar/Bug8152077.java

Changeset: 841f1fe6d486
Author:redestad
Date:  2016-03-29 18:27 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/841f1fe6d486

8152951: Avoid calculating the reverse of StringConcatFactory$Recipe elements
Reviewed-by: shade, vlivanov

! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java

Changeset: fa4686fe4fac
Author:mchung
Date:  2016-03-29 12:43 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fa4686fe4fac

8153027: Exclude tools/jimage/JImageTest.java
Reviewed-by: lancea

! test/ProblemList.txt

Changeset: 380afcaf1507
Author:naoto
Date:  2016-03-29 17:06 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/380afcaf1507

8152704: jlink command line output/help message improvement
Reviewed-by: mchung

! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java
! 
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties
! test/tools/jlink/JLink2Test.java
! test/tools/jlink/plugins/IncludeLocalesPluginTest.java

Changeset: 727255af5ed4
Author:rriggs
Date:  2016-03-30 12:47 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/727255af5ed4

8152005: sun/misc/SunMiscSignalTest.java failed intermittently
Summary: extend timeout and retry
Reviewed-by: darcy

! test/sun/misc/SunMiscSignalTest.java

Changeset: 81b03502e5e7
Author:alanb
Date:  2016-03-30 19:56 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/81b03502e5e7

8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image
Reviewed-by: alanb, sundar
Contributed-by: felix.y...@oracle.com

! test/Makefile
+ test/jdk/internal/jrtfs/remote/Main.java
+ test/jdk/internal/jrtfs/remote/RemoteRuntimeImageTest.java

Changeset: 850b61c46092
Author:mchung
Date:  2016-03-30 17:23 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/850b61c46092

8153035: GenModuleInfoSource strips away the API comments
Reviewed-by: chegar

! make/src/classes/build/tools/module/GenModuleInfoSource.java
- make/src/classes/build/tools/module/Module.java
- make/src/classes/build/tools/module/ModuleInfoReader.java
- make/src/classes/build/tools/module/ModulesXmlReader.java
- make/src/classes/build/tools/module/ModulesXmlWriter.java

Changeset: 679f9542362b
Author:darcy
Date:  2016-03-30 18:12 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/679f9542362b

8151763: Use more informative format for problem list
Reviewed-by: mchung, serb, chegar, alanb, mullan, jjg

! test/ProblemList.txt

Changeset: 1993af50385d
Author:mrkam
Date:  2016-03-30 19:05 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1993af50385d

8153141: Develop initial set of tests for SwingSet
Reviewed-by: prr

! .hgignore
+ 

hg: jigsaw/jake/nashorn: 5 new changesets

[alan . bateman]

Changeset: 4fbf7a66d49b
Author:sundar
Date:  2016-03-28 23:05 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/4fbf7a66d49b

8152533: ant octane target fails with "Unable to load a script engine manager 
(org.apache.bsf.BSFManager or javax.script.ScriptEngineManager)"
Reviewed-by: jlaskey

+ buildtools/nashorntask/README
+ buildtools/nashorntask/build.xml
+ buildtools/nashorntask/project.properties
+ buildtools/nashorntask/src/jdk/nashorn/ant/NashornTask.java
! make/build-benchmark.xml
! make/project.properties

Changeset: c0d57cb54210
Author:lana
Date:  2016-03-31 08:59 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c0d57cb54210

Merge


Changeset: a5d1990fd32d
Author:mchung
Date:  2016-03-31 11:50 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a5d1990fd32d

8153211: Convert build tool to use the new -XaddExports syntax in bootcycle 
build
Reviewed-by: alanb

! make/BuildNashorn.gmk

Changeset: e015a1c14289
Author:lana
Date:  2016-04-07 10:07 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e015a1c14289

Added tag jdk-9+113 for changeset a5d1990fd32d

! .hgtags

Changeset: 2cc1a597713a
Author:alanb
Date:  2016-04-08 07:32 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/2cc1a597713a

Merge

! .hgtags
! make/BuildNashorn.gmk
! make/project.properties

hg: jigsaw/jake/langtools: 8 new changesets

[alan . bateman]

Changeset: 305e9e96a7f6
Author:mchung
Date:  2016-03-31 11:50 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/305e9e96a7f6

8153211: Convert build tool to use the new -XaddExports syntax in bootcycle 
build
Reviewed-by: alanb

! make/gendata/Gendata-jdk.compiler.gmk

Changeset: f31075169c33
Author:vromero
Date:  2016-03-31 17:25 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f31075169c33

8150733: NPE when compiling module-info.java with a class declaration in a 
non-module mode
Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/modules/NPECompilingModuleInfoTest.java

Changeset: 0ef6f9a479f8
Author:darcy
Date:  2016-03-31 14:56 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0ef6f9a479f8

6818181: Update naming convention annotation processing samples for modules
Reviewed-by: jjg

! src/sample/share/javac/processing/src/CheckNamesProcessor.java

Changeset: 97ec97671022
Author:jjg
Date:  2016-03-31 15:20 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/97ec97671022

8152897: refactor ToolBox to allow reduced documented dependencies
Reviewed-by: vromero

! test/jdk/jshell/ClassPathTest.java
! test/jdk/jshell/CommandCompletionTest.java
! test/jdk/jshell/Compiler.java
! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/ComputeFQNsTest.java
! test/jdk/jshell/ErrorTranslationTest.java
! test/jdk/jshell/ImportTest.java
! test/jdk/jshell/InferTypeTest.java
! test/jdk/jshell/StartOptionTest.java
! test/jdk/jshell/ToolBasicTest.java
! test/jdk/jshell/ToolFormatTest.java
! test/jdk/jshell/ToolReloadTest.java
! test/tools/doclint/tool/PathsTest.java
! test/tools/javac/4846262/CheckEBCDICLocaleTest.java
! test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java
! test/tools/javac/6508981/TestInferBinaryName.java
! test/tools/javac/AnonymousSubclassTest.java
! test/tools/javac/ClassPathTest/ClassPathTest.java
! test/tools/javac/ConstFoldTest.java
! test/tools/javac/ExtDirs/ExtDirTest.java
! test/tools/javac/IncorrectInheritance/IncorrectInheritanceTest.java
! test/tools/javac/MissingInclude/MissingIncludeTest.java
! test/tools/javac/Paths/AbsolutePathTest.java
! test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java
! test/tools/javac/T5090006/AssertionFailureTest.java
! test/tools/javac/T6558476.java
! test/tools/javac/T6725036.java
! test/tools/javac/T6970173/DebugPointerAtBadPositionTest.java
! test/tools/javac/T7008643/InlinedFinallyConfuseDebuggersTest.java
! test/tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java
! test/tools/javac/T8010659/CompilerCrashWhenMixingBinariesAndSourcesTest.java
! test/tools/javac/T8013394/CompileErrorWithIteratorTest.java
! test/tools/javac/T8019486/WrongLNTForLambdaTest.java
! 
test/tools/javac/T8022162/IncorrectSignatureDeterminationForInnerClassesTest.java
! test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java
! test/tools/javac/T8024437/ExceptionInferenceFromClassFileTest.java
! 
test/tools/javac/annotations/typeAnnotations/classfile/NestedLambdasCastedTest.java
! test/tools/javac/api/ToolProvider/HelloWorldTest.java
! test/tools/javac/api/ToolProvider/ToolProviderTest1.java
! test/tools/javac/api/ToolProvider/ToolProviderTest2.java
! test/tools/javac/boxing/IncrementBoxedAndAccess.java
! test/tools/javac/classfiles/InnerClasses/T8068517.java
! 
test/tools/javac/classfiles/attributes/AnnotationDefault/AnnotationDefaultTest.java
! 
test/tools/javac/classfiles/attributes/EnclosingMethod/EnclosingMethodTest.java
! test/tools/javac/classfiles/attributes/LineNumberTable/LineNumberTest.java
! 
test/tools/javac/classfiles/attributes/LocalVariableTable/LocalVariableTableTest.java
! 
test/tools/javac/classfiles/attributes/LocalVariableTable/LocalVariableTypeTableTest.java
! test/tools/javac/classfiles/attributes/Module/ModuleFlagTest.java
! test/tools/javac/classfiles/attributes/Module/ModuleTest.java
! test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java
! test/tools/javac/classfiles/attributes/Signature/ConstructorTest.java
! test/tools/javac/classfiles/attributes/Signature/EnumTest.java
! test/tools/javac/classfiles/attributes/Signature/ExceptionTest.java
! test/tools/javac/classfiles/attributes/Signature/FieldTest.java
! test/tools/javac/classfiles/attributes/Signature/InnerClassTest.java
! test/tools/javac/classfiles/attributes/Signature/MethodParameterTest.java
! test/tools/javac/classfiles/attributes/Signature/MethodTypeBoundTest.java
! test/tools/javac/classfiles/attributes/Signature/ReturnTypeTest.java
! test/tools/javac/classfiles/attributes/SourceFile/AnonymousClassTest.java
! test/tools/javac/classfiles/attributes/SourceFile/InnerClassTest.java
! test/tools/javac/classfiles/attributes/SourceFile/LocalClassTest.java
! test/tools/javac/classfiles/attributes/SourceFile/MixTest.java
! 

hg: jigsaw/jake/jaxws: 2 new changesets

[alan . bateman]

Changeset: b314bb02182b
Author:lana
Date:  2016-04-07 10:07 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b314bb02182b

Added tag jdk-9+113 for changeset e980062475c1

! .hgtags

Changeset: a5a9add894df
Author:alanb
Date:  2016-04-08 07:33 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/a5a9add894df

Merge

hg: jigsaw/jake/jaxp: 4 new changesets

[alan . bateman]

Changeset: ccd848271666
Author:joehw
Date:  2016-03-30 11:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ccd848271666

8147431: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
Reviewed-by: rriggs

! test/ProblemList.txt
! test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh

Changeset: 28626780e245
Author:lana
Date:  2016-03-31 08:59 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/28626780e245

Merge


Changeset: bf08e8fdd47a
Author:lana
Date:  2016-04-07 10:07 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/bf08e8fdd47a

Added tag jdk-9+113 for changeset 28626780e245

! .hgtags

Changeset: 2ad648dfb667
Author:alanb
Date:  2016-04-08 07:33 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/2ad648dfb667

Merge

hg: jigsaw/jake/corba: 2 new changesets

[alan . bateman]

Changeset: 5df43ffe48c4
Author:lana
Date:  2016-04-07 10:06 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/5df43ffe48c4

Added tag jdk-9+113 for changeset cc30faa2da49

! .hgtags

Changeset: 14e394516f38
Author:alanb
Date:  2016-04-08 07:34 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/14e394516f38

Merge

hg: jigsaw/jake: 7 new changesets

[alan . bateman]

Changeset: d360f7499380
Author:mchung
Date:  2016-03-31 14:11 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/d360f7499380

8153217: javafx modules are not included in the jre
Reviewed-by: alanb

! make/Images.gmk
! make/common/Modules.gmk

Changeset: 1e97e2ae06f9
Author:erikj
Date:  2016-04-01 17:06 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/1e97e2ae06f9

8153257: Jib profiles config broken after JDK-8031767
Reviewed-by: tbell

! common/conf/jib-profiles.js

Changeset: 7cd13f24127f
Author:erikj
Date:  2016-04-01 17:08 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/7cd13f24127f

8153261: Clean up fix for JDK-8153217
Reviewed-by: tbell

! make/Images.gmk
! make/common/Modules.gmk

Changeset: 6cf3e6866c37
Author:erikj
Date:  2016-04-01 17:10 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/6cf3e6866c37

8153273: Test lib compilations trigger find crash on Solaris
Reviewed-by: tbell

! make/test/BuildTestLib.gmk

Changeset: 55b6d550828d
Author:tbell
Date:  2016-04-01 12:25 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/55b6d550828d

8153303: Jib profiles config broken after JDK-8153257 after JDK-8031767
Reviewed-by: mchung

! common/conf/jib-profiles.js

Changeset: 51fb48619b0e
Author:lana
Date:  2016-04-07 10:06 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/51fb48619b0e

Added tag jdk-9+113 for changeset 55b6d550828d

! .hgtags

Changeset: 76006a6ddec1
Author:alanb
Date:  2016-04-08 08:26 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/76006a6ddec1

Merge

! common/conf/jib-profiles.js
! make/Images.gmk
! make/common/Modules.gmk

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

[Felix Yang]

Hi Stuart,
 thanks for the comments. I adjusted the test.  The test failed 
with NoClassDefFoundErr if client/server are in named module but dummy 
app in unnamed module. See https://bugs.openjdk.java.net/browse/JDK-8153833


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



About simplifying the scenario, I replaced inheritance by moving classes 
in runtime.


Thanks,
Felix

On 2016/3/2 10:28, Stuart Marks wrote:

Hi Felix, sorry for the delay.

Several comments below.

--

 119 // wait for rmiregistry to be fully ready
 120 Thread.sleep(3000);

There are some RMI test utilities that will handle starting up and 
waiting for the registry to be ready. Unfortunately they're in the 
unnamed package (still haven't cleaned that up) so you can't use them 
from this test.


For now I'd recommend scaling the timeout by the test.timeout.factor, 
so that this won't fail on slow systems. There's a test utility for 
that; see Utils.adjustTimeout().


--

The directory "unamed" is misspelled; it has classes in the unnamed 
module. This misspelling is reflected in variable names and values, e.g.,


  59 private static final Path UNAMED_SRC_DIR = 
Paths.get(TEST_SRC, "unamed");

  60 private static final Path MODS_OUTPUT_DIR = Paths.get("mods");
  61 private static final Path UNAMED_OUTPUT_DIR = 
Paths.get("unamed");


While spelling errors aren't that big a deal, since this involves file 
and directory names, I'd recommend fixing this now. It'll just be 
harder to fix it later.


Also, "SeperateModuleClient" => "SeparateModuleClient"

--

Overall the structure of the test seems reasonable to test various 
clients and servers in combinations of the same, different, and 
unnamed modules.


I'm not entirely sure what p2.SeperateModuleClient is testing. It 
extends p1.Client and its constructor and testStub() method simply 
call the corresponding methods on super, so it doesn't seem to be 
testing anything different from p1.Client running against p3.Server.


Also, p4.UnamedModuleClient seems to want to run the client from the 
unnamed module, but it too extends p1.Client and simply defers all of 
its execution to its superclass. So I don't think this actually 
testing an RMI client call originating from an unnamed module.


There is an uncomfortable amount of duplication between 
mtest/test/DummyApp.java and p4/UnamedModuleDummyApp. I see what this 
is trying to do, which is to test a RMI server from an unnamed module. 
It instantiates p3.Server, which resides in a named module, but 
exports it from an unnamed module.


So I think there's some tension here. There's subclassing among the 
clients that attempts to avoid duplication, which is good, but it 
doesn't truly seem to be testing clients in different modules and in 
an unnamed module. The server, on the other hand, does seem to be 
testing things properly in different modules, at the cost of 
duplicating all the code into another class that resides in a 
different (unnamed) module.


I'm not entirely sure what the best approach is here. Ideally you'd 
want to have a single implementation of client, server + remote 
interface, and application, and compile each of them once. Then since 
you're invoking a new JVM for each test, invoke it with different 
options to put the client, or the server, or the app, into modules, or 
onto the classpath (to get into an unnamed module). You might have to 
copy compiled class files to different locations so that different 
classes can be either on the classpath or in a named module without 
causing any conflicts.


I'm willing to entertain some simplifications here as well. It might 
be sufficient to deal with just clients and servers in 
different/unnamed modules, and not worry about putting the application 
into different modules. That should reduce the number of cases to cover.


s'marks

On 2/29/16 10:05 PM, Felix Yang wrote:

Ping...

-Felix
On 2016/2/24 14:06, Felix Yang wrote:

Hi all,
  please review the new tests to use RMI in module world.

Webrev:
http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8078812

Thanks,
Felix