Get `ide` to work with Java 11 / Eclipse 4.17 #129

nedtwigg · 2020-09-17T17:17:19Z

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 ide with Java 11, the task fails like so:

> Task :ide:ideSetupP2
!SESSION 2020-09-17 10:04:12.926 -----------------------------------------------
eclipse.buildId=unknown
java.version=11.0.8
java.vendor=AdoptOpenJDK
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Framework arguments:  -application org.eclipse.equinox.p2.director -repository https://download.eclipse.org/eclipse/updates/4.17/R-4.17-202009021800/,https://download.eclipse.org/wildwebdeveloper/releases/0.9.1/ -artifactRepository file:///Users/ntwigg/.goomph/shared-bundles -installIU org.eclipse.platform.ide,org.eclipse.jdt.feature.group,org.eclipse.ui.views.log,org.eclipse.wildwebdeveloper.feature.feature.group -profile OomphIde -destination file:///Users/ntwigg/Documents/dev/mytakedotorg/ide/build/oomph-ide.app -bundlepool /Users/ntwigg/.goomph/shared-bundles -p2.os macosx -p2.ws cocoa -p2.arch x86_64
Command-line arguments:  -application org.eclipse.equinox.p2.director -clean -consolelog -repository https://download.eclipse.org/eclipse/updates/4.17/R-4.17-202009021800/,https://download.eclipse.org/wildwebdeveloper/releases/0.9.1/ -artifactRepository file:///Users/ntwigg/.goomph/shared-bundles -installIU org.eclipse.platform.ide,org.eclipse.jdt.feature.group,org.eclipse.ui.views.log,org.eclipse.wildwebdeveloper.feature.feature.group -profile OomphIde -destination file:///Users/ntwigg/Documents/dev/mytakedotorg/ide/build/oomph-ide.app -bundlepool /Users/ntwigg/.goomph/shared-bundles -p2.os macosx -p2.ws cocoa -p2.arch x86_64

!ENTRY org.eclipse.osgi 4 0 2020-09-17 10:04:12.949
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Cannot support framework extension bundles without a public addURL(URL) method on the framework class loader: org.eclipse.osgi.compatibility.state_1.1.0.v20170516-1513 [36]
        at org.eclipse.osgi.storage.FrameworkExtensionInstaller.addExtensionContent0(FrameworkExtensionInstaller.java:104)
        at org.eclipse.osgi.storage.FrameworkExtensionInstaller.addExtensionContent(FrameworkExtensionInstaller.java:79)
        at org.eclipse.osgi.internal.loader.SystemBundleLoader$SystemModuleClassLoader.loadFragments(SystemBundleLoader.java:129)
        at org.eclipse.osgi.internal.loader.SystemBundleLoader.loadClassLoaderFragments(SystemBundleLoader.java:111)
        at org.eclipse.osgi.internal.loader.BundleLoader.loadFragments(BundleLoader.java:282)
        at org.eclipse.osgi.container.ModuleWiring.loadFragments(ModuleWiring.java:273)
        at org.eclipse.osgi.container.ModuleContainer.applyDelta(ModuleContainer.java:710)
        at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:511)
        at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:457)
        at org.eclipse.osgi.container.ModuleContainer.refresh(ModuleContainer.java:1001)
        at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1382)
        at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1)
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)

!ENTRY org.eclipse.core.net 1 0 2020-09-17 10:04:13.413
!MESSAGE System property http.nonProxyHosts has been set to local|*.local|169.254/16|*.169.254/16 by an external source. This value will be overwritten using the values from the preferences
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.eclipse.ecf.provider.filetransfer.httpclient4.SNIAwareHttpClient$1 (file:/Users/ntwigg/.goomph/p2-bootstrap/4.7.2/plugins/org.eclipse.ecf.provider.filetransfer.httpclient4_1.1.200.v20170314-0133.jar) to method sun.security.ssl.SSLSocketImpl.setHost(java.lang.String)
WARNING: Please consider reporting this to the maintainers of org.eclipse.ecf.provider.filetransfer.httpclient4.SNIAwareHttpClient$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Installing org.eclipse.platform.ide 4.17.0.I20200902-1800.
Installing org.eclipse.jdt.feature.group 3.18.500.v20200902-1800.
Installing org.eclipse.ui.views.log 1.2.1200.v20200828-0938.
Installing org.eclipse.wildwebdeveloper.feature.feature.group 0.9.1.202005041657.
An error occurred while installing the items
Installation failed.
 session context was:(profile=OomphIde, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null --> [R]com.google.gson 2.8.2.v20180104-1110, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction).
 Could not acquire the framework manipulator service.
Caused by: Application failed, log file location: /Users/ntwigg/.goomph/p2-bootstrap/4.7.2/configuration/1600362252277.log

!ENTRY org.eclipse.equinox.p2.engine 4 4 2020-09-17 10:04:23.625
!MESSAGE An error occurred while installing the items
!SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2020-09-17 10:04:23.626
!MESSAGE session context was:(profile=OomphIde, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null --> [R]com.google.gson 2.8.2.v20180104-1110, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction).
!SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2020-09-17 10:04:23.626
!MESSAGE Could not acquire the framework manipulator service.
!STACK 0
java.lang.IllegalStateException: Could not acquire the framework manipulator service.
        at org.eclipse.equinox.internal.p2.touchpoint.eclipse.LazyManipulator.loadDelegate(LazyManipulator.java:45)
        at org.eclipse.equinox.internal.p2.touchpoint.eclipse.LazyManipulator.getConfigData(LazyManipulator.java:108)
        at org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction.installBundle(InstallBundleAction.java:75)
        at org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction.execute(InstallBundleAction.java:32)
        at org.eclipse.equinox.internal.p2.engine.ParameterizedProvisioningAction.execute(ParameterizedProvisioningAction.java:39)
        at org.eclipse.equinox.internal.p2.engine.Phase.mainPerform(Phase.java:184)
        at org.eclipse.equinox.internal.p2.engine.Phase.perform(Phase.java:96)
        at org.eclipse.equinox.internal.p2.engine.PhaseSet.perform(PhaseSet.java:47)
        at org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:77)
        at org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:45)
        at org.eclipse.equinox.internal.provisional.p2.director.PlanExecutionHelper.executePlan(PlanExecutionHelper.java:42)
        at org.eclipse.equinox.internal.provisional.p2.director.PlanExecutionHelper.executePlan(PlanExecutionHelper.java:24)
        at org.eclipse.equinox.internal.p2.director.app.DirectorApplication.executePlan(DirectorApplication.java:813)
        at org.eclipse.equinox.internal.p2.director.app.DirectorApplication.planAndExecute(DirectorApplication.java:806)
        at org.eclipse.equinox.internal.p2.director.app.DirectorApplication.performProvisioningActions(DirectorApplication.java:793)
        at org.eclipse.equinox.internal.p2.director.app.DirectorApplication.run(DirectorApplication.java:1111)
        at org.eclipse.equinox.internal.p2.director.app.DirectorApplication.start(DirectorApplication.java:1293)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
        at com.diffplug.gradle.eclipserunner.EquinoxLauncher$Running.run(EquinoxLauncher.java:190)
        at com.diffplug.gradle.eclipserunner.EquinoxLauncher$Running.access$100(EquinoxLauncher.java:172)
        at com.diffplug.gradle.eclipserunner.EquinoxLauncher.run(EquinoxLauncher.java:163)
        at com.diffplug.gradle.eclipserunner.JarFolderRunner.run(JarFolderRunner.java:37)
        at com.diffplug.gradle.eclipserunner.JarFolderRunnerExternalJvm$RunOutside.run(JarFolderRunnerExternalJvm.java:126)
        at com.diffplug.gradle.JavaExecable.main(JavaExecable.java:134)

It's really important for Goomph to support the latest version of eclipse. Goomph still works with 4.17 with the mavenCentral plugin, but the ide plugin 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!

