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

[Stuart Marks]

Hi Felix,

This is looking quite nice.

One small cleanup. Client.java has a constructor Client(int port), and an int 
port field. Both are unused and can be removed.



I accept your changes. 'pathJoin' looks cool. Though, I personally prefer to
work with Path rather than strings (fileJoin). Any way, both ways are OK for me.


If you'd like to switch to using Path, that's fine with me. Jon G has also 
expressed such a preference. It should be a fairly straightforward change. The 
fileJoin() utility can be removed, and pathJoin() can be replaced with the 
alternative version from my previous mail. Otherwise it's mostly a matter of 
removing calls to Paths.get() and adding calls to toString() in the right places.



OK, I updated the test to a pure automatic modules version. Following subset is
selected. Please suggest:
1. all in automatic modules
2. only dummy app as automatic module, and others are in classpath
3. client/server as automatic module, and dummy app is in classpath
4. server/app as automatic module, and client is in classpath

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


I think this is a fine subset. The different test cases are all quite simple and 
they're all straightforward variations of each other, and they all use the same 
test fixture!



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

How about try this in later expansion?
All declared as named modules
Compile to exploded dir as usual
Enhance the JarUtil to accept a filter to exclude any file during creating jars
(in this case, module-info.class)
Then expand the test by specifying mp/cp with automatic modules, explored named
modules


Yes, this would be fine for future work. The exclusion of module-info.class from 
jar file creation seems like a reasonable approach.


If you eventually end up adding more test cases, it will probably result in a 
lot of redundancy in the way the sub-JVM is invoked. Also, the way to specify 
whether a particular component is in an unnamed module, an automatic module, or 
a named module will be somewhat cumbersome, so you'll probably want helper 
methods for that. And maybe you'd end up with a data provider to drive the test 
cases, instead of writing out individual test methods.


But all of this can be future work.

* * *

In summary, I think there is only the Client.java cleanup, and (optionally) the 
String=>Path conversion.


Did you need me to push this for you? This will go into jdk9/dev, right? I don't 
think it needs to go into jake.


s'marks

hg: jigsaw/jake/nashorn: 14 new changesets

[alan . bateman]

Changeset: c24beef07d1b
Author:sundar
Date:  2016-05-18 14:08 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c24beef07d1b

8157160: JSON.stringify does not work on ScriptObjectMirror objects
Reviewed-by: hannesw, mhaupt

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSON.java
+ test/script/basic/JDK-8157160.js
+ test/script/basic/JDK-8157160.js.EXPECTED

Changeset: c187d75b77aa
Author:mhaupt
Date:  2016-05-18 12:07 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c187d75b77aa

8157225: adopt method handle for array length getter in BeanLinker
Reviewed-by: hannesw, sundar

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

Changeset: bb6cf30cf892
Author:sundar
Date:  2016-05-18 20:17 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/bb6cf30cf892

8157241: Remove javac warnings of Nashorn "ant clean test"
Reviewed-by: mhaupt, hannesw

! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java
! 
buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java
! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArrayBuffer.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeFloat32Array.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeFloat64Array.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeInt16Array.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeInt32Array.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeInt8Array.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint16Array.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint32Array.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint8Array.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! test/src/jdk/nashorn/api/scripting/test/ScriptEngineSecurityTest.java

Changeset: 7099f590cdec
Author:mhaupt
Date:  2016-05-18 17:37 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7099f590cdec

8157250: BeanLinker assumes fixed array type linkage
Reviewed-by: attila, sundar

! src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java
+ test/script/basic/JDK-8157250.js
+ test/script/basic/JDK-8157250.js.EXPECTED

Changeset: 9a6da438e0f6
Author:hannesw
Date:  2016-05-18 18:44 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/9a6da438e0f6

8066229: Fuzzing bug: Can't find scope depth
Reviewed-by: sundar

+ test/script/basic/JDK-8066229.js
- test/script/basic/JDK-8157250.js.EXPECTED

Changeset: be28ce2f1054
Author:jlahoda
Date:  2016-05-18 21:00 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/be28ce2f1054

8133549: Generalize jshell's EditingHistory
Summary: Using a generic EditingHistory in jjs
Reviewed-by: sundar

! 
src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/Console.java
! 
src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/HistoryObject.java
! 
src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/NashornCompleter.java

