Problems building with --release=8

[Jonathan Gibbons]

On 1/17/18 9:56 AM, David Lloyd wrote:
> 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.
Thanks for the update/correction.
>
>>> 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.