Reilly Brogan (#ReillyBrogan), 2022-04-07 21:25:11 UTC
OpenJDK 17 is the newest Java LTS and represents a significant number of improvements over the previous OpenJDK 11 LTS.
Todo:
- [x] Bootstrap OpenJDK 17
- [x] De-Bootsrap OpenJDK 17 (Probably going to wait for 17.0.3 for this - Roughly April 19th)
- [x] Package jtreg and use it to run tests to ensure that our OpenJDK 17 build is conformant
Go through and update application package manifests to use OpenJDK 17(where supported). Where NOT supported ensure that OpenJDK 11 is an explicit build and rundep with appropriate environmental variables:
- [ ] Arduino
- [ ] Bisq
- [x] Chatty
- [x] Cryptomator
- [x] Davmail
- [x] DBeaver
- [x] Fop
- [x] Freeplane
- [x] jabref
- [ ] josm
- [x] ipscan
- [x] Languagetool
- [ ] Modelio
- [x] PDFSam
- [x] ProjectLibre (has UI issues running under JDK 17, keep at 11 for now - https://sourceforge.net/p/projectlibre/tickets/174/)
Update build tools and their dependencies to use OpenJDK 17 by default:
- [ ] closure-compiler
- [ ] emscripten
- [x] apache-maven
- [ ] scala
- [ ] sbt
- [x] gradle
- [ ] bazel
- [ ] apache-ant
- [ ] clojure-tools
- [ ] kotlin
Reilly Brogan (#ReillyBrogan), 2022-04-07 23:17:11 UTC
CC #chax for arduino. I don't feel comfortable updating that one as the build appears fairly complex and I don't have any way to test it was still functional afterwards.
Reilly Brogan (#ReillyBrogan), 2022-04-08 05:33:34 UTC
>>! In T10227#195016, #alexanderzhirov wrote:
> #ReillyBrogan I will check it soon, but I think everything will work correctly.
Yeah most likely it'll work fine. I've been pleasantly surprised with how compatible most openjdk-11 using applications are with openjdk-17.
The only compatibility issue I've seen is one application that needs to be built in openjdk-11 but runs fine in openjdk-17.
Feel free to look at one of the other linked diffs to see how I've been forcing openjdk-17 during the build if you want inspiration. If you want to do this before openjdk-17 hits the repo you can either build it yourself using the linked diff or I can post a link to eopkg later.
Alexander Zhirov (#alexanderzhirov), 2022-04-08 06:01:19 UTC
>>! In T10227#195017, #ReillyBrogan wrote:
>>>! In T10227#195016, #alexanderzhirov wrote:
>> #ReillyBrogan I will check it soon, but I think everything will work correctly.
>
> Yeah most likely it'll work fine. I've been pleasantly surprised with how compatible most openjdk-11 using applications are with openjdk-17.
Yes, I'll check. It seems that in JDK16 DavMail worked correctly for me. I made another request [here](https://dev.getsol.us/T9975) at the time for a new version of OpenJDK. It will just open up the possibility to add new packages that are currently available in GitHub based on the latest versions of OpenJDK
`jabref` is another Java 8 application, possibly not here because it depends only on `openjfx-8`. I have the latest version of it building with the bootstrap package.
Reilly Brogan (#ReillyBrogan), 2022-04-08 17:13:26 UTC
>>! In T10227#195028, #biqqles wrote:
> `jabref` is another Java 8 application, possibly not here because it depends only on `openjfx-8`. I have the latest version of it building with the bootstrap package.
The latest version of jabref appears to be fully compatible with `openjdk-17`. It appears that they may pull in the openjfx libraries during build time, at which point it should just work with the bootstrap package (which lacks built-in openjfx support and I'd like to keep it that way if possible).
Do you want to take updating that one?
Yes happy to take it. It indeed pulls in openjfx with gradle. We can deprecate `openjfx-8` after this as jabref is the only dep. By the way, the description for the new `openjdk-17` currently states it "includes [...] OpenJFX 17."
Reilly Brogan (#ReillyBrogan), 2022-04-08 20:51:01 UTC
>>! In T10227#195037, #biqqles wrote:
> Yes happy to take it. It indeed pulls in openjfx with gradle. We can deprecate `openjfx-8` after this as jabref is the only dep. By the way, the description for the new `openjdk-17` currently states it "includes [...] OpenJFX 17."
Yeah, I basically copied the openjdk-11 build file to start out with. I had intended to include openjfx after bootstrapping but realized we could get away with not including it because applications have come to expect that it's not included with the JDK/JRE anymore and so bundle it themselves.
The next revision of the `openjdk-17` diff I push will have the updated description.
Reilly Brogan (#ReillyBrogan), 2022-04-12 17:24:39 UTC
FYI the openjdk-17 build is broken right now due to T10232 so I've uploaded a pre-built eopkg [here](https://solus.reillybrogan.com:8443/openjdk-17/openjdk-17-17.0.2-1-1-x86_64.eopkg)
OpenJDK 17 is the newest Java LTS and represents a significant number of improvements over the previous OpenJDK 11 LTS. Todo: - [x] Bootstrap OpenJDK 17 - [x] De-Bootsrap OpenJDK 17 (Probably going to wait for 17.0.3 for this - Roughly April 19th) - [x] Package jtreg and use it to run tests to ensure that our OpenJDK 17 build is conformant Go through and update application package manifests to use OpenJDK 17(where supported). Where NOT supported ensure that OpenJDK 11 is an explicit build and rundep with appropriate environmental variables: - [ ] Arduino - [ ] Bisq - [x] Chatty - [x] Cryptomator - [x] Davmail - [x] DBeaver - [x] Fop - [x] Freeplane - [x] jabref - [ ] josm - [x] ipscan - [x] Languagetool - [ ] Modelio - [x] PDFSam - [x] ProjectLibre (has UI issues running under JDK 17, keep at 11 for now - https://sourceforge.net/p/projectlibre/tickets/174/) Update build tools and their dependencies to use OpenJDK 17 by default: - [ ] closure-compiler - [ ] emscripten - [x] apache-maven - [ ] scala - [ ] sbt - [x] gradle - [ ] bazel - [ ] apache-ant - [ ] clojure-tools - [ ] kotlin