Changeset: b13b36ca5821
Author:hannesw
Date:  2016-05-18 22:30 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b13b36ca5821

8157263: Octane svn repository no longer exists
Reviewed-by: sundar

! make/build.xml

Changeset: 8ad91dc85bfa
Author:lana
Date:  2016-05-19 19:46 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/8ad91dc85bfa

Merge


Changeset: 2d3d3a04ce6c
Author:sundar
Date:  2016-05-20 13:20 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/2d3d3a04ce6c

8157310: jdk.dynalink.linker.support.Lookup should have more checks before 
adding module read link
Reviewed-by: hannesw, attila

! 
src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java
! src/jdk.dynalink/share/classes/jdk/dynalink/linker/support/Lookup.java

Changeset: 141d0cf2c12e
Author:mhaupt
Date:  2016-05-20 16:02 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/141d0cf2c12e

8157444: exclude jjs shebang handling test from runs
Reviewed-by: sundar, hannesw, jlaskey

+ test/script/currently-failing/JDK-8144221.js
+ 

hg: jigsaw/jake/jaxws: 2 new changesets

[alan . bateman]

Changeset: fb771fa3a986
Author:lana
Date:  2016-05-26 16:02 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/fb771fa3a986

Added tag jdk-9+120 for changeset ecd0d6a71c7c

! .hgtags

Changeset: cb4cd9596539
Author:alanb
Date:  2016-05-26 18:55 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/cb4cd9596539

Merge

hg: jigsaw/jake/corba: 2 new changesets

[alan . bateman]

Changeset: 9a5fc5a27560
Author:lana
Date:  2016-05-26 16:02 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/9a5fc5a27560

Added tag jdk-9+120 for changeset 5943b791e131

! .hgtags

Changeset: 79e446fcbde1
Author:alanb
Date:  2016-05-26 18:56 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/79e446fcbde1

Merge

Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9

[Mandy Chung]

> On May 26, 2016, at 8:38 AM, Kevin Rushforth  
> wrote:
> 
> Yes, I've tested it in both modes (with a simple HelloFXCanvas program) -- as 
> an automatic jar file and as just an ordinary jar on the classpath.

an automatic module needs to be on modulepath.

For container-like environment, it can create a Layer to load javafx.swt with a 
parent class loader that loads SWT classes - would that be feasible?

Mandy

> 
> -- Kevin
> 
> 
> Tom Schindl wrote:
>> Rereading the jira it take that back if javafx.swt can still be loaded as a 
>> simple jar things will work
>> 
>> Tom
>> 
>> Von meinem iPhone gesendet
>> 
>>   
>> 
>>> Am 26.05.2016 um 16:51 schrieb Tom Schindl 
>>> :
>>> 
>>> Hi,
>>> 
>>> I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) 
>>> use case for SWT useage.
>>> 
>>> The SWT jar is not on the application classpath so how should a module 
>>> (named or unnamed) find the SWT classes?
>>> 
>>> Tom
>>> 
>>> Von meinem iPhone gesendet
>>> 
>>> 
>>> 
 Am 26.05.2016 um 02:43 schrieb Mandy Chung 
 :
 
 
 
   
 
