Imho Eclipse has never been a good ide. Its confusing user experience never appealed me. But then, it was free and had certain features and was quite extensible.
Then Netbeans began improving quickly, IDEA had a free edition and Jetbrains released many good IDEs for other languages as well.
I've always despised Eclipse. It was always a PITA and was a resource hog. It turned me off of all IDE's for years until I came back and saw the light with IDEA & friends.
Eclipse set the bar in terms of having an utterly vast list of features and wild west bazaar of plugins. It was like market research for the more sophisticated vendors. IntelliJ has the 30% of features users actually wanted with a much tighter implementation.
My impression is quite different: IntelliJ has comparable set of features, but the difference is that in IntelliJ those features actually work without annoying user. this started with a simple but brilliant idea JetBrains developers had: "disk space is dirt cheap, let's use 1-2 GB of it to store index, so that autocompletion could work lightining fast". Also, because it was initially developed by single company and single team of developers IDEA code (both core and plugins) is much more consistent in terms of quality than Eclipse's counterparts.
I am a long time happy user of IDEA but they seem to be always screwing up index these days. There has been version when the responsiveness of autocomplete has plummet. It has gone faster in places and slower in others. I think in general the worst case performance (people remember the annoyances more) has often regressed between releases too much. It seems every software out there is getting more features but the produces are getting sloppy and bug prone.
I agree completely. While Eclipse had a lot of plugins, it was often difficult to make them work together; so I was stuck with multiple Eclipse or eclipse customizations with a different set of plugins for each one.
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.
I disagree. Eclipse used to be a capable IDE, even if some UI choices were dubious (but everyone has opinions about interface design, don't they?)
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...
I started using Eclipse as a netbeans convert, I loved it initially until ofcourse I started using IDEA from Jetbrains. This has been the case with most of my friends so I'm not really surprised by the lack of interest in Eclipse.
imo Eclipse's main flaw was that plugins just didn't work or stay working. It seemed to have gotten better in later years but it still wasn't good enough for work. I'm not sure how not using Swing affected development either since Swing had some huge improvements in 1.7
- 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.
That second one confuses me, Eclipse as of the three days ago I last opened it absolutely does warn about unused imports, methods, and variables. And this is with the bog standard out of the box configuration.
> 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.
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.
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.
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.
Many years ago, Eclipse as a whole had a few promising points:
* 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).
Yes, you can place stuff outside the workspace, and I've done that. It feels like you're fighting the system. And the fact of the Workspace's existence still means that it adds pointless workflow machinations and cognitive load to Eclipse users for no benefit, at least to those who aren't building (nearly obligatory) multi-project workspaces for Java software. The very existence of the Workspace has helped reinforce that useful, trivial actions such as command line invocations don't even make sense to Eclipse:
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.
I have a love / hate relationship with Eclipse. On one hand it's everything I've always wanted development to be: Technically correct, free, pluggable and open source. On the other hand I've upgraded my computer 8 times in the past 10 years and Eclipse is constant in its ability to always be way to slow to do anything.
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 :/
I have the exact opposite experience. I've attempted to switch to IntelliJ on multiple occasions in the past couple of years but I've never gotten it to feel as fast and flexible as Eclipse. Is it possible you're comparing to old versions; Eclipse used to be really slow 4-5 years ago, but the current versions running on an SSD are blazing fast.
If there's one thing I hate about Eclipse, it's that it's kind of ugly :).
So it's totally possible, my Eclipse journey ended about 3 years ago and I've never looked back.
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.
What do you mean by "true multiproject/workspace support?" You can add other maven projects as modules into your IntelliJ project using the "Add Maven Projects" icon in the Maven Projects tool window. And you can also open multiple IntelliJ projects at once in different windows.
I want to be able to have 10-20 projects open and be able to view their sources without switching between windows. The project files should also not depend on each other, but if one of its maven dependency is another opened project it should use that during maven dependency resolution.
You can do this just fine with IntelliJ! IMHO, IntelliJ support for multi-project with maven is better. There are no duplicate resource or type when looking for something. There is a correct hierarchy view in the sidebar.
I think I got it to work, somewhat. It seems I need some kind of "master" project to add all of the other projects to, which seems kind of clumsy. I suppose it works, though.
That's not true support. I have IntelliJ AND pycharm. In pycharm I have all my python and Javascript projects open in the left. I never close a project. I open them all at once.
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
I had only one showstopper which prevented me from switching to 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.
I switched from Eclipse to IntelliJ about a year ago, on a machine with an SSD, and found IntelliJ to be way faster and to have more useful features. I'm not sure what accounts for the difference.
> 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.
If only Adobe hadn't enough of a monopoly to be able to demand arbitrary prices.
I finally got on the Adobe train this year, because the cost of the photographer bundle is trivial. It's less than a Dropbox subscription at this point.
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.
I have a hate / hate relationship with Eclipse. It uses too much RAM, is slow and throws random messages about some exception in connection with some cvs I don't even use. Unfortunately I can't use anything else because of some custom plugins... Also, I learned that the most efficient way to find something in its menus is to google it. Horrible UX. Even Netbeans was better (I am still using an old version which supports python).
"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"."
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.
Yes... it seems very different than the activity shown on the project page... 108 commits in the latest four months is not that bad. Why such difference in data?
Please see above. It's because the JDT project page doesn't roll up the stats from its sub-projects, where all the real work happens. We're looking into fixing that.
I've chuckled a few times in this discussion where people have been asking "Have you tried Eclipse on an SSD?" Know what makes an IDE work even better than an SSD? Being able to fit the entire thing in RAM and not have to page out all the time.
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.
Emacs isn't perfect, and Emacs was the Eclipse of its day.
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.
Kind of surprised by the comments here regarding speed. Have none of you used Eclipse recently on an SSD? I use Jetbrain's stuff a lot of the time, but the biggest problem Jetbrain's stuff has is how terribly slow it is compared to Eclipse.
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.
So it's never been the SSDs for me, it's always been paging / memory consumption. When I run Eclipse / JetBrains I set the XmX flags super high on the JVM to compensate, but it still always felt slower.
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.
> Other than that, Eclipse is free software which is important in the same way Linux is important to cultivate even though we have Windows.
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?
Never looked at the source code for Eclipse, but I'm guessing it does a lot of parsing and linking on source code and reads the same file multiple times while doing random access to other files. So a decent SSD with good random read speed makes all of that basically instant, while on a slow 5000 rpm laptop hdd it's going to take minutes.
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!"
Agreed. Ppl have an initial impression that simpler software is faster but once that software gets all the required features (if it ever does) the speed has, in my experience, rarely been as good.
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:
Did you bump up the memory (-Xmx) for Eclipse (in eclipse.ini)?
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!
I'm always so confused by comment threads like this page. I used Eclipse daily for 6 years then was forced to switch and now I've been using IntelliJ daily for the past 2 years. So I think I'm qualified to make a fair comparison and I still vastly prefer Eclipse. But then I look at comment threads like this page and it's all about how superior IntelliJ is. It always leaves me confused, like I'm missing something about IntelliJ but I don't know what it is.
Same here. I haven't used eclipse in the past two years because I've been doing non-java work. Before that I used it since the beginning of my career, around 2000. I don't recall having issues with slowness and plugins randomly not working. When I first started using it, I remember being a bit confused by projects vs files. That's when I didn't understand the concept of IDEs (as opposed to text editors). I feel like I'm living in an alternative universe.
I was using Eclipse for a couple of years for C++ and Java work (some of that work was building things on Eclipse) about three years back.
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?
I think it's because IntelliJ has a greater cool factor. Exact same thing happens with Apple. Apple customers, say macbook users, complain about the high prices, subpar hardware, iTunes and other software issues in private. But then the same people can brag about their macbook in a different context. Eclipse is just not as cool as IntelliJ. But it gets the work done. And has more capabilities, and is open source, etc. etc. Yet, Eclipse is not cool. So we see an eagerness to point at its weak points.
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)
I'm always so confused by comment threads like this page. I used Eclipse daily for 6+ years(I used it back when it was Visual Age for Java) then was forced to switch and now I've been using IntelliJ daily for the past 1 years(3 if you count RubyMine). So I think I'm qualified to make a fair comparison and I vastly prefer IntelliJ. But then I look at comment threads like this page and it's all about how superior Eclipse is. It always leaves me confused, like I'm missing something about Eclipse but I don't know what it is.
There was a 2 month window a year ago where I used eclipse, before I forced my new company to buy IntelliJ.
Do you realize that some people are coding Javascript (sic) in Notepad (sic)?
So please, let's be serious.
Eclipse (and IntelliJ, and Netbeans) are f.cking AWESOME productivity tools !!!!
Suppose you have a hard requirement that your tools are free and open source. What IDE would you recommend as a replacement for Eclipse? (JetBrains is out, it's neither free nor open source). The worry I have with Eclipse dying is that there isn't a great completely open alternative.
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,...
Nowadays, Android Studio has become the default IDE for Android development, and Eclipse support hasn't been a primary objective in quite a while. Also, XCode is not what I would call a good user interface....
It's really sad to see this happening. I prefer IntelliJ for most of my development work, but certain things it's completely unsuitable for. Debugging multi-threaded code in particular in IntelliJ is a very paintful experience compared to Eclipse.
"A lie can travel halfway around the world before the truth can get its boots on"
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.
Are you denying that :
1. The chart screenshots are not from your website?
2. the screenshot of New and Noteworthy is not correct?
3. The screenshot of mailing list is not correct?
4. the screenshot showing website not update in years is incorrect?
"Deny"? No, not really. What I am saying is that pretty much every factoid in that blog post is either wrong or taken out of context.
Again: JDT is just fine. It is not dying.
Yes the chart screenshots are from our website. But I can also confirm that the chart screenshots show only the data from the the top-level JDT project. It is not including the sub-projects. We have someone working on fixing that now. Here is a summary of the commits since June:
As I said all the work is happening in the Java 9 branch, and are not being included. Take a look at the link I included in my original post, which shows 108 commits in jdt.core just in the last month.
Re: New and Noteworthy, as I said the team is focused on Java 9....there will be lots of content there when they have something.
Re: mailing list - Mailing lists are Eclipse are not like many other open source projects. They only use them for internal project conversations. (Yes, I know that's sort of weird.) If you want to find where the action is at Eclipse, you don't look at the mailing lists. Look in Bugzilla. I'll try to find the right query and link it here to show what I mean.
Re: Website: Yes, that is totally bogus. Yes, the project doesn't pay a lot of attention to that. That's at least partially because we focus on [1] as the landing page for users.
I gave Mike that data without providing enough context. Yes, 108 is the number of commits since the beginning of June. That number includes all commits on all branches.
You're right that the number of commits in September is down, but the trend line in the months preceding September is pretty stable and represents a healthy project that is on track to deliver Java 9 support in September 2016 (and that's what is really important, right?)
The project lead has taken some time out of his busy schedule to capture down an explanation for the anomaly in the commit chart.
That the project didn't include any talk of Java 9 in their new and noteworthy is, I believe, primarily the project lead trying to be careful about what claims we make about Java 9 support.
I've changed how we generate those charts to make it easier for people to see activity without having to understand (and navigate) our (arcane?) project hierarchy.
Sorry, I got the root cause wrong. The problem is not that the numbers didn't include the branches, it is because it doesn't include the sub-projects (where the real work is happening).
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.
Hey, just wanted to say Thank you! Keep up the great work. I've been using Eclipse for about 8 years.
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 :)
> "A lie can travel halfway around the world before the truth can get its boots on"
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!
Are there any stats regarding the work that goes into the "IDE/editing" components vs. the amount of work on Eclipse as a modular, pluggable AbstractFactoryFactory platform for random companies to add their proprietary stuff on top?
As a long term user it feels like no one from the Eclipse project actually uses Eclipse to write code anymore.
Post open sourcing, Eclipse development was supported by IBM for strategic reasons, in opposition to MS. When Oracle bought Sun, the strategic relationship changed, and IBM saw less reason to invest in Oracle tech.
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.
I sort of agree that Eclipse started out that way (mostly paid for by IBM), but I am happy to report that the community has evolved a great deal since those days. If you take a look at the Platform UI project, for example, you will see a very diverse project, with a lot of unaffiliated committers.
The preferences window would be useless without its search box.
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.
Eclipse has always been a needed and valuable IDE for Java development. If I wanted to spin up a Java app with Maven, I could do okay with Eclipse. Refactoring tools work fine, debugging is great.
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.
Dying? I doubt it. While it's not the tool of the "cool kids" anymore, it Just Works, and it has gotten better in some important ways with the last couple of releases. I have to admit, when they started the whole 4.x thing, I was not a fan, and I do still think a lot of work went into making Eclipse more "web based" in a way that didn't actually add much value. And as result, the UI got buggy and it got slower and less stable. But at least with the Mars release, Eclipse works amazingly well. The performance is reasonable, most all of the plugins I want to use installed cleanly and work with no problems, etc.
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.
Interesting... I've had glitches here and there in the past, but most seemed to be related to certain combinations of plugins. But the Mars release, even with the Scala IDE, Counterclockwise and a bunch of other stuff added, really "Just Works" for me.
102 comments
[ 3.2 ms ] story [ 149 ms ] threadThen 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.
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...
Intellij pretty much took over
- 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.
* Open-source, with an apparently large community
* Extensible within itself via plugins
* Some interesting GUI features:
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).
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.
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.
http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/log/
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.
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!
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.
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.
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...
Again: JDT is just fine. It is not dying.
Yes the chart screenshots are from our website. But I can also confirm that the chart screenshots show only the data from the the top-level JDT project. It is not including the sub-projects. We have someone working on fixing that now. Here is a summary of the commits since June:
+-------------------+---------+ | project | commits | +-------------------+---------+ | eclipse.jdt | 8 | | eclipse.jdt.core | 165 | | eclipse.jdt.debug | 18 | | eclipse.jdt.ui | 34 | +-------------------+---------+
As I said all the work is happening in the Java 9 branch, and are not being included. Take a look at the link I included in my original post, which shows 108 commits in jdt.core just in the last month.
Re: New and Noteworthy, as I said the team is focused on Java 9....there will be lots of content there when they have something.
Re: mailing list - Mailing lists are Eclipse are not like many other open source projects. They only use them for internal project conversations. (Yes, I know that's sort of weird.) If you want to find where the action is at Eclipse, you don't look at the mailing lists. Look in Bugzilla. I'll try to find the right query and link it here to show what I mean.
Re: Website: Yes, that is totally bogus. Yes, the project doesn't pay a lot of attention to that. That's at least partially because we focus on [1] as the landing page for users.
[1] https://www.eclipse.org/ide/
You need to take another look at the timeframe for that statement.
The link (http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/stats/?per...) in your original post shows 15 commits so far in September, not 108 as you claim. The 108 figure is total commits since the beginning of June.
You're right that the number of commits in September is down, but the trend line in the months preceding September is pretty stable and represents a healthy project that is on track to deliver Java 9 support in September 2016 (and that's what is really important, right?)
The project lead has taken some time out of his busy schedule to capture down an explanation for the anomaly in the commit chart.
https://dev.eclipse.org/mhonarc/lists/jdt-ui-dev/msg01425.ht...
That the project didn't include any talk of Java 9 in their new and noteworthy is, I believe, primarily the project lead trying to be careful about what claims we make about Java 9 support.
FWIW, you can test the Java 9 support BETA today.
http://marketplace.eclipse.org/content/eclipse-java%E2%84%A2...
I've changed how we generate those charts to make it easier for people to see activity without having to understand (and navigate) our (arcane?) project hierarchy.
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.
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.
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.
[1] http://www.nodeclipse.org/
Given the old system they are trying to extend and enhance, I'm not surprised it didn't work.
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.