Why does Ubuntu 14.04 stick with (old) Eclipse 3.8 when 4.3 is out?
Asked Answered
J

2

55

Ubuntu is usually a cutting edge distro. But why does it stick to a 2011 version of Eclipse when we are 4 years into 4.x development?

It's not even optional and cannot be installed from the repositories. And it's not 'easy' from a download either. For some reason, the Java SE 7 reference implementation, OpenJDK, is not enough, and you need the Oracle version. Why? This isn't available from the repo's either, and you need some weird untrusted 3rd party repo for that or follow a whole chapter on how to install it yourself.

There were problems three years ago. When Juno 4.2 came out, it had a lot of performance issues. Eclipse Director Mike Milinkovich explains one of the reasons is lack of funding. For the first time in a major release:

"The performance test were turned off because the Eclipse platform team has a serious resource issue."

For that reason, developers released unnamed and unpromoted version 3.8 simultaneously with 4.2 to bridge the gap for this (hopefully) temporary problem, and it's popularity caused a notable trend downwards amongst developers. As one Eclipse b3 developer mentioned:

"I was stunned by the performance improvement after the switch. The 3.8 platform is much MUCH faster"

The 3.8 release is still a popular alternative to the 4.x branch among developers (ask my colleagues or google), I think mainly because of (genuine) trust issues. But the bridge (read: support for 3.8) has closed now that 4.3 is released.

The core problems (funding and developers) have not been fixed though, as seen by Google's gesture of donating money to the Eclipse Foundation in the hopes that other companies will follow suit. Does this mean that 4.3 is still not up to par with the 3.x standards?

This is not a problem with a plugin or a feature for a specific language, this is a problem within the core of the platform itself. (But I'm using WST with Javascript and V8 plugins for PHP and Node development in particular.)

This is not a specific platform problem either. There are similar complaints from Linux, Windows, and OSX users. (But I'm using Linux (Mint 13).)


On the one hand you have people telling the EOL for 3.8 "proves" that 4.3 is fine now. On the other hand (see comments):

"I've moved back to 3.8 due to constant crashes on ubuntu with 4.3"

3.8 is far from problem-free and I wouldn't mind to get a smoother development experience. So I am wondering, why is Eclipse 4 'kept from us' by the people who decide what software versions are 'good for us' (AKA what goes into the official repository)?

  • lucid (10.04 LTS)
    • Eclipse 3.5.2-2
  • precise (12.04 LTS)
    • Eclipse 3.7.2-1
  • raring (13.04)
    • Eclipse 3.8.1-1
  • saucy (13.10)
    • Eclipse 3.8.1-4
  • trusty (14.04 LTS)
    • Eclipse 3.8.1-5.1
  • utopic (14.10)
    • Eclipse 3.8.1-5.1

Update 2014-05-30: I just tried Kepler (again) and it still suffers from UI glitches out of the box. E.g.:

enter image description here

And no, changing the inactive window toolbar background color in preferences does not fix this. (Even if it would, this would be a silly default choice).

I would like to know, from someone who is not positively or negatively biased because of their own highly specialized and tweaked workflow - preferably from someone with experience in the Ubuntu package maintaining process for non-trivial packages - why this decision is made by a team of professionals who know what they are doing for the most widely used Linux distribution out there?

Jory answered 5/11, 2013 at 15:44 Comment(11)
For this discussion, maybe a distinction between the platform and the IDE would be useful. For example I use the Juno IDE but my RCP applications still are based on the Platform 3.Desist
I've moved back to 3.8 due to constant crashes on ubuntu with 4.3Unsavory
@dystroy the platform == the IDE?Jory
@Jory I'm not sure if my comment is useful for you as you seem to focus on node.js dev but if you develop a SWT/RCP application, you can use the Eclipse4 IDE to develop an Eclipse3 application (see related question if you're interested in this specific point).Desist
@dystroy ah yes indeed that's different from my usecase. 4.x has a compatibility layer for 3.x chains and plugins. I mean the specific case where you install 4.3 and the 4.x accompanying wst plugins for handling code parsing. I don't (even) know where the original 'performance issues' label came from - the core or the plugins - but it was there.Jory
4.3.1 is the current version, along with Kepler SR1. 3.x is not maintained any more. Even so, the JavaScript tools in 3.8 and 4.2 were identical. If your concern was performance in the Platform itself, they kept working on it (wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation). Unless you're looking for someone to tell you it's ok to keep using the outdated version, I'm not sure what answer you're looking for.Hierodule
-1 because the first hit on google for "eclipse performance issues" is the official statement that precisely answers your question.Fatimahfatimid
@MaxHohenegger: First, of course I searched, but not everyone uses NSA approved Google. DuckDuckGo hadn't listed it in the top results. Second, you could have linked to the relevant article, making your comment relevant. Third, certain users contradict the statements and I was looking for a human experience based answer. Fourth, the statements are from Eclipse about Eclipse. Fifth, your downvote just cost you -2 rep I hope it was worth it. :)Jory
@Redsandro: If you did your research, you should post the most relevant references in your question. nitind already posted the link. If you want a human experience based answer, your question is too generic. The Eclipse 4.3 Release Trains is build from 55M lines of code, and consists of thousands of plug-ins. Which ones do you plan on using? Specify more details. E.g. are you using Linux, etc. Feel free to improve your question so I can remove my downvote. I'd might even be able to answer it.Fatimahfatimid
I thought it was a "known" problem. No need to reference common knowledge. My colleagues still use 3.8 because they don't trust the 4.x branch. So I am inclined not to use it either. However, at the same time I'd like to stick to new and supported software and 3.8 is not perfect. I elaborated on my question, maybe it is to your liking now. If not, soit. :)Jory
There are still issues with GTK3 in Luna. I'd recommend to vote for, and possibly contribute to the most urgent ones: bugs.eclipse.org/bugs/…Fatimahfatimid
F
14

