Losing my mind with Java Eclipse on Linux

Background

I’ve ported a project that I wrote in C# to Java to aid in job my job search. Its complete and I just cleaned up the github page to remove unnecessary files created by the IDE. I thought it would be a good idea to clone the project and make sure it will easily build in whatever IDE I pull it into before moving on.

I pretended I was a recruiter and cloned the project to a new file and imported it fresh into the following IDEs

On Windows:

  • Eclipse :white_check_mark:
  • NetBeans :white_check_mark:
  • VS Code :white_check_mark:

On Linux

  • Eclipse :x:
  • NetBeans :white_check_mark:
  • VS Code :white_check_mark:

Problem

Whenever I tell Eclipse in Linux to run the project it gives me the following message:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f84087910d4, pid=140, tid=141
#
# JRE version: OpenJDK Runtime Environment (16.0.2+7) (build 16.0.2+7-67)
# Java VM: OpenJDK 64-Bit Server VM (16.0.2+7-67, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  0x00007f84087910d4
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/aaron/git/JavaSpreadsheet/core.140)
#
# An error report file with more information is saved as:
# /home/aaron/git/JavaSpreadsheet/hs_err_pid140.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

I have tried the following:

  • Restoring Eclipse defaults
  • Purging Eclipse from my system and reinstalling
  • Purging Java from my system and reinstalling

I don’t seem to be making any headway. I haven’t tried going back to a previous commit before the file cleanup in the project but that is my next step, however since it is working everywhere else that would be my last idea. Looking to see if anyone else has any thoughts.

Thanks

Have you tried running it on an older / newer java version? (v11/v17)

I haven’t tried a different jdk installation though I have tried a different compiler compliance level through the IDE. I’ve also done as I suggested in my original post, which is rolling back the project itself to a different commit.

I’m on Pop!_OS 21.04 using the default jre “openjdk version “11.0.11” 2021-04-20. I’ve”

I don’t know If I’m running into a problem with the flatpak installation of eclipse, a unique configuration of my environment or the jdk/jre itself. I can try to test each.

I can try to test flatpak by installing the native apt version of eclipse
I can install the newest (v17) of the jdk to test the jdk
I guess spinning up a vm and installing eclipse there should help me isolate the environment.

These are just stabs in the dark though because it compiles fine using other IDE’s and this jdk on this environment. The error is only happening in Eclipse.

Oh yeah, flatpacks and snaps cause problems in many cases, so I’d try to avoid them, when running into problems.

Also flatpacks don’t use the installed JDK, but come with one of their own AFAIK.

Also if you want to test it in all IDEs you shouldn’t forget about the most used Java IDE: Intellij IDEA. They have a open source community edition, that’s probably perfectly sufficient for your use case.

3 Likes

Installing the latest native version of Eclipse as opposed to the flatpak did the trick. I wasn’t aware that flatpaks didn’t use the installed JDK. I’m glad I learned now so I don’t have to trip over that in the future.

Also thanks for the advice on Intellij. I’ll run a test there just to make sure. IDK why I didn’t think of it at the time.

2 Likes

Flatpacks are supposed to be like containers, they ship all dependencies themselves and contain the application inside some boundaries. That often causes bugs though.

I assumed (hoped) it would avoid issues with the unique environments on a user’s machine though which is why I have leaned towards it since I switched to LInux in January. I’ve stubbed my toe on assumptions more times that I would like to admit :sweat_smile:

Well if they work, they usually work fine everywhere, but to get them working perfectly, a developer probably needs to put in a little bit of work.

The flatpak version of Eclipse broke down so many times for me that I gave up and switched to IntelliJ. Surprisingly (for me at least), support for Eclipse on Linux is much worse than on Windows.

Snaps and flatpaks are often not maintained by the applications developer! If you want a application to run as intended, install it as intended. In the case of Eclipse it means from the provided tar ball. The distributions integrated package management is mostly also a dependable source to install software from. Installing a package thrown together by some random person is not trustworthy.

Its the sandboxing. You would have to tell the flatpak to ignore filesystem sandboxing and use host. Giving it full perms which essentially kills the point of thr flatpak

1 Like

Lol. I just git build my stuff if I cant find it in the arch repo

Been so nice staying close to upstream. Absolutely zero breakage

Fucking “stable” is a meme I refuse to believe and I hate flatpaks and snaps

1 Like

A stable model can also have advantages. If I run a business based on certain software, I would test it on an LTS distribution and then run it worry-free until the end of the support period. For private use I see more disadvantages than advantages, because if you encounter a bug, you will stuck with it until you upgrade.

1 Like

Snaps and flatpaks are often not maintained by the applications developer!

Actually, the VSCode and Mozilla snaps are maintained by Microsoft and Mozilla in partnership with Canonical.

The distributions integrated package management is mostly also a dependable source to install software from.

The arch version of vscode is a rebuild of the open-source code without some prop bits that are needed for a few docker extensions. Would recommend using the snap version.

As I said, often. Eclipse is not!

By the way, many corporations that employ Java developers will also use Jetbrains IntelliJ for Java devlopment, so you should test that as well. You can get the all product pack for free as a student!

1 Like

Do you do git-rebase and automated re-builds after every upgrade?

2 Likes

Yup set a pacman hook for it too so when I upgrade the system they come with

1 Like

Most projects in the Java ecosystem also use some sort of build tool. Gradle or Maven. I think it is somewhat more important to disclose that and if there is any specific JDK or software the project needs.
Presumably you don’t have to explain them their IDE and one of the upsides of using a build tool is that it’s easy to build without an IDE at all, which is very nice for automation. But also when you can build it without an IDE you don’t have to worry so much what IDE they are using.

1 Like

I usually install Java in my home directory, including all the tools, instead of relying on whatever the distro ships. For development I’d honestly recommend that approach, especially once you start needing multiple JDK versions, or deal with projects that for some reason must have an Oracle JDK.

On another note, I’d recommend giving IntelliJ IDEA a good look, it’s so much better than Eclipse (imho), that they’re not even in the same universe. Eclipse has barely improved since I was in college (that’s get towards the 2 decades mark, fwiw), and still suffers many of the same problems it did then (like locking you out of your IDE while re-indexing for ages, the abysmal Maven support, etc.). I give it a go for a week every other year but at this point I wonder why I even still bother.

2 Likes