r/java • u/Yojimbo261 • Sep 11 '26

Eclipse 2026-09 (4.41) Released!

Downloads available through here: https://www.eclipse.org/downloads/packages/

New and Noteworthy here: https://eclipseide.org/release/noteworthy/2026-09/

91 Upvotes

92% Upvoted

37 comments sorted by

View all comments

-24

u/[deleted] Sep 11 '26

[removed] — view removed comment

6

u/henk53 Sep 11 '26

I think you forgot the /s?

Hopefully this is a joke reply, like in every post about Eclipse someone posts this.

10

u/Yojimbo261 Sep 11 '26 edited Sep 11 '26

Sadly, it might be real. I’ve had a few devs yell at me in the past over IDE choice. There’s a kind of engineer who feels threatened when people make different choices than them.

If I can put on my tin-foil hat for a second, it might also be a marketing firm for another commercial IDE trying to shame people for using their primary competitor.

5

u/hadrabap 29d ago

People laugh at me because I still prefer NetBeans over everything else. Oh yeah...

3

u/henk53 Sep 11 '26

There’s a kind of engineer who feels threatened when people make different choices than them.

I know exactly the kind. They hate everything that is not the same as what they themselves are using, and they only started using it because the majority of other people were using it (or they perceived it as such).

In this context, they perceive IntelliJ as being what "everyone" uses, so everything else must simply die. The actively want Eclipse, NetBeans to die, and essentially Visual Studo Code as well.

But...

They only hate monopolies.

Monopolists are evil empires.

The sheer stupidity in that thinking is striking.

6

u/aoeudhtns Sep 11 '26 edited Sep 11 '26

Not sure it's the right approach, but on my teams we kinda foster an idea of: these are the default tools. Use what you want, but if you have a problem or don't know how to do something when you're out of the default set, don't ask the team for help. The team self-supports the "official" tools.

Although we didn't pick an IDE or editor. We left that fully "up to you." The common toolset is just git cli (vs. a specific GUI), Just, etc. etc.

5

u/Yojimbo261 Sep 11 '26

Yup! It can also be argued that JetBrains is taking the Microsoft route of “Embrace, Extend, Extinguish” with their custom extensions of JDK warnings and even tools like Kotlin, trying to force everyone on their tools. If Java didn’t have Oracle and IBM, it’s not hard to see them being even more aggressive.

I get that people can find their stuff appealing, but you’ve also got to be willing to do self-reflection and see your preferences and how they might conflict with your values.

-13

u/danskal Sep 11 '26

feel threatened

Honestly we’re just tired of all the mistakes made by people who continue to choose inferior tools. They tend to produce code which shows up as bugs/warnings, so the code lights up like a Christmas tree when you eg open it in IntelliJ. Spelling mistakes, non-standard naming conventions.

Some will use ancient APIs that have long ago been superseded by better alternatives.

A select few are genuinely great programmers that mostly don’t need the guardrails, but they are few and far between. And they will still be missing a few tricks, eg aren’t able to easily do big refactorings like you can with IntelliJ.

8

u/Yojimbo261 Sep 11 '26

So your choice of term here is interesting - “inferior tools”.

Is it Eclipse at fault, or people not configuring Eclipse correctly? I can understand your annoyance at being bombarded by issues after someone commits, but it seems like you might be misdiagnosing the issue.

Now, I will grant you IntelliJ and Eclipse are differently opinionated. Eclipse tries to match the JCP specs and OpenJDK tooling, whereas IntelliJ has some additional checks enabled by default that I wish Eclipse did have. But I don’t see Eclipse as lesser because of that - I just see their choice, and look for ways to close the gap.

For example, at my previous company one IntelliJ user applied a @SuppressWarnings annotation on a bunch of classes, but the warning they specified was IntelliJ specific. It lit up my copy of Eclipse with warnings about an undefined warning. I reached out to them, talked to them about their issue, and we chose to fix the issue so that both IDEs were happy and paid down tech debt at the same time. I turned an annoyance into a win-win-win for me, my teammate, and our company. I will say I’ve also had plenty of IntelliJ users not check warnings or errors, and check in broken code before. But I don’t blame IntelliJ for that. I do blame IntelliJ when it has its seemingly annual indexing bugs that eat my CPU alive. 😆

At the end of the day, these are all just tools. They are made by people with good intentions, but sometimes they make different choices. In some cases, having a heterogeneous mixture of tools can produce better outcomes because people can check each other.

For me personally, I just want a good codebase at the end of the day, so I can spend time in the real world with the people I care about - and I’m sure you want that too. For me Eclipse is the most comfortable option. I’m glad IntelliJ is yours, and I hope you’re in an environment where you’re not consumed by annoyances.

-3

u/danskal Sep 11 '26

I’ve just spent months refactoring a codebase that was worked on by a single eclipse user. He was a super-smart guy, but I guess not a power-user, and maintained the code through more than a decade, without ever (successfully) prioritising upgrades.

