Eclipse Is Back on Raspberry Pi

Daniel Sendula 2020-06-06 14:45 Comments

Eclipse is Back On Raspberry Pi

Since the Raspberry Pi foundation released a new Raspberry Pi 4 with 8GB of RAM and since they started started working on 64bit ~~Raspbian~~ Raspberry Pi OS, all the requirements needed for Eclipse to work on Raspberry Pi again are met.

TL;DR - you can get a working version of Eclipse For Java Developers (2020-03) from here: eclipse-java-2020-03-v1-R-linux-gtk-aarch64.tar.gz

It only works on 64bit Raspberry Pi OS - follow the above forum link on how to get it and install it.

Eclipse On Raspberry Pi 4

Why Eclipse

Eclipse has been here since late 2001 and it was made for computers of that time. I've recently resurrected an old laptop from 1999 with the following specs:

333MHz Celeron CPU
128MB of RAM
4.5GB HardDisk

1999 Laptop With Raspberry Pi

I've installed Java 1.2 (and then 1.3 immediately after) and Eclipse 2.0.2 from 2002, and it all worked. The IDE wasn't up to today's standards as some of the intellisense stuff was very crude and rudimentary but responsiveness was decent. When 'Run' was selected it took less than 2 seconds before the Java code started. A very similar response (if not faster) than IntelliJ's Idea on MacBook Pro on 3.3GHz CPU, 16GB RAM and really fast SSD.

Raspberry Pi, since version 4, solidly became a Desktop Computer (or here on Raspberry Pi forums) and I've been using it on and off for Java and Python development (and regular web browsing and emails). PyCharm works like a charm, but when we got to Idea things were less than ideal. Although it worked (and worked well for developing Virtual PiWars), there's a slight gap between what kind of target platform Idea was made for and what CPU speed Raspberry Pi offers. And that's what Eclipse excells in.

Slight History Digression

Eclipse is made based on inspiration of VisualAge (see more here on wikipedia) and even though VisualAge wasn't really a hit, as it was quite awkward to use (in my 2001 engagement we copied files from VisualAge to a separate, simple text editor, for changing and back again for compilation and source control), an incremental Java compiler that came from it turned it into an instant hit.

Eclipse overcame a slow Java start-up and expected compilation times by pre-parsing all source files into AST, along with a background process which parsed currently edited file while it was being typed in. That smart step limited the actual amount of code to be compiled into fragment to the currently changed portion of abstract syntax tree (AST). That way, Eclipse became very snapy and responsive: the moment the developer stopped changing code it would be already compiled into bytecode of that class and all other possbile inconsistencies fixed in seconds after that. By the time developer selected the 'Run' menu item, the code was ready to be run and the only thing which needed to be waited for was for new JVM to be started with all the classes ready.

That's different to what other languages' IDEs, and even modern Java IDEs (i.e. Idea) are doing: at the point when the developer presses 'Run', all files are inspected for changes (in Java's case comparing timestamp on bytecode to source file's timestamp) and changes detected, source files loaded up and compiled into corresponding bytecode. That process itself takes some time... and for a long time Eclipse was the fastest IDE around. Maven and Idea have tried to incorporate Eclipse's incremental compiler but I am not aware what problems they encountered and they've never gone to mainstream.

Why Not Eclipse On Raspberry Pi Up To Now

There was an Eclipse package that worked on Raspberry Pi (version 3.8.1) thanks to Torkild U. Resheim (here and here). But, since then, Eclipse Foundation decided to ditch 32bit versions of Eclipse and provide only 64bit versions. Also, along that road they've dropped support for ARM processors too. Therefore, before the first 64 bit OS versions were available for Raspberry Pi we would be required to stay with version 3.8.1 - but even that started to deteriorate over time until it stopped working altogether.

When Raspberry Pi 4 came out, I tried to resurrect it, learning a lot in the process - which parts of the code stayed, and which inevitably stopped supporting 32bit libraries and such. It was quite painful and I found myself at one point trying to fix hundreds of calls to work with 32bit and still failed. Also, alongside what I have been doing, some other efforts to provide Eclipse on Raspberry Pi like here.