The text was updated successfully, but these errors were encountered:

nedtwigg · 2020-09-17T17:18:58Z

Related: #127, #99, #69.

drkstr101 · 2020-09-21T00:00:18Z

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?

nedtwigg · 2020-09-21T04:24:38Z

The most obvious place to start would be upgrading the eclipse launcher jars and code. The jars are defined here:

goomph/build.gradle

Lines 44 to 53 in d95be31

    
           // eclipse 4.7.2 
        
           compileOnly 'org.eclipse.platform:org.eclipse.core.jobs:3.9.2' 
        
           compileOnly 'org.eclipse.platform:org.eclipse.core.runtime:3.13.0' 
        
           compileOnly 'org.eclipse.platform:org.eclipse.core.resources:3.12.0' 
        
           compileOnly 'org.eclipse.platform:org.eclipse.equinox.common:3.9.0' 
        
           compileOnly 'org.eclipse.platform:org.eclipse.ui.workbench:3.110.1' 
        
           compileOnly 'org.eclipse.pde:org.eclipse.pde.core:3.11.100' 
        
           compileOnly 'org.eclipse.jdt:org.eclipse.jdt.launching:3.9.51' 
        
           // from 4.6.3 cuz that's the latest one 
        
           compileOnly 'org.eclipse.emf:org.eclipse.emf.ecore:2.12.0'

And the code is here:
https://github.com/diffplug/goomph/tree/main/src/main/java/com/diffplug/gradle/eclipserunner/launcher

How to do it

A long time ago, you couldn't apply a gradle plugin to the build.gradle of the build that built it (aka you could not bootstrap). That is fixed now, so you could use eclipseMavenCentral to get the latest 4.17 jars into build.gradle.

And as for the eclipserunner.launcher package, 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 .launcher package), 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, goomph isn't adding a ton of features, so I think it's fine to say "if you want Eclipse < 4.17, use Goomph vBlah".

drkstr101 · 2020-09-22T17:32:01Z

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.

drkstr101 · 2020-10-14T22:34:29Z

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.

drkstr101 · 2020-10-21T00:13:57Z

FYI I am going to start testing this in watheia/gradle-and-eclipse-rcp, so I will add a branch there for java-11.

drkstr101 · 2020-10-21T21:13:07Z

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

apply 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!

nedtwigg · 2020-10-21T21:14:00Z

https://github.com/diffplug/blowdryer

drkstr101 · 2020-10-21T21:14:53Z

Ah, of course. Says so right above that block of code!

Thanks for the speedy reply. =)

nedtwigg · 2020-10-21T21:40:07Z

Sorry for brief answer from phone, juggling sick kids. The longer answer is to swap the comment here:

goomph/settings.gradle

Lines 22 to 25 in 292e0eb

    
           blowdryerSetup { 
        
           	github 'diffplug/blowdryer-diffplug', 'tag', '3.2.4' 
        
           	//devLocal '../blowdryer-diffplug' 
        
           }

and clone this repo in a folder next to goomph: https://github.com/diffplug/blowdryer-diffplug

drkstr101 · 2020-10-21T22:34:33Z

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

drkstr101 · 2020-10-22T01:15:48Z

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/805235920

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

nedtwigg · 2020-10-22T04:29:49Z

Very cool approach you are taking! I have two points:

1 ) You don't have to include blowdryer-diffplug as a build. blowdryer is an extremely simple plugin. blowdryer-diffplug is just a central collection of script.gradle files, which we use across our fleet of projects to set conventions for our org. There are other blowdryer-foo out there, for other organizations.

The goomph build (in devLocal mode) literally just slurps script.gradle files from the local filesystem, and that's it. When it's in github mode, it's downloading and caching those script.gradle files using http GET. That's all. Including it in the settings.gradle will 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.gradle of the gradle-and-eclipse-rcp project, 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.

drkstr101 · 2020-10-22T04:53:15Z

Thanks for the tips! I did actually have them working individually, but I was starting to pollute the repos with my own personal workflows so I was hoping to move all that to the top.