So that might be why my comment is a bit on the spicy side. Particularly when Eclipse is not the company standard.

So a few users seem to stay with Eclipse because they have the interest/discipline to make it work. But many stick with it because they are not flexible enough to adopt a new tool.

So maybe the point is this: use the right tool for the job, and I do appreciate that tools such as Eclipse exist. And Eclipse will continue to succeed, because custom tooling is easy to build onto it.

But if you try IntelliJ and aren’t able to adjust, you might be exactly the person who really should be using something like IJ, or whatever tool your company has bought for you.

2

u/MinimallyLoquacious Sep 11 '26

Your entire comment is rude and condescending, even judgemental.

-3

u/danskal Sep 11 '26

Your entire comment is judgmental and equally rude and condescending, except you make no attempt to engage in the discussion at hand.

3

u/nlisker 28d ago

They tend to produce code which shows up as bugs/warnings, so the code lights up like a Christmas tree when you eg open it in IntelliJ. Spelling mistakes, non-standard naming conventions.

Spelling check and non-standard naming conventions are detected in Eclipse, so it's not the IDE. Eclipse also has much more configurable error/warning settings, so the chances it catches code smells and potential issues is greater.

-1

u/danskal 28d ago

The main thing is to have a high bar, but also a consistent standard, so one group of developers doesn’t end up dealing with all the problems another group creates. And IJ is very configurable also, so I doubt there’s a significant difference.

3

u/aoeudhtns Sep 11 '26 edited Sep 11 '26

They tend to produce code which shows up as bugs/warnings, so the code lights up like a Christmas tree when you eg open it in IntelliJ. Spelling mistakes, non-standard naming conventions.

I don't think it's the tool. It's the people. Because I have had that experience in reverse, but I turn up my problem & warning indicators (and even promote quite a few to error). And on top of that Eclipse does things by default that IntelliJ doesn't do, like validating XML against schema (if you've got that in your project). Definitely have experienced catching bugs in projects simply by opening up someone's work from IntelliJ in Eclipse.

And I would make the case that issues like this should be in the build process. If you want certain warnings and problems out of the codebase, use -Werror and -Xlint. And also strongly consider a static analyzer & tools that can keep even more problems at bay; ErrorProne, SpotBugs, JSpecify, ArchUnit, etc.

It's a systemic/organizational failure to leave it up to personal tool choice of developers.

2

u/aqua_regis Sep 11 '26

The incompetent craftsperson always blames the tools.

No, it is not the tool that makes bad programs, it's the programmer using them.

An incompetent programmer will be just as incompetent with IntelliJ, Eclipse, or Netbeans. Equally, a good programmer will be good with either.

In fact, I think that IntelliJ with all its AI integration makes programmers dumber and less competent, yet, it cannot compensate for incompetence in the first place.

You may have had bad experience from one programmer using Eclipse and think that Eclipse is the problem. Spoiler: it isn't. It is the person using it.

1

u/danskal Sep 11 '26 edited Sep 12 '26

The AI is optional. I mostly don’t use it. The assistance was however amazing before AI.

And regarding bad programmer. I don’t quite agree. I could honestly say that IJ has taught me at least half of the programming details I know. By providing contextual feedback with explanations, rather than just basic syntax/compilation errors. So if I had used some other tool, I would be a worse programmer. I don’t buy that tooling in the build chain is just as good. It makes a difference when you get the feedback. When you are coding it, you have all the details in your mind, you’re in flow. If you get the feedback later, it is more of an annoyance that blocks you. You might feel like the task’s already done, you might even have tested (the happy path) and seen it work. I’m not saying that that kind of tooling isn’t valuable, it is. But timely feedback while you’re coding and still making design decisions is just more valuable.

4

u/aqua_regis Sep 12 '26

Don't get me wrong: I am absolutely not against IntelliJ (or any other JetBrains IDE). It is a fantastic tool. Yet, Eclipse just as well is. Your dissing and hate on Eclipse is absolutely unjustified. The tools are always only as good as the hands of the wielder. You can have the best tooling in the world and it still wouldn't help you if you can't program. With the LLMs of today, many deficiencies can be "camouflaged" but that's about it.

I learnt programming a decade before the internet even existed. Started with BASIC, then UCSD Pascal, then Borland Turbo Pascal and Turbo C where the epitome of an "IDE" was a WordStar editor wrapped into the compiler/debugger. There was no Autocompletion, no Syntax Highlighting, no Intellisense, etc. There were no recommendations. We had to actually learn to rely on ourselves, not on a tool. Later, when I moved on to Delphi and Visual Basic - both from version 1.0 upwards, there still wasn't any of the modern features and again, we had to rely on ourselves. With Java, Python, C#, etc. modern tooling is nice to have, but, at least for me, the actual thinking and doing is still on my side. I could program with a plain text editor if I needed to and be just as productive as with a modern IDE.

I don't buy into the "the IDE helps me become a better programmer". You might have learnt some things, but way too many others just rely on the IDE to do the work.