Skip to main content

Why Eclipse is not as good as IntelliJ IDEA

3 months ago I switched to Eclipse after using IntelliJ IDEA for years. I soon learned that Eclipse doesn't let you configure the JDK it uses to compile your workspace, but the strange thing is, it allows you to configure the JRE it will use to run your code. I thought that was odd and would probably cause me headaches someday. Well today is that day. Today, I learned the extent of the problem when I attempted to run an Ant script through Eclipse. Long story short, when using Eclipse make sure you run the eclipse.exe with the -vm switch to define which JDK it should use and make sure the tools.jar in the Eclipse Ant classpath matches that same JDK. It's absolutely retarded that Eclipse allows them to be different. It caused me all kinds of 'class version mismatch' headaches. Why they thought it was a good idea to build projects and run Ant scripts in the same virtual machine that they run the GUI in is beyond me. IntelliJ IDEA has a much cleaner separation where they run their GUI in their own instance of the JVM (which they control tightly), and they allow you, the user, to specify what JDKs you have installed and which one to use on any given 'module' (Eclipse calls this a 'project') and which to use when running an Ant script. The beauty is its so flexible in IDEA that you can specify different JDKs for different modules and Ant scripts in the same IDEA project (a.k.a. Eclipse 'workspace'). I miss my IDEA.

Comments

ddrum said…
Of course it does!
You can add different JRE to the eclipse configuration in the preferences/Java/Installed JRE menu.

Then in the project properties you can chose to change the JRE in Properties/Java Build Path/Libraries/Add Library/JRE Library

And of course you must change the compiler settings in the Java Compiler project setting.
jaXzin said…
ddrum, unfortunately that only changes the JRE which runs the compiled code, it doesn't affect which JDK Eclipse will use to compile your code.

Popular posts from this blog

Paperless

I've been slowly going paperless over the past decade. The first step on my journey started in 2000 when I signed up to use a payment service, PayTrust, to receive my incoming bills, scan them, and put them online for me to pay. The next major step was probably when I got a digital camera to replace my traditional film cameras. It might not be considered a "paperless" use case, but it has lead to very little hardcopies over the years as monitors and HDTV with screensavers and AppleTVs have become so beautiful.  Back to the paperless office, my next big step was eFileing my taxes but that didn't come until about 5 years later. Then suddenly about two years ago, I hit a real shift in my desire to go completely paperless when I got my iPad and installed Evernote.

digital notes...
If you aren't familiar with Evernote its an excellent app, available on all the major desktop and mobile OSes, that makes note-taking and organizing really simple. The killer feature is …

3D Photo Viewer for Looking Glass

I created my first Chrome extension, which is now live on the Chrome Web Store! It's built for the Looking Glass, a holographic display that let's you view three-dimensional objects without glasses. I've also opened the source to the extension on GitHub.

The Chrome extension allows you to view Facebook's "3D Photos", a feature they added in 2018 for displaying photos that include a depth map like those from phones with dual cameras, such as Apple's "Portrait Mode".

Getting Started To use the extension, connect your Looking Glass to your computer, navigate to Facebook and open the viewer from the extension's popup menu. This will open a browser window on the Looking Glass display's screen in fullscreen mode.
Once the viewer is open, the extension watches for any 3D Photo files being downloaded, so browse around Facebook looking for 3D Photos.  I recommend some of the Facebook groups dedicated to this topic like Facebook 3D Photos, and th…

Simplifying logging with Maven and SLF4J (Part 2)

So in my previous post I explained how to simplify your logging with Maven and SLF4J. If you haven't read it yet, please do before reading more.  Since then I've discovered an easier and cleaner way to remove the secondary frameworks from your Maven dependency tree.

Here's a revised overview of the steps:

Decided which logging framework will be your primary, aka who will actually write to your log file.Define the dependency scope of all the secondary frameworks to be 'provided'.Configure your project to depend on drop-in replacements of each secondary framework from SLF4J.
Define secondary frameworks as provided
Use the dependencyManagement section for this. Its used when you might have a dependency transitively.
Add dependency on SLF4J Add the following to your pom.xml
Conclusion
So now in only 3 steps you can redirect all your logging to your primary logging framework without changing a line of code!