Skip to content
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

Do we need Java 11 migration? #5750

Open
sampottinger opened this issue Jan 12, 2019 · 6 comments

Comments

@sampottinger
Copy link

commented Jan 12, 2019

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...

@sampottinger

This comment has been minimized.

Copy link
Author

commented Jan 12, 2019

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...

@sampottinger sampottinger changed the title Java 11 Do we need Java 11 migration? Jan 12, 2019

sampottinger added a commit to sampottinger/processing that referenced this issue Jan 12, 2019
Initial migration to Java 11 on Mac as POC.
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.
sampottinger added a commit to sampottinger/processing that referenced this issue Jan 12, 2019
Initial migration to Java 11 on Mac as POC.
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.
sampottinger added a commit to sampottinger/processing that referenced this issue Jan 12, 2019
Initial migration to Java 11 on Mac as POC.
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.
@neilcsmith-net

This comment has been minimized.

Copy link

commented Jan 14, 2019

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
https://adoptopenjdk.net/support.html#roadmap

@benfry

This comment has been minimized.

Copy link
Member

commented Jan 14, 2019

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.

@sampottinger

This comment has been minimized.

Copy link
Author

commented Jan 14, 2019

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?

@neilcsmith-net

This comment has been minimized.

Copy link

commented Jan 14, 2019

@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.

sampottinger added a commit to sampottinger/processing that referenced this issue Jan 15, 2019
Refactored to strategies for supporting AdoptOpenJDK in build.
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).
@sampottinger

This comment has been minimized.

Copy link
Author

commented Jan 15, 2019

Hey @neilcsmith-net, thanks for the response! I do certainly see the logic. Review below...


there is very little, if any, work required to switch over to OpenJDK

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.


license redistribution situation is for Oracle Java 8 from the end of this month - it's possible it's no longer allowed.

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!

sampottinger added a commit to sampottinger/processing that referenced this issue Jan 17, 2019
PDE running under linux but sketches fail on java path.
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.
sampottinger added a commit to sampottinger/processing that referenced this issue Jan 17, 2019
Working proof of concept in linux with AdoptOpenJDK 11.
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.
sampottinger added a commit to sampottinger/processing that referenced this issue Jan 17, 2019
Working PDE / example sketch in win64 for AdoptOpenJDK.
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.
sampottinger added a commit to sampottinger/processing that referenced this issue Jan 18, 2019
Migrate deprecated com.apple.eawt calls in core.
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.
sampottinger added a commit to sampottinger/processing that referenced this issue Jan 18, 2019
Merge pull request #2 from sampottinger/master
Sync to master processing while working on processing#5753 / processing#5750
sampottinger added a commit to sampottinger/processing that referenced this issue Jan 22, 2019
Addressed java.xml.bind issues as part of JEP 320 for Java 11.
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).
sampottinger added a commit to sampottinger/processing that referenced this issue Jan 26, 2019
Preprocessing service compliance with JEP 220/261.
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.
sampottinger added a commit to sampottinger/processing that referenced this issue Jan 28, 2019
Refactored java build for testing in java mode.
Refactored java build for testing in java mode related to processing#5753 / processing#5750.
sampottinger added a commit to sampottinger/processing that referenced this issue Jan 28, 2019
Finished refactor to pdex.util.runtime ahead of adding tests.
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.
sampottinger added a commit to sampottinger/processing that referenced this issue Jan 29, 2019
Added tests and javadoc for new non-composite classpath strategies.
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.
sampottinger added a commit to sampottinger/processing that referenced this issue Jan 29, 2019
Finished refactor to runtime resolution strategies.
Finished pdex.util.runtime.* for processing#5753 / processing#5750 which adds support for restructured modules (Jigsaw) and OpenJFX.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.