RE: How to actually ship JSR-250?

[Stephen Felts]

Yes, you are correct that Java EE 8 won't require Java SE 9.  This will be the 
first time that two versions of Java SE ship before the next Java EE.

There are a bunch of JDK 9 bugs against the RI but they are generally for 
internal API's.

However, the RI won't be able to run on JDK9 until the API class problem is 
resolved, even if for the short term.  Some of the classes are in the endorsed 
directory and some of the classes don't exist in the RI (e.g., 
javax.activation).  The quick fix is to require the JDK9 option to make the EE 
classes in the SE visible.



-Original Message-
From: David M. Lloyd [mailto:david.ll...@redhat.com] 
Sent: Thursday, April 20, 2017 6:49 PM
To: Stephen Felts; Alan Bateman; jigsaw-dev
Subject: Re: How to actually ship JSR-250?

To address the first point only... I think if Java EE 8 required Java SE 9, 
that would be surprising news for all.  For the last few Java EE releases at 
least, each Java EE release has required the Java SE version of the same 
number.  And there has been plenty of talk over the past couple years that 
seems to indicate that this will continue to 9.  Thus I have no expectation 
that Java EE 8 will do anything special for Java SE 9.

However, we definitely want our implementation to run on Java SE 9.  My 
understanding was that you cannot replace classes in upgradeable modules via 
the class path, but if that's wrong then I suppose it's time to do another 
round of experiments.

