Re: Fwd: resource location problem in JDK 9 from build 148 onward

[Rick Hillegas]

On 1/18/17, 2:14 AM, Alan Bateman wrote:

On 18/01/2017 01:21, Rick Hillegas wrote:

Thanks, David and Alan. The suggested workaround works for me. I will 
mouse your response into the commentary on 
https://issues.apache.org/jira/browse/DERBY-6856, where I have been 
collecting all of the issues I've encountered when building and 
testing Apache Derby with JDK 9.


I strongly recommend a GA release note about this topic if the 
backward-incompatibility won't be ameliorated.
The "Risks and Assumptions" section in JEP 261 will be refreshed soon 
so that it has an up to date list of the compatibility issues that 
relate to the changes that we are doing here. They will eventually 
show up in release notes and migration documentation.

Thanks again, Alan.


Thanks for the link to the Derby issue tracking your migration 
efforts. From a quick read then the only other issue that seems to be 
relevant to what we are doing here is the test that was hacking into a 
field of java.security.Permission.


As regards the test using Object.class to locate 
"/org/apache/derbyTesting/functionTests/suites/derbyall.properties" 
then it's an odd way to locate a resource and not clear why it didn't 
use ClassLoader.getSystemResourceAsStream originally. Anyway, as I 
said, we'll need to see if using types in modules to locate a resource 
on the class path make sense or not.
I don't know why the original author coded it that way. It's a very old 
piece of code from the last millennium, something that just worked and 
therefore wasn't touched for almost two decades.


Cheers,
-Rick


-Alan

hg: jigsaw/jake/jdk: Minor update on Proxy spec to clarify open packages

[mandy . chung]

Changeset: c1569ce11b78
Author:mchung
Date:  2017-01-18 13:20 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c1569ce11b78

Minor update on Proxy spec to clarify open packages

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

hg: jigsaw/jake/langtools: jshell tests fail as KullaTesting uses resolveRequires

[alan . bateman]

Changeset: d5141c15aa1d
Author:alanb
Date:  2017-01-18 19:52 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d5141c15aa1d

jshell tests fail as KullaTesting uses resolveRequires

! test/jdk/jshell/KullaTesting.java
! test/tools/javac/T8003967/DetectMutableStaticFields.java

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

[Sundararajan Athijegannathan]

+1

-Sundar

On 18/01/17, 10:35 PM, Chris Hegarty wrote:

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

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

-Chris.

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

[Mandy Chung]

> On Jan 18, 2017, at 1:25 AM, Chris Hegarty  wrote:
> 
> 
>> On 18 Jan 2017, at 07:38, Alan Bateman  wrote:
>> 
>> On 17/01/2017 21:23, Mandy Chung wrote:
>> 
>>> This test case attempts to verify that the temp file created by jmod is 
>>> cleaned up and removed if jmod create command fails.  It first cleans up 
>>> any temp files matching the prefix and suffix created for this test case.  
>>> The test fails because the fix for JDK-8160286 that creates the jmod temp 
>>> file in the tmp directory and it was updated to use Files.walk that may 
>>> fail to read the file attributes if the user doesn’t have access.
>>> 
>>> The patch fixes the test to call Files.list and find only the writeable 
>>> files matching the prefix and suffix.
>>> 
>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172870/webrev.00/
> 
> When this test was added originally jmod was creating the tmp file in 
> the current working directory. 
> 
> To avoid interference you could run with test with java.io.tmpdir set
> to the current working directory, “testng/othervm -Djava.io.tmpdir=. …"

Good suggestion.  I updated JmodTest.java on top of the patch:

* @run testng/othervm -Djava.io.tmpdir=. JmodTest

Mandy

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

[Mandy Chung]

+1

Mandy

