Do we need Java 11 migration? #5750
Comments
|
If it is welcome, happily the JDK and I are good friends so I'm hoping to address this issue with at least a draft PR this weekend to get the ball rolling. That said, I suspect though that this may require some discussion and testing as these changes are going to cut a bit deep if we take them on. It is also worth noting that lambda has gotten a bit more traction in the broader java community since its original introduction and, since this may provide a good opportunity to revisit, I love to pick up #3054 after this gets a bit more sorted... |
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.
|
This will require a move to OpenJDK anyway - there are no free Oracle LTS releases. But, it's also true that this only affects the Oracle build - OpenJDK 8 is not being EOL'd. It might be worth migrating to the AdoptOpenJDK 8 build prior to any move to Java 11? https://adoptopenjdk.net |
|
Thanks @sampottinger. The “official” word is this section of the platforms page. The short version is that I've not had time to work on it, and most people on here are lecturing me about how important it is, and how it should be done, rather than doing anything about it. Really appreciate you taking a look into fixing some of the issues. It's a huge step, especially for a project this complex. |
|
Hello @benfry! Really happy to help. For some quick background, I just started a 6 month sabbatical to work on open source / open data (I'm gonna be turning a lot of public PDFs into spreadsheets). So, I've got a few months to try to dig into some things a bit more deeply. If it is ok with you, I really would love to spend some time contributing here and to p5.js. Hey @neilcsmith-net! I think that's a very good point and I have been looking into OpenJDK8 as well. I'd normally agree with you on orthogonalizing these changes but I'd like to post a bit more on that today / tomorrow (hopefully with some more concrete experimentation with OpenJDK8 in a PR). To kinda preview that though... We are seeing some bifurcation already in the broader community outside the JDK. That doesn't mean we should jump right to OpenJDK11 but, doing some looking around, I think there are a few points to consider that might counterintuitively make a case for at least considering it. Separately, I just posted a OpenJDK11 POC working on Mac and I am trying to sort out Linux. I don't have access to a windows machine presently though... Is anyone out there with Windows super excited to try some JDK plumbing with me? |
|
@sampottinger there is very little, if any, work required to switch over to OpenJDK 8 - possibly just removing the warning in PDE. I have numerous users using Processing core in PraxisLIVE on Mac and Windows with OpenJDK 8 (whether they know it or not 😄). Switching to this for Processing and PDE as a whole might throw up a few minor issues, but they're things that are likely to need fixing in the move to OpenJDK 11 too! That would give some leeway then for some modifications to Processing needed for the adventurous amongst us to start testing and reporting issues. I'm not entirely sure what the license redistribution situation is for Oracle Java 8 from the end of this month - it's possible it's no longer allowed. My 2c anyway. |
As part of processing#5750, added support for AdoptOpenJDK (also required for - OracleDownloadUrlGenerator - AdoptOpenJdkDownloadUrlGenerator which support Downloader. Tests and documentation included (required refactor of build.xml).
|
Hey @neilcsmith-net, thanks for the response! I do certainly see the logic. Review below...
I think there might be a curse of a long tail here. Doing some testing on #5753, there's a lot that's working again but the Processing documentation seems to suggest there's some stuff that still needs addressing.
A cursory reading of the license doesn't look like there's a sunset but can't be sure. In general, I agree that moving to OpenJDK is generally a (very) good idea. I may fork or repurpose #5753 to tackle OpenJDK8 first (and I'll post some more commentary on that shortly). That said, in the meantime, I just tackled some stuff in the build chain (see 79f6353) which is required for either. Progress! |
As part of processing#5753 and processing#5750, working AdoptOpenJDK released java on Elementary Linux 5.0 (Juno, 64bit). Linux 4.15.0-36-generic. Tested with Java 11. JDK downloads working and PDE runs but sketches wont execute due to broken java path.
As part of processing#5750 / processing#5753, example sketch and PDE running in Linux with Elementary 5.0 (Juno, 64bit). Linux 4.15.0-36-generic. Specifically, resolved issue with java path on linux given new JDK structure.
As part of processing#5750 and processing#5753, have the development environment and example sketch working in Windows 64 bit with some display issues in the IDE in particular. This is using AdoptOpenJDK 11 with Windows 10.
As part of processing#5753 / processing#5750, remove deprecated com.apple.eawt calls made in the core module. Specifically, respond to (JEP 272)[http://openjdk.java.net/jeps/272] which is generating warnings on sketch run and may cause failure in future JDKs.
Sync to master processing while working on processing#5753 / processing#5750
As part of processing#5753 / processing#5750, migrates base 64 binary image data loading away from java.xml.bind as Java 11 has removed the deprecated module [JEP 320](As part of processing#5753 / processing#5750).
As part of processing#5753 and processing#5750, migrated the preprocessing service to use the jmod for java base. Will refactor out this logic to support other jmods shortly with some code clean up and tests. All of this allows our use of the JDT to work without rt.java which was removed as part of Jigsaw. Please see JEP 220 and JEP 261.
Refactored java build for testing in java mode related to processing#5753 / processing#5750.
As part of processing#5753 / processing#5750's support for jmod (Jigsaw) and new OpenJFX structure, finished the refactor to pdex.util.runtime which increases testability and (hopefully) readability of runtime formulation now that Java 11 has made it slightly more complex.
Added tests and javadoc for classpath and module path formulation logic related to processing#5753 / processing#5750 including support for jmod (Jigsaw) and OpenJFX. This only includes non-composite strategies (not RuntimePathFactoryStrategyCollection) which will be addressed in a later commit.
Finished pdex.util.runtime.* for processing#5753 / processing#5750 which adds support for restructured modules (Jigsaw) and OpenJFX.
Squash port of sampottinger:java11 on processing train with a number of sub-changes, resolving processing/processing#5750 in the processing4 train. Original message below. Moves to OpenJDK11 as part of #5750. There's lots in here so a quick rundown of the bigger stuff... **Primary required changes:** Some changes directly support OpenJFX / OpenJDK 11: - Response to image loading changes caused by [JEP 320](https://openjdk.java.net/jeps/320) - Use of jmodules as necessitated by [JEP 261](https://openjdk.java.net/jeps/261) - Reponse to largely changed file paths caused by [JEP 220](https://openjdk.java.net/jeps/220). - Modifications in build system related to AdoptOpenJDK and Java 11 which have a different naming structure for downloads. - Allowing use of non-Oracle Java within internal Processing checks. **Secondary required changes:** There were some secondary required changes that impacted the usability of Processing after having moved to OpenJFX / OpenJDK 11: - Removal of com.apple.eawt calls related to [JEP 272](http://openjdk.java.net/jeps/272) - Response to HiDPI support on Windows and Linux in [JEP 263](https://openjdk.java.net/jeps/263) - Removal of `java.ext.dirs`. Would be forced by [JEP 220](http://openjdk.java.net/jeps/220). - Due to bugs on Windows, updated the JNA jars. - Changes in downloader build tasks to support AdoptOpenJDK and OpenJFX. - Updated org.eclipse.* / equinox jars. - Some optimization around size of distribution. - Update of AppBundler. - Some changes in formulation of classpath and modifications in PreprocessingService given [JEP 261](https://openjdk.java.net/jeps/261). **Incidental changes:** This was (ahem) a bit of a larger PR with the above modifications. So, I wanted to introduce automated tests when possible and convenient along with a few changes for platform sustainability in order to support development: - Addition of cross-building capability (!) made possible by AdoptOpenJDK. - Addition of mockito for testing. - Upgrade of junit. - Addition of ant-contrib. - Standardized nomenclature around JRE / JDK in `build/build.xml` - Deduplication of code in `jre/build.xml`. - Addition of JavaDoc in a few places. - Some refactoring of PImage / Shape to support increased testing and readability in image manipulation code.
|
Closing now that development has moved to https://github.com/processing/processing4 |
Hey friends! Thank you for a beautiful community and tool. Sorry I couldn't quite fit this in the prescribed format but hopefully this helps...
I'm writing because it's January and, unfortunately, Java 8 is slated to stop receiving public updates this month (article, roadmap, Oracle blog post) so we're nearing a kind of EOL for Java 8. I'd love to help with the Java 11 migration if that's a thing we want to do and have started preparing a pull request. However, I wanted to first enumerate the (ahem) exciting growth opportunities presented by moving to JDK 11 to see if this resonates with the other developers here. With that, Oracle have been busy...
Changes to the runtime structure
Moving on from Java 8, there were a number of changes in fundamental runtime structures:
Changes to the licensing
Java 11's official Oracle JDK release changes licensing. As far I can tell, it's a bit complicated but generally seems to require a commercial license to use Java in "production" settings (helpful walkthrough, entertaining walkthrough, Oracle blog). I think Proceessing intended core to be LGPL so that the resulting builds could be used in a permissive way but, if bundling with the Oracle release, this could be complicated. I know this been a topic of discussion before (#4415) but this may require movement to OpenJDK to continue accomplishing permissive licensing goals.
JavaFx
As discussed here before (#5286), JavaFx has had a number of API modifications and is also being removed from non-commercial JDK release starting with JDK 11. OpenFX is a thing now (it still is official OpenJDK) but the bundling will need to change.
Other Misc Changes
There's a few other bits that I think might require some attention:
The Upside
Well... silver linings... There's a lot of cool new features in Java 11 and it is LTS...
The text was updated successfully, but these errors were encountered: