Use of javc --release option with JavaFX

[Jan Lahoda]

Hi,

for --release <= 8, the historical data used by --release contain class 
for the default javac bootclasspath for OpenJDK, which does not include 
JavaFX.

For --release >= 9, this will probably need to be different (currently, 
--release 9 is supposed to include JavaFX if JavaFX is in the runtime 
image).

Jan

On 5.10.2017 18:32, mandy chung wrote:
> Jan and Jon can comment on the javac --release 8 behavior (which I think
> it may expect to place jfxrt.jar from JDK 8 runtime).
>
> On the other hand, I think JDK 10 javac should accept --release 9 when
> compiing this test since JavaFX modules are linked in the image.  I
> created https://bugs.openjdk.java.net/browse/JDK-8188823 to follow up
> this issue.
>
> Mandy
>
> On 10/4/17 9:17 PM, Matthew wrote:
>> How exactly should the new release flag work when JavaFX is used.
>> Consider the following very simple (and not very useful) class
>> (Testing.java)
>>          import javafx.application.Application;
>>          public class Testing {            public static void
>> main(String... args) {}        }
>> This compiles perfectly fine under (Oracle's release of) JDK 8 using
>> the command
>>          javac Testing.java
>> and compiles just fine under JDK9 using the same command.  However
>> when trying to target java 8 with JDK9 using
>>          javac --release 8 Testing.java
>> it results in an error
>>          Testing.java:1:error: package javafx.application does not exist
>> I have tried using the --add-modules option to include the JavaFX
>> modules, but this flag does not work with release 8 targeted.  It does
>> work if the jfxrt.jar file from the JDK8 directory is explicitly added
>> to the classpath.  However, this requires us to have that file around,
>> and thus have a second version of the JDK installed.
>> Is this the desired behavior?  I know that the release flag should
>> release us from needing to set the bootclasspath to the desired rt.jar
>> file, but should something that compiles fine under JDK8 and JDK9 with
>> no extra jars (or even command line flags) needed require an extra jar
>> when targeting java 8?
>