> On Jan 18, 2017, at 9:05 AM, Chris Hegarty  wrote:
> 
> Since the jlink plugin package is no longer exported this test should
> add the appropriate @modules tag.
> 
> diff -r 5b75946223fb test/tools/jlink/ResourceDuplicateCheckTest.java
> --- a/test/tools/jlink/ResourceDuplicateCheckTest.javaWed Jan 18 
> 13:56:50 2017 +
> +++ b/test/tools/jlink/ResourceDuplicateCheckTest.javaWed Jan 18 
> 17:05:11 2017 +
> @@ -27,6 +27,7 @@
>  * @summary Detect duplicated resources in packaged modules
>  * @modules jdk.jlink/jdk.tools.jlink.builder
>  *  jdk.jlink/jdk.tools.jlink.internal
> + *  jdk.jlink/jdk.tools.jlink.plugin
>  * @run build ResourceDuplicateCheckTest
>  * @run main ResourceDuplicateCheckTest
>  */
> 
> -Chris.

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

[Chris Hegarty]

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

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

-Chris.

Re: MethodHandle performance

[Claes Redestad]

Hi Attila,

thanks for doing this experiment!

An alternative would be to add similar caching to 
java.lang.invoke.Invokers::spreadInvoker,
which appears to have been largely the case prior to 
https://bugs.openjdk.java.net/browse/JDK-8050053


Guessing maybe it was removed due to the possibility for unbounded 
growth of
number of cached spreaders (which is also an issue in your patch), and 
maybe
we should consider special-casing low-arity spreaders and/or a bounded 
cache of

recently used invokers for other cases to keep footprint down.

Thanks!

/Claes

On 01/14/2017 05:23 PM, Hontvári Attila wrote:
That makes the code simpler. The performance doesn't change. I've 
updated in place.



2017-01-14 15:53 keltezéssel, Remi Forax írta:

Attila,
you can use @Stable initialized with null instead of final when you 
declare the spreaderCache so you do not have to use Unsafe.


Rémi

- Mail original -

De: "Hontvári Attila" 
À: jigsaw-dev@openjdk.java.net
Envoyé: Samedi 14 Janvier 2017 13:56:58
Objet: Re: MethodHandle performance
As an experiment I have reimplemented 
MethodHandle::invokeWithArguments,

so it only generates a spreader on the first invocation, after that the
spreader will be reused. Now it is 10 times faster, therefore it 
reaches
the performance of reflection. If we don't pass primitive arguments, 
the

performance is close to MethodHandle::invoke.

https://gist.github.com/hoat4/b459938cf7ae93e64bba3208c69af567

On the first invocation of iWA, the new code checks if the MH is a
fixed-arity MH, or a varargs collector. In case of a fixed-arity MH,
this is simple, it stores the spreadInvoker in a field to be called by
iWA. But if the MH is a varargs-collector, it creates a new object for
caching the spreaders by the arguments count, and the iWA calls will be
forwarded to this object.

To enable inlining of a constant MH's iWA, the spreader is stored in a
final field. The field's initial value is an MH pointing to a setup
method, and when it is called, it generates the spreader, and rewrites
the final field with the generated spreader. This is risky, but I
couldn't induce the JVM to inline the wrong spreader method. I haven't
considered concurrency problems.

I've ran Michael Rasmussen's benchmark. This is the original JDK 8
MethodHandle:

Benchmark  Mode  CntScore Error  Units

MyBenchmark.invoke avgt5   25,611 ± 0,256  
ns/op
MyBenchmark.invokeExactavgt5   25,658 ± 0,116  
ns/op
MyBenchmark.invokeWithArgumentsavgt5  397,023 ± 39,137  
ns/op
MyBenchmark.reflective avgt5   42,578 ± 4,206  
ns/op
MyBenchmark.staticInvoke   avgt5   18,863 ± 0,417  
ns/op
MyBenchmark.staticInvokeExact  avgt5   18,918 ± 0,461  
ns/op
MyBenchmark.staticInvokeWithArguments  avgt5  390,777 ± 41,888  
ns/op


And this is the new code's performance:

Benchmark  Mode  Cnt   Score Error  Units
MyBenchmark.invoke avgt5  25,623 ± 0,249 ns/op
MyBenchmark.invokeExactavgt5  25,623 ± 0,390 ns/op
MyBenchmark.invokeWithArgumentsavgt5  44,167 ± 0,774 ns/op
MyBenchmark.reflective avgt5  42,549 ± 4,202 ns/op
MyBenchmark.staticInvoke   avgt5  19,025 ± 0,417 ns/op
MyBenchmark.staticInvokeExact  avgt5  18,910 ± 0,304 ns/op
MyBenchmark.staticInvokeWithArguments  avgt5  32,013 ± 2,749 ns/op

  Attila

