-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Java 11 incompatibilities inside PSurfaceFX #5286
Comments
@benfry Do you known if there is a way to use the current one on jre 8 and a different code when running on jre 9? I don't think there is a solution which would work on both. |
Hm, good question. Not that I know of. We could use reflection (harkening back to the bad old days of Processing 1.x where we had to do this heavily b/c of Java version issues like this), but I think it'd be a matter of making the move to Java 9 and not looking back. For now, that means it probably has to be done in a branch. It's not a high priority, it's more the inevitability of having to move to Java 9. The macOS side is a mess because they've deprecated/removed all the OS integration stuff that made things work properly but only half-replaced it. |
*shakes fist at sky* |
Be aware that under Oracle's new 6-monthly Java release plan, Java 8 is an LTS, but Java 9 is not! So the move to Java 9 might not be inevitable - sticking to Java LTS releases might be a good thing for Processing? |
@JakubValtar btw, in answer to your question earlier, multi-release JARs in 9 are theoretically the way to handle that http://openjdk.java.net/jeps/238 |
No plans to upgrade to a non-LTS version, so I think we'll be skipping 9. Their roadmap is a clown show. https://github.com/processing/processing/wiki/Supported-Platforms#java-9 |
@benfry good to know you're sticking with LTS as mentioned earlier - that's one rabbit hole I don't want to follow you down - we're having enough fun getting a stable Apache NetBeans on 9! Still, when you do decide to go to 11 (with suitable Spinal Tap codename obviously! 😄) the multi-release JAR's might be handy unless you plan to do everything in one go. Personally, I and every other Java dev I've spoken with about it think the new roadmap is a massive plus! |
Renaming since we're skipping Java 9. |
Just FYI JavaFX is slated to be removed from the main distribution starting from Java 11 (the next LTS release) and will be available separately. Tbh I have no idea what Oracle is doing here. https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates |
Focusing first on getting "hello world" applications running under Java 11, this initial migration works for Mac OS X (10.14.1). There are a number of issues and warnings still to address so the overall PR remains WIP. Specific modifications to address processing#5750: - Modification in build system to address a unified JDK / JRE. - Modification in build system and application code to deal with version naming convention migration. - Modification of OS X specific system paths changed by Java 11. - Migration to OpenJDK (processing#4415) via AdoptOpenJDK (selected due to long term build support and some vendor independence). - Migration to OpenJFX (processing#5286). - Removal of deprecated `java.ext.dirs` (replacement funcationality is still being explored). - Update to the appbundler fork. - Update to the JDT jars. Documentation is still incomplete as is reaching feature parity on mac as well as testing on other OS'. Please don't merge yet.
Focusing first on getting "hello world" applications running under Java 11, this initial migration works for Mac OS X (10.14.1). There are a number of issues and warnings still to address so the overall PR remains WIP. Specific modifications to address processing#5750: - Modification in build system to address a unified JDK / JRE. - Modification in build system and application code to deal with version naming convention migration. - Modification of OS X specific system paths changed by Java 11. - Migration to OpenJDK (processing#4415) via AdoptOpenJDK (selected due to long term build support and some vendor independence). - Migration to OpenJFX (processing#5286). - Removal of deprecated `java.ext.dirs` (replacement funcationality is still being explored). - Update to the appbundler fork. - Update to the JDT jars. Documentation is still incomplete as is reaching feature parity on mac as well as testing on other OS'. Please don't merge yet.
Focusing first on getting "hello world" applications running under Java 11, this initial migration works for Mac OS X (10.14.1). There are a number of issues and warnings still to address so the overall PR remains WIP. Specific modifications to address processing#5750: - Modification in build system to address a unified JDK / JRE. - Modification in build system and application code to deal with version naming convention migration. - Modification of OS X specific system paths changed by Java 11. - Migration to OpenJDK (processing#4415) via AdoptOpenJDK (selected due to long term build support and some vendor independence). - Migration to OpenJFX (processing#5286). - Removal of deprecated `java.ext.dirs` (replacement funcationality is still being explored). - Update to the appbundler fork. - Update to the JDT jars. Documentation is still incomplete as is reaching feature parity on mac as well as testing on other OS'. Please don't merge yet.
Updating title since Java 10 is already gone… |
Fixed with benfry/processing4#1 and continued development happening at https://github.com/processing/processing4 |
Several methods that we're using are no longer available in JavaFX:
Screen
class:getRenderScale()
,getUIScale()
KeyCode
class:impl_getChar()
andimpl_getCode()
The text was updated successfully, but these errors were encountered: