Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
IBM Java Programming IT Technology

Eclipse Reaches Version 3.0 70

Tarantolato writes "The Eclipse Foundation has released version 3.0 of its open-source Java-based IDE. Eclipse backers like IBM say the program offers not only increased productivity and ease of use, but also a plugin-based architecture for creating 'rich client' applications with the networking capabilities of web-based apps and the persistence and native widgets of desktop applications. The Lotus Workplace platform is already Eclipse-based. Some in the Java community, however, are concerned with Eclipse's use of SWT rather than the standard Swing widget set, and some analysts think that project is part of a 'broader challenge to Microsoft's entire .Net development framework' from IBM. Meanwhile, Eclipse executives are attempting to woo Microsoft into joining the foundation."
This discussion has been archived. No new comments can be posted.

Eclipse Reaches Version 3.0

Comments Filter:
  • I just finished downloading Release Candidate 3!

  • by Anonymous Coward
    Will somebody please write a *good* IDE for Ruby? I found some stuff for Eclipse once but it wasn't more than just an editor. I want to be able to refactor Ruby code, see it correctly syntax-highlighted, be able to dynamically get lists of methods on objects...etc.

    Bitch, moan. :-)

    It's funny how much Eclipse reminds me of Emacs though, except in Java instead of Lisp (one step forward, two steps back?)

    Is there a mail reader for Eclipse yet?
  • Eclipse + Python (Score:5, Informative)

    by timothv ( 730957 ) on Tuesday June 22, 2004 @01:40AM (#9492270)
    If anyone's interested in Python support in Eclipse, I use and recommend pydev [sourceforge.net]. It's certainly incomplete, but it has syntax highlighting, a class/method browser, realtime syntax checking, and there's a debugger which I couldn't get working.
  • BitTorrent? (Score:5, Interesting)

    by Nimey ( 114278 ) on Tuesday June 22, 2004 @01:43AM (#9492287) Homepage Journal
    Anybody got a torrent of the 3.0-final release? I only see 3.0-rc3 on their website.
    • Re:BitTorrent? (Score:5, Informative)

      by darkpurpleblob ( 180550 ) on Tuesday June 22, 2004 @02:07AM (#9492387)
      The final release is not yet available. From the press release [eclipse.org]:

      Distributions of Eclipse 3.0 will be available by June 30 for download from http://www.eclipse.org.

      See the project plan [eclipse.org] for more about the release details.
    • From the press release...


      Distributions of Eclipse 3.0 will be available by June 30 for download from http://www.eclipse.org.

      So, we need to wait for a few more days before it is available.

      • by Anonymous Coward on Tuesday June 22, 2004 @02:41AM (#9492530)
        I guess paper launches are so trendy these days even opensource groups are using them.

        "Today Linus Tovalds announced the release of Kernel 2.6.10. '2.6.10 contains several bugfixes over version 2.6.9' says Tovalds in a short post to lkm. Kernel 2.6.10 will be available Q2 of 2005, shortly after the Q1 scheduled release of 2.6.9."
  • Now that's amazing (Score:5, Interesting)

    by 0x54524F4C4C ( 712971 ) on Tuesday June 22, 2004 @02:55AM (#9492578)

    How can someone say that SWT is "worse" than Swing in any way? Wasn't the ultimate goal of GUIs to provide users a better experience? How could the pathetic Swing crap create such a big amount of pundits follwing it? I wonder if these developers are focusing on the API (which is mostly clean in Swing, I agree) as opposed to the the actual user interface. Talking about SWT, it's fast and lightweight, and it made people think that java makes sense for desktop applications (which is the exact opposite of what Swing has achieved).

    • by Moraelin ( 679338 ) on Tuesday June 22, 2004 @07:01AM (#9493320) Journal
      Well, guess we can both aggree that Swing is pathetic crap. But I also can't see how Swing could ever be considered a "clean API".

      E.g., take the listeners memory leak problem. I don't know of _any_ major Swing project that didn't end up chasing listener leaks. (No, home brewn programs with 5 buttons and 2 windows don't count.)

      I also know projects, and _been_ in one, which ended up throwing up a two hands salute to that problem. Basically, "screw it, we'll implement the windows/frames/whatever as singletons, or recycle them in a list for future use, rather than spend another month chasing the last listener." (If you're new in a project and the architecture involves singletons for every single frame, or recycling windows into a cache instead of closing them, that's your clue: they ran into that problem, spent weeks, and gave up on even trying any more.)

      E.g., take the idiocy of Swing being inherently non-thread-safe. Then the client comes and says "yeah, it's nice, but this loading sometimes takes 5 seconds, and in the meantime it looks like the app has crashed. Can't you display some progress bars, or something? And can't that other thing preload in the background?" Whop-de-do. Now you're cooking with threads. Time to go through the whole program, adding synchronized blocks (or synchronized child classes of the original Swing controls) everywhere. And still end up spending weeks to chase some spurrious thread problem, which occasionally crashes the Swing dispatcher thread.

      Seems to me like if you took C or C++, and any major GUI API of your choice (X or Windows, pick your poison), you'd still end up with less problems. Even adding the regular C memory leaks from the non-GUI part of that program, it usually still ends up better than the Swing equivalent. Which defeats one of the major advantages Java was supposed to have in the first place.

      Don't get me wrong, I'm not generally against Java or anything, but a Swing fan I ain't. It could be a textbook example of how _not_ to design a GUI API.
      • .g., take the idiocy of Swing being inherently non-thread-safe.

        Yeah, I've run into that. Sheer laziness or incompetence on the part of Sun, no idea which. Either way, it's put me off Swing.
      • by Anonymous Coward
        "screw it, we'll implement the windows/frames/whatever as singletons, or recycle them in a list for future use, rather than spend another month chasing the last listener."

        Is there something wrong with this approach? Sounds reasonable to me. Might be a tad memory-intensive, I guess.

        Now you're cooking with threads. Time to go through the whole program, adding synchronized blocks (or synchronized child classes of the original Swing controls) everywhere.

        Not in my experience. You just use SwingUtilities
        • by Moraelin ( 679338 ) on Tuesday June 22, 2004 @09:55AM (#9494337) Journal
          "Is there something wrong with this approach? Sounds reasonable to me. Might be a tad memory-intensive, I guess."

          There is nothing inherently wrong with caching already open (but invisible) frames, if that was your design to start with.

          What's wrong is that you end up _having_ to modify your architecture like that, just to get out of the inherently leak-prone design of Swing. Not because you did a performance analysis and decided to cut down on time with caching. But because you've already spent pointless weeks tracking listener allocation and deallocation, you're already hopelessly past the deadline, and still can't get Swing's normal architecture to work right.

          Either that, or to give an example from another actual project, you end up extending every single Swing class to include some form of listener tracking, and a baroque dispatcher mechanism to help with that. (Ironically enough, in the end they still ended up with the "closed window cache" way out, when some new team members failed to use that baroque dispatcher properly.)

          Either way it's extra work, which shouldn't have been there. Why are listeners hard references anyway? Why can't they be a soft or weak reference that doesn't prevent garbage collection? Why do I have to go through loops like that just to get a frame out of memory? Wasn't the whole idea of Java and its Garbage Collector to _avoid_ personally tracking pointers?

          I.e., why can't it be like, say, the Windows API, where I never had to do such silly tricks? I'd just close the window, any child windows or controlls would automatically get the right event, so that they too can unload any resources they keep, and that would be it.
      • by bay43270 ( 267213 ) on Tuesday June 22, 2004 @10:30AM (#9494656) Homepage
        It sounds like you just don't know how to use swing. Any API you use for GUI development requires some adapting to. Swing has its issues, but the issues you're pointing out here are personal shortcomings.

        Listener leaks are due to bad programming. I really don't want to take the time to explain solutions here. You can do some research on your own. Most listener leaks will be from inter-screen communication. Try minimizing problems using an event bus or a mediator.

        The thread safety issue you describe doesn't have as much to do with thread safety as it does the single-threaded nature of Java. Most GUI apis use a single thread for event processing. Your issue with Swing seems to be that Swing paints itself on the event thread. I'm not sure how you solved the problem with synchronize blocks. Maybe you should look into SwingUtilities.invokeLater() and .invokeAndWait(). Its an extra 2 lines of code per event.

        Yes there are better solutions than Swing, but C/C++ are not among the choices.

        Now, here are a few *good* reasons to hate Swing:

        - The look and feel will NEVER look the same as the native platform
        - Swing's complexity make difficult things easy, but simple things are much more difficult than they should be. SWT fixed this by layering complex parts of the API on top of simpler ones (JFace sits above SWT providing extra functionality for more advanced uses.
        - Sun expected third party vendors to extend Swing and finish the job, but no one wants to use third party tools because of vendor lock in (something Sun promised us wouldn't be an issue with Java). As a result, most components that could be improved upon with very little effort are left untouched by Sun. At how many companies will I have to implement a table sorter, or type ahead combobox, or formatted text field (one that works, not that JFormmattedTextField crap)

        • OK, guess I better answer the "invokeLater()" thing before I get 10 more replies to the exact same end.

          Give me some minimal credit, people. I know how to invoke later. For tiny projects where you only need to invoke later, but don't actually share any collections between a thread and a GUI model, it even works wonderfully.

          I also know that every single collection class throws an exception if you change it while someone (e.g.: a Swing component) traverses it with an iterator. And therein lies the problem.

          • Just wanted to add that synchronizing a collection isn't as easy as it sounds, either.

            Contrary to the mistake everyone makes when they start with Java, just using a Vector or declaring every single method as synchronized doesn't even start to cut it. You'll still get rare race condition exceptions if you do only that, as soon as one thread uses an Iterator.

            To actually use a collection in a truly thread-safe manner, you have to separately synchronize in a way where every single iterator loop is in a synchr
          • by Anonymous Coward
            I also know that every single collection class throws an exception if you change it while someone (e.g.: a Swing component) traverses it with an iterator. And therein lies the problem.

            Why do that? Why not use a producer/consumer approach? I assume that the background thread is producing data that needs to be displayed in the GUI. So, instead of having the background thread update a shared collection, make the background thread pass each piece of data to the GUI using Swing.invokeLater/invokeAndWait.

      • The solution to the listeners problems is simple. You don't directly keep the listeners objects in a list, but in special objects (WeekReferences, ReferenceQueue). See the java.lang.ref.* package.

        As for working with Threads, yeah, your're right. But it's not that bad. Anyways, I think that under .NET you cannot also update the GUI in a thread, like Swing. You always have to use the main dispatcher thread.
  • Not sure why (Score:5, Interesting)

    by miyako ( 632510 ) <miyakoNO@SPAMgmail.com> on Tuesday June 22, 2004 @03:03AM (#9492606) Homepage Journal
    but I've never been able to get into the swing (pun intended) of Eclipse. NetBeans has always just seemed overall more comfortable to me.
    It seems that while eclipse supports some really nice features (refactoring comes to mind), the way it handles the little things just make it seem less refined to me.
    It also seems to me that too many of the useful features for eclipse are pay-for plugins.
    Other than code refactoring and it's support of swt, can anyone point out any other benefits Eclipse provides over NetBeans or Project Builder?
    • Re:Not sure why (Score:3, Interesting)

      by iwadasn ( 742362 )
      Netbeans 3.6 is quite nice as well. I agree with the parent that it isn't really that slow. It's fairly slow on my OS X box (which is a G5, so there's no excuse, you hear me Apple), but at work on windows and linux it's snappy enough that I can't tell it isn't native. I really wish SUN would just bite the bullet and provide a good profiler with netbeans though. They already include a debugger, why not a profiler too? It seems like netbeans is to the level where it really just needs some additional plugins
    • Re:Not sure why (Score:4, Interesting)

      by Khelder ( 34398 ) on Tuesday June 22, 2004 @10:49AM (#9494846)
      I've been using Netbeans off and on for a few years (along with emacs), and like it pretty well. I tried Eclipse a few months ago, and I found it a lot harder to use, and I didn't like the look & feel as much in general. Some people prefer the Eclipse UI, I guess. YMMV.

      I'm running on a 2.2GHz machine, so Netbeans seems plenty responsive to me most of the time. I can understand why people on slower hardware might prefer Eclipse.
      • I hated eclipse until I got some good emacs keybindings going (specifically the behavior of tab and the indentation style). Now if it tightly integrated with Subversion, I'd be using it for all of my Java development.

      • If anything Eclipse is far more resource hungry then NetBeans. I can run netbeans 3.6/Tomcat/MySQL for development concurrently on my 4 year old laptop, but Eclipse/Tomcat/MySQL just grinds the whole system to a halt.

        I personally like NetBeans better, however the CVS support included with Eclipse is fantastic, I still haven't managed to get it working properly in NetBeans.
  • Why not SWT? (Score:5, Insightful)

    by agent dero ( 680753 ) on Tuesday June 22, 2004 @03:18AM (#9492670) Homepage
    "however, are concerned with Eclipse's use of SWT rather than the standard Swing widget set"

    Wait, what's exactly wrong with SWT? It's not like they force you to use SWT for your projects, I have a good Swing based project in Eclipse right now.

    If anything SWT makes eclipse feel snappier, it's the IDE's choice, and doesn't have to be yours. Stop whining.
    • Re:Why not SWT? (Score:5, Interesting)

      by RAMMS+EIN ( 578166 ) on Tuesday June 22, 2004 @04:48AM (#9492966) Homepage Journal
      Nothing is wrong with SWT. SWT is what Swing (and AWT) should have been: a rich toolkit which uses native widgets where available. It's the best of all worlds: easy to code for, code runs on a wide range of platforms, it's snappy (why are Swing widgets "lightweight" if they are a full implementation rather than a thin wrapper?!), and fits in with the native look and feel about as well as you can hope for.

      Personally, I use AWT, because it's more standard. That is, when I use Java at all.
      • Re:Why not SWT? (Score:3, Informative)

        by bay43270 ( 267213 )
        why are Swing widgets "lightweight" if they are a full implementation rather than a thin wrapper

        The term 'Lightweight' refers to the interaction with the operating system, not the size of the source code.
    • Re:Why not SWT? (Score:5, Informative)

      by caseih ( 160668 ) on Tuesday June 22, 2004 @10:05AM (#9494429)
      The SwingWT [sourceforge.net] project gives you the best of both worlds for developing your Java GUIs. It's an in-progress implementation of the Swing and AWT apis using SWT to draw the widgets. Looks much, much better than Swing, but still lets you use the nice API that many developers like. And for platforms where SWT isn't running, you can go back to the normal Swing classes. Java 1.5's Swing is supposed to be much more themeable and support anti-aliased fonts, so that will mitigate a lot of Swing's ugliness.
    • Well, as far as I can tell there's no useful documentation for SWT, which is a bit of a disadvantage. Take a look at the Eclipse documentation page [eclipse.org]--where's the SWT documentation, let alone the JFace documentation?
    • Wait, what's exactly wrong with SWT? It's not like they force you to use SWT for your projects, I have a good Swing based project in Eclipse right now.

      If you use Eclipse you might want to extend it...

      A more serious point would be: a thing that Sun was so afraid OSSing Java would do (a fork) has been done by IBM. We now have TWO desktop Javas: OSGi/SWT (Eclipse platform) vs JavaWebStart/Swing (J2SE)...

      How to fix it? Make SWT (and OSGi?) a part of J2SE ASAP. I guess it should be obvious for Sun that resist

  • Eh? (Score:3, Interesting)

    by lpontiac ( 173839 ) on Tuesday June 22, 2004 @06:37AM (#9493232)
    Is it an IDE? Is it a GUI toolkit? Is it a component architecture?

    As an outsider with no knowledge of Eclipse, I find it hard to figure out what exactly Eclipse is supposed to be .. in fact, I feel exactly the way I did about .NET back when Microsoft was branding everything as .NET, and the entire development community just stood around asking, what the fuck is .NET?

    • Well you could say the same about the Jakarta project, but that would clearly be stupid, because all you have to do is go and look at the website and read about the sub-projects.

      Eclipse has grown from being an open-source IDE framework, with an 'example' IDE for Java, into a general application framework, still with an 'example' application, being a Java IDE.

      The fact that the Java IDE is superb helps matters.
    • Re:Eh? (Score:5, Informative)

      by primus_sucks ( 565583 ) on Tuesday June 22, 2004 @07:25AM (#9493391)
      Eclipse is a framework for developing client side applications - i.e, it makes it far faster and easier (once you learn it anyway!) to create client applications. It makes it easy to create "Views", "Editors", "Perspectives", wizards, dialogs, property editors, etc., and connect them all together. It's created with the SWT GUI toolkit, which is far better/faster than Swing. One such client application, what many people think of as "Eclipse", is the Java IDE. If you need to create a complex, cross-platform client application in Java, the Eclipse framework would be good way to do it.
      • Thanks, that helps.

      • Eclipse does an excellent job at providing an environment for java. We just used eclipse to develop a rather large client/server application, incorperating RMI and using the CVS `perspective'. While most of the team used eclipse and one or two chose jbuilder, we could all upload (and download) to/from cvs without messing up the source tree. With the RMI plugin (available for free for educational and non-profit use) it was a breeze to get the client to talk to the server, and vice versa.

        Because we had to wo
    • Re:Eh? (Score:5, Informative)

      by Phil John ( 576633 ) <phil.webstarsltd@com> on Tuesday June 22, 2004 @07:27AM (#9493394)
      Eclipse is an extensible application framework.

      At the moment it's been extended to be useful in writing Java programs (code completion, code folding, code refactoring etc).

      There is also a PHP plugin/development mode in active development (it is now somewhat useable). The real crux of ecplise is that it can be whatever you want it to be (but a lot of people, myself included simply use it as a kick ass Java IDE).
    • It's a UI component architecture. It was orginally developed as an IDE, but people are realizing that it is the best, last hope for Java to make any inroads on the desktop for the general user. It will become more of a client-side portal. People will develop modern versions of applets to plug into it, and there will be standard "portlets" to provide a non-programmatic methods of quickly developing UIs. The advantage of a client-side portal is that it is much cheaper to run the presentation management
  • ...ah...but I just finished downloading 3.0RC3 on my 2400 baud modem :o( (not really, I'm on broadband but I HAVE just downloaded RC3, oh well).
    • You can use it during the following days, because downloads of eclipse 3.0 final will only be available on June 30, according to the press relase.
  • by mikera ( 98932 ) on Tuesday June 22, 2004 @10:19AM (#9494557) Homepage Journal
    ...and it keeps getting better and better. I'm off to download my copy right now!

    I seriously think that more open source developers should get behind eclipse, even if they don't use Java as their primary language. Right now it's probably the *only* free software IDE that has the potential to match Visual Studio, which like it or not is an awesome product for developers.

    Want to contribute to open source? Write some quality plugins for eclipse and you can't go far wrong.

    Meanwhile, does anyone have any tips for getting Eclipse for Sourceforge? I'm using it for my own little free software project but haven't been able to connect the damn thing to CVS. Perhaps v3.0 has fixed that?
  • It's not as if SWT does the same thing as Swing and only exists because people/companies couldn't get along. It is fundamentally different than Swing so having a second primary GUI toolkit is justified.

    In C++ there are tons of GUI toolkits/API's, and this is a bad situation, but I wouldn't want there to be only one. Ideally, C++ would have 2 or (at most) 3 primary toolkits, one for native widgets, one for cross-platform widgets, and maybe one that draws it's own widgets.

    There is another possible role fo
  • IMHO, Although Eclipse has come a long way, there're parts of it that drive me insane.
    Here's a short comparison to VS .NET

    I'm a Visual Studio .NET guy. I'm not saying VS .NET is a 100% bug free program, but however it has these features.

    1. really "intelligent" to know the context
    2. faster (or) more responsive than any other IDE
    3. language parser works unobtrusivly while coding
    4. Customization of the IDE GUI is easy

    I spent a long time trying to figure out how to remap Shortcut keys in Eclipse,
    and it made me

    • I would hardly call your post a comparison -- all you did was list a few bullets about VS .NET. I guess we're supposed to assume that Eclipse does NOT have any of the listed traits? Hmmm, I'll have to disagree there.

      Furthermore, I think you've made a common mistake in assuming that Eclipse is only an IDE. Rather, it is an application framework that is particularly well suited for an IDE, among other things. Many people see the Java Development Toolkit, with is often distributed with Eclipse, and assume

      • I wouldn't call the parent to your post particularly well worded, but I think his point was that it isn't necessarily easy to get all the features you want in Eclipse to work. I know, I've been there too. In fact, I'm no longer there. I'm using JBuilder now. Is JBuilder more powerful than Eclipse? Probably not; it may even be less powerful over the long haul. But it gets the job done without fuss. It doesn't get in my way. It doesn't require me to download 99 add-ons and configure each one. Etc. etc
        • I would tell you to go get Lomboz [objectweb.org], except that there's no release compatible with Eclipse 3.0RC3 (I've heard that you can pull it out of CVS and build it, or you can try someone else's build here [kruszewski.name] for RC1, which is what I use). This would take care of your Tomcat support, along with support for a bunch of other servers (Weblogic, JBoss, etc.), and takes care of JSP syntax highlighting, correction, and debugging [objectlearn.com]. UML is taken care of with a plugin from an Eclipse subproject, UML2 [eclipse.org]. CVS is there right out of
  • by Nicopa ( 87617 ) <nico.lichtmaier@g[ ]l.com ['mai' in gap]> on Wednesday June 23, 2004 @01:49AM (#9503649)

    Here's the Eclipse 3.0 press release [businesswire.com].

    A quote from it:

    support for national languages through I18N-style internationalization".

    How do you pronounce that? internationalization-style internationalization!

  • What? (Score:2, Informative)

    by glenroe ( 791530 )
    The latest status report on the eclipse site as of 10am CDT says

    Friday June 25, 2004 10:15 EDT Status: A rebuild of RC4 will happen at 12:00 EDT to include last-minute doc problems (only).

    The release is due some time next week.

It is not for me to attempt to fathom the inscrutable workings of Providence. -- The Earl of Birkenhead