On 04/20/2017 11:45 AM, Stephen Felts wrote:
> First, I'm not sure that Java EE 8 (corresponding to Java SE 9) will define 
> modules.
> It seems that the RI will tolerate JDK9 (remove internal JDK API calls) as 
> opposed to adopting the new module system.
>
> Since javax.annotation.* classes are now hidden in JDK 9, every project that 
> uses these classes will need to ship a copy of these classes.
>
> For a project that is not adopting the module system, these classes will be 
> on the classpath.  They can just ship the RI jar file (currently 
> glassfish4/glassfish/modules/endorsed/javax.annotation-api.jar) and in JDK9 
> endorsed is no longer supported but no longer needed for these classes 
> (that's the reason for hiding the classes).
> To provide the jax-ws annotations (they seem to live in 
> glassfish4/glassfish/modules/endorsed/webservices-api-osgi.jar) also on the 
> classpath, it just works.
> Both jar files need to be provided by project that uses these annotations and 
> added to the classpath directly or indirectly via a manifest classpath.
> (As a side note, there are some API's that are not in the endorsed 
> directory that will need to be additionally shipped for projects that 
> use them.)
>
> For a project that is adopting the module system, the jar files need to be 
> turned into modules with the correct names and the associated 
> module-info.class in the root.
> Both modules need to be shipped and both jar files need to be in the module 
> path or upgrade module path?
>
> If two projects run in the same JVM, one using the classpath and one using 
> the module path, the module path wins?
>
>
>
>
> -Original Message-
> From: David M. Lloyd [mailto:david.ll...@redhat.com]
> Sent: Thursday, April 20, 2017 9:21 AM
> To: Alan Bateman; jigsaw-dev
> Subject: Re: How to actually ship JSR-250?
>
> On 04/20/2017 08:18 AM, Alan Bateman wrote:
>> On 20/04/2017 13:57, David M. Lloyd wrote:
>>
>>> Let's say I want to create a module distribution with my own JSR 250 
>>> classes.  Let's also assume that I or the spec team want the module 
>>> to be named java.annotations.common.
>>>
>>> How do I properly upgrade the JDK's java.xml.ws.annotation module 
>>> such that java.xml.ws can see it, *and* I have my proper 
>>> java.annotations.common module name?  Am I forced to ship my 
>>> annotations module as java.xml.ws.annotation?  Or manually replace 
>>> java.xml.ws with one that looks for my annotations (and where does 
>>> that leave the original java.xml.ws.annotation module)?
>>>
>> java.xml.ws.annotation is upgradable so all you need to do is deploy 
>> the compiled form of the following on the upgrade module path:
>>
>> module java.xml.ws.annotation {
>> requires transitive java.annotations.common; }
>>
>> Separately, I don't know what name that JSR-250 will eventually choose.
>> It could be indeed be "java.annotations.common", maybe 
>> "java.ee.annotation", maybe something else.
>
> I'm not too worried about that; it has to be decided by the time of Java EE 9 
> (obviously) but until then I just want to ensure that it is definitely 
> possible to do this, as (unless I missed something) I don't believe that it 
> was adequately covered in prior discussions.
>
> --
> - DML
>

--
- DML

Re: RFR 8178323: Add negative tests for bind services Jlink feature

[Mandy Chung]

> On Apr 20, 2017, at 5:12 PM, Andrey Nazarov  
> wrote:
> 
> HI Mandy,
> 
> I’ve update patch 
> http://cr.openjdk.java.net/~anazarov/8178323/webrev.03/webrev/ 
> 
Nit: use 4-space indent e.g. BindServices.java. line 159 (the following lines 
will move along) and SuggestProviders.java line 255-258, 262, 273-276,  and 280.

Otherwise looks good.

You can fix the formatting before push.

Thanks
Mandy

Re: RFR 8178323: Add negative tests for bind services Jlink feature

[Andrey Nazarov]

HI Mandy,

I’ve update patch 
http://cr.openjdk.java.net/~anazarov/8178323/webrev.03/webrev/ 

I’ve removed some tests since you pushed them with fix for 
https://bugs.openjdk.java.net/browse/JDK-8178404

—Andrey
> On 11 Apr 2017, at 12:46, Andrey Nazarov  wrote:
> 
> Hi Mandy,
> 
> Here is updated patch 
> http://cr.openjdk.java.net/~anazarov/8178323/webrev.02/webrev/ 
> 
> 
> — Thanks,
> Andrey
>> On 10 Apr 2017, at 23:50, Mandy Chung  wrote:
>> 
>> 
>>> On Apr 10, 2017, at 12:30 PM, Andrey Nazarov >> > wrote:
>>> 
>>> Mandy, thanks for review. I’ve updated patch
>>> http://cr.openjdk.java.net/~anazarov/8178323/webrev.01/webrev/ 
>>> 
>>> 
>> 
>> I suggest to add m4/p4.S to make it clear it’s a service type and m4 
>> provides p4.S with  p4.Impl.
>> noOneUsesProvider will call —suggest-providers p4.S instead.
>> 
>> 239 static JLink run(boolean expectSuccess, String... options) {
>> Instead of adding a new parameter, what about adding a new 
>> runWithNonZeroExitCode method?
>> 
>>> See my comments inline
 
 
 line 159-161: formatting nit: can you add spaces to align with the first
 argument in line 158.  Same comment to SuggestProviders.java line 180-182
 an 198-200.
>>> Fixed
>> 
>> line 216-219.
>> 
>>> Actually there are two issues here: 
>>> https://bugs.openjdk.java.net/browse/JDK-8178404 
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8178405 
>>> 
>> Not really a bug but it’d be helpful to show that the provider exists but 
>> the service is not used in this case.
>> Mandy
>> 
> 

Re: How to actually ship JSR-250?

[David M. Lloyd]

To address the first point only... I think if Java EE 8 required Java SE 
9, that would be surprising news for all.  For the last few Java EE 
releases at least, each Java EE release has required the Java SE version 
of the same number.  And there has been plenty of talk over the past 
couple years that seems to indicate that this will continue to 9.  Thus 
I have no expectation that Java EE 8 will do anything special for Java SE 9.


However, we definitely want our implementation to run on Java SE 9.  My 
understanding was that you cannot replace classes in upgradeable modules 
via the class path, but if that's wrong then I suppose it's time to do 
another round of experiments.


On 04/20/2017 11:45 AM, Stephen Felts wrote:

First, I'm not sure that Java EE 8 (corresponding to Java SE 9) will define 
modules.
It seems that the RI will tolerate JDK9 (remove internal JDK API calls) as 
opposed to adopting the new module system.

Since javax.annotation.* classes are now hidden in JDK 9, every project that 
uses these classes will need to ship a copy of these classes.

For a project that is not adopting the module system, these classes will be on 
the classpath.  They can just ship the RI jar file (currently 
glassfish4/glassfish/modules/endorsed/javax.annotation-api.jar) and in JDK9 
endorsed is no longer supported but no longer needed for these classes (that's 
the reason for hiding the classes).
To provide the jax-ws annotations (they seem to live in 
glassfish4/glassfish/modules/endorsed/webservices-api-osgi.jar) also on the 
classpath, it just works.
Both jar files need to be provided by project that uses these annotations and 
added to the classpath directly or indirectly via a manifest classpath.
(As a side note, there are some API's that are not in the endorsed directory 
that will need to be additionally shipped for projects that use them.)

For a project that is adopting the module system, the jar files need to be 
turned into modules with the correct names and the associated module-info.class 
in the root.
Both modules need to be shipped and both jar files need to be in the module 
path or upgrade module path?

If two projects run in the same JVM, one using the classpath and one using the 
module path, the module path wins?




-Original Message-
From: David M. Lloyd [mailto:david.ll...@redhat.com]
Sent: Thursday, April 20, 2017 9:21 AM
To: Alan Bateman; jigsaw-dev
Subject: Re: How to actually ship JSR-250?

On 04/20/2017 08:18 AM, Alan Bateman wrote:

On 20/04/2017 13:57, David M. Lloyd wrote:


Let's say I want to create a module distribution with my own JSR 250
classes.  Let's also assume that I or the spec team want the module
to be named java.annotations.common.

How do I properly upgrade the JDK's java.xml.ws.annotation module
such that java.xml.ws can see it, *and* I have my proper
java.annotations.common module name?  Am I forced to ship my
annotations module as java.xml.ws.annotation?  Or manually replace
java.xml.ws with one that looks for my annotations (and where does
that leave the original java.xml.ws.annotation module)?


java.xml.ws.annotation is upgradable so all you need to do is deploy
the compiled form of the following on the upgrade module path:

module java.xml.ws.annotation {
requires transitive java.annotations.common; }

Separately, I don't know what name that JSR-250 will eventually choose.
It could be indeed be "java.annotations.common", maybe
"java.ee.annotation", maybe something else.


I'm not too worried about that; it has to be decided by the time of Java EE 9 
(obviously) but until then I just want to ensure that it is definitely possible 
to do this, as (unless I missed something) I don't believe that it was 
adequately covered in prior discussions.

--
- DML



--
- DML

hg: jigsaw/jake/jdk: 42 new changesets

[alan . bateman]

Changeset: cd268728d178
Author:weijun
Date:  2017-04-11 10:12 +0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cd268728d178

8177969: Faster FilePermission::implies by avoiding the use of Path::relativize
Reviewed-by: rriggs, mullan

! src/java.base/share/classes/java/io/FilePermission.java
! test/java/io/FilePermission/Correctness.java

Changeset: c35ff69c2852
Author:dfuchs
Date:  2017-04-11 16:32 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c35ff69c2852

8178147: Race conditions in timeout handling code in http/2 incubator client
Summary: Timeout handling code (in particular cancel(IOException)) is modified 
to take into account cancellation arising before exchange implementation is 
established or response completable future is created. TimeoutEvent::compareTo 
method is modified to be consistent with TimeoutEvent::equals.
Reviewed-by: prappo, chegar, michaelm

! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Exchange.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Http1Exchange.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpClientImpl.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/MultiExchange.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/PlainHttpConnection.java
! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Stream.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/TimeoutEvent.java
! test/ProblemList.txt
+ test/java/net/httpclient/SmallTimeout.java
! test/java/net/httpclient/TimeoutOrdering.java

Changeset: 23255bc8606d
Author:rriggs
Date:  2017-04-11 14:18 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/23255bc8606d

8178347: Process and ProcessHandle getPid method name inconsistency
Reviewed-by: alanb, bpb

! src/java.base/share/classes/java/lang/Process.java
! src/java.base/share/classes/java/lang/ProcessHandle.java
! src/java.base/share/classes/java/lang/ProcessHandleImpl.java
! src/java.base/unix/classes/java/lang/ProcessImpl.java
! src/java.base/windows/classes/java/lang/ProcessImpl.java
! test/com/sun/jdi/ProcessAttachTest.java
! test/java/lang/ProcessBuilder/Basic.java
! test/java/lang/ProcessBuilder/PipelineTest.java
! test/java/lang/ProcessBuilder/Zombies.java
! test/java/lang/ProcessHandle/Basic.java
! test/java/lang/ProcessHandle/JavaChild.java
! test/java/lang/ProcessHandle/OnExitTest.java
! test/java/lang/ProcessHandle/ProcessUtil.java
! test/java/lang/ProcessHandle/TreeTest.java
! test/java/lang/Runtime/exec/SleepyCat.java
! test/java/util/logging/LoggingDeadlock2.java
! test/lib/testlibrary/jdk/testlibrary/ProcessThread.java
! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java
! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java
! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java
! test/sun/management/jmxremote/startstop/JMXStartStopTest.java
! test/sun/tools/jps/LingeredApp.java
! test/sun/tools/jstat/JStatInterval.java

Changeset: 0c8f43317c1f
Author:ascarpino
Date:  2017-04-12 12:57 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c8f43317c1f

8177784: Use CounterMode intrinsic for AES/GCM
Reviewed-by: mullan, psandoz, chegar

! src/java.base/share/classes/com/sun/crypto/provider/CounterMode.java
! src/java.base/share/classes/com/sun/crypto/provider/GCTR.java

Changeset: ede22275fbfa
Author:dlong
Date:  2017-04-12 16:37 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ede22275fbfa

8158168: Missing bounds checks for some String intrinsics
Reviewed-by: vlivanov, thartmann, sherman

! src/java.base/share/classes/java/lang/AbstractStringBuilder.java
! src/java.base/share/classes/java/lang/Integer.java
! src/java.base/share/classes/java/lang/Long.java
! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/StringConcatHelper.java
! src/java.base/share/classes/java/lang/StringLatin1.java
! src/java.base/share/classes/java/lang/StringUTF16.java

Changeset: 2a15003cb4b7
Author:jwilhelm
Date:  2017-04-13 15:57 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2a15003cb4b7

8178447: Remove link from JavaDoc to Dev guide
Reviewed-by: tschatzl, dholmes

! src/jdk.management/share/classes/com/sun/management/VMOption.java

Changeset: 15cb1241abad
Author:lana
Date:  2017-04-13 16:27 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/15cb1241abad

Merge


Changeset: f36e07712a1b
Author:serb
Date:  2017-03-21 01:39 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f36e07712a1b

8176544: Compilation error in plaf.metal.MetalBumps.Test6657026
Reviewed-by: prr

! test/javax/swing/plaf/metal/MetalBumps/Test6657026.java

Changeset: 1158c3e5bd9c
Author:prr
Date:  2017-03-21 11:05 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1158c3e5bd9c

Merge


Changeset: 0f4994564ae6
Author:

hg: jigsaw/jake: 7 new changesets

[alan . bateman]

Changeset: 7d5d7ae50c72
Author:rriggs
Date:  2017-04-11 14:20 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/7d5d7ae50c72

8178347: Process and ProcessHandle getPid method name inconsistency
Reviewed-by: alanb, bpb

! test/lib/jdk/test/lib/apps/LingeredApp.java
! test/lib/jdk/test/lib/process/ProcessTools.java

Changeset: 35fbd9906dfc
Author:erikj
Date:  2017-04-13 09:41 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/35fbd9906dfc

8177822: Move closed jib configuration for arm platforms to open
Reviewed-by: tbell

! common/conf/jib-profiles.js

Changeset: 9e093f2eaabc
Author:erikj
Date:  2017-04-13 09:50 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/9e093f2eaabc

8176271: Still unable to build JDK 9 on some *7 sparcs
Reviewed-by: ihse

! common/conf/jib-profiles.js

Changeset: 455bd4cb2482
Author:lana
Date:  2017-04-13 16:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/455bd4cb2482

Merge


Changeset: ba5b16c9c6d8
Author:darcy
Date:  2017-04-13 14:38 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/ba5b16c9c6d8

8177553: Address removal lint warnings in the JDK build
Reviewed-by: mchung, erikj

! make/common/SetupJavaCompilers.gmk

Changeset: cf6ee4d4c839
Author:lana
Date:  2017-04-20 18:14 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/cf6ee4d4c839

Added tag jdk-9+166 for changeset ba5b16c9c6d8

! .hgtags

Changeset: 03d4146b2bd4
Author:alanb
Date:  2017-04-20 20:15 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/03d4146b2bd4

Merge

! .hgtags
! common/conf/jib-profiles.js
! make/common/SetupJavaCompilers.gmk

hg: jigsaw/jake/corba: 2 new changesets

[alan . bateman]

Changeset: 43de67f51801
Author:lana
Date:  2017-04-20 18:14 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/43de67f51801

Added tag jdk-9+166 for changeset 934c18145915

! .hgtags

Changeset: d072e5afa03f
Author:alanb
Date:  2017-04-20 20:16 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/d072e5afa03f

Merge

! .hgtags

hg: jigsaw/jake/langtools: 13 new changesets

[alan . bateman]

Changeset: 151bc67acf92
Author:mcimadamore
Date:  2017-04-11 14:03 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/151bc67acf92

8178414: T8177933.java fails even after fix for JDK-8178283
Summary: add T8177933.java to problem list
Reviewed-by: jlahoda

! test/ProblemList.txt

Changeset: 256d9fce6c53
Author:rfield
Date:  2017-04-11 17:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/256d9fce6c53

8178023: jshell tool: crash with ugly message on attempt to add non-existant 
module path
Reviewed-by: jlahoda

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! 
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties
! 
src/jdk.jshell/share/classes/jdk/jshell/execution/FailOverExecutionControlProvider.java
! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java
! test/jdk/jshell/DyingRemoteAgent.java
! test/jdk/jshell/HangingRemoteAgent.java
! test/jdk/jshell/HistoryTest.java
! test/jdk/jshell/JdiBadOptionLaunchExecutionControlTest.java
! test/jdk/jshell/JdiBadOptionListenExecutionControlTest.java
! test/jdk/jshell/JdiBogusHostListenExecutionControlTest.java
! test/jdk/jshell/ReplToolTesting.java
! test/jdk/jshell/StartOptionTest.java
! test/jdk/jshell/ToolProviderTest.java
! test/jdk/jshell/ToolReloadTest.java
! test/jdk/jshell/UITesting.java

Changeset: 3e7eab1d1e96
Author:ksrini
Date:  2017-04-12 11:42 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3e7eab1d1e96

8178067: support for @uses/@provides tags is broken
Reviewed-by: jjg

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! test/jdk/javadoc/doclet/lib/JavadocTester.java
+ test/jdk/javadoc/doclet/testModules/TestModuleServices.java
! test/jdk/javadoc/doclet/testModules/TestModules.java
! test/tools/lib/toolbox/ModuleBuilder.java

Changeset: 688279815c27
Author:ksrini
Date:  2017-04-12 13:48 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/688279815c27

8178686: Fix incorrect bug id in test.
Reviewed-by: darcy

! test/jdk/javadoc/doclet/testModules/TestModuleServices.java

Changeset: 42705de602d7
Author:lana
Date:  2017-04-13 16:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/42705de602d7

Merge


Changeset: b51c0ba6fd8f
Author:rfield
Date:  2017-04-13 14:11 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b51c0ba6fd8f

8178520: jshell tool: /help /save -- incorrect description of /save -start
Reviewed-by: jlahoda

! 
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties

Changeset: ad2910e96239
Author:jjg
Date:  2017-04-14 15:54 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ad2910e96239

8178426: Extra } is coming in the javadoc of Taglet.toString() API
Reviewed-by: ksrini, bpatel

! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Taglet.java

Changeset: d2f92cb767a6
Author:bpatel
Date:  2017-04-14 17:23 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d2f92cb767a6

8175823: doclet crashes when documenting a single class in a module.
Reviewed-by: jjg, ksrini

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! test/jdk/javadoc/doclet/testModules/TestModules.java
+ test/jdk/javadoc/doclet/testModules/moduleNoExport/module-info.java
+ 
test/jdk/javadoc/doclet/testModules/moduleNoExport/testpkgmdlNoExport/TestClassInModuleNoExport.java

Changeset: 8b68fb0d8159
Author:jjg
Date:  2017-04-17 14:16 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8b68fb0d8159

8178509: MODULE_SOURCE_PATH: Implement missing methods
8178493: StandardJavaFileManager: Clarify/document the use of 
IllegalStateException
Reviewed-by: jlahoda

! src/java.compiler/share/classes/javax/tools/StandardJavaFileManager.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java
! test/tools/javac/modules/ModuleSourcePathTest.java
! test/tools/lib/toolbox/JavacTask.java

Changeset: 229a32ad3b26
Author:jjg
Date:  2017-04-17 15:08 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/229a32ad3b26

8176801: tools/javac/platform/PlatformProviderTest.java sensitive to warnings 
sent to stderr
Reviewed-by: ksrini

! test/ProblemList.txt

Changeset: 2a8b403a6233
Author:jjg
Date:  2017-04-17 15:28 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2a8b403a6233

8161295: javac, cleanup use of ModuleTestBase
Reviewed-by: ksrini

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

Changeset: 2bd173891dcf
Author:lana
Date:  2017-04-20 18:14 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2bd173891dcf

Added tag jdk-9+166 for changeset 2a8b403a6233

! .hgtags

Changeset: 94a50bfd5340
Author:alanb
Date:  2017-04-20 20:15 +0100
URL:   

hg: jigsaw/jake/nashorn: 2 new changesets

[alan . bateman]

Changeset: 85bf1d0aeb09
Author:lana
Date:  2017-04-20 18:14 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/85bf1d0aeb09

Added tag jdk-9+166 for changeset 5b2e7b2101c0

! .hgtags

Changeset: e89bf7fa0a32
Author:alanb
Date:  2017-04-20 20:16 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e89bf7fa0a32

Merge

! .hgtags

hg: jigsaw/jake/hotspot: 9 new changesets

[alan . bateman]

Changeset: e8699be63872
Author:iveresov
Date:  2017-04-11 11:34 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e8699be63872

8176887: AOT: SIGSEGV in AOTCodeHeap::next when using specific configuration
Summary: Derive MethodCounters from Metadata
Reviewed-by: kvn, coleenp

! src/share/vm/oops/metadata.hpp
! src/share/vm/oops/methodCounters.cpp
! src/share/vm/oops/methodCounters.hpp

Changeset: 66ec8add62cd
Author:dholmes
Date:  2017-04-11 19:39 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/66ec8add62cd

8135161: Missing commas in copyright notices
Reviewed-by: sspitsyn

! src/cpu/s390/vm/c1_Runtime1_s390.cpp
! src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
! src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp

Changeset: 773e40f3fc21
Author:never
Date:  2017-04-06 00:03 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/773e40f3fc21

8178119: [JVMCI] when rethrowing exceptions at deopt the exception must be 
fetched after materialization
Reviewed-by: kvn

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

Changeset: 00bf892e5553
Author:rriggs
Date:  2017-04-12 11:43 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/00bf892e5553

8178347: Process and ProcessHandle getPid method name inconsistency
Reviewed-by: hseigel

! test/runtime/libadimalloc.solaris.sparc/Testlibadimalloc.java
! test/serviceability/attach/AttachSetGetFlag.java
! test/serviceability/tmtools/jstack/DaemonThreadTest.java
! test/serviceability/tmtools/jstack/SpreadLockTest.java
! test/serviceability/tmtools/jstack/ThreadNamesTest.java
! test/serviceability/tmtools/jstack/TraveledLockTest.java
! test/serviceability/tmtools/jstack/WaitNotifyThreadTest.java
! test/serviceability/tmtools/jstat/GcCapacityTest.java
! test/serviceability/tmtools/jstat/GcCauseTest01.java
! test/serviceability/tmtools/jstat/GcCauseTest02.java
! test/serviceability/tmtools/jstat/GcCauseTest03.java
! test/serviceability/tmtools/jstat/GcNewTest.java
! test/serviceability/tmtools/jstat/GcTest01.java
! test/serviceability/tmtools/jstat/GcTest02.java

Changeset: 4d6df9a75465
Author:dlong
Date:  2017-04-12 16:36 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4d6df9a75465

8158168: Missing bounds checks for some String intrinsics
Reviewed-by: vlivanov, thartmann, sherman

! src/share/vm/opto/library_call.cpp
+ test/compiler/intrinsics/string/TestStringUTF16IntrinsicRangeChecks.java
! test/compiler/patches/java.base/java/lang/Helper.java

Changeset: bbf855a44562
Author:lana
Date:  2017-04-13 16:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bbf855a44562

Merge


Changeset: 560d7aa083a2
Author:iignatyev
Date:  2017-04-14 18:31 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/560d7aa083a2

8178731: compiler/ciReplay/SABase.java does not compile
Reviewed-by: iignatyev, sspitsyn
Contributed-by: ekaterina.pavl...@oracle.com

! test/compiler/ciReplay/SABase.java
! test/serviceability/sa/sadebugd/SADebugDTest.java

Changeset: 443a768ec827
Author:lana
Date:  2017-04-20 18:14 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/443a768ec827

Added tag jdk-9+166 for changeset 560d7aa083a2

! .hgtags

Changeset: c150239dda02
Author:alanb
Date:  2017-04-20 20:24 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c150239dda02

Merge

! .hgtags
! src/share/vm/opto/library_call.cpp
! test/serviceability/attach/AttachSetGetFlag.java

hg: jigsaw/jake/jaxp: 4 new changesets

[alan . bateman]

Changeset: 37cdb2871070
Author:rriggs
Date:  2017-04-12 10:53 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/37cdb2871070

8178347: Process and ProcessHandle getPid method name inconsistency
Reviewed-by: alanb, bpb

! test/javax/xml/jaxp/libs/jdk/testlibrary/ProcessTools.java

Changeset: 8d3febd5c9d8
Author:lana
Date:  2017-04-13 16:27 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/8d3febd5c9d8

Merge


Changeset: c98480dd22e7
Author:lana
Date:  2017-04-20 18:14 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/c98480dd22e7

Added tag jdk-9+166 for changeset 8d3febd5c9d8

! .hgtags

Changeset: 241f86f89fe8
Author:alanb
Date:  2017-04-20 20:15 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/241f86f89fe8

Merge

! .hgtags

hg: jigsaw/jake/jaxws: 2 new changesets

[alan . bateman]

Changeset: eea021f7411c
Author:lana
Date:  2017-04-20 18:14 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/eea021f7411c

Added tag jdk-9+166 for changeset b1f30c27367b

! .hgtags

Changeset: 32200acaad50
Author:alanb
Date:  2017-04-20 20:15 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/32200acaad50

Merge

! .hgtags

Re: RFR: 8177845: Need a mechanism to load Graal

[Doug Simon]

I've had to update the webrev again to support selection of a "null" compiler 
(i.e. one that raises an
exception upon a compilation request) and added -Djvmci.Compiler=null to a 
large number of JVMCI jtreg
tests to prevent Graal being selected and initialized by the JVMCI compiler 
auto-selection mechanism.
Initializing Graal will currently fail with errors (see stack trace below) 
until Graal is updated to
the version compatible with the JVMCI API changes.

In addition to resolving the compatibility issue, explicitly selecting the 
"null" compiler for these
tests better isolates them from parts of the runtime they are not aiming to 
test.

org.graalvm.compiler.debug.GraalError: java.lang.ClassCastException: 
java.base/java.util.ImmutableCollections$MapN cannot be cast to 
java.base/java.util.Properties
at 
jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:217)
at 
jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:138)
at 
jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:95)
at 
jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:104)
at 
jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:290)
at 
jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:65)
at 
jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime$DelayedInit.(HotSpotJVMCIRuntime.java:73)
at 
jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:83)
at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native 
Method)
at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.(JVMCI.java:58)
at 
jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:82)
at 
jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfig.config(HotSpotVMConfig.java:41)
at 
jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getHolder(HotSpotResolvedJavaMethodImpl.java:92)
at 
jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.fromMetaspace(HotSpotResolvedJavaMethodImpl.java:110)
at 
jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.asResolvedJavaMethod(Native 
Method)
at 
jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper.asResolvedJavaMethod(CompilerToVMHelper.java:185)
at 
compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:59)
at 
compiler.jvmci.common.CTVMUtilities.getResolvedMethod(CTVMUtilities.java:64)
at 
compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:125)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1378)
at 
compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:71)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.ClassCastException: 
java.base/java.util.ImmutableCollections$MapN cannot be cast to 
java.base/java.util.Properties
at 
jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:215)
... 26 more