> On May 25, 2016, at 3:38 PM, Kevin Rushforth 
>  wrote:
> 
> Please review the following:
> 
> 
> https://bugs.openjdk.java.net/browse/JDK-8131888
> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/
> 
> 
> This adds support for the javafx.embed.swt package back into the JDK, 
> which will be delivered as an automatic module in 
> $JAVA_HOME/lib/javafx-swt.jar (final location is TBD).
> 
> 
 The approach to have javafx.swt be an automatic module that can access 
 org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable.  
 I wonder what the JAR file should be named -  javafx.swt.jar or 
 javafx-swt.jar?  They both have the same module name “javafx.swt”.
 
 I skimmed through the change.  There are several System.err.println calls 
 that I assume are debugging code to be removed. e.g.
 
 FXCanvas.java
 247 System.err.println("FXCanvas class successfully initialized”);
 294 System.err.println("FXCanvas: FX platform is 
 initlialized”);
 
 PlatformImpl.java
 308 System.err.println("FXCanvas: no permission to access 
 JavaFX internals");
 309 ex.printStackTrace();
 
 I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods.  
 Happy to see StackWalker be useful in this case.  The check to compare the 
 class name with “javafx.embed.swt.FXCanvas” to derermine whether qualified 
 exports should be added.  You can consider checking the caller's module 
 name as a starter.  I know you are planning to look into the integrity 
 check as a follows up.
 
 ModuleHelper.java
 57 // ignore
 
 This deserves to be an InternalError.  This is temporary until FX is 
 transitioned to be built with JDK 9.
 
 Otherwise, look fine to me.
 Mandy
   
 
>> 
>>   
>> 

Re: RFR 8157931, jdk/internal/jrtfs/Basic.java fails with exploded builds

[Alan Bateman]

On 26/05/2016 15:50, Felix Yang wrote:

Hi all,

thanks for review. A clean-up version:

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


This looks okay to me.

-Alan

Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9

[Kevin Rushforth]

Yes, I've tested it in both modes (with a simple HelloFXCanvas program) 
-- as an automatic jar file and as just an ordinary jar on the classpath.


-- Kevin


Tom Schindl wrote:

Rereading the jira it take that back if javafx.swt can still be loaded as a 
simple jar things will work

Tom

Von meinem iPhone gesendet

  

Am 26.05.2016 um 16:51 schrieb Tom Schindl :

Hi,

I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use 
case for SWT useage.

The SWT jar is not on the application classpath so how should a module (named 
or unnamed) find the SWT classes?

Tom

Von meinem iPhone gesendet



Am 26.05.2016 um 02:43 schrieb Mandy Chung :



  

On May 25, 2016, at 3:38 PM, Kevin Rushforth  wrote:

Please review the following:

https://bugs.openjdk.java.net/browse/JDK-8131888
http://cr.openjdk.java.net/~kcr/8131888/webrev.00/

This adds support for the javafx.embed.swt package back into the JDK, which 
will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar 
(final location is TBD).


The approach to have javafx.swt be an automatic module that can access 
org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable.  I 
wonder what the JAR file should be named -  javafx.swt.jar or javafx-swt.jar?  
They both have the same module name “javafx.swt”.

I skimmed through the change.  There are several System.err.println calls that 
I assume are debugging code to be removed. e.g.

FXCanvas.java
247 System.err.println("FXCanvas class successfully initialized”);
294 System.err.println("FXCanvas: FX platform is initlialized”);

PlatformImpl.java
308 System.err.println("FXCanvas: no permission to access JavaFX 
internals");
309 ex.printStackTrace();

I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods.  Happy 
to see StackWalker be useful in this case.  The check to compare the class name 
with “javafx.embed.swt.FXCanvas” to derermine whether qualified exports should 
be added.  You can consider checking the caller's module name as a starter.  I 
know you are planning to look into the integrity check as a follows up.

ModuleHelper.java
57 // ignore

This deserves to be an InternalError.  This is temporary until FX is 
transitioned to be built with JDK 9.

Otherwise, look fine to me.
Mandy
  


  

Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9

[Kevin Rushforth]

If you add javafx-swt.jar to the custom classpath created by the OSGI 
container it should work in the same way it does today when you add 
jfxswt.jar.


Can you suggest an easy way that I can test this?

-- Kevin


Tom Schindl wrote:

Hi,

I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use 
case for SWT useage.

The SWT jar is not on the application classpath so how should a module (named 
or unnamed) find the SWT classes?

Tom

Von meinem iPhone gesendet

  

Am 26.05.2016 um 02:43 schrieb Mandy Chung :





On May 25, 2016, at 3:38 PM, Kevin Rushforth  wrote:

Please review the following:

https://bugs.openjdk.java.net/browse/JDK-8131888
http://cr.openjdk.java.net/~kcr/8131888/webrev.00/

This adds support for the javafx.embed.swt package back into the JDK, which 
will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar 
(final location is TBD).
  

The approach to have javafx.swt be an automatic module that can access 
org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable.  I 
wonder what the JAR file should be named -  javafx.swt.jar or javafx-swt.jar?  
They both have the same module name “javafx.swt”.

I skimmed through the change.  There are several System.err.println calls that 
I assume are debugging code to be removed. e.g.

FXCanvas.java
247 System.err.println("FXCanvas class successfully initialized”);
294 System.err.println("FXCanvas: FX platform is initlialized”);

PlatformImpl.java
308 System.err.println("FXCanvas: no permission to access JavaFX 
internals");
309 ex.printStackTrace();

I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods.  Happy 
to see StackWalker be useful in this case.  The check to compare the class name 
with “javafx.embed.swt.FXCanvas” to derermine whether qualified exports should 
be added.  You can consider checking the caller's module name as a starter.  I 
know you are planning to look into the integrity check as a follows up.

ModuleHelper.java
 57 // ignore

This deserves to be an InternalError.  This is temporary until FX is 
transitioned to be built with JDK 9.

Otherwise, look fine to me.
Mandy



  

Re: RFR 8157931, jdk/internal/jrtfs/Basic.java fails with exploded builds

[Felix Yang]

Hi all,

thanks for review. A clean-up version:

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

- Felix
On 2016/5/26 19:22, Alan Bateman wrote:



On 26/05/2016 11:58, Felix Yang wrote:

Hi there,

please review the following change.

Webrev: http://cr.openjdk.java.net/~xiaofeya/8157931/webrev.00/

The approach looks okay but would be good to do a few clean ups before 
pushing this.


One thing is the indentation in setup() is messed up by the removal of 
try/catch.


I also think it should use notExists rather than !exists (remember 
!exists will return true if the existence cannot be determined so the 
test should fail for this case).


testKnownClassFiles now prints the file size, I assume that is for 
another issue.


-Alan

Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9

[Kevin Rushforth]

Mandy,

Thanks for your feedback. Comments inline.

Mandy Chung wrote:
  

On May 25, 2016, at 3:38 PM, Kevin Rushforth  wrote:

Please review the following:

https://bugs.openjdk.java.net/browse/JDK-8131888
http://cr.openjdk.java.net/~kcr/8131888/webrev.00/

This adds support for the javafx.embed.swt package back into the JDK, which 
will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar 
(final location is TBD).



The approach to have javafx.swt be an automatic module that can access 
org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable.  I 
wonder what the JAR file should be named -  javafx.swt.jar or javafx-swt.jar?  
They both have the same module name “javafx.swt”.
  


Filenames with two dots are a little odd, so I went with the dash. It 
doesn't much matter, though.



I skimmed through the change.  There are several System.err.println calls that 
I assume are debugging code to be removed. e.g.

FXCanvas.java
 247 System.err.println("FXCanvas class successfully initialized”);
 294 System.err.println("FXCanvas: FX platform is 
initlialized”);

PlatformImpl.java
 308 System.err.println("FXCanvas: no permission to access JavaFX 
internals");
 309 ex.printStackTrace();
  


Right. I noted this in the JBS evaluation and will remove all when I 
post the final webrev.



I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods.  Happy 
to see StackWalker be useful in this case.  The check to compare the class name 
with “javafx.embed.swt.FXCanvas” to derermine whether qualified exports should 
be added.  You can consider checking the caller's module name as a starter.  I 
know you are planning to look into the integrity check as a follows up.
  


I had considered adding the check for the module name, but was concerned 
about the OSGi case, as mentioned by Tom Schindl in the bug report, in 
which they add the jar file via a custom classloader; the concern is 
that there is no support in the JDK to make it an automatic module in 
this case. I will file a follow-up issue to improve the integrity checking.




ModuleHelper.java
  57 // ignore

This deserves to be an InternalError.  This is temporary until FX is 
transitioned to be built with JDK 9.
  


Actually, we can't do this yet, because we still build and test with JDK 
9 build 109 which doesn't have support for the module system. Until we 
upgrade to a JDK with the module system enabled we need this to be a 
silent no-op or all of our tests will fail.


-- Kevin



Otherwise, look fine to me.
Mandy

Re: creating proxies for interfaces with default methods

[Remi Forax]

Not if you use Lookup.findSpecial() [1]
Anyway, you can not use it because you can not get the Lookup object associated 
with the proxy class.

That's why i've written the Proxy2 library [2].

so the solutions are either you use the Proxy2 library (which doesn't work with 
jdk9 yet) or we retrofit the interface InvocationHandler to take a 
supplementary Lookup object.

regards,
Rémi

[1] 
http://docs.oracle.com/javase/7/docs/api/java/lang/invoke/MethodHandles.Lookup.html#findSpecial%28java.lang.Class,%20java.lang.String,%20java.lang.invoke.MethodType,%20java.lang.Class%29
[2] https://github.com/forax/proxy2

- Mail original -
> De: "Jochen Theodorou" 
> À: "Alan Bateman" 
> Cc: "jigsaw-dev" 
> Envoyé: Jeudi 26 Mai 2016 09:21:15
> Objet: Re: creating proxies for interfaces with default methods
> 
> On 26.05.2016 09:03, Alan Bateman wrote:
> > On 26/05/2016 07:04, Jochen Theodorou wrote:
> >>
> >> you cannot invoke the default method with reflection without
> >> implementation of the interface
> > It sounds like you want to invoke the default method without a receiver.
> > This does seem like sorcery for mlvm-dev.
> 
> the problem is, that if I use a dynamic proxy as receiver and reflection
> as invocation method, I will end up in the invocation hadler again.
> 
> bye Jochen
> 
> 

Re: RFR 8157931, jdk/internal/jrtfs/Basic.java fails with exploded builds

[Sundararajan Athijegannathan]

+1


On 5/26/2016 4:28 PM, Felix Yang wrote:
> Hi there,
>
> please review the following change.
>
> Webrev:   http://cr.openjdk.java.net/~xiaofeya/8157931/webrev.00/
>
> Bug:  https://bugs.openjdk.java.net/browse/JDK-8157931
>
>
> The test "jdk/internal/jrtfs/Basic.java" fails when testing with
> exploded builds. It tried to access jrt-fs.jar which not exists in
> exploded builds.
>
> In this fix, those tests will be skipped, if the build is identified
> as an exploded one. And please note that, a bug (JDK-8157936
> ) was found with the
> updated test.
>
> Thanks,
>
> Felix
>

Re: RFR 8157931, jdk/internal/jrtfs/Basic.java fails with exploded builds

[Jim Laskey (Oracle)]

+1

> On May 26, 2016, at 7:58 AM, Felix Yang  wrote:
> 
> Hi there,
> 
>please review the following change.
> 
> Webrev:   http://cr.openjdk.java.net/~xiaofeya/8157931/webrev.00/
> 
> Bug:  https://bugs.openjdk.java.net/browse/JDK-8157931
> 
> 
> The test "jdk/internal/jrtfs/Basic.java" fails when testing with exploded 
> builds. It tried to access jrt-fs.jar which not exists in exploded builds.
> 
> In this fix, those tests will be skipped, if the build is identified as an 
> exploded one. And please note that, a bug (JDK-8157936 
> ) was found with the 
> updated test.
> 
> Thanks,
> 
> Felix
> 

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

[John Jiang]

Hi Chris,
Thanks for your comment!
Please review the updated webrev: 
http://cr.openjdk.java.net/~jjiang/8157783/webrev.01

It excludes the /javax/* tests.

Best regards,
John Jiang


On 2016/5/25 16:02, Chris Hegarty wrote:

On 25 May 2016, at 07:44, John Jiang  wrote:

Hi,
Please review this patch on fixing module dependencies for /javax/* and /jdk/* 
tests.

Issue: https://bugs.openjdk.java.net/browse/JDK-8157783
Webrev: http://cr.openjdk.java.net/~jjiang/8157783/webrev.00/

The changes to the non-javax tests look fine.

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

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

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

-Chris.

Re: creating proxies for interfaces with default methods

[Jochen Theodorou]

On 26.05.2016 09:03, Alan Bateman wrote:

On 26/05/2016 07:04, Jochen Theodorou wrote:


you cannot invoke the default method with reflection without
implementation of the interface

It sounds like you want to invoke the default method without a receiver.
This does seem like sorcery for mlvm-dev.


the problem is, that if I use a dynamic proxy as receiver and reflection 
as invocation method, I will end up in the invocation hadler again.


bye Jochen

Re: 8156143: Module.getResourceAsStream throws unspecified SecurityException with module in custom Layer

[Alan Bateman]

On 25/05/2016 22:25, Mandy Chung wrote:

On a related note (nothing to deal with this issue), the javadoc of 
ClassLoader::findResource(String) should be updated to reflect that it returns 
null if access to the resource is denied by the security manager, at least for 
built-in class loader as an implementation note.



I agree as it is long standing (but unspecified) behavior.

-Alan.

Re: creating proxies for interfaces with default methods

[Alan Bateman]

On 26/05/2016 07:04, Jochen Theodorou wrote:


you cannot invoke the default method with reflection without 
implementation of the interface
It sounds like you want to invoke the default method without a receiver. 
This does seem like sorcery for mlvm-dev.


-Alan