But now that's not a problem any more - we have a 64 bit Raspberry Pi OS and code for x86_64 compiled for aarch64 'just works'.

(Short) How I Did It

(Attempt one and at the time of writing this the only one)

Disclaimer: this is not to allow straightforward reproducibility but to serve as some kind of reminder to myself and give insight to anyone who might be interested. So here it is:

Attempt On 'The Right Way'

I've started from Platform-releng/Platform Build. Got all sources and searched for x86_64 Maven sub-projects to copy/paste them and renamed them to aarch64 and all references to x86_64 inside of those new Maven sub-projects. At the end it seemed that I found only five (all in eclipse.platform.releng.aggregator):

rt.equinox.binaries/org.eclipse.equinox.launcher.gtk.linux.aarch64
rt.equinox.bundles/bundles/org.eclipse.equinox.security.linux.aarch64
eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.aarch64
eclipse.platform.team/bundles/org.eclipse.core.net.linux.aarch64
eclipse.platform.resources/bundles/org.eclipse.core.filesystem.linux.aarch64

But that's not enough. I've been through three days of Maven builds from 1.5 hour up to 3+ hours hunting down 'what else I am missing' and 'what else I don't know about the build' (I should) before giving up. Those things I learnt among others were:

eclipse-platform-parent/pom.xml - needs another 'environment' added (linux/gtk/aarch64)
adding <strictVersions>false</strictVersions> to tycho-packaging-plugin configuration helps
same as adding <baselineReplace>common</baselineReplace> to tycho-p2-plugin configuration
there's 'environment' in eclipse.platform.releng.tychoeclipsebuilder/equinox.starterkit.product/pom.xml, too
eclipse.platform.releng.tychoeclipsebuilder/equinox/buildConfigs/equinox-launchers/build.xml has buildRepos to be updated (maybe?)
building without tests helps a lot! (-DMavenSkipTests=true)
places like eclipse.platform.releng.tychoeclipsebuilder/rcp.config/build.properties contains something needed for native builds (copy paste of x86_64 to aarch64). Also, there are a few others places where build.properties exist with same/similar content to be added.
eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.aarch64 - already exists!
same as rt.equinox.framework/bundles/org.eclipse.equinox.launcher.gtk.linux.aarch64 (these two helped a lot)

Still - all of that didn't yield the correct build. The main issue arose from baselineReplace and how versions are treated in the build. For instance:

Cannot complete the install because one or more required items could not be found.
        Software being installed: EclipseRT OSGi Starter Kit 4.16.0.I20200605-0711 (org.eclipse.rt.osgistarterkit.product 4.16.0.I20200605-0711)
        Missing requirement for filter properties ~= $0: org.eclipse.rt.osgistarterkit.product.executable.gtk.linux.aarch64 4.16.0.I20200605-0711 requires 'org.eclipse.equinox.p2.iu; org.eclipse.e
quinox.launcher.gtk.linux.aarch64 0.0.0' but it could not be found

(see that 0.0.0 version)

Fallback On Quick And Dirty