-Doug

> On 19 Apr 2017, at 23:26, Doug Simon  wrote:
> 
> I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these 
> changes:
> 
> 1. JVMCIServiceLocator.getProvider(Class) is now protected
> 2. JVMCIServiceLocator.getProviders(Class) now checks JVMCIPermission
> 3. Rename: jdk.vm.ci.services.internal.JDK9 -> 
> jdk.vm.ci.services.internal.ReflectionAccessJDK
> 
> -Doug
> 
>> On 19 Apr 2017, at 23:12, Doug Simon  wrote:
>> 
>>> 
>>> On 19 Apr 2017, at 21:40, Christian Thalinger  
>>> wrote:
>>> 
 
 On Apr 19, 2017, at 9:27 AM, Doug Simon  wrote:
 
> 
> On 19 Apr 2017, at 21:04, Mandy Chung  wrote:
> 
> 
>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger 
>>  wrote:
>> 
>> 
>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung  wrote:
>>> 
>>> Since jdk.internal.vm.compiler becomes an 

Re: RFR: 8177845: Need a mechanism to load Graal

[Doug Simon]

> On 19 Apr 2017, at 22:29, Vladimir Kozlov  wrote:
> 
> ReflectionAccessJDK ? Based on your comment in the file.
> 
> Vladimir
> 
> On 4/19/17 1:02 PM, Doug Simon wrote:
>> Sure - how about good old Util? ;-) I'm open to other suggestions.
>> 
>> Sent from my iPhone
>> 
>>> On Apr 19, 2017, at 9:46 PM, Vladimir Kozlov  
>>> wrote:
>>> 
>>> Hi Doug,
>>> 
>>> Can you consider using other name and not JDK9 for new JVMCI class? It will 
>>> be used in JDK 10 too:
>>> 
>>> jdk.vm.ci.services.internal.JDK9;
>>> 
>>> Thanks,
>>> Vladimir
>>> 
 On 4/18/17 3:13 PM, Doug Simon wrote:
 Please review these changes that make jdk.internal.vm.compiler an 
 upgradable compiler.
 The primary requirement for this is to remove all usage of JDK internals 
 from Graal.
 While this most involves changes in Graal, there remain a few capabilities 
 that must
 be exposed via JVMCI. Namely:
 
 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can 
 Graal initialize
  can use system properties that are guaranteed not to have been modified 
 by application
  code (Graal initialization is lazy and may occur after application code 
 has been run).
 
 2. Truffle needs to be able to trigger JVMCI initialization so that it can 
 select the Graal
  optimized implementation of the Truffle runtime.
 
 These capabilities have been added to jdk.vm.ci.services.Services. A 
 comment has
 also been added to this class to denote the current methods to be removed
 in a subsequent bug to update the JDK copy of Graal with the upstream 
 version which
 no longer uses the methods. The methods destined for removal are:
 
 exportJVMCITo(Class requestor)
 load(Class service)
 loadSingle(Class service, boolean required)
 
 The first one is no longer needed as JVMCI exports itself to Graal service 
 providers
 it loads via private API and Graal re-exports[1] JVMCI to any module the 
 extends Graal.
 The latter 2 are no longer required as Graal uses the standard 
 ServiceLoader. This API
 is only useful for JVMCI-8 where a hidden JVMCI class loader is used.
 
 These changes have been tested against upstream Graal. To make the Graal 
 tests pass, 2 extra
 minor changes were required:
 
 1. In JDK-8177663, HotSpotMemoryAccessProviderImpl::checkRead was added 
 and throws IllegalArgumentException
  on all error paths except one which throws AssertionError. The latter was 
 a mistake and has been
  fixed to also throw IllegalArgumentException.
 2. An invalid assertion has been removed from 
 HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo.
  Up to JDK 8, it was true that all classes in java.* packages were loaded 
 by the boot class loader.
  This is no longer true in JDK 9 with classes like java.sql being loaded 
 by platform class loader.
 
 As hinted above, a subsequent bug will be required to pull in the latest 
 upstream Graal and
 remove use of JDK internal API from the jdk.aot module. The qualified 
 exports to
 jdk.vm.internal.compiler and jdk.aot can then be removed.
 
 -Doug
 
 https://bugs.openjdk.java.net/browse/JDK-8177845
 http://cr.openjdk.java.net/~dnsimon/8177845/
 
 [1] 
 http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess
 
 
 
