Is Eclipse JDT dying?
blog.dripstat.com
blog.dripstat.com
JDT is not dying.
I am the Executive Director of the Eclipse Foundation, and I am here to tell you that the commit numbers quoted in the blog post are completely bogus.
The stats shown on the Eclipse project pages only show the activity in the master branch. At the moment, the vast majority of the JDT activity is happening in a separate Java 9 branch. If you actually look at the git repositories directly (see link below for one repo), you can find a couple hundred commits in September, not zero.
The other thing going on is that the team has been in rampdown mode for the Mars.1 release shipping in the first week of October. A code freeze leading to a release is standard operating procedure for the Eclipse project.
In summary, this article is based on incorrect and incomplete numbers, and is entirely misleading.
http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/stats/?per...
The JDT root project is basically only going to show commits to build scripts and the like.
For those who are interested, you can read the Eclipse 4.6 release plan, and see the stuff planned for next June's release. But at the risk of repeating myself: a lot of the energy is going into the Java 9 work.
https://www.eclipse.org/projects/project-plan.php?planurl=ht...
My only major gripe: Why aren't the Eclipse binaries signed with GPG keys? The binaries are served off mirrors. We just saw XCodeGhost happen. This really needs to be fixed.
Minor gripes: ARM builds would be nice. Hi DPI would be nice.
Regarding the GPG signing, currently we sign every executable and jar inside the zip file, and rely on SHA checksums to allow users to verify the content. If you think that's insufficient, could I ask that you open a bug explaining your reasoning?
There are ARM builds available at fedora.org. But I agree that getting those available somewhere on eclipse.org would be sweet.
I think high DPI is on the list of things to do. Contributions are always gratefully accepted :)
Thanks for using Eclipse!
Indeed it can and does, but welcome to HN where people care about setting the record straight. Thanks for coming and giving us the facts, and welcome to the community too!
As a long term user it feels like no one from the Eclipse project actually uses Eclipse to write code anymore.
I now use JetBrains IDE's and VIM and it's a totally different world. It's nice to not have to think about what random Eclipse plugin is colliding with what other random minor version update that is stopping me from using the debugger correctly.
Sometimes if a task is complex, annoying and specific enough, it's better to just pay a company to produce a maintained tool rather than relying on the open source community to just "solve it for you".
A good analogy might be Gimp vs Photoshop. Gimp is great for learning and gets you there, but if your job depends on it, it starts making economic sense to pay someone for something better.
I started using Eclipse back at School and it was great at getting me into programming. It will always have a place in my heart ... just not on my hard drive :/
If there's one thing I hate about Eclipse, it's that it's kind of ugly :).
Also for the past 2 years I haven't been coding much java, mainly python django / javascript. And I will say the tooling for django debugging in PyCharm is really excellent, both in setting it up and daily use. The Eclipse plugin might work but really PyCharm is the meth of debugging setups: It'd be hard to leave.
* No true multiproject/workspace support (with maven integration)
* Slower compile times than in Eclipse, somehow
* Have to hit an extra shortcut after editing a file for a hot reload to happen while debugging
Am I just crazy, or are these really areas that IntelliJ is weaker in than Eclipse?
Java projects on the other hand have to be in separate windows and its annoying. I don't even program in python anymore but I keep renewing pycharm just for the Javascript project convenience that beats intelliJ
* Whenever I Alt-Tab to some other application, and then Alt-Tab back to IntelliJ, it somehow selects Menu, and I need to actually get off hands from my keyboard, click on the editor frame, and only after all of that hassle I could continue typing. Happened on multiple machines using multiple operating systems.
If only Adobe hadn't enough of a monopoly to be able to demand arbitrary prices.
If ~$10/month is too much for the best photo organiser and the market leading photo manipulation software, then you're basically saying no-one should be able to make any money out of software, ever.
With a yearly subscription. Otherwise it's $100.
That's a lot of money considering the old creative suite used to cost less than $2000 in total. More like ~$500 per year or less.
Hey, if you feel like paying for Eclipse, you totally can :) That because, Eclipse is a basis for IBM's commercial IDEs such as "Rational Application Developer", "Rational Software Architect", etc. IIRC, some of these go for $5,000+ a pop. So, anyways, Eclipse is not built by some random open source enthusiasts, it is mostly built by IBM employees.
I wrote up some notes on the experience - differences in shortcuts (on a mac) and features and whatnot, here:
http://www.davnicwil.com/eclipse-to-intellij-on-a-mac/
Should be a useful to skim through it as a quick-start, will save you some shortcut/setup googling at the very least.
Are these comments just relics of experience from years ago, or is there some secret I'm using in having Eclipse be around 2x the speed of Jetbrains? Just tried opening an Android Java project in both Eclipse and Android Studio and the Eclipse is finished loading before Android Studio is even 20%
Other than that, Eclipse is free software which is important in the same way Linux is important to cultivate even though we have Windows.
Basically I've found that a lot of Eclipse plugins and core pieces associated with the debugger allocate a lot of heap space that never goes away.
However I haven't used Eclipse in about 3 years (or on Java 8), or for Android, so if there's something new I'm missing, your point might be valid.
I fully share your sentiment. The rest of my comment is eclipsed (no pun intended!) by this.
That said, SSDs are still not that widely deployed in my country, and almost never in cheap developer laptops. Yes, yes, we can argue all day long about why employers still consider buying good developer machines a needless expense, but meanwhile accept that in many places in the world that is the case.
So the question becomes... when the hell did Eclipse decide that in order to work decently you had to use an SSD? Why did its performance degrade so much; what new and revolutionary features did this performance degradation buy us? And why does IntelliJ work so much faster in the same, non-SSD hardware?
In the long run everything will be using SSDs so maybe it won't matter in a couple years? Can see it now: Developer headlines in 2019. "Have you checked out this never before seen IDE called Eclipse? It's blazing fast!"
Yes. It's still so slow that I'm faster by using Vim with the javadocs open in a browser window.
It's not just disk I/O. CPU overhead and memory consumption are crippling, too.
I saw the same thing in the early HTC/Samsung smartphone wars. Lots of negative comments/reviews but once you added all the required Sense features via 3rd party apps to comparable Samsung/Google phones the speed was seldom as good.
Turns out in that case, it was actually paid astroturfing on samsung's part:
http://www.idigitaltimes.com/samsung-fined-340000-fake-htc-r...
Sadly I find the android studio (intellij) spped about the same as elcipse and I don't have any plugins loaded in Android Studio.
I'm using Eclipse on work laptop with SSD, and it is soul-crushingly slow, much slower than Idea.
Second: Eclipse "edition" matters... like, there is Eclipse for "Java developers" and the one for "J2EE developers, etc". The J2EE edition includes some tooling for Javascript, and that can get completely stuck (CPU at 100%, vents screaming) while trying to deal with large Javascript libraries (say, jQuery). So, try disabling Javascript validation, see if that helps, or just get a Java developer edition. BTW Eclipse support for Javascript is not good at all, so no big loss if you disable it.
Next... it used to be that certain antivirus software (McAffee for sure) was slowing down everything big time.
Anyways, on a fairly old machine with 8GB RAM, SSD, i7 (4/8) and Oracle JDK and Eclipse 4.4.2. Eclipse works very well. Btw this is on OSX, but some people here use Windows, and it seems to work well on that, too. Hope this helps!
Then Netbeans began improving quickly, IDEA had a free edition and Jetbrains released many good IDEs for other languages as well.
Game over.
IDEA has probably less features, and third party plugins don't necessarily work well together; but you can see the idea of the "ide as a whole" behind Jetbrains products.
It was free & open source, and had superb autocompletion and refactoring, and a decent debugger. What else could you ask of a Java IDE?
Unfortunately, it seems to me Eclipse has become more unusable, slow and confusing with each iteration. But it didn't start that way. I seem to remember one major version which completely changed the UI, and at the same time the team disabled most UI tests, and the justification was "most tests broke with the latest change, and we don't have enough resources to fix them". And it showed...
what about settings and configuration... export your eclipse settings from one workstation to another can be half day of work.
Once you increased a few limits like the Java max heap size [0] Eclipse was a bit slow to start, but -once started- was no slower than any other full-featured IDE I'd used. CDT was really nice, and the Java tooling worked as well as I expected it to.
The two really big issues I had were the really terrible dependency resolver -which not infrequently required you to update packages in stages, playing the "Which package(s) is giving the dep resolver grief now?" game for several fives of minutes-, and Eclipse's tendency to cache all sorts of file state. Once you learned what Eclipse cached, you knew what sorts of things to not do outside of Eclipse, but until then... oh, the mysterious errors one was likely to receive! :P
[0] Rant: Why the fuck is this even a tunable? Every other program I use (including software written with a language that targets a GC'd VM like C# or Erlang) is completely capable of regulating its own memory usage. Why does Java need me to tell it how much memory it is allowed to use?
My personal comparison:
Once you have the right plugins it's super easy to create a scala project with maven in Eclipse. I had to download scala sources and tell IntelliJ their location, still it didn't work. Forget about maven. (I'm sure IntelliJ gurus can set it up, my point is it's not easy for n00bs)
There was a 2 month window a year ago where I used eclipse, before I forced my new company to buy IntelliJ.
https://github.com/eclipse/eclipse.jdt.ui/graphs/contributor... https://github.com/eclipse/eclipse.jdt/graphs/contributors https://github.com/eclipse/eclipse.jdt.core/graphs/contribut...
The only real fly in the ointment to me, is something that isn't any fault of Eclipse itself. The Groovy/Grails IDE has not(last time I looked anyway) shipped a Mars compatible version, meaning I'm stuck using an older version of Eclipse for doing Groovy/Grails work. But that's mostly, as far as I can tell, a side effect of Pivotal dropping their support for Groovy and Grails.
That's what I'm praying for every single day before I start Eclipse. Sadly, Eclipse keeps inventing new ways in which it breaks.
Support for languages OTHER than Java, however, vary wildly in terms of value.
One language support that seems to have crossed over into complete obsolescence is JavaScript. I hate to break it to you Eclipse Foundation, but developing JavaScript on a WebIDE is completely out of the question for many of us, so your fancy Orion system is a non-starter. It's mean of me to say, but I'm rooting for Orion to fail so you can move those developers back to enhancing the desktop IDE's JavaScript support.
Eclipse JSDT is my only option, and it seems broken and unmaintained. Around the 2008 timeframe, I was really impressed with JSDT's ability to build out a type library as it parsed my prototypes, it really understood the type system when I added JSDocs. It all works ok for rink-a-dink projects that are targeting the browser and coexisting with HTML. But, for any modern development like server-side Node.JS or CommonJS browserify/webpack projects in the browser, ES6 or anything modern, Eclipse JSDT is really up a creek without a paddle. I can't use you, and that makes me so sad to say because I WAS a staunch Eclipse user who turned his nose up at JetBrains!
To make matters worse, Eclipse has gotten slower and buggy since the last major upgrade (Luna?) and WebStorm is cheap and great and amazing at parsing JSDoc's to the point it practically turns JavaScript into a statically typed language, and it groks CommonJS and my node_modules folder (with the help of a little plugin I downloaded.) I admit I haven't tried running Eclipse in a year, so perhaps the bugginess has been addressed.
Given the old system they are trying to extend and enhance, I'm not surprised it didn't work.
IMO Eclipse is a product of a particular type of engineering, one that is done on a 9-5 payroll, and never as a labour of love. I've always found it awkward to use and surprisingly difficult to configure - even simple things like syntax highlighting is spread over multiple locations in the byzantine preferences. The whole perspectives thing, and its obsession with you selecting a workspace, up front, which is distinct from the project you're working on - it forces the user to adopt its internal idioms and jargon, rather than the other way around.
Eclipse killed off JBuilder's original IDE back in the day, undercutting it. I far preferred JBuilder's UI.
https://projects.eclipse.org/projects/eclipse.platform.ui/wh...
I found Perspectives odd at first, but I grew to like them. For the work I was doing, being able to set up a couple of modes, each with its own set of open and positioned windows was rather useful.
As to workspaces, I initially found it strange that I was expected to have like all of my projects in a given workspace, but Working Sets (or whatever the thing was called that opened certain sets of projects and closed all others) made that pretty reasonable. I did end up having separate workspaces for my C++ work and my Java work, though.
Intellij pretty much took over
* Open-source, with an apparently large community
* Extensible within itself via plugins
* Some interesting GUI features:
* User- and plugin- definable and customizable
"perspectives" that captured specific workflows, e.g.
debugging, language X editing, schema editing, etc.
* For its time, relative to other IDEs (Visual Studio,
I'm lookin' at you) a much easier approach to managing
panes and tabs to the user's liking.
* The fantastic ability to quickly narrow the settings
pane navigation via text search. OS X's System
Preferences later added a similar feature to find &
narrow pref panes based on a keyword search. I still
feel that there's untapped opportunity for GUIs and
traditional editor modes (emacs/vim) to leverage
spinoffs from this interaction model.
That said, Eclipse never seemed to surmount what I feel were its major difficulties:* The Workspace -- IMO the most absolutely toxic abstraction an IDE has ever had. All "projects" must live under a "workspace" which is both an on-disk top-level directory+data that users must cope with above their project(s) and an inescapable in-code monstrosity that plugin writers must also cope with. This was a mimicking of other IDEs that thought it was a good idea to maintain an entire separate organizational data structure for code that created a separate hierarchy that duplicated and obscured the on-disk organization, and a short-sighted hard-coding of a Java-centric mindset where any non-trivial codebase was certainly going to consist of multiple interdependent projects. The Workspace was a core architectural disaster. A symptom: it made Eclipse ridiculously painful to use to, e.g., "just edit a python file". Contrast with TextMate's lightweight approach of "a directory is a project" and fast in-project navigation/fuzzy search tools. No state was required other than what was on disk. TextMate's full power and bundles were available with zero friction for either project-centric for file-centric work.
* Speed -- The more time goes on, the less excusable Eclipse's dog-slow performance is. Early on, it was easy to overlook its slugishness, because reasons. Some recent work has had me suddenly delving back into (two different!) Eclipse projects, and its amazing just how the poor the UI responsiveness compares to other modern environments, even on screamingly fast hardware.
* Extensibility schizophrenia -- Despite Eclipse being extensible through plugins, those were really envisioned as third-party shippable modules. User configuration was a separate second-class sytem, entirely GUI-managed, and a major pain to clone to a new system. Compare to how Emacs & Vim work with a VCS-managed home directory, or even just a zip file or tarball. In no small part, this came from Eclipse's foundations on an early Java/JVM compiled-only mindset. With no scriptability baked into that platform, there was little choice but to have a strong divide between code (plugin) vs. data (configuration).
eclipse foo.md # NOPE!
eclipse /path/to/my_rails_thing # NOPE!
'man eclipse' is telling: eclipse [ platform options ] [ -vmargs [ Java VM Arguments ]]
Read through "platform options" and the intent becomes clear: you're starting a black box, not wielding a tool.This is all really unfortunate, since Eclipse became home to the first (to my knowledge) open-source platform for a wide range of AST-aware language tools, and all the power those can enable. These often grew up with alternative language implementations on the JVM. Other extensible development editors are still largely stuck with some flavor of regexp soup and/or a cobbled-together pot of external tools with widely varying performance, usability, and UI.
ps: oops, that was meant to be an answer for https://news.ycombinator.com/item?id=10274067
Other than the speed part, the main reason I keep using Emacs is because of the easy-to-access-remotely part of it. I've got a nice beefy Linux box at home that I can ssh into. Tmux keeps my sessions alive. Emacs lets me do all of the code editing. And the nice little Surface 3 is easy to carry around and makes a fantastic SSH terminal.
But it makes a lot of sense so many times. Very pragmatic, extensible simply. It's still thin spaghetti compared to the "sturdiness" of Java/Eclipse. But I've seen the internal long time ago and it was just a fatter model of spaghetti.
Anything in Eclipse requires a lot of efforts, and too many times the original goal gets diluted in the implementation. I said it elsewhere, after spending 2004-2007 on Eclipse, then leaving for Emacs, I recently had to go back to Eclipse, it's not better, git integration is useless, lots of windows for no reason, a very special kind of UI, maybe suitable for people that likes windows and mouse.
It's sad because it comes from the same community that creates the most job friendly systems, so if you wanna play with JEE/Maven/EMF/..., you'll end up needing something like Eclipse, because of this subtle synergy.
I know a lot of iOS developers that hate development for Android and I think Eclipse is a major reason. Unlike Linuxers, Macers know that a good user interface is possible thus they can't put up with the crashing, slowness, pluginitis,...
Thanks for the insightful analysis.
- Dependencies between modules in the same source base for one, which given the most common setup (single workspace) Eclipse will quite happily ignore and treat everything as one module.
- The default static analysis setup misses so many common things (unused imports, methods, variables) that whenever I open a class in IntelliJ I have to spend 5 minutes removing the cruft.
In its time Eclipse was a good IDE, but its time has passed.
Wait what? I have no idea what you are talking about. If modules are depending upon each other via Maven, you simply stick dependant one to the other's classpath if you want to use the workspace version.
> The default static analysis setup misses so many common things (unused imports, methods, variables) that whenever I open a class in IntelliJ I have to spend 5 minutes removing the cruft.
I'm looking at the same project here side by side and once again I'm not sure what you are referring to. If anything, some of IntelliJ assumptions for code quality can actually result in more fragile code if you aren't careful.
That does not jibe with my experience with Eclipse at all. I see the stock configuration being quite comprehensive in showing those kinds of warnings, including all three of the items you just mentioned.