Slashdot Mirror

← Back to Stories (view on slashdot.org)

Eclipse Reaches Version 3.0

Posted by timothy on from the da-da-da-dum dept.

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."

70 comments

  1. I hate to sound cliche, but... by Keith+Russell · · Score: 2, Funny

    I just finished downloading Release Candidate 3!

    --
    This sig intentionally left blank.
  2. Great, if you program Java... by Anonymous Coward · · Score: 2, Interesting

    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?

    1. Re:Great, if you program Java... by tcopeland · · Score: 5, Informative

      There's a Ruby-Eclipse project... last release was in May of this year, so perhaps it's pretty active...

      --
      The Army reading list
  3. But still no full support for 1.5 by Anonymous Coward · · Score: 0

    lack of support for enums in Cheetah is a big pain point for me :(

    1. Re:But still no full support for 1.5 by g_lightyear · · Score: 3, Informative

      Just so that everyone knows:

      Concurrent with development of 3.0, and slated for a post-3.0 release, is a complete early preview of J2SE 1.5 support, codenamed "Cheetah", last release 2004/05/17.

      http://dev.eclipse.org/viewcvs/index.cgi/%7Echec ko ut%7E/jdt-core-home/r3.0/main.html#updates

      Instructions are there for downloading and maintaining the most recent version of Cheetah via the Eclipse Update Manager, which will install and update any installed version of this plugin once installed.

      Currently supported include JCK 1.5 compliance, claiming, at the time of writing, 97.32% (271 test failures remain) compliancy; broad support for most of the generic types functionality (except covariance), and support for the enhanced for loops (but missing autoboxing, enumerations, static imports, metadata.)

      It is unfinished; it won't make 3.0 release, but will hopefully reach feature completion around the time that JDK 1.5 is actually released.

      --
      -- A mind is a terrible thing.
  4. Eclipse + Python by timothv · · Score: 5, Informative

    If anyone's interested in Python support in Eclipse, I use and recommend pydev. 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.

    1. Re:Eclipse + Python by Anonymous Coward · · Score: 0

      If you want a real python IDE get eric.

    2. Re:Eclipse + Python by killjoe · · Score: 1

      Does it have code completion?

      --
      evil is as evil does
    3. Re:Eclipse + Python by LittleBigLui · · Score: 1

      does it have auto-indent? *g*

      --
      Free as in mason.
  5. BitTorrent? by Nimey · · Score: 4, Interesting

    Anybody got a torrent of the 3.0-final release? I only see 3.0-rc3 on their website.

    --
    Hail Eris, full of mischief...

    E pluribus sanguinem
    1. Re:BitTorrent? by darkpurpleblob · · Score: 5, Informative
      The final release is not yet available. From the press release:
      Availability

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

      See the project plan for more about the release details.
    2. Re:BitTorrent? by Lawrence+Ho · · Score: 1

      From the press release...

      Availability

      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.

    3. Re:BitTorrent? by Anonymous Coward · · Score: 5, Funny

      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."

  6. Now that's amazing by 0x54524F4C4C · · Score: 5, Interesting


    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).

    1. Re:Now that's amazing by Moraelin · · Score: 4, Interesting

      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.

      --
      A polar bear is a cartesian bear after a coordinate transform.
    2. Re:Now that's amazing by sql*kitten · · Score: 1

      .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.

    3. Re:Now that's amazing by Anonymous Coward · · Score: 3, Interesting

      "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.invokeLater/invokeAndWait where you would have referenced the GUI component directly. No need to "go through the whole program", just update the code that is executing in the background 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.

      Hah! Now you're just being absurd.

    4. Re:Now that's amazing by Moraelin · · Score: 3, Interesting

      "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.

      --
      A polar bear is a cartesian bear after a coordinate transform.
    5. Re:Now that's amazing by bay43270 · · Score: 5, Insightful

      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)

    6. Re:Now that's amazing by M1000 · · Score: 1

      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.

    7. Re:Now that's amazing by Moraelin · · Score: 1

      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.

      When that loading thread shares some baroque collections with Swing, you end up having to add synchronization to each of them, or the very Swing event Thread will die to an exception. OK, that is at least obvious. (We all know we should synchronize collections for multithreaded access, Swing or no Swing.)

      A more perverse problem, is when that loading has to add or remove elements to a Swing List or to components to a Swing form. It's not even hard to end there. Just takes a spec along the lines of "I want this and that to only be on the page if the loaded data contains this other thing."

      There the collections may not even be under your control, but are burried deep in Swing. It's not that hard, especially if you bring someone new into the project, to see them code something which ought to work all right in the Windows API, but bombs the Swing event thread.

      Either way, whether you actually add "synchronized" blocks, or move code into a Runnable implementation for invoking later, it's still extra work. It's still moving it in another block. And still a chance for someone to forget to do it. Or do it wrong.

      That's all I'm saying. If Swing was synchronized to start with, like, say the normal Windows API is, you wouldn't have to do it.

      That said, yep, your reasons are very good ones too.

      --
      A polar bear is a cartesian bear after a coordinate transform.
    8. Re:Now that's amazing by Moraelin · · Score: 1

      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 synchronized block. To be precise, synchronized to the same monitor as every single method which can add or remove elements. Anything less than that is a very rare race condition waiting to happen.

      And that's a lot less easy than it sounds when the iterator loop is buried deep in Swing and not under your control. You end up needing to also move all data transfers to the element's model in those Runnable implementation for later invoking.

      And you'd be surprised how often people get that wrong.

      Swing or no Swing. I've seen cache implementations which lock wrong too. But Swing just begs for that to happen.

      --
      A polar bear is a cartesian bear after a coordinate transform.
    9. Re:Now that's amazing by Anonymous Coward · · Score: 1, Insightful

      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.

      I realize that not all background threads fit the producer/consumer model, but even those threads can still avoid touching shared data outside of a runnable executing in the GUI thread. Having only one thread access a particular object is much easier to understand and less error-prone than synchronization.

      Either way, whether you actually add "synchronized" blocks, or move code into a Runnable implementation for invoking later, it's still extra work. It's still moving it in another block. And still a chance for someone to forget to do it. Or do it wrong.

      You're right, it's extra work. But not a whole lot of extra work, IMHO. If you have a problem with this, you could write simple utility functions that call invokeLater. Personally, I just stick the runnable in the code unless it looks ugly or I'm doing the same operation in many places.

      That's all I'm saying. If Swing was synchronized to start with, like, say the normal Windows API is, you wouldn't have to do it.

      For the record, I've been using the .Net System.Windows.Forms library in C#, and every class I've used so far is not thread-safe. In fact, they have a similar "invoke later" method for updating GUI components (Control.BeginInvoke, Control.Invoke, Control.EndInvoke). I'm not sure which GUI toolkit you're referring to. I hope you're not talking about the straight windows API (the one with a CreateWindow that takes 11 parameters, etc), because that is more painful than Swing by far, thread safety or no thread safety.

    10. Re:Now that's amazing by Anonymous Coward · · Score: 0

      And that's a lot less easy than it sounds when the iterator loop is buried deep in Swing and not under your control. You end up needing to also move all data transfers to the element's model in those Runnable implementation for later invoking.

      And you'd be surprised how often people get that wrong.

      Swing or no Swing. I've seen cache implementations which lock wrong too. But Swing just begs for that to happen.

      I think you're being unfair to Swing. I think it's strange that you openly admit that people get multithreading wrong all the time, and then say that Swing "begs for that to happen". It seems to me that, for whatever reason, you just don't like using the provided mechanism for updating a GUI when executing in a background thread (invokeLater(), invokeAndWait()).

      SwingUtilities.invokeLater() and SwingUtilities.invokeAndWait() are better than synchronization because the programmer is encouraged to avoid sharing data between threads. As you point out, sharing data between threads can be difficult and error-prone. While synchronization has its place, it requires a good bit of thought to get it right, and it doesn't work in all instances (iteration, as you mentioned, is one such instance). Even if the Swing components were thread-safe, you would still have to do some sort of messy synchronization logic when you touched the data you're sharing between the two threads. Therefore, Swing provides functionality that allows you to modify and access data that would be shared from a single thread. The result is fewer headaches.

  7. Not sure why by miyako · · Score: 4, Interesting

    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?

    --
    Famous Last Words: "hmm...wikipedia says it's edible"
    1. Re:Not sure why by Anonymous Coward · · Score: 0

      NetBeans has always just seemed overall more comfortable to me
      I'm pretty sure your brain is quite slow to not complain about the 1-2 seconds delay between clicking on *any       Actually, this is not true... well, perhaps the box here @ work is fast enough and I certainly could not use it on my old PIII 550, however, I also find more polished the netbeans ide.
      Perhaps it is only I have not played enough with eclipse...

    2. Re:Not sure why by Anonymous Coward · · Score: 0

      I used NetBeans for years and when Eclipse was first released I was blown away. After a short lerning curve I could do everything I could do in netbeans, cvs integration was awsome and IT WAS NOT SLOW AS A SNAIL! Beleive me from experience, take the time learn the tool and make the switch!

    3. Re:Not sure why by iwadasn · · Score: 3, Interesting

      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, it already pretty much surpasses visual studio in terms of usefulness as far as I'm concerned. In addition, be sure to run it on a modern VM, the newer JVMs have pretty substantially improved SWING performance. Apple's offering seems to be the weakest in this area, but it's made the most improvement from the early days, so maybe by 1.5 they'll be competitive.

    4. Re:Not sure why by Khelder · · Score: 3, Interesting

      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.

    5. Re:Not sure why by Anonymous Coward · · Score: 0

      GMFM... (or if you can't process: get more f*** memory) Check memory usage and see how much memory netbeans needs, and then multiply it by 3 and that's how much you need.

    6. Re:Not sure why by ldspartan · · Score: 1

      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.

      --
      lds

    7. Re:Not sure why by whitelines · · Score: 1

      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.

      --
      /* TBD */
    8. Re:Not sure why by Anonymous Coward · · Score: 0

      "Other than code refactoring ..."

      I don't think I could live without refactoring support anymore, so this is not an option.

      How do you handle studiply names classes and methods in large projects? Just let them be? And that is just the tip of the iceberg. The refactorings and quick fixes are the killer features of Eclipse.

  8. Why not SWT? by agent+dero · · Score: 5, Insightful

    "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.

    --
    Error 407 - No creative sig found
    1. Re:Why not SWT? by RAMMS+EIN · · Score: 4, Interesting

      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.

      --
      Please correct me if I got my facts wrong.
    2. Re:Why not SWT? by bay43270 · · Score: 2, Informative

      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.

    3. Re:Why not SWT? by caseih · · Score: 5, Informative

      The SwingWT 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.

    4. Re:Why not SWT? by sadiklis · · Score: 1
      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 resistance is futile ant SWT's popularity is unstoppable... anyway, will IBM please stand up and explain why SWT is not yet a JSR?

    5. Re:Why not SWT? by Anonymous Coward · · Score: 0

      I believe SWT can now work with Swing. Atleast in M6, they had a screen shot of Swing and SWT widgets in the same gui.

  9. How about you write a plugin for ecplise then? by Phil+John · · Score: 4, Informative

    That's the beaty of it, it's not just a Java IDE, it can be anything.

    There's already a plugin that mostly works for editing PHP so why don't you get a few java/ruby hackers together and create one?)

    As for a mail reader, I don't know about that, but there is tetris and snake available :o)

    --
    I am NaN
    1. Re:How about you write a plugin for ecplise then? by Anonymous Coward · · Score: 0

      But what's the point? It's still just a fancy, memory sucking, slow, editor.

      What about GUI development?

    2. Re:How about you write a plugin for ecplise then? by Anonymous Coward · · Score: 0

      What about GUI development?

      Just keep using VB, kid, real programmers don't want form builders.

      Just like you don't build houses from lego bricks, you don't build GUIs from lego bricks.

    3. Re:How about you write a plugin for ecplise then? by Anonymous Coward · · Score: 0

      Just keep using VB, kid, real programmers don't want form builders.

      Just like you don't build houses from lego bricks, you don't build GUIs from lego bricks.

      Speak for yourself. As long as the generated code is good (and sometimes this is not the case, unfortunately), I'll take a Visual GUI editor over coding them by hand any day. You're just trying to look hardcore but are in fact missing out on a productivity boost. Being able to make a change and see its effect immediately is great.

    4. Re:How about you write a plugin for ecplise then? by Anonymous Coward · · Score: 0

      real programmers don't want form builders.

      ah, the impetuous of code monkeys. knowledge without wisdom is like stacking books on the back of an ass.

    5. Re:How about you write a plugin for ecplise then? by Tukla · · Score: 1

      And I'm sure you hand-convert all of your logic into wiring diagrams before putting it together on a breadboard. I mean, real programmers don't want compilers, libraries, and prefabricated hardware. Just like you don't build houses from lego bricks, you don't build software from lego bricks.

  10. Eh? by lpontiac · · Score: 2, Interesting

    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?

    1. Re:Eh? by tolan-b · · Score: 1

      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.

    2. Re:Eh? by primus_sucks · · Score: 4, Informative

      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.

    3. Re:Eh? by Phil+John · · Score: 4, Informative

      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).

      --
      I am NaN
    4. Re:Eh? by lpontiac · · Score: 1

      Thanks, that helps.

    5. Re:Eh? by natterca · · Score: 1

      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 on each client's machine rather than pay for server farms to remote manage presentation. It also allows the user to mix and match "portlets" from various sites onto a single customized page.

    6. Re:Eh? by rteunissen · · Score: 1

      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 work on locked down workstations we could just put eclipse and the JDK on a usb memory stick and run from there. And did i mention we used both linux and windows workstations to develop :-)

      So far the eclipse developers have done a wonderfull job, thanks!

  11. Oblig... by Phil+John · · Score: 1

    ...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).

    --
    I am NaN
    1. Re:Oblig... by dolmen.fr · · Score: 1

      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.

  12. Been using eclipse for a few years.... by mikera · · Score: 4, Interesting

    ...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?

    1. Re:Been using eclipse for a few years.... by chez69 · · Score: 1

      the cvs environment at sourceforge sucks badly. most likely it is something they fucked up and not you.

      --
      PHP is the solution of choice for relaying mysql errors to web users.
    2. Re:Been using eclipse for a few years.... by mikera · · Score: 1

      Hmmm... suspected it might be something like that, though I did get it working before with WinCVS (nice little free tool BTW for people like me who like developing with GUIs).

      Guess I'll just keep plugging away till I find some configuration that works...

  13. What's wrong with having 2 GUI toolkits? by Qwavel · · Score: 1

    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 for SWT. There is no standard GUI for dotNet (Windows Forms is not cross-platform and is not part of the standard). Perhaps IBM could submit SWT to the EMCA as a toolkit for dotNet (there is a dotNet version of SWT)?

  14. What's wrong with SWT? by metamatic · · Score: 2, Interesting

    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--where's the SWT documentation, let alone the JFace documentation?

    --
    GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
  15. Eclipse - Needs more UI refinement by stun · · Score: 2, Interesting
    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 so frustrated to the point that I stopped trying.

    Just those above 4 reasons make me love VS .NET

    What makes a great IDE is getting rid of those small annoyances
    rather than having a very great feature in the first place for me.

    What do you guys think?

    1. Re:Eclipse - Needs more UI refinement by Anonymous Coward · · Score: 0
      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
       on the top of my list is refactoring code, easy way to create new interface (which vs.net doesn't support in 2003), avoid shorthand syntax, runs fast on a system with less than 512Mb of ram.

      If that is your biggest gripe about eclipse, then stick with VS.NET and the screwed up way programming. For those who say, "what's the big deal about not supporting interfaces in the new class wizard?" I can tell you from first hand experience it leads to really bad coding practices. We going through a painful rewrite because the programmers didn't bother making interfaces because it wasn't part of vs.net wizard.

      don't even claim it's not M$ fault, when it is an easy to add and easy to recommend people use interfaces to decouple applications. Instead, most of the MSDN samples and recommendations all use concrete classes. No abstract classes, no interfaces, just hardcode everything.

  16. Well, FreeRIDE is coming along I hear... by maddog2o_2o · · Score: 2, Informative
    Well, the folks at FreeRIDE have a nice little Ruby IDE (Screenshots), written in Ruby using FXRuby, that covers most programming needs. It has a shiny plugin architecture so folks can add on extra tools.

    They even have a Refactoring Support Plugin newly included these days. It appears to include

    Rename Local Variable

    Rename Instance Variable

    Rename Class Variable

    Rename Global Variable

    Rename Method

    Rename Constant

    Extract Method

    Pull Up Method

    Pull Down Method

    It (the Plugin) was written by the folks behind the Ruby Refactoring Browser which also seems to work under EMACS .. huh, go figure. ;)

    I haven't used FreeRIDE in awhile as I'm busy staring at code here and don't want to switch editors in midstream really, but it's coming along slowly but surely. Maybe it'll be what you're looking for.

    Kevin

  17. Hardly Hardly a comparison by fcgreg · · Score: 2, Informative

    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 they are one in the same. But I digress.

    I think your bullets need more background to fully understand them, but I'll take a shot. Let's take this point by point:

    1. really "intelligent" to know the context : I'm not exactly sure what this means. Again, Eclipse is a framework, but I'll assume you mean the Java development environment. In all of my experience with it, I find the JDT to be EXTREMELY intelligent. As of the 2.1/3.0 era of JDT, the IDE can tell me everything about every type of class/project I am using, gives me unbelievable code completion, gives me every compiler flag and optimization I can think of using, pop-up context displays of class characteristics and JavaDocs on mouse-over, etc. I could go on and on. Without more clarification on what you're going for, I won't bother.
    2. Faster (or) more responsive than any other IDE : I guess this would have to be quantified in some meaningful way, so I'll make my comments here simple. In the Eclipse JDT, loading times depend on your Workspace, which Perspectives you are opening, etc. I have been perfectly happy with the loading times of my environment. If I want something faster, I don't have as much open.
    3. language parser works unobtrusively while coding : Again, I think you're assuming the Java development environment here not Eclipse. In my Eclipse/JDT environment, I enjoy full syntax highlighting, code auto-formatting, compile-checking, etc., without any noticeable hesitation. Furthermore, I can skip options and reformat as necessary with a simple keystroke or by simply typing right over its suggestions. I don't see anything obtrusive can you quantify your statement? Also, considering that my development laptop is by NO MEANS the latest and greatest in the hardware arena, I don't think that is a major factor (although I do have a nice amount of RAM).
    4. Customization of the IDE GUI is easy : Let me respond like this: I recently reinstalled my Eclipse environment from scratch (for reasons unrelated to anything discussed here). After installing, it took me about 5 minutes or so to have my customized development environment customized again, including rearranging of the standard window docking, new perspectives open, special views enabled, compiler options configured and custom tools (like JUnit) in place. I will say that I've never tried to rearrange the standard key mappings, so I can't respond there.

    Your comments make me wonder which version of Eclipse and the JDT environment you last tried. In any case, if you're a VS .NET developer then you may not be interested in the JDT anyway. Did you know that there is a budding C/C++ IDE environment for Eclipse as well (as well as for PHP and other languages)? Perhaps you were referring to one of them?

    While I do agree with your statement about lack of annoyances over features, my real purpose in an IDE is to make me more productive. If it doesn't do that, I'll use VIM or JEdit.

    --
    Greg T.
  18. You're obviously trolling, but I'll rebute..... by Phil+John · · Score: 1

    ...you've got two out of four right (fancy and editor).

    As for the other two, slow? With JIT compilation and IBM's SWT it feels no slower than any native apps I use (same goes for Azureus bittorrent client).

    Memory sucking? Pah, Firefox with four tabs is currently using 75Mb, Eclipse on the other hand with 30+ source files open is using 60. Cubase SX when I use it regularly consumes more than 300Mb, just to put things into perspective.

    There are several plugins that allow development of both swing and swt interfaces.

    Next time do some research.

    --
    I am NaN
  19. Press release quote by Nicopa · · Score: 2, Funny

    Here's the Eclipse 3.0 press release.

    A quote from it:

    " support for national languages through I18N-style internationalization".

    How do you pronounce that? internationalization-style internationalization!

  20. Re:HardlyHardly a comparison by Da+VinMan · · Score: 2, Interesting

    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 also have used VS.NET, and I can tell you that folks from that camp have some very high standards for what makes a good IDE. We (or at least, I) are/am not patient with "application development frameworks" that masquerade as IDEs. If Eclipse isn't first and foremost an IDE (which is also extensible), its usability will suffer.

    Having said all that, I would love to get an in your face response of "hell download these two files and install and you'll have the Java IDE to end all Java IDEs with Tomcat support, JSP debugging, UML, CVS, code completion, code standards auditing, code optimization, blah blah blah support". I would love that. I would love to be wrong because I would love to be able to run all the way to the bank with such a product.

    Go on then... let's see it.

    Oh, and I am downloading Eclipse 3.0 RC3 just to take a look-see. What else do I need?

    --
    Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
  21. Re:HardlyHardly a comparison by peter_gzowski · · Score: 1

    I would tell you to go get Lomboz, 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 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. UML is taken care of with a plugin from an Eclipse subproject, UML2. CVS is there right out of the box, as is code completion. Code optimization is helped by Hyades, another Eclipse subproject. How's that? Assuming that the projects release compatible versions once version 3.0 hits, then you need three things:

    Lomboz
    UML2
    Hyades

    --
    "Now gluttony and exploitation serves eight!" - TV's Frank
  22. What? by glenroe · · Score: 2, Informative

    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.