>> 

RE: How to actually ship JSR-250?

[Stephen Felts]

First, I'm not sure that Java EE 8 (corresponding to Java SE 9) will define 
modules.
It seems that the RI will tolerate JDK9 (remove internal JDK API calls) as 
opposed to adopting the new module system.

Since javax.annotation.* classes are now hidden in JDK 9, every project that 
uses these classes will need to ship a copy of these classes.

For a project that is not adopting the module system, these classes will be on 
the classpath.  They can just ship the RI jar file (currently 
glassfish4/glassfish/modules/endorsed/javax.annotation-api.jar) and in JDK9 
endorsed is no longer supported but no longer needed for these classes (that's 
the reason for hiding the classes).
To provide the jax-ws annotations (they seem to live in 
glassfish4/glassfish/modules/endorsed/webservices-api-osgi.jar) also on the 
classpath, it just works.
Both jar files need to be provided by project that uses these annotations and 
added to the classpath directly or indirectly via a manifest classpath.
(As a side note, there are some API's that are not in the endorsed directory 
that will need to be additionally shipped for projects that use them.)

For a project that is adopting the module system, the jar files need to be 
turned into modules with the correct names and the associated module-info.class 
in the root.
Both modules need to be shipped and both jar files need to be in the module 
path or upgrade module path?

