Problems building with --release=8
David Lloyd
david.lloyd at redhat.com
Wed Jan 17 17:56:34 UTC 2018
On Wed, Jan 17, 2018 at 11:49 AM, David Lloyd <david.lloyd at redhat.com> wrote:
> On Wed, Jan 17, 2018 at 11:43 AM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>> On 1/17/18 9:37 AM, David Lloyd wrote:
>>
>>> I'm trying to create some MR JARs for projects which use
>>> sun.misc.Unsafe and sun.reflect.ReflectionFactory (both of which exist
>>> in the jdk.unsupported module). For the Java 8 portion, I'm
>>> attempting to move from using the Java 8 javac to Java 9 (or later).
>>> However I'm running into a problem where these classes are not
>>> available when I compile with --release=8.
>>>
>>> As a workaround, I created a JAR which stubbed these two classes and
>>> included it on the compile class path. However, it seems that they
>>> were actively filtered out or ignored somehow. Removing --release=8
>>> and just using -source 8 -target 8 allowed the compilation to succeed,
>>> however I want to be sure that no 9+ classes sneak into the 8 part so
>>> I want to use --release=8 if possible.
>>>
>>> If jdk.unsupported is allowed for Java 9+, then surely these two
>>> classes should be included in the Java 8 image.
>>>
>>> Did I make some kind of mistake or is this a legitimate bug?
>>
>>
>> It doesn't sound like you made a mistake, but this is not a bug.
>> Generally, the spec for --release N is to provide access to the
>> public documented API for JDK N.
>
> I'm on board with that, however it is also preventing me from adding
> my own sun.misc etc. on the class path. Surely _that_ is a bug?
Never mind, this was my mistake, a typo in my build file. So, the
stub-JAR solution is working OK for me.
>> That being said, there has been discussion recently about providing
>> access to some of the API that precedes jdk.unsupported, as a special
>> case.
>
> That would be nice.
--
- DML
More information about the compiler-dev
mailing list