Build with Java 8

[doompadee]

It would be nice if the latest Ikonli release would support older Java versions as well. Java 8 is still very commonly used. Or is there a technical reason Java 11 is required?

With newer Java versions one can use the "--release" compiler option to produce compatible classes.

[aalmiray]

The problem lies in the implementation of the FontIcon class. It requires access to CSS support classes that are private in JKD 8, but were moved to a different package and made public in JDK 9+. We had a MRJAR build (which did not produce all desired results) for a while before scrapping the whole thing and opting for biting the bullet and go with Java11 as a minimum.

There are 3 options at hand:

1. Keep the project Java 11+. Sorry Java 8, we have to say goodbye to you at some point.
2. Update the build to produce separate Java 8 and Java 11+ artifacts.
3. Update the build to produce Java 8/11+ compatible artifacts using MRJARs.

Option 1 is the path of least resistance from the builders POV, however consumers become affected because either the use an older version compatible with Java 8 (thus lacking new features and packs) or forcibly upgrade to Java 11+.

Option 2 can be tricky as the following changes are required:

• compile code with -release.
• 2 different versions of the FontIcon class.
• 2 different codebases as module-info.java should be skipped from the Java 8 artifacts.
• 2 different sets of artifacts. You'd have to pay attention to version numbers to figure out which one should be used (we tried classifiers, not a good idea either).

Option 3 is similar to 2 but the codebase split may be managed with a MRJAR layout.

Granted, when we tried building MRJARs in the past we didn't have any support from Gradle to make it easy, nowadays we have access to https://github.com/java9-modularity/gradle-modules-plugin which might makes things easier.

[doompadee]

Thanks much for the very detailed feedback!

The API requirement is just for the JavaFX artifact? I was initially looking at the Swing offering. But if you already made a conscious decision about upgrading to a newer Java version, than that's what it is. It's probably not too difficult to produce a compatible version if I shouldn't be able to lift the Java version.

[aalmiray]

Yes, this is indeed a restriction imposed by the JavaFX artifact. Swing could be used with any version above if it were compiles with Java 8. Perhaps that's the key, compile all modules (except ikonli-javafx) with Java 8. This would require using modiTect to generate module information or package icon packs as MRJARs.

[RalphSteinhagen]

There are some discussions on ControlsFX: controlsfx/controlsfx#1195

@aalmiray Is there any chance to reconsider and to release two binary jars? One for JDK8 and the other for JDK11? We, unfortunately, live in an imperfect world between JDK8/11 ... Would be much appreciated! grin

[jaychewitt]

I have an issue compiling my JavaFxProject to an executable Jar. the jar is created but when I run the jar file in intellij i get the following error:

`Mar 18, 2021 3:04:57 PM com.sun.javafx.application.PlatformImpl startup
WARNING: Unsupported JavaFX configuration: classes were loaded from 'unnamed module @4fab64ed'
Exception in Application start method
Exception in thread "main" java.lang.RuntimeException: Exception in Application start method
at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:900)
at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
at java.base/java.lang.Thread.run(Thread.java:831)
Caused by: javafx.fxml.LoadException:
file:/C:/Users/Lit/Desktop/Application/Java/out/artifacts/Java_jar/Java.jar!/montransfer/montransfer.fxml:20

at javafx.fxml.FXMLLoader.constructLoadException(FXMLLoader.java:2707)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2685)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2548)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:3323)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:3280)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:3249)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:3222)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:3199)
at javafx.fxml.FXMLLoader.load(FXMLLoader.java:3192)
at montransfer.Main.start(Main.java:16)
at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:846)
at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474)
at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446)
at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
... 1 more

Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at com.sun.javafx.fxml.BeanAdapter.put(BeanAdapter.java:262)
at com.sun.javafx.fxml.BeanAdapter.put(BeanAdapter.java:54)
at javafx.fxml.FXMLLoader$Element.applyProperty(FXMLLoader.java:522)
at javafx.fxml.FXMLLoader$Element.processValue(FXMLLoader.java:372)
at javafx.fxml.FXMLLoader$Element.processPropertyAttribute(FXMLLoader.java:334)
at javafx.fxml.FXMLLoader$Element.processInstancePropertyAttributes(FXMLLoader.java:244)
at javafx.fxml.FXMLLoader$ValueElement.processEndElement(FXMLLoader.java:777)
at javafx.fxml.FXMLLoader.processEndElement(FXMLLoader.java:2924)
at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2639)
... 17 more
Caused by: java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at com.sun.javafx.fxml.ModuleHelper.invoke(ModuleHelper.java:100)
at com.sun.javafx.fxml.BeanAdapter.put(BeanAdapter.java:258)
... 25 more
Caused by: java.lang.UnsupportedOperationException: Cannot resolve 'fth-x'
at org.kordamp.ikonli.AbstractIkonResolver.resolve(AbstractIkonResolver.java:61)
at org.kordamp.ikonli.javafx.IkonResolver.resolve(IkonResolver.java:69)
at org.kordamp.ikonli.javafx.FontIcon.setIconLiteral(FontIcon.java:235)
... 31 more`

[jaychewitt]

I am using Java 16 with OpenJFX 16. in intellij I created a normal JavaFX project and it worked fine and with another project with the ikonli icons I got the error i posted early.

CAN I GET SOME HELP PLEASE!!!!!!!!!!!

[aalmiray]

1. This looks like a different issue than the original one, that is, running an application with Java 8 and Ikonli.
2. Latest Ikonli (12.x) only works with JavaFX 11 an upwards.
3. Running JavaFX with Ikonli in a single JAR in the classpath require merging all service files found in /META-INF/services. Use the Maven shade plugin or the Gradle shadow plugin to create a shaded JAR.
4. Running a single JAR in the modulepath requires more work, as you'd need to shade al dependencoies and craft an aggregating module-info.java that exposes all required services.

[jaychewitt]

The project i created wasn't created using maven. Can i still use maven i am using intellij

…

On Thu, Mar 18, 2021, 3:20 PM Andres Almiray ***@***.***> wrote: 1. This looks like a different issue than the original one, that is, running an application with Java 8 and Ikonli. 2. Latest Ikonli (12.x) only works with JavaFX 11 an upwards. 3. Running JavaFX with Ikonli in a single JAR in the classpath require merging all service files found in /META-INF/services. Use the Maven shade plugin or the Gradle shadow plugin to create a shaded JAR. 4. Running a single JAR in the modulepath requires more work, as you'd need to shade al dependencoies and craft an aggregating module-info.java that exposes all required services. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#44 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARTJHQYPWOPGW7WBQUOK2L3TEJOA7ANCNFSM4GUA6DGQ> .

[aalmiray]

The same rules apply. Running the application from the IDE (using a run configuration) should put all required dependencies in the runtime classpath, the service files should be found. Running the JAR from the IDE requires all dependencies to be available. Either you add a Class-Path: manifest entry to the application' JAR manifest AND include all dependencies as value AND ensure all dependency JARs are physically located where the manifest will find them, OR shade the application JAR. It might be possible to use the IDE to create a shaded JAR, I have no idea as I prefer to use command line tools to build projects. Pick either Maven or Gradle.

[jaychewitt]

Ok am going to try something. Hope it works

…

On Thu, Mar 18, 2021, 3:32 PM Andres Almiray ***@***.***> wrote: The same rules apply. Running the application from the IDE (using a run configuration) should put all required dependencies in the runtime classpath, the service files should be found. Running the JAR from the IDE requires all dependencies to be available. Either you add a Class-Path: manifest entry to the application' JAR manifest *AND* include all dependencies as value *AND* ensure all dependency JARs are physically located where the manifest will find them, *OR* shade the application JAR. It might be possible to use the IDE to create a shaded JAR, I have no idea as I prefer to use command line tools to build projects. Pick either Maven or Gradle. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#44 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARTJHQ7XQHZP4YRD34623LLTEJPMNANCNFSM4GUA6DGQ> .