If two projects run in the same JVM, one using the classpath and one using the 
module path, the module path wins?




-Original Message-
From: David M. Lloyd [mailto:david.ll...@redhat.com] 
Sent: Thursday, April 20, 2017 9:21 AM
To: Alan Bateman; jigsaw-dev
Subject: Re: How to actually ship JSR-250?

On 04/20/2017 08:18 AM, Alan Bateman wrote:
> On 20/04/2017 13:57, David M. Lloyd wrote:
>
>> Let's say I want to create a module distribution with my own JSR 250 
>> classes.  Let's also assume that I or the spec team want the module 
>> to be named java.annotations.common.
>>
>> How do I properly upgrade the JDK's java.xml.ws.annotation module 
>> such that java.xml.ws can see it, *and* I have my proper 
>> java.annotations.common module name?  Am I forced to ship my 
>> annotations module as java.xml.ws.annotation?  Or manually replace 
>> java.xml.ws with one that looks for my annotations (and where does 
>> that leave the original java.xml.ws.annotation module)?
>>
> java.xml.ws.annotation is upgradable so all you need to do is deploy 
> the compiled form of the following on the upgrade module path:
>
> module java.xml.ws.annotation {
> requires transitive java.annotations.common; }
>
> Separately, I don't know what name that JSR-250 will eventually choose.
> It could be indeed be "java.annotations.common", maybe 
> "java.ee.annotation", maybe something else.

