Slashdot Mirror


Eclipse Reaches Version 3.0

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

2 of 70 comments (clear)

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