2017-01-13 20:04 keltezéssel, John Rose írta:
On Jan 12, 2017, at 12:29 PM, Claes Redestad 
 wrote:
Right, I was just looking at the micro Stephen provided me, and it 
does

seem that the added cost for this case is due to invokeWithArguments
creating a new invoker every time.

This is a good workaround, and Stephen's report is a helpful reminder
that our performance story has a sharp edge.

We cache spreaders in the case of varargs methods,
for full performance, but not for the ad hoc spreader used by MH.iWA.

We should cache them, to remove this sharp edge (or performance 
pothole).

There are small technical challenges to do so.  Claes and I added
some notes to the bug report; maybe someone can look into it more.

— John

Re: hg: jigsaw/jake/langtools: resolveRequires/resolveRequiresAndUses -> resolve/resolveAndBind

[Remi Forax]

Alan,
I think it's better to have only one method 'resolve' that takes a varargs of 
an interface with an implementation using an enum like OpenOption for 
java.nio.file.Files*,
so it will be future proof if we add new ways to do the resolution.

  resolve() -> resolve()
  resolveAndBind -> resolve(BIND_SERVICES)

regards,
Rémi

* as far as i know you are the author of this pattern, no ?

- Mail original -
> De: "alan bateman" 
> À: jigsaw-dev@openjdk.java.net
> Envoyé: Mercredi 18 Janvier 2017 15:28:04
> Objet: hg: jigsaw/jake/langtools: resolveRequires/resolveRequiresAndUses ->   
> resolve/resolveAndBind

> Changeset: 6d8f7ff2ac37
> Author:alanb
> Date:  2017-01-18 14:12 +
> URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6d8f7ff2ac37
> 
> resolveRequires/resolveRequiresAndUses -> resolve/resolveAndBind
> 
> ! 
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
> ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java
> ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java

hg: jigsaw/jake/langtools: resolveRequires/resolveRequiresAndUses -> resolve/resolveAndBind

[alan . bateman]

Changeset: 6d8f7ff2ac37
Author:alanb
Date:  2017-01-18 14:12 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6d8f7ff2ac37

resolveRequires/resolveRequiresAndUses -> resolve/resolveAndBind

! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java

hg: jigsaw/jake/nashorn: resolveRequires/resolveRequiresAndUses -> resolve/resolveAndBind

[alan . bateman]

Changeset: 38cf77ce5d45
Author:alanb
Date:  2017-01-18 14:12 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/38cf77ce5d45

resolveRequires/resolveRequiresAndUses -> resolve/resolveAndBind

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java

hg: jigsaw/jake/jaxp: resolveRequires/resolveRequiresAndUses -> resolve/resolveAndBind

[alan . bateman]

Changeset: 00f7f4435cdb
Author:alanb
Date:  2017-01-18 14:11 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/00f7f4435cdb

resolveRequires/resolveRequiresAndUses -> resolve/resolveAndBind

! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java
! test/javax/xml/jaxp/module/ServiceProviderTest/LayerModularXMLParserTest.java

AW: [JDK-8153077] JNLP example with -XaddExports

[Reto Merz]

Thanks Alan for clarify the syntax, it works!

This was just an example. At the moment we just want to evaluate some basics 
with Java 9 + Webstart.
In our real world application we use these classes from sun.security.*

sun.security.util.DerValue
sun.security.x509.AVA
sun.security.x509.AlgorithmId
sun.security.x509.CertificateAlgorithmId
sun.security.x509.CertificateIssuerName
sun.security.x509.CertificateSerialNumber
sun.security.x509.CertificateSubjectName
sun.security.x509.CertificateValidity
sun.security.x509.CertificateVersion
sun.security.x509.CertificateX509Key
sun.security.x509.RDN
sun.security.x509.X500Name
sun.security.x509.X509CertImpl
sun.security.x509.X509CertInfo
sun.security.x509.AVA
sun.security.x509.CertificatePoliciesExtension
sun.security.x509.CertificatePolicyId
sun.security.x509.PolicyInformation
sun.security.x509.X500Name
sun.security.x509.X509CertImpl
sun.security.x509.X509CertImpl