I'm not too worried about that; it has to be decided by the time of Java EE 9 
(obviously) but until then I just want to ensure that it is definitely possible 
to do this, as (unless I missed something) I don't believe that it was 
adequately covered in prior discussions.

--
- DML

hg: jigsaw/jake/jdk: Add @spec JPMS to ThreadInfo::from

[mandy . chung]

Changeset: 31ed261df102
Author:mchung
Date:  2017-04-20 09:00 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/31ed261df102

Add @spec JPMS to ThreadInfo::from

! src/java.management/share/classes/java/lang/management/ThreadInfo.java

hg: jigsaw/jake/hotspot: Dynamic loading of JMX or tool agent into modular application

[alan . bateman]

Changeset: d2c2e33197d2
Author:alanb
Date:  2017-04-20 16:56 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d2c2e33197d2

Dynamic loading of JMX or tool agent into modular application

! src/share/vm/classfile/modules.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiExport.hpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/diagnosticCommand.cpp

hg: jigsaw/jake/jdk: Dynamic loading of JMX or tool agent into modular application

[alan . bateman]

Changeset: ba4e9b37cd44
Author:alanb
Date:  2017-04-20 16:56 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ba4e9b37cd44

Dynamic loading of JMX or tool agent into modular application

! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/Module.java
! src/java.base/share/classes/java/lang/SecurityManager.java
! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java
! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
! src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.java
! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java
! src/java.base/share/classes/jdk/internal/module/Modules.java
! src/java.base/share/classes/sun/launcher/LauncherHelper.java
! src/java.instrument/share/classes/java/lang/instrument/package.html
+ test/com/sun/tools/attach/modules/Agent.java
+ test/com/sun/tools/attach/modules/Driver.java
+ test/com/sun/tools/attach/modules/m/module-info.java
+ test/com/sun/tools/attach/modules/m/p/Main.java

Re: How to actually ship JSR-250?

[David M. Lloyd]

On 04/20/2017 08:18 AM, Alan Bateman wrote:

On 20/04/2017 13:57, David M. Lloyd wrote:


Let's say I want to create a module distribution with my own JSR 250
classes.  Let's also assume that I or the spec team want the module to
be named java.annotations.common.