So, after a while I dropped to a fallback solution which involved downloading x86_64 version of Eclipse IDE for Java Developers archive (eclipse-java-2020-03-R-linux-gtk-x86_64.tar.gz from https://www.eclipse.org/downloads/packages/) and update it to work with those five aarch64 versinos of launcher, swt, security, net and filesystem plugins.

First I've rebuilt those packages with something like this:

In: eclipse.platform.releng.aggregator/rt.equinox.framework/bundles/org.eclipse.equinox.launcher.gtk.linux.aarch64

$ mvn -DMaven.repo.local=../../../../local-repo clean install -Pbuild-natives

In: eclipse.platform.releng.aggregator/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.aarch64
In: eclipse.platform.releng.aggregator/eclipse.platform.team/bundles/org.eclipse.core.net.linux.aarch64
In: eclipse.platform.releng.aggregator/eclipse.platform.resources/bundles/org.eclipse.core.filesystem.linux.aarch64
In: eclipse.platform.releng.aggregator/rt.equinox.bundles/bundles/org.eclipse.equinox.security.linux.aarch64   (sudo apt-get install libsecret-1-dev)

$ mvn -DMaven.repo.local=../../../../local-repo clean install -Pbuild-individual-bundles -Dnative=gtk.linux.aarch64

I've then unzipped the tar.gz archive, found those five '_x86_64' packages, and dropped replacements back in. Also, I had to find launcher (executable from eclipse.platform.releng.aggregator/rt.equinox.framework/features/org.eclipse.equinox.executable.feature/bin/gtk/linux/aarch64/launcher) file and copy it over eclipse executable in eclipse folder and make it executable (chmod a+x eclipse). But it wasn't enough. First obstacle was that packages had '-SNAPSHOT' and Eclipse didn't like it. I've updated the versions (and strictVersions configuration - see above) and build them again. But, even that wasn't enough...

Next was to go through: - in eclipse.aarch64/eclipse.ini replaced reference of 'x86_64' lanuncher to 'aarch64' one (full filename with proper new filename) - features/org.eclipse.platform_.../feature.xml, features/org.eclipse.e4.rcp_.../feature.xml and features/org.eclipse.equinox.p2.core.feature_.../feature.xml and update references to '_x86_64' to '_aarch64'. But to do so I had to extract all jar files of launcher, gtw, security, net and filesystem plugins and peek into META-INF/MANIFEST.MF to get their respective versions so I can update above files properly. - updated artifacts.xml (not sure if it was needed)

And it still didn't work. But at least it complained that new jars aren't signed (or at least I think that was the issue). So, I created a new keystore with self-signed certificates and signed jars. And just in case added -Declipse.p2.unsignedPolicy=allow to eclipse.ini.

But what finally did it was to update configuration/org.eclipse.equinox.simpleconfigurator/bundles.info with correct versions.

There's one odd point - a grey area in the process. There are two more x86_64 files in original eclipse directory: - p2/org.eclipse.equinox.p2.core/cache/binary/epp.package.java.executable.gtk.linux.x86_64... - p2/org.eclipse.equinox.p2.core/cache/binary/org.eclipse.platform.ide.executable.gtk.linux.x86_64...

I don't know what those two are for, nor where and how they are used. I failed to find epp.package.java.executable.gtk as a package in Eclipse's source tree. Also, I've got two exceptions coming from Webkit in console, but they didn't directly affect rest of eclipse's operations. So, fingers crossed they are not that important.

Conclusion

It is not ideal, not clean and easily reproducibly built, but at least it made my day. Eclipse UI is as responsive as other UI apps on Raspberry Pi and now Java development is much easier - more responsive. No up to 5-10 seconds lag between finishing typing and starting app. Also, there's the familiarity of using same the IDE for 18 years (I got into it around 2002 and it was love at first sight).

And what do we have now? An Eclipse platform which works on Raspberry Pi. Starting point is Eclipse for Java Developers, but as it is build on OSGi, any other plugin, set of plugins or feature(s) can be easily added to it (as long as it doesn't require native code). I've tested Maven integration and Gradle integration and both are quite happy with what we have.

Next Steps

There are two/three steps I can see from now:

Get this process of 'fixing' linux gtk x86-64 version with those 5 'hand-built' packages automated somehow (or as much as possible). That's the least interesting version - as no matter of automation it will include manual steps and it will be prone to problems mid-term as code progresses.
Get Maven build working and learn how to build Eclipse product properly. This requires acquiring extra knowledge - but it could be then properly automated and replicated locally by anyone with Raspberry Pi.
And ultimate goal would be to get Eclipse Foundation to once again adopt aarch64 for good and have those builds done along with other builds

Time will tell how far we'll be able to go...