I should probably just read the blowdryer docs before going too far into the weeds into something unrelated to the problem. I will most likely be consuming goomph downstream in a similar setup though, so I will keep this on the back burner for now.

I have actually had success depending on a plugin in-situ like this before so it is possible. Sometimes though one needs to make a few minor tweaks to support that use case. Usually nothing major.

It has only been in Gradle 6.x that this was even viable, so the pattern has not been widely adopted yet.

I will keep you posted on further progress.

Cheers!

drkstr101 · 2020-10-22T22:27:31Z

I am still getting dependency resolution errors on main with fresh Docker build.

https://scans.gradle.com/s/pxs6jzwfq3j3a

I will poke through blowdryer some more to see if I can resolve them.

Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not find any matches for com.sun.jna:com.sun.jna:[4.5.1,6.0.0) as no versions of com.sun.jna:com.sun.jna are available.
     Searched in the following locations:
       - https://repo.maven.apache.org/maven2/com/sun/jna/com.sun.jna/maven-metadata.xml
     Required by:
         project : > org.eclipse.platform:org.eclipse.ui.workbench:3.110.1 > org.eclipse.platform:org.eclipse.e4.ui.workbench.swt:0.14.1100 > org.eclipse.platform:org.eclipse.urischeme:1.1.100
   > Could not find any matches for com.sun.jna:com.sun.jna.platform:[4.5.1,6.0.0) as no versions of com.sun.jna:com.sun.jna.platform are available.
     Searched in the following locations:
       - https://repo.maven.apache.org/maven2/com/sun/jna/com.sun.jna.platform/maven-metadata.xml
     Required by:
         project : > org.eclipse.platform:org.eclipse.ui.workbench:3.110.1 > org.eclipse.platform:org.eclipse.e4.ui.workbench.swt:0.14.1100 > org.eclipse.platform:org.eclipse.urischeme:1.1.100

nedtwigg · 2020-10-23T08:22:24Z

I'm not sure what the cause is, but the problem is that it shouldn't be trying to get jna anyway. Looking at the error message, it's trying to resolve this:

goomph/build.gradle

Line 49 in 292e0eb

compileOnly 'org.eclipse.platform:org.eclipse.ui.workbench:3.110.1'

     Required by:
         project : > org.eclipse.platform:org.eclipse.ui.workbench:3.110.1 > org.eclipse.platform:org.eclipse.e4.ui.workbench.swt:0.14.1100 > org.eclipse.platform:org.eclipse.urischeme:1.1.100

But it shouldn't do that, because of this:

goomph/build.gradle

Lines 58 to 62 in 292e0eb

    
           configurations.all { 
        
           	exclude group: 'org.eclipse.platform', module: 'org.eclipse.swt.${osgi.platform}' 
        
           	exclude group: 'com.sun.jna', module: 'com.sun.jna' 
        
           	exclude group: 'com.sun.jna', module: 'com.sun.jna.platform' 
        
           }

I don't know why composite build would do that, but it seems like that's what's happening.

drkstr101 · 2020-10-23T09:46:26Z

This was actually run on its own inside a clean Docker container since I figured this would be the best way to get a working baseline. This does actually help get me started though! I tried searching for the dependency usage but didn't use a wide enough net I suppose! I will take another stab at in tomorrow.

FYI I published a full build scan with --info flag enabled if you're interested, but I think I have an idea how to move forward now so maybe just stand by?

https://scans.gradle.com/s/ezyzqmfbe5kmg

I will get the Docker container up and running in GitLab CI tomorrow so it will be easier to debug. I was just experimenting on localhost a bit first.

nedtwigg · 2020-10-23T20:53:53Z

Goomph is also building on a clean docker container in CI, so it's very confusing: https://travis-ci.org/github/diffplug/goomph

drkstr101 · 2020-10-24T05:01:42Z

Indeed that is alarming! Except now maybe it makes sense what happened. I clearly broke something by upgrading to Gradle 6.7! Whoops, better start over and try again. O_o

drkstr101 · 2020-10-26T00:25:01Z