I am not the owner of this code and I dont know what exactly is does, it is 
beyond me.
As far as I know the public JRE API and bouncycastle lib does not provide some 
functionality needed to support some Smartcards and SuisseID.

Reto


On 18/01/2017 14:48, Alan Bateman wrote:

> On 18/01/2017 13:35, Reto Merz wrote:
> 
> > Hello,
> >
> > Is there any documentation or a public available working example how to
> use -XaddExports for WebStart apps ?
> > I have no acces to the example mentioned in JDK-8153077.
> >
> > We try this:
> >  
> I suspect this is what you want (and should be allowed because the
> application is signed):
> 
>  java-vm-args="--add-exports=java.base/sun.security.action=ALL-
> UNNAMED"/>
> 
> At the same time then it would be good to understand why this code needs
> to make direct use of types in sun.security.action. As there isn't
> anything very critical in that package then it make be a
> straight-forward dependency to remove.
> 
> -Alan
> 

Re: [JDK-8153077] JNLP example with -XaddExports

[Alan Bateman]

On 18/01/2017 13:35, Reto Merz wrote:


Hello,

Is there any documentation or a public available working example how to use 
-XaddExports for WebStart apps ?
I have no acces to the example mentioned in JDK-8153077.

We try this:
 
I suspect this is what you want (and should be allowed because the 
application is signed):


java-vm-args="--add-exports=java.base/sun.security.action=ALL-UNNAMED"/>


At the same time then it would be good to understand why this code needs 
to make direct use of types in sun.security.action. As there isn't 
anything very critical in that package then it make be a 
straight-forward dependency to remove.


-Alan

[JDK-8153077] JNLP example with -XaddExports

[Reto Merz]

Hello,

Is there any documentation or a public available working example how to use 
-XaddExports for WebStart apps ?
I have no acces to the example mentioned in JDK-8153077.

We try this:

  
and also this:
  

[..]

   
  
In both cases WebStart throws a IAE. All our JARs are signed and JNLP also 
request all-permissions.
Tested with Java 9 b152 and Windows 7. Java Webstart Console output:
  
Java Web Start 12.0.0.0
Using JRE version 9-ea+152 Java HotSpot(TM) 64-Bit Server VM
JRE expiration date: 11.07.17, 00:00
User home directory = C:\Users\Administrator
[..]
 Java Web Start Error:
 java.lang.IllegalAccessError: class ch.abacus.Java9Test (in unnamed 
module @0x4ab3b734) cannot access class sun.security.action.GetPropertyAction 
(in module java.base) because module java.base does not export 
sun.security.action to unnamed module @0x4ab3b734

Thanks
Reto Merz

Re: RFR 8168254: Detect duplicated resources in packaged modules

[Jim Laskey (Oracle)]

+1

> On Jan 18, 2017, at 2:03 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8168254/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8168254
> 
> Thanks,
> -Sundar

Re: Fwd: resource location problem in JDK 9 from build 148 onward

[Alan Bateman]

On 18/01/2017 01:21, Rick Hillegas wrote:

Thanks, David and Alan. The suggested workaround works for me. I will 
mouse your response into the commentary on 
https://issues.apache.org/jira/browse/DERBY-6856, where I have been 
collecting all of the issues I've encountered when building and 
testing Apache Derby with JDK 9.


I strongly recommend a GA release note about this topic if the 
backward-incompatibility won't be ameliorated.
The "Risks and Assumptions" section in JEP 261 will be refreshed soon so 
that it has an up to date list of the compatibility issues that relate 
to the changes that we are doing here. They will eventually show up in 
release notes and migration documentation.


Thanks for the link to the Derby issue tracking your migration efforts. 
From a quick read then the only other issue that seems to be relevant 
to what we are doing here is the test that was hacking into a field of 
java.security.Permission.


As regards the test using Object.class to locate 
"/org/apache/derbyTesting/functionTests/suites/derbyall.properties" then 
it's an odd way to locate a resource and not clear why it didn't use 
ClassLoader.getSystemResourceAsStream originally. Anyway, as I said, 
we'll need to see if using types in modules to locate a resource on the 
class path make sense or not.


-Alan

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

[Chris Hegarty]

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

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

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

-Chris.