Eclipse Juno was released 2012-06-27. On 2012-07-17 a bug concerning the responsiveness of the UI was reported. Four months later, around 2012-11-14 the first patch was released to the official update-site.

Many users, however, completely missed the release of the patches. I assume the information drowned in the FUD, and other more important news, that was spread around that time. At the end of 2012 I posted an answer on SO. Apparently I was not the only one for whom the patch fixed this performance issue. On 2013-02-22 Eclipse 4.2.2 was released, which contained the same patch, yet I kept receiving upvotes for my answer on SO until June.

Probably the only known fact among developers is that Eclipse had serious performance issues at some point. However, the knowledge about scope, magnitude and duration of these issues seems to me like a series of common misconceptions. There was a four months period during which it was a good idea for many Eclipse users to stick with the 3.8 branch. I say "many" because I worked with 4.2.0 and 4.2.1 and it was O.K. for me. Subjectively, switching tabs was about two times slower and the IDE froze maybe once a day for a couple of seconds. For colleagues of mine the problem was much more severe. I assume it depended on your setup and on your workflow, however, I never felt like investigating further because I knew the platform developers were working on the issues, and there was a good fallback, using 3.8.

One year and three Eclpse releases later these serious performance issues are still fixed. Of course, this doesn't mean that there are no more performance issues. As of now I find 1979 reports in the Eclipse bugzilla with the keyword "performance". This doesn't mean that Eclipse is very buggy, but only that it is very well documented and open. Whether or not you are affected by any of these issues, again, depends on the setup, the plug-ins you are using and your workflow. I am a Java, plug-in and EMF developer. I work with medium to big work spaces (~1M LoC), and Eclipse 4.3.1 is fast enough. The 3.8 release is not an option for me because as Eric said, it won't receive all of the important updates. People will still continue using it in the future. Many of them will also continue using Internet Explorer 5.5. If you try the 4.x branch and notice any performance issues, please report them, but be specific about your setup.

From the official Wiki page:

Several major performance defects have been addressed in Juno SR2 (4.2.2). Community members have confirmed that these fixes substantially address the performance problems with editor and view opening, closing, and switching. These fixes are widely available in Juno Service Release 2 (February 2013). All defects are also resolved in the Kepler (June 2013) release stream.

new Features

Fatimahfatimid answered 9/11, 2013 at 11:50 Comment(5)
If the 4.x branch has been 'safe' since late 2012, why did the clever people over at Ubuntu 13.10 still use 3.8.1 in their default repository?Jory
@Redsandro, I don't use Ubuntu for Eclipse. Also, I'm not an Ubuntu repository maintainer, but it might have to do something with this or one of the related bugs: bugs.eclipse.org/bugs/show_bug.cgi?id=340067Fatimahfatimid
Interesting, I didn't know they had to maintain GTK2 compatability (and why). Maintainers for the main repo usually stick to packages that they think are in the best interest of everyone, especially for important packages like Eclipse. And it's very unlike them not to go cutting edge and latest version. So I'll trust their judgement and stick with their version for crucial work. I hope I can install 4.x alongside so I can try it out in the meanwhile.Jory
If there is no Ubuntu-related problem I'm not aware of, there is no reason you can't have additional Eclipse 4.x installations on your machine. I'd recommend using different workspaces for different Eclipse versions, though.Fatimahfatimid
A few days ago I have tested a plug-in I'm developing under Ubuntu 13.10 "Saucy" (inside a VM), on Eclipse 4.3.1. The VM had no CPU limitation, but only 1GB RAM. Operations such as opening parts, switching tabs, etc. were actually quite snappy. Comparable to the host. It was only a short test, but there was no sign of any obvious performance issues.Fatimahfatimid
D
1

Your statement "3.8 release was specifically released as a faster and more stable alternative to 4.2" is clearly incorrect; 3.x has gone into its 'end of life' maintenance and was most certainly not released as an alternative to 4.x.

While folks are welcome to continue to use the 3.x stream if it suits their needs please recognize that as the various projects move forward there will be significant divergence in the features available between the two versions...

Dissipated answered 6/11, 2013 at 20:43 Comment(4)
Actually it was. 3.8 came out simultaneously with 4.2, and for the first time there was a trend downwards in Eclipse adoption: The slow down in adoption is most likely the result of the performance issues found in Eclipse 4.2. Issues were caused because there was no money for quality testing like before. Google even donated money specifically for this problem.Jory
@Redsandro: Perhaps I misunderstood. Yes 4.2 and 3.8 were indeed released at the same time but the 3.8 release was just so that we could freeze the bits at a known release point, certainly not as a specific fallback position. Which version you use is up to you but the 3.8 version has already fallen behind 4.x in some cases (e.g. EGit support...).Dissipated
@EricMoffatt, where do you get that quote from?Jennifferjennilee
@RobertSiemer Approximately 24,900 pages at eclipse.org include the name "Eric Moffatt".Benedict

© 2022 - 2024 — McMap. All rights reserved.