@nedtwigg It was indeed Gradle 6.7 causing the issues.

https://gitlab.com/watheia/goomph/-/jobs/811015751

goomph builds fine using the wrapped 6.2.2 Gradle version. This is a bit concerning to me. I've always just upgraded immediately without much thought unless it was a major version bump. I will need to be more cautious with this going forward.

drkstr101 · 2020-10-26T01:23:37Z

Unfortunately, the version of javadoc included in 6.2.2 doesn't seem to be compatible with Java 11.

https://gitlab.com/watheia/goomph/-/jobs/811053032

I had the same results locally. I'm not exactly sure how to upgrade javadoc without Gradle, but I'll see if I can find the magic target.

> Task :jar
javadoc: warning - The old Doclet and Taglet APIs in the packages
com.sun.javadoc, com.sun.tools.doclets and their implementations
are planned to be removed in a future JDK release. These
components have been superseded by the new APIs in jdk.javadoc.doclet.

> Task :javadoc
Users are strongly recommended to migrate to the new APIs.
javadoc: error - invalid flag: -Xdoclint:none

nedtwigg · 2020-10-26T01:26:37Z

My advice:

find the version of gradle where it breaks (there's a few between 6.2 and 6.7)
look at the release notes for that version

drkstr101 · 2020-10-26T05:15:39Z

spotbugsMain started failing at Gradle 6.5.1, although assemble completed fine.

Same results for 6.6.1.

And here is where I start questioning my sanity...

assemble now works fine in 6.7!! (spotbugsMain issue carried through as expected).

Prior to this assemble was throwing dependency errors before it even kicked off the build. Now it's fine??

I think I will pick this back up again tomorrow. Nothing makes sense anymore, hah! :)

EDIT

Probably relevant...

The first time I generated the wrapper from my default Java 11 install, while this time I used the Docker container built from the version prior to the one I'm targeting (IE. generated from Java 8). At least I can sleep a little sounder tonight. haha!

nedtwigg · 2020-10-26T17:22:58Z

Feel free to turn spotbugs off, I can turn it back on later.

drkstr101 · 2020-10-27T06:19:15Z

spotbugs worked as expected (reporting 9 ignored failures) after a major version bump and some tweaks in build.gradle.

We now have goomph up and running on gradle:6.7-jdk8. Let's see if we can get that too gradle:6.7-jdk11 tomorrow!

drkstr101 · 2020-10-27T18:37:38Z

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 from gradle:6.7-jdk11 Docker image.

I will keep at it, just giving you a heads up!

drkstr101 · 2020-10-28T01:45:30Z

@nedtwigg Here is the first working goomph build on gradle: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 failOnError to false in all the javadoc blocks.

ralfgrossklaus · 2020-12-15T22:41:03Z

Hi 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-SYSTEM to 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

nedtwigg · 2020-12-15T22:51:37Z

Great, thanks very much @ralfgrossklaus, looking forward to see what you come up with :)

ralfgrossklaus · 2020-12-17T12:04:55Z

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

nedtwigg · 2020-12-17T19:27:00Z

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 to https://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.

ralfgrossklaus · 2021-01-26T15:13:23Z

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

nedtwigg · 2021-02-11T00:03:44Z

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

ralfgrossklaus · 2021-02-11T16:57:04Z

@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

nedtwigg · 2021-02-11T18:24:33Z

Interesting. On my branch, I updated Main to the latest from eclipse, and StartupClassLoader is an inner class there:

https://github.com/eclipse/rt.equinox.framework/blob/d7c024f15311e85a8572d5532fb4a8e51982f92d/bundles/org.eclipse.equinox.launcher/src/org/eclipse/equinox/launcher/Main.java#L2681-L2730

Your StartupClassLoader is mostly the same, except that it adds addExtensionPath. Did you add that, or did you find it in an eclipse source somewhere?

nedtwigg · 2021-02-12T03:21:15Z

Huzzah! Your fork is amazing. I've mushed things around a bit, should have a new release later tonight.

