Repository navigation
Get ide to work with Java 11 / Eclipse 4.17 #129
Description
Activity
Ugg, what a pain (RE supporting both Java 8/11). I need a version of ANTLWorks that only works with 1.8, but VScode and now Eclipse are forcing Java 11. I better start getting ahead of this. Any ideas on where to get started, or is that the first steps here?
The most obvious place to start would be upgrading the eclipse launcher jars and code. The jars are defined here:
Lines 44 to 53 in d95be31
And the code is here:
https://github.com/diffplug/goomph/tree/main/src/main/java/com/diffplug/gradle/eclipserunner/launcherHow to do it
A long time ago, you couldn't apply a gradle plugin to the
build.gradleof the build that built it (aka you could not bootstrap). That is fixed now, so you could useeclipseMavenCentralto get the latest4.17jars intobuild.gradle.And as for the
eclipserunner.launcherpackage, that code was just straight copy-pasted from the super-old Eclipse Mars.2. I'm not sure which package it came from originally, but it shouldn't be too hard to track down.Past those two things (updating the jars, updating the
.launcherpackage), I would just follow a stacktrace, then try to fix it. Follow the next stacktrace, try to fix that.As mentioned before, these upgrades are likely to drop support for all the old Eclipse's. But I think that's fine,
goomphisn't adding a ton of features, so I think it's fine to say "if you want Eclipse < 4.17, use Goomph vBlah".Awesome, thanks for the head start! I will start plugging away at it and see if I can make any progress on this. I will have more time at the end of the week, so I'll post back then with any results.
Sorry it took me so long to get back to this. I have all my DevOps up and running on Java 11 now, so hopefully I can make some progress on this.
Reacted by Ned TwiggFYI I am going to start testing this in watheia/gradle-and-eclipse-rcp, so I will add a branch there for java-11.
@nedtwigg When you have a min, could you please give me some additional context on where I can look into making changes to the following in the
build.gradleapply from: 干.file('base/java8.gradle') apply from: 干.file('base/changelog.gradle') apply from: 干.file('base/gradle-plugin.gradle') apply from: 干.file('base/maven.gradle') apply from: 干.file('base/bintray.gradle') apply from: 干.file('spotless/freshmark.gradle') apply from: 干.file('spotless/java.gradle')I'm not exactly sure if those symbols are intentional or some kind of encoding error, but I was more curious about where I can locate, and make changes to, the referenced Gradle file.
Cheers, and thank you!
Ah, of course. Says so right above that block of code!
Thanks for the speedy reply. =)
Sorry for brief answer from phone, juggling sick kids. The longer answer is to swap the comment here:
Lines 22 to 25 in 292e0eb
and clone this repo in a folder next to goomph: https://github.com/diffplug/blowdryer-diffplug
No worries, I just clicked the link at the top of the README to find it.
FYI I am attempting to get the CI workspace set up here; https://gitlab.com/watheia/diffplug
If you have a GitLab account I can add you on if you wish.
Once it's working I will be able to run "Auto DevOps" against
graalvm-java11native images on a DO droplet. I expect this to blow up in my face, but hopefully, it will at least shake out a few issues with java-next compatibility.Unfortunately, decoupled projects seem to break classpath resolution with p2 targets. You want me to see if I can take a stab at that first, assuming it's not just something stupid in my setup?
(pass) https://gitlab.com/watheia/diffplug/-/jobs/805215016
(fail) https://gitlab.com/watheia/diffplug/-/jobs/805235920Note: At this point, I'm just trying to get everything up and running on java-8, before I move on to the more challenging bit. I have done a few experiments locally to test the waters, but I need to integrate cross-project builds to make any real progress.
Very cool approach you are taking! I have two points:
1 ) You don't have to include
blowdryer-diffplugas a build.blowdryeris an extremely simple plugin.blowdryer-diffplugis just a central collection ofscript.gradlefiles, which we use across our fleet of projects to set conventions for our org. There are otherblowdryer-fooout there, for other organizations.The
goomphbuild (indevLocalmode) literally just slurpsscript.gradlefiles from the local filesystem, and that's it. When it's ingithubmode, it's downloading and caching thosescript.gradlefiles usinghttp GET. That's all. Including it in thesettings.gradlewill have no effect at all.2 ) I'm surprised by the error, and it looks like you know more about composite builds than I do. My only feedback is that the only time I've had success using composite builds with plugins is this:
// settings.gradle of plugin consumer includeBuild('../plugin-producer')
I think your submodule repo is a great idea, but I think you can probably get away with just modifying the
settings.gradleof thegradle-and-eclipse-rcpproject, rather than having a parent build. If the parent build works, then I say go for it. But it might be worth seeing if ditching the parent build (but keeping the monorepo) fixes anything.11 remaining items
spotbugsworked as expected (reporting 9 ignored failures) after a major version bump and some tweaks inbuild.gradle.We now have
goomphup and running ongradle:6.7-jdk8. Let's see if we can get that toogradle:6.7-jdk11tomorrow!Well, shoot. Now we get to figure out why my native JDK11 toolchain only produces warnings on
javadoc, but those same warnings are now errors when run fromgradle:6.7-jdk11Docker image.I will keep at it, just giving you a heads up!
@nedtwigg Here is the first working
goomphbuild ongradle:6.7-jdk11:https://gitlab.com/watheia/diffplug/-/pipelines/208489628
There are a few bits disabled in dev tasks, but tests are passing. Still no idea why localhost produced different results than Docker, but I worked around it by setting
failOnErrorto false in all thejavadocblocks.Reacted by Ned TwiggHi Ned,
I looked in that issue as we are upgrading to Java 11 and the version of "goomph" that we use is quite old. It was kind of a struggle, but i made some progress the last days so i want to inform about my findings:-
I created a new version of the p2-bootstrap with Eclipse 4.13 (because it supports both, Java 8 and Java 11). The problem was, that Eclipse removed the update.configurator reconciling code from the platform with https://bugs.eclipse.org/bugs/show_bug.cgi?id=527783, so the new bootstrap needs to use the simple configurator and a complete bundles.info.
-
The p2-bootstrap works with Java 8, but haves some problems when running with Java 11. I tried to add
--add-modules=ALL-SYSTEMto the JVM options when the process is forked for the bootstrap, but that didn't help (even though i think that it is still necessary, as this option is in the .ini file for all Eclipse versions which supports Java 9+). I think the problem you mentioned is due to the different class loader architecture that was introduced with Java 9. The Classloader that starts Eclipse in the P2 bootstrap does not inherit from URLClassloader and thus missing the "addURL" method. If i interpret the comment in https://bugs.eclipse.org/bugs/show_bug.cgi?id=515286#c2 correctly, Eclipse has to be started using an URLClassloader in order to use Framework Extensions. So i think there should be a mechanism to detect which Java Version is used and for 9+ Eclipse will be launched not using the default Classloader.
I will do some further investigation this week and hope i can come up with a solution that i can share here.
Regards, Ralf
-
Great, thanks very much @ralfgrossklaus, looking forward to see what you come up with :)
You're welcome. I am still working on the classloader issue. But you can have look about the changes for an Eclipse 4.13.0 bootstrap here: https://github.com/ralfgrossklaus/goomph/tree/4.13.0_p2_bootstrap
Not much to do. The main problem was to find the reason why the the bundle initialization did not work anymore. I added my boostrap zip to dropbox here: https://www.dropbox.com/s/zgxj3blfevsb9gz/goomph-p2-bootstrap.zip?dl=0
What I did to create it was the following:
- I ran p2 director using the following command to create a starting point:
eclipsec.exe -application org.eclipse.equinox.p2.director -repository <OUR_ECLIPSE_MIRROR> -installIU org.eclipse.equinox.p2.core.feature.feature.group,org.eclipse.equinox.p2.director.app,org.eclipse.equinox.p2.repository.tools,org.eclipse.core.net,org.eclipse.osgi.compatibility.state,org.eclipse.ant.core,org.apache.ant,org.eclipse.core.runtime,org.eclipse.update.configurator,org.eclipse.equinox.ds,org.eclipse.equinox.p2.reconciler.dropins -tag InitialState -destination d:/4.13.0/goomph-p2-bootstrap/ -profile SDKProfile -profileProperties org.eclipse.update.install.features=true -bundlepool d:/4.13.0/goomph-p2-bootstrap/ - Than deleted the features folder as it is not needed
- Created a bundle.info in configuration/org.eclipse.equinox.simpleconfigurator/bundles.info based on an actual Eclipse 4.13 IDE, but removed all the bundles which are not present in p2-bootstrap.
It works on our local mirror, however the bootstrap is currently 18MB which is quite a bit more than the old one. Not sure which plugins can be removed safely from the ZIP in order to bring the size down. Im afraid I don't have much time to look into this, as It is not much of a problem in our local network. But i guess when you want to publish one to bintray, a smaller version would be better?
I will keep you updated about my progress.
Regards, Ralf
Reacted by Ned Twigg- I ran p2 director using the following command to create a starting point:
Great, thanks very much! The old bootstraps were created like so, but your way works great too. I'm not particularly worried about the size of the bootstrap jar.
Aside: you're doing links like this (I've been editing your comments to fix them)
[https://www.dropbox.com/s/zgxj3blfevsb9gz/goomph-p2-bootstrap.zip?dl=0](url)which goes to the URL
url, and not tohttps://www.dropbox.com/etc. If you just plop the URL inline github will automatically mark it as a link, or you can do something like[link here](https://www.dropbox.com/s/zgxj3blfevsb9gz/goomph-p2-bootstrap.zip?dl=0)if you're trying to make the text smaller.
Hi!
small update on the Java 11 issue: I managed to start PDE using a URL classloader in in JarFolderRunner to startup Eclipse. It works as far as I can see; however i haven't cleaned up my code and i haven't tested it extensively yet (I am behind a company firewall were i have to deactivate lots of the tests). I am planning doing so maybe at the weekend.
Regards@ralfgrossklaus I'm taking a stab at this now too, and your hints above have been fantastically helpful. If you have an unfinished WIP branch, I'd love to take a peek!
@nedtwigg Sure. You can take a look at my j11 branch. There are a few issues with it, hence i haven't created a PR yet.
- The code from StartupClassLoader and the ClassPathUtil is mainly extracted from the Equinox launcher. Not sure about the license implications of that. I wanted to rewrite that part
- Spotbugs doesn't seem to be happy with the way the class loader is created. It wants a "doPrivileged" block for that.
Besides that and if the boostrap pde is provided, it should run for Java 11. I haven't tested it for java 8 however.
Regards, Ralf
Interesting. On my branch, I updated
Mainto the latest from eclipse, andStartupClassLoaderis an inner class there:Your
StartupClassLoaderis mostly the same, except that it addsaddExtensionPath. Did you add that, or did you find it in an eclipse source somewhere?Huzzah! Your fork is amazing. I've mushed things around a bit, should have a new release later tonight.
Hey friend! I apologize for the lack of activity. Iv'e been busy launching a startup!
I have a meeting in a couple hours (11:30 Pacific), but I'm free the rest of the afternoon.
PS: This is a bit embarrassing, but the reason I could get it to work in Docker and not localhost is because I had accidently installed jre instead of jdk.
¯\_(ツ)_/¯Reacted by Ned TwiggThanks for all the help! A fix is shipped in
3.28.0. On my fleet of projects:- works great on on one (but you get weird errors if you use Java 8 to try to launch Java 11-only IDE)
- getting signing errors on another
So there will definitely be bugfix releases, but it's working.
Eclipse 4.17 requires Java 11+ to run. If you try to run it with Java 8, there are no explicit warnings about using the wrong version, and eclipse will start successfully. However, you won't actually be able to use it, it's functionally broken.
If you start
idewith Java 11, the task fails like so:It's really important for Goomph to support the latest version of eclipse. Goomph still works with
4.17with themavenCentralplugin, but theideplugin needs to work too. It would be nice for Goomph to stay compatible with Java 8, but if we have to bump our minimum required Java to 11, I'm okay with that.Fixing this is important, but I don't expect to have time to look at this further until early 2021. PRs are welcome!