Weird use case: compiling against dummy sun.misc.* class

[Alex Buckley]

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
>