|Re: [ide-dev] Java IDEs comparison|
Bruno, it's interesting that many of the issues you mention are against components that are *not* part of the Platform UI project... In short the Platform takes the heat for almost any issue encountered by a user.
The Project Explorer wasn't touched by e4 so the state that it's in wasn't some sort of regression.
As far as being 'laggy' goes the JetBrains folks *by their own benchmarks* are slower in reacting to keyboard input than IntelliJ. If you can articulate where it feels laggy perhaps there's some tuning that could be done.
Bruno Medeiros ---09/15/2016 11:20:39 AM---TL;DR summary of this post: Bad software practices from the historical Eclipse team (IBM I guess?),
From: Bruno Medeiros <bruno.do.medeiros@xxxxxxxxx>
To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Date: 09/15/2016 11:20 AM
Subject: Re: [ide-dev] Java IDEs comparison
Sent by: ide-dev-bounces@xxxxxxxxxxx
So, while we are on this topic, there's two more things I'd like to mention. (Mickael Istria was asking me a few months on Twitter why I was losing faith in Eclipse, I said I'd reply later, but not on Twitter as it's too short form. So here goes...)
First one is about polish. I feel like Eclipse is lagging a lot, even though I haven't properly used other IDEs. But it is still noticeable. For example, with Neon I've just switched to using the Project Explorer again (away from JDT's Package Explorer), because I want to use the nested project features. I found the feature was still a bit immature in it's initial release in Eclipse 4.5.
Now, I just found a bug that affects me quite often. Although not a drastic bug (quick to workaround), it's very commonly occurring, and I imagine it would be simple to fix. So I go to bugzilla to open a report, find one is already open: https://bugs.eclipse.org/bugs/show_bug.cgi?id=328739
And it was open in 2010!! OMG... So it has been open for 5-6 years already! Seriously, these are the kind of issues, although minor, that you would not encounter in IntelliJ, or if you did, would be fixed very quickly!
Another example of a recent bug. Open a text compare editor (not a Java Compare). You can do either from Git, or just by comparing two files. Now if you open the context menu, the "Open, Open With, Show in" menu entries will be there, as expected. But if you modify one of the files of the compare editor and save, and open the context menu again, those menu entries no longer appear! 😱
And I could give more example, it would just be a matter of search my Eclipse Platform UI bugzilla entries.
So I hit a lot of bugs frequently - and this is just the basic plaform/workbench (core Java, Egit, and PDE). Imagine the bigger difference there is sure to be between Eclipse and IntelliJ for people working with web development, or Android development. (according to Lars the later case can't even be compared, it's a no-go!)
Even me, just as an user of the basic platform/workbench, I would gladly prefer to pay the price of the IntelliJ annual subscription if I doing so I did not have to worry about the issues/bugs mentioned before. Any competent developer would. The time/hassle it saves is worth much more than the subscription fee.
My second critique of Eclipse is a technical one. It is something that has become more apparent to me in the last year or so, as I've become more involved in contributing to Eclipse Platform code. In my opinion, Eclipse has historically been very bad at modularization of its components and libraries, and also really bad at re-using 3rd party ones. Intertwined with that, Eclipse has been too focused on the OSGi world and not that well adapted to the Maven world, which in Java at large is more popular, and has a much bigger ecosystem.
Take for example org.eclipse.text, the bundle containing IDocument and most of the document related code. This code does not conceptually depend on anything UI related, nor even on any other any major Eclipse Core component like Resources or Jobs, etc. . So it is quite conceivable that this code be re-used by other IDEs or editors. However, literally the most basic of Eclipse common code: org.eclipse.core.runtime.Assert, is in a bundle that requires not only OSGi but also Equinox specifically... #EpicFail
That is a horrible software practice, with regards to abstraction and modularization.
Yes, the Assert class, and others like org.eclipse.core.runtime.IStatus state that they can "be used without OSGi running", but a mere documentation comment is too brittle of a way to do things. Ideally we'd have such common code in a Maven bundle (which means it can be used in OSGi too), so that the Java community at large could easily use those libraries. And so that bundles like org.eclipse.text could also be made into pure Maven libraries too, without dependencies on OSGi and Equinox.
I can see why this happened historically: when IBM had loads of developers working in Eclipse, they didn't need to worry about the open source community at large, they had enough manpower to keep Eclipse going just by themselves. (plus, other ecosystems like Maven were perhaps not as mature or existent then as they are now - I know little about Maven history). But now IBM is gone, and we are paying the price of really hard adoption barrier for others in the Java community at large, because Eclipse code has been isolated in a niche.
Yet another example: org.eclipse.core.filebuffers. The work I did on a patch for that plugin illustrated similar flaws. There is lots of code there that should have be refactored in into a "commons.io" library, completely independent of Eclipse code. Or better yet, it should have just used Apache Commons IO.
I don't know if when this code was first written, Commons IO existed already. But if it didn't, then the Eclipse team should have taken the initiative at the time to better refactor their code, and start their own Common Utils and Common IO if the Apache one didn't exist yet.
Another example is e(fx)clipse. It's a very interesting project, but one wonders if they could have gotten even further ahead if Eclipse has made their life easier. You see, there is a lot of "JFace" code that is actually UI-independent, stuff like jface.text IRule, IPredicate and document partition management code, or certain preference utilities - however, all such code is in plugins that indirectly depend on SWT (!) Even though their core functionality does not depend on anything UI. So e(fx)clipse can't use it. (Or they can, but have to bundle SWT and bloat their program footprint, or otherwise have other issues).
The recent announcement that Netbeans has been moved to the Apache Software Foundation shines some light on this criticism. I can imagine a different world were Eclipse IDE-independent code was much better abstracted, and was perhaps picked up by other projects like Netbeans. Or maybe it would have been easier for Eclipse to pick up code from Netbeans or IntelliJ. The IntelliJ open-source platform, from the quick look I took at it, seems to readily use Apache Commons code, Google libraries, etc. - smart of them. I'd guess it's a similar case with Eclipse Ché.
On the other hand Eclipse Platform and JDT, remains badly modularized, and we pay a big price for that. That's my take._______________________________________________
ide-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top