How do I properly upgrade the JDK's java.xml.ws.annotation module such
that java.xml.ws can see it, *and* I have my proper
java.annotations.common module name?  Am I forced to ship my
annotations module as java.xml.ws.annotation?  Or manually replace
java.xml.ws with one that looks for my annotations (and where does
that leave the original java.xml.ws.annotation module)?


java.xml.ws.annotation is upgradable so all you need to do is deploy the
compiled form of the following on the upgrade module path:

module java.xml.ws.annotation {
requires transitive java.annotations.common;
}

Separately, I don't know what name that JSR-250 will eventually choose.
It could be indeed be "java.annotations.common", maybe
"java.ee.annotation", maybe something else.


I'm not too worried about that; it has to be decided by the time of Java 
EE 9 (obviously) but until then I just want to ensure that it is 
definitely possible to do this, as (unless I missed something) I don't 
believe that it was adequately covered in prior discussions.


--
- DML

Re: How to actually ship JSR-250?

[Alan Bateman]

On 20/04/2017 13:57, David M. Lloyd wrote:

Let's say I want to create a module distribution with my own JSR 250 
classes.  Let's also assume that I or the spec team want the module to 
be named java.annotations.common.


How do I properly upgrade the JDK's java.xml.ws.annotation module such 
that java.xml.ws can see it, *and* I have my proper 
java.annotations.common module name?  Am I forced to ship my 
annotations module as java.xml.ws.annotation?  Or manually replace 
java.xml.ws with one that looks for my annotations (and where does 
that leave the original java.xml.ws.annotation module)?


java.xml.ws.annotation is upgradable so all you need to do is deploy the 
compiled form of the following on the upgrade module path:


module java.xml.ws.annotation {
requires transitive java.annotations.common;
}

Separately, I don't know what name that JSR-250 will eventually choose. 
It could be indeed be "java.annotations.common", maybe 
"java.ee.annotation", maybe something else.


-Alan

How to actually ship JSR-250?

[David M. Lloyd]

Let's say I want to create a module distribution with my own JSR 250 
classes.  Let's also assume that I or the spec team want the module to 
be named java.annotations.common.


How do I properly upgrade the JDK's java.xml.ws.annotation module such 
that java.xml.ws can see it, *and* I have my proper 
java.annotations.common module name?  Am I forced to ship my annotations 
module as java.xml.ws.annotation?  Or manually replace java.xml.ws with 
one that looks for my annotations (and where does that leave the 
original java.xml.ws.annotation module)?


--
- DML

Re: setAccessible() alternative with Jigsaw - feedback on Lookup

[Andrew Dinn]

On 20/04/17 09:52, Alan Bateman wrote:
> On 20/04/2017 07:43, Matej Novotny wrote:
>> Another nasty thing is that the code of course needs to work with
>> both, JDK 9 and 8.
>> While it isn't impossible, it will add a not-so-nice reflection magic
>> layer to the mix.
>>
> Multi-release JARs (JEP 238 [3]) and the ability to compile to older
> releases (JEP 247 [4]) might be useful here (you might know about these
> features already).

Alan is right to point to multi-release JARs as a useful way to solve
this type of problem. However, I managed to bypass this issue in Byteman
simply by hiding the affected code behind a facade (interface) and
dynamically loading either a pre-jdk9 or jdk9+ implementation with all
code bundled into the same jar. So, only one reflective operation was
required (to instantiate the facade class).

n.b. I realise that decoupling the rest of the code from the two
alternative implementations is not necessarily going to be
straightforward and might lead you to prefer the nulti-release jar
approach. In my case the factoring this implied was not too difficult
but it was actually a very useful exercise to go through. It forced me
to clean up a slightly scrappy internal dependency with the *right*
abstraction.

If you are going to have to maintain jdk8 and jdk9 function for some
time then I suspect Alan's route will probably also require you either
to i) introduce some such clean abstraction or ii) go mad maintaining
two slowly diverging sets of classes. So, you might still want to
consider the approach I followed.

Your mileage (or madness) may vary.

regards,


Andrew Dinn
---

Re: setAccessible() alternative with Jigsaw - feedback on Lookup

[Alan Bateman]

On 20/04/2017 07:43, Matej Novotny wrote:


So I did some hacking and tried to make Weld use MethodHandles.Lookup and here 
is a bit of a feedback for you.
But first of all, thanks for your quick advice on how to approach this.

Thank you for writing down your experiences.




So, how did Lookup work for us?

1) privateLookupIn + drop private mode
This was the way to go, as the bean classes can be anywhere (in classes not 
openly accessible to us, especially if we consider modules).
BTW I am not sure about the purpose of the private mode as you always need to 
drop it to be able to use lookup.
This should work fine for existing bean classes as presumably they are 
in the class path or at least not in modules that are strongly 
encapsulated. In the future then if the bean classes are compiled and 
deployed as modules then the owner of the module will have to open the 
packages to at least the library that wants to reflect deeply.


The reason you have to drop the PRIVATE mode is because it is expected 
to be used in the future. JDK-8171335 [1] and JEP 181 [2] provide some 
context as how this could evolve.




2) Lookup approach carries along the need to pass the reference to the base 
lookup class at all times.
This is kind of weird  because in some (not-so-rare) cases, we need to create 
"artificial packages" in which we place proxy classes. For instance when we 
create a proxy for Interger, Map, Principal,...
Ofc we cannot place in into java.* packages, so we create our own. For this to work with 
Lookup, we need to have that package created ahead of time and have a reference to some 
"dummy" useless class inside to be able to do the lookup.
Or is there a way to define a whole new (open by default) package where we could place it 
using Lookup? Having the "dummy" package/class just to use Lookup is lame and 
very error prone (I can think of several ways to break the proxy creation even now).
What is the defining loader of the proxy class that you spin for types 
such as java.lang.Integer? If it's your class loader implementation then 
you can invoke its defineClass method to define the class, your don't 
need a Lookup to an existing class for that scenario.


If you are looking to define a class in a new runtime package and the 
class loader that is not your implementation then you are out of luck. 
Lookup is designed for doing computations in the context of an existing 
class. There is a note in the archives here from John Rose about 
extending the lookup API for cases like this but it would come with a 
lot of complexity. Also there isn't any notion of adding a package to a 
named module at this time. When java.lang.reflect.Proxy spins proxy 
classes then it doesn't add packages to named modules, it instead spins 
the proxy classes into its own module (something you could do too, 
assuming the classes that you are proxying are accessible).




