IllegalAccessError even when -XaddExports adds ALL-UNNAMED to the reported module/package

Sat Dec 5 09:03:06 UTC 2015

Thanks, that was it.

I must say that the command line got big pretty fast, since I had to export
several packages.

How about having to possibility of adding an export to all packages in a
module?
-XaddExports:jdk.compiler/*=ALL-UNNAMED
On Dec 4, 2015 2:48 AM, "Jonathan Gibbons" <jonathan.gibbons at oracle.com>
wrote:

> Roel,
>
> To understand the problem, you need to understand something of how javac
> works.
>
> javac is a Java program, and as such it is composed of a set of modules
> that run in a JVM. The primary module is jdk.compiler, and if you follow
> the dependencies, you'll see it references java.compiler, and of course
> java.base.   Call that the "execution environment".
>
> Now, the function of javac is to analyze and compile source code, which
> exists in a conceptually separate collection of modules. It will typically
> be uncommon for the compiled code to depend on javac's modules, like
> jdk.compiler and java.compiler, and will likely depend on its own modules,
> specified on the module path provided to javac.  All modules depend on
> java.base, but there is no requirement or assumption that the version of
> the java.base module being referenced by the code being compiled is the
> same version of java.base being used by javac code itself.  Wind the clock
> forward a few years, and imagine running javac on JDK 10, compiling code to
> run on JDK 9. Just as on JDK 8, we recommend setting the bootclasspath when
> compiling code for earlier versions of JDK, in future, we will recommend
> that you specify the set of system modules appropriate to your setting of
> -target.  All of which is to say that the set of modules used by javac to
> analyze and compile your program is conceptually distinct from the set of
> modules being used to execute javac itself.  Call this new set of modules
> the "compilation environment".
>
> Now consider javac options like -modulepath, -modulesource path and so on.
> These affect the compilation environment. So too does the javac
> -XaddExports option.   When you specify -modulepath to javac, you are
> making additional modules available for use by the code being compiled.
> When you specify -XaddExports to javac, you are instructing javac to make
> some specific packages visible to code in other modules that would not
> otherwise be able to do so.  Neither of these options affect the
> configuration of modules in the JVM being used to execute javac itself.
> The same is true for all other module-related options for javac.
>
> Now consider an annotation processor. Annotation processors are like
> plugins or extensions to javac. As such, they run in the same JVM as javac,
> and more specifically, in the same execution environment as javac. (Not
> 100% true, but close enough for now.)  So, using "javac -XaddExports" will
> not have any direct effect on an annotation processor, because javac
> -XaddExports affects the compilation environment available to the
> annotation processor, not the execution environment in which it will be
> running.
>
> So how do you affect the execution environment used to execute javac and
> any annotation processors that you specify?
>
> You need to pass -XaddExports not to javac but to the underlying runtime.
> The standard practice for all JDK tools invoked from the command line is
> (and has long been) that options prefixed with -J are passed to the
> underlying runtime.  And so, in this case, if you are running javac from
> the command line, you need a command like
>
> $ javac
> -J-XaddExports:jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED -cp
> lombok.jar Test.java
>
>
> Here's a different way of looking at it.   javac is "just" a Java program,
> and so running "javac args" is equivalent to executing the following
> command:
>
> $ java   ...some.options...  com.sun.tools.javac.Main  args
>
> So when you specify "javac -XaddExports" the effective command is
>
> $ java   ...some.options...  com.sun.tools.javac.Main -XaddExports...  args
>
> But if you want to affect javac's execution environment, the command you
> really want is
>
> $ java   ...some.options... -XaddExports... com.sun.tools.javac.Main args
>
> i.e. you want -XaddExports passed to the java command, not to the javac
> command.  That is what "javac -J-XaddExports..." does.
>
>
> -- Jon
>
>
>
>
>
> On 12/03/2015 03:26 PM, Roel Spilker wrote:
>
>> Hi,
>>
>> I have a problem using -XaddExports in jigsaw build 94. This is the first
>> build I tried so I don't know if the problem also occurs in earlier
>> versions.
>>
>> In Lombok we use unsupported internal APIs (yes at our own risk)
>>
>> After reading the instructions on http://openjdk.java.net/jeps/261
>> "Breaking encapsulation" I've added the -XaddExports flag. The exception I
>> got luckily gave me the module name as well as the package to export.
>> However I still got the same exception (details below).
>>
>> Am I doing something wrong (apart from using unsupported internal APIs)?
>> Is
>> the exception wrong?
>>
>> Roel
>>
>>
>>
>> $ java -version
>> java version "1.9.0-ea"
>> Java(TM) SE Runtime Environment (build
>> 1.9.0-ea-jigsaw-nightly-h403-20151201-b94)
>> Java HotSpot(TM) 64-Bit Server VM (build
>> 1.9.0-ea-jigsaw-nightly-h403-20151201-b94, mixed mode)
>>
>>
>>
>>
>> $ javac
>> -XaddExports:jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED -cp
>> lombok.jar Test.java
>>
>>
>> An annotation processor threw an uncaught exception.
>> Consult the following stack trace for details.
>> java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (in
>> module: Unnamed Module) cannot access class
>> com.sun.tools.javac.processing.JavacProcessingEnvironment (in module:
>> jdk.compiler), com.sun.tools.javac.processing is not exported to Unnamed
>> Module
>>          at lombok.javac.apt.LombokProcessor.init(LombokProcessor.java:84)
>>          at
>>
>> lombok.core.AnnotationProcessor$JavacDescriptor.want(AnnotationProcessor.java:87)
>>          at
>> lombok.core.AnnotationProcessor.init(AnnotationProcessor.java:141)
>>          at
>>
>> lombok.launch.AnnotationProcessorHider$AnnotationProcessor.init(AnnotationProcessor.java:53)
>>          at
>>
>> com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.<init>(jdk.compiler at 9.0
>> /JavacProcessingEnvironment.java:669)
>>          at
>>
>> com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(jdk.compiler at 9.0
>> /JavacProcessingEnvironment.java:766)
>>          at
>>
>> com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(jdk.compiler at 9.0
>> /JavacProcessingEnvironment.java:857)
>>          at
>>
>> com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2100(jdk.compiler at 9.0
>> /JavacProcessingEnvironment.java:104)
>>          at
>>
>> com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(jdk.compiler at 9.0
>> /JavacProcessingEnvironment.java:1183)
>>          at
>>
>> com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(jdk.compiler at 9.0
>> /JavacProcessingEnvironment.java:1291)
>>          at
>> com.sun.tools.javac.main.JavaCompiler.processAnnotations(jdk.compiler at 9.0
>> /JavaCompiler.java:1247)
>>          at com.sun.tools.javac.main.JavaCompiler.compile(jdk.compiler at 9.0
>> /JavaCompiler.java:921)
>>          at com.sun.tools.javac.main.Main.compile(jdk.compiler at 9.0
>> /Main.java:261)
>>          at com.sun.tools.javac.main.Main.compile(jdk.compiler at 9.0
>> /Main.java:143)
>>          at com.sun.tools.javac.Main.compile(jdk.compiler at 9.0
>> /Main.java:56)
>>          at com.sun.tools.javac.Main.main(jdk.compiler at 9.0/Main.java:42)
>>
>
>