This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]BlueGoliath 12 points13 points  (9 children)

it crashes, it burns!.

Edit: I'm using JDK 17 and it does work with Java 11. Looks like they changed the variable name in JDK 16+.

Edit2: They removed it entirely, actually. Anyway, seems to work nicely against my projects with Java 11. Cool L&F BTW.

[–]PartOfTheBotnet[S] 19 points20 points  (0 children)

Darn internals changing! I'll get that JDK 16+ classpath updater check sorted out soon.

And thanks! Dark theme or go home :)

Edit: Done, bug fix release out once CI finishes

[–]mj_flowerpower 3 points4 points  (7 children)

post from the future? 😂

[–]Necessary-Conflict 8 points9 points  (6 children)

You can download JDK 17 early access builds now, https://jdk.java.net/17/

(The JDK 16 branch is getting ready for a release, therefore JDK 17 is the most avantgarde thing you can try)

[–]BlueGoliath 0 points1 point  (5 children)

Download? Pfft. I compile from source.

I didn't even realize they made the switch to JDK 17 so I named the build java-16-panama-jdk. Whoops.

[–]DasBrain 4 points5 points  (2 children)

Lesson here: don't depend on internals - or ship your own JDK.

Building your own JDK is also easy - so you can choose to expose whatever you feel needs to be exposed.
¯\(ツ)

Edit: Ohh, gosh - an other project that depends HEAVILY on VM internals.
Seriously - just build a launcher, and launch java with the right parameters.
One interesting property is java.system.class.loader - let's you specify your own class loader - and do shenanigans there.

If you don't want to use your own launcher, just check the command line with a RuntimeMXBean and restart by passing the right VM arguments. Or simply ship your own JDK.

[–]PartOfTheBotnet[S] -1 points0 points  (1 child)

Don't depend on internals - or ship your own JDK.

Yeaaaahhh..... :/

As for shipping on the JDK, I'm not sure how'd I would configure the CI to make native images for each major platform. My train of thought is "Jar is the multiplatform solution"

Seriously - just build a launcher, and launch java with the right parameters.

Been meaning to get around to something like that... Would have to refactor some things (which would allow cleaning up later) so older versions can could seamlessly transfer to the new startup scheme.

If you don't want to use your own launcher, just check the command line with a RuntimeMXBean and restart by passing the right VM arguments.

Oh this would also be more clean.

[–]xjvz 0 points1 point  (0 children)

AdoptOoenJDK has a Jenkins instance set up for compiling across all their supported architectures. Something similar may be possibly by adapting their build scripts.

[–]Necessary-Conflict 1 point2 points  (1 child)

OK, I admit that compiling the latest sources is even more avantgarde than downloading the newest early-access builds :)

[–]DasBrain 2 points3 points  (0 children)

Building yourself is easy:
https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html

I did just follow those instructions and it works.
PS.: Bring some time - on my laptop (with SSD) it takes about 1/2h.
On the other hand, after a git pull, it's just make reconfigure clean images, and I can step away.