Re: Weird use case: compiling against dummy sun.misc.* class
On 05/20/2016 07:13 PM, Alan Bateman wrote: > On 20/05/2016 16:55, Aleksey Shipilev wrote: > jcstress is boot loader so I assume multi-release JARs are out of the > question? Yes, a simple workaround would be better than doing MR JARs at this point. We have >50 Mb JARs as it is, MR JARs would be at least twice as that if we ship JDK <=8 and JDK >=9 classes in the same package. > So what is the javac command that you are using? If you are compiling > sun/misc/Contented.java then I would expect to see `javac > -Xmodule:jdk.unsupported` so that it is compiled "as if" part of the > jdk.unsupported module. -Xmodule:jdk.unsupported definitely works, thanks! What are the drawbacks for enabling this? I can easily enable that globally for the entire project, but that would compile all project files as if in the jdk.unsupported module? I guess that does not matter if I don't produce/deploy the module as the build artifact. (Aside: by reading the javac source code, I discovered -XDnoModules, which also works, but hidden, unsupported, fragile, and scary) Thanks, -Aleksey
Re: Weird use case: compiling against dummy sun.misc.* class
If you have your own sun.misc.FOO on the classpath, then you DON'T want a module exporting sun.misc to be readable, because that module is where javac and the runtime will get sun.misc.* types from. So, no need to add readability of the jdk.unsupported module which is not read by default on JDK 9b118. javac "should" be observing your sun.misc.Contended type out of the box -- there may be a javac bug or some other problem with how javac is invoked, please send more details. I assume that the jdk.internal.annotations package exists in java.base so at run time you'll need to -Xpatch your jdk.internal.annotations.Contended type into java.base. Alex On 5/20/2016 8:55 AM, Aleksey Shipilev wrote: Hi, I have a weird use case in jcstress around @Contended. In order to support both JDK 8 and JDK 9 we build against *our own* sun.misc.Contended and jdk.internal.annotations.Contended. This works arguably well for both compiling and running with both JDK 8 and JDK 9: the real annotation gets picked up from the JDK. However, since JDK 9b118 we cannot build anymore, because: LongResult1_jcstress.java:[3,13] error: Contended is not visible because package sun.misc is not visible ...even though sun/misc/Contended.java is right here in my source tree. Is there a magic incantation to make javac proceed? The usual tricks did not help (probably because the target class is not in jdk.unsupported, but rather in the source tree itself): -addmods jdk.unsupported -XaddExports:jdk.unsupported/sun.misc=ALL-UNNAMED -XaddReads:jdk.unsupported=ALL-UNNAMED Thanks, -Aleksey
Re: Weird use case: compiling against dummy sun.misc.* class
On 20/05/2016 16:55, Aleksey Shipilev wrote: Hi, I have a weird use case in jcstress around @Contended. In order to support both JDK 8 and JDK 9 we build against *our own* sun.misc.Contended and jdk.internal.annotations.Contended. This works arguably well for both compiling and running with both JDK 8 and JDK 9: the real annotation gets picked up from the JDK. However, since JDK 9b118 we cannot build anymore, because: LongResult1_jcstress.java:[3,13] error: Contended is not visible because package sun.misc is not visible ...even though sun/misc/Contended.java is right here in my source tree. Is there a magic incantation to make javac proceed? The usual tricks did not help (probably because the target class is not in jdk.unsupported, but rather in the source tree itself): -addmods jdk.unsupported -XaddExports:jdk.unsupported/sun.misc=ALL-UNNAMED -XaddReads:jdk.unsupported=ALL-UNNAMED jcstress is boot loader so I assume multi-release JARs are out of the question? So what is the javac command that you are using? If you are compiling sun/misc/Contented.java then I would expect to see `javac -Xmodule:jdk.unsupported` so that it is compiled "as if" part of the jdk.unsupported module. -Alan