drkstr101 · 2021-02-12T17:40:54Z

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. ¯\_(ツ)_/¯

nedtwigg · 2021-02-13T00:35:47Z

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

nedtwigg added bug help wanted labels Sep 17, 2020

nedtwigg mentioned this issue Sep 17, 2020

Eclipse 4.17 (2020-09) will require Java 11 diffplug/spotless#547

Closed

drkstr101 mentioned this issue Nov 16, 2020

Gradle: Update to Gradle 6/7 & deal with deprecations in Gradle 6.x/7.x eclipse/xtext#1548

Closed

nedtwigg mentioned this issue Feb 11, 2021

Switch p2bootstrap from 4.7.2 to 4.13.0 (adds full Java 11 support, but breaks p2asmaven) #137

Merged

nedtwigg closed this as completed Feb 13, 2021

nedtwigg mentioned this issue Jun 6, 2021

CI fails to build Eclipse plugins which require Java 11 diffplug/spotless#873

Closed

Get ide to work with Java 11 / Eclipse 4.17 #129

Get ide to work with Java 11 / Eclipse 4.17 #129

Comments

nedtwigg commented Sep 17, 2020

nedtwigg commented Sep 17, 2020

drkstr101 commented Sep 21, 2020

nedtwigg commented Sep 21, 2020

How to do it

drkstr101 commented Sep 22, 2020

drkstr101 commented Oct 14, 2020

drkstr101 commented Oct 21, 2020

drkstr101 commented Oct 21, 2020 • edited Loading

nedtwigg commented Oct 21, 2020

drkstr101 commented Oct 21, 2020

nedtwigg commented Oct 21, 2020

drkstr101 commented Oct 21, 2020

drkstr101 commented Oct 22, 2020

nedtwigg commented Oct 22, 2020 • edited Loading

drkstr101 commented Oct 22, 2020

drkstr101 commented Oct 22, 2020 • edited Loading

nedtwigg commented Oct 23, 2020

drkstr101 commented Oct 23, 2020

nedtwigg commented Oct 23, 2020

drkstr101 commented Oct 24, 2020 • edited Loading

drkstr101 commented Oct 26, 2020

drkstr101 commented Oct 26, 2020

nedtwigg commented Oct 26, 2020

drkstr101 commented Oct 26, 2020 • edited Loading

nedtwigg commented Oct 26, 2020

drkstr101 commented Oct 27, 2020 • edited Loading

drkstr101 commented Oct 27, 2020

drkstr101 commented Oct 28, 2020 • edited Loading

ralfgrossklaus commented Dec 15, 2020 • edited by nedtwigg Loading

nedtwigg commented Dec 15, 2020

ralfgrossklaus commented Dec 17, 2020 • edited by nedtwigg Loading

nedtwigg commented Dec 17, 2020

ralfgrossklaus commented Jan 26, 2021

nedtwigg commented Feb 11, 2021

ralfgrossklaus commented Feb 11, 2021

nedtwigg commented Feb 11, 2021

nedtwigg commented Feb 12, 2021

drkstr101 commented Feb 12, 2021 • edited Loading

nedtwigg commented Feb 13, 2021

Get `ide` to work with Java 11 / Eclipse 4.17 #129

Get `ide` to work with Java 11 / Eclipse 4.17 #129

drkstr101 commented Oct 21, 2020 •

edited

Loading

nedtwigg commented Oct 22, 2020 •

edited

Loading

drkstr101 commented Oct 22, 2020 •

edited

Loading

drkstr101 commented Oct 24, 2020 •

edited

Loading

drkstr101 commented Oct 26, 2020 •

edited

Loading

drkstr101 commented Oct 27, 2020 •

edited

Loading

drkstr101 commented Oct 28, 2020 •

edited

Loading

ralfgrossklaus commented Dec 15, 2020 •

edited by nedtwigg

Loading

ralfgrossklaus commented Dec 17, 2020 •

edited by nedtwigg

Loading

drkstr101 commented Feb 12, 2021 •

edited

Loading