3) All in all the changes carried along a lot of complexity compared to plain 
old ClassLoader.defineClass
We need to create A LOT of Lookups (might present performance overhead, haven't 
tested yet).
Extra care needs to be given to the packages for Lookup not to blow up while we 
in fact don't really care where the proxy lands as long as it is usable.
Can you expand on the "don't really care" comment? Do you mean that you 
don't care about either the defining loader or runtime package?





Another nasty thing is that the code of course needs to work with both, JDK 9 
and 8.
While it isn't impossible, it will add a not-so-nice reflection magic layer to 
the mix.

Multi-release JARs (JEP 238 [3]) and the ability to compile to older 
releases (JEP 247 [4]) might be useful here (you might know about these 
features already).


-Alan.

[1] https://bugs.openjdk.java.net/browse/JDK-8171335
[2] http://openjdk.java.net/jeps/181
[3] http://openjdk.java.net/jeps/238
[4] http://openjdk.java.net/jeps/247

Re: RFR: 8177845: Need a mechanism to load Graal

[Doug Simon]

> On 20 Apr 2017, at 00:31, Vladimir Kozlov  wrote:
> 
> Doug,
> 
> Can you point (link) particular code which needs to be reviewed? And what 
> security issues could be?

I believe Chris had possible concerns with Services.initializeJVMCI() (at 
http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java.udiff.html).
 As previously stated, I can't see any security issues with this method which 
is why it doesn't check JVMCIPermission.

-Doug

> 
> Thanks,
> Vladimir
> 
> On 4/19/17 2:12 PM, Doug Simon wrote:
>>> 3. Services.initializeJVMCI()
> 
 3 is harmless from a security perspective in my opinion.
>>> Would be good if one of Oracle’s security engineers could take a quick look 
>>> just to be sure.
>> Vladimir, can you please bring this to the attention of the relevant 
>> engineer.
>> 

Re: setAccessible() alternative with Jigsaw - feedback on Lookup

[Matej Novotny]

So I did some hacking and tried to make Weld use MethodHandles.Lookup and here 
is a bit of a feedback for you.
But first of all, thanks for your quick advice on how to approach this.

Alright, I should say that I _somehow_ managed to make it work in simple cases 
(SE container for most part).
I haven't tried my dirty solution in anything EE, which is where problems will 
definitely pop-up (as they always do when you say "EAR").
ATM it is pretty impossible to try Weld 3 (will support jdk 9, still not final, 
CDI 2.0 impl) with any AS as none support it ATM (will try to port it to 
Wildfly 11).


To sum up how well Lookup worked for me, let me shed some light on how Weld 
works (simplified ofc) and therefore what I needed to achieve:

In short, we scan CP for classes which are to become beans. Such classes are 
the processed and eventually get a proxy created for them (given they have the 
right scope).
This proxy is a piece of generated bytecode which we need to register via CL, 
or now via Lookup, using defineClass method.
We respect the packages - proxy lands in the same package as the original class 
(with notable exceptions, see below).
All the above has to be done during bootstrap - you cannot dynamically 
add/remove beans once you got application running.


So, how did Lookup work for us?

1) privateLookupIn + drop private mode
This was the way to go, as the bean classes can be anywhere (in classes not 
openly accessible to us, especially if we consider modules).
BTW I am not sure about the purpose of the private mode as you always need to 
drop it to be able to use lookup.

2) Lookup approach carries along the need to pass the reference to the base 
lookup class at all times.
This is kind of weird  because in some (not-so-rare) cases, we need to create 
"artificial packages" in which we place proxy classes. For instance when we 
create a proxy for Interger, Map, Principal,...
Ofc we cannot place in into java.* packages, so we create our own. For this to 
work with Lookup, we need to have that package created ahead of time and have a 
reference to some "dummy" useless class inside to be able to do the lookup.
Or is there a way to define a whole new (open by default) package where we 
could place it using Lookup? Having the "dummy" package/class just to use 
Lookup is lame and very error prone (I can think of several ways to break the 
proxy creation even now).

3) All in all the changes carried along a lot of complexity compared to plain 
old ClassLoader.defineClass
We need to create A LOT of Lookups (might present performance overhead, haven't 
tested yet).
Extra care needs to be given to the packages for Lookup not to blow up while we 
in fact don't really care where the proxy lands as long as it is usable.


Another nasty thing is that the code of course needs to work with both, JDK 9 
and 8.
While it isn't impossible, it will add a not-so-nice reflection magic layer to 
the mix.

Regards
Matej


- Original Message -
> From: "Alan Bateman" 
> To: "Matej Novotny" , jigsaw-dev@openjdk.java.net
> Cc: "Martin Kouba" 
> Sent: Friday, March 31, 2017 4:28:34 PM
> Subject: Re: setAccessible() alternative with Jigsaw
> 
> On 31/03/2017 14:46, Matej Novotny wrote:
> 
> > Hello,
> >
> > I work on Weld, context dependency injection framework.
> > Long story short - we need to generate proxies for classes - bytecode which
> > we then "register" with the class loader using
> > java.lang.ClassLoader#defineClass.
> >
> > Obviously, for this you need reflections - to load java.lang.ClassLoader,
> > then to load the method itself, and most importantly, to make the method
> > accessible cause it's `protected`.
> > In JDK 9, this blows up as soon as you try to make the method accessible
> > (invocation of setAccessible).
> >
> > Fair enough, but what is the "legitimate" alternative?
> > I know I can --add-opens  / --add-opens / --permit-illegal-access
> > But all those just bypass the checks and don't really solve it. I am
> > looking for an intended way to do such stuff.
> > I am pretty sure there are many frameworks which need to do this in one way
> > or the other.
> >
> > So far I have found workarounds which involve using `sun.misc.Unsafe`
> > because there (for some reason) you are allowed to invoke setAccessible().
> > Is this the official intended backdoor? Because it sure does not look any
> > safer/cleaner solution than the original one...
> >
> As Claes pointed out, look at Lookup.defineClass. It shouldn't be too
> hard to imagine a future update of the CDI spec where there a select
> variant that includes a Lookup to the target class with the @Inject
> annotation. When using Weld outside of a container then I think there is
> main code that obtains the WeldContainer and selects the types, that
> might be a suitable place to extend to provide the Lookup to the library.
> 
> MethodHandles.privateLookupIn might also be useful to know