Erich Gamma on Improved User Experience for Eclipse 3.0

Discussions

News: Erich Gamma on Improved User Experience for Eclipse 3.0

  1. Eclipse committers are upgrading features for Eclipse 3.0, release - summer 2004. Improvements include a generalized Eclipse platform for building non-IDE applications, increased UI responsiveness, and generalized Java tools to support Java like languages.

    Erik Gamma has been interviewed on the direction for Eclipse 3.0.

    Snippet: ""We've identified four (4) main directions where we want to take Eclipse,” Gamma told OET." “As a whole, these efforts taken together have the goal to grow the Eclipse community to the next level." The upgrade focus areas include:
    (1) Rich Client Platform -- moving beyond development tools, (2) UI Responsiveness -- running more operations in the background (3) Improved User Experience -- easier navigation/accessing features, and (4) Generalized Java tools -- handling more than just Java source files."


    Read the Erik Gamma interview on Eclipse 3.0

    Threaded Messages (33)

  2. Every time I evaluate Eclipse, I abandon it. Release 3 is no exception. The performance on Windows XP still sucks, thereby proving that SWT has no reason to exist. The menus are still confusing. The concepts are still confusing: features vs plugins, the EMF plugin's documentation available only as yet another plugin of its own, etc. Plugins are so easy to create that the space is flooded with inferior plugins. Plugins always shipped as a zip file, but not always unzipped in the same way. Plugin updating not widely embraced. Dizzying plugin interdependencies: UML2 depends on EMF; VE depends on EMF and GEF. Versioning issues between interdependent plugins and the IDE. Some plugins don't run headless, even though it might be sensible. Strange allocation of plugins to zips: EMF has maybe a dozen plugins spread across maybe three zip files.

    I considered using Eclipse 3 as an MDA studio, but like most open source MDA code generators (AndroMDA also), it is biased towards Java. I'm guessing the UML drawing support is clunky, though I lost interest before trying it since the code generation plugins are so dorky. There's JET (based on JSP), which stands for Java Emitter, but strangely it can emit any text language. Then there's GMT which combines FUUTJE (a Java biased generator) and UMLX. UMLX is totally alien, and seems useful only for doing model-to-model transforms, which is something I never do. UMLX might actually be very useful as a visual direct manipulation way to edit XSLT in much the same way as Microsoft's BizTalk mapper, has anyone considered this?

    Last night I realized that most MDA tools (AndroMDA, CompuWare, Innoq, Eclipse, etc) have the wrong strategy -- they all shun the use of XSLT, which was documented for model compilation in the August 2002 issue of XML Journal. XSLT should be perfect for transforming XMI. UMT-QVT at SourceForge embraces XSLT, and I plan to evaluate it this week. Clearly any attempt at QVT without XSLT is a mistake, as with Eclipse's GMT. I'm also wondering if Cocoon's XSP might be a sweet way to do template-based generation with XSLT. Last week I discovered an noteworthy OOPSLA 2003 paper: "Classification of Model Transformation Approaches".
  3. Did you try it?[ Go to top ]

    I think if you tried to write an XSLT stylesheet to do transformations of XMI documents you would see that it is very tedious, especially if you want to handle all the variations of XMI produced by all the different tools. Even if it is a "compliant" XMI document, XMI 1.x still allows too much flexibility that causes problems for writing model transformations at the XML level.
  4. Did you try it?[ Go to top ]

    I think if you tried to write an XSLT stylesheet to do transformations of XMI documents you would see that it is very tedious, especially if you want to handle all the variations of XMI produced by all the different tools. Even if it is a "compliant" XMI document, XMI 1.x still allows too much flexibility that causes problems for writing model transformations at the XML level.

    SourceForge's UMT-QVT solves this by introducing an intermediate XML dialect that presents a distilled view of XMI. XMI isn't necessarily exposed to user stylesheets. I'm really looking forward to trying this tool out. And it comes with XSD and WSDL generators, which is perfect since I'm doing web service.
  5. Did you try it?[ Go to top ]

    You can see a fully documented use of XMI transformation using XSLT at http://www.objectsbydesign.com/projects/xmi_to_html.html .

    The problem of incompatible XMI implementations is real, but could be solved by vendors migrating to a de facto standard, such as Poseidon for UML's latest version. See the following forum thread for more information on this version of XMI:
    http://forums.objectsbydesign.com/showthread.php?s=&threadid=687

    SZ
    Objects by Design
  6. XSLT & SMI & MDD[ Go to top ]

    If you want a flexible generator, that
    - does not show XMI to the user
    - is not Java-biased
    - is very powerful
    then look at sourceforge's open architectureware.
    it's not a model transformer, it's a code generator;
    a very good one, though.
  7. XSLT & SMI & MDD[ Go to top ]

    then look at sourceforge's open architectureware.

    That project isn't ready for public consumption. It has no documentation, no description, and is a daughter release of some commercial product.
  8. Open Architectureware[ Go to top ]

    <quote>
    That project isn't ready for public consumption. It has no documentation, no description, and is a daughter release of some commercial product.
    </quote>

    Actually you can find some good docus at their site: http://www.architectureware.de:

    2 Docus:
    http://www.architectureware.de/download/Whitepaper_en.pdf
    http://www.architectureware.de/download/b%2Bm-GeneratorFrameWork-Function-Glossary_2003-01.pdf

    It's nice to see that we have a lot of good Open Source MDA tools. I feel that these products below, could be a good start for MDA:
    - AndroMDA (http://www.andromda.org) and
    - b+m-GeneratorFrameWork (http://www.architectureware.de)
    - Jamda (http://sourceforge.net/projects/jamda)
    - XCoder (http://sourceforge.net/projects/xcoder)

    Would be a dream to be able to write "one" cartridge for all those tools ;-) I myself like the approach of AndroMDA by using Velocity as the template language. This does not mean that other template languages (XPand in b+m) don't have their pros.

    Cheers,
    Lofi.
    http://www.openuss.org
  9. Open Architectureware[ Go to top ]

    Brian: It has no documentation, no description, and is a daughter release of some commercial product.

    Lofi: Actually you can find some good docus at their site: www.architectureware.de

    Oh, so they pulled a JBoss stunt: documentation not available at SourceForge. How annoying. Is this a trend?
  10. Open Architectureware[ Go to top ]

    <quote>
    Oh, so they pulled a JBoss stunt: documentation not available at SourceForge. How annoying. Is this a trend?
    </quote>

    You can download the docu for free (no fee)... so this is different than JBoss. They just don't have enough man-power I think, so all the stuffs are spread over the net ;-) Therefore we have google, right?

    Cheers,
    Lofi.
  11. Plugin development too easy?[ Go to top ]

    Plugins are so easy to create that the space is flooded with inferior plugins.


    Oh no, lets make plugin development harder!

    Isn't this the problem with Open Source in general though? Too easy to churn out rubbish, too difficult to find the wheat for all the chaff. I don't think it's the responsibility of the Eclipse project to solve this particular problem.
  12. Plugin development too easy?[ Go to top ]

    Brian: Plugins are so easy to create that the space is flooded with inferior plugins.

    Neil: Oh no, lets make plugin development harder!

    Eclipse has become a honeypot for developers dreaming of inventing a tool. Almost every Eclipse plugin is bested by one or more stand alone tools. Spiritually Eclipse is a drag on interoperability. Who needs interchange formats when everything can be tightly harnessed within Eclipse? Who needs Swing when there's Eclipse?
  13. Plugin development too easy?[ Go to top ]

    Brian >>
    Eclipse has become a honeypot for developers dreaming of inventing a tool. Almost every Eclipse plugin is bested by one or more stand alone tools. Spiritually Eclipse is a drag on interoperability. Who needs interchange formats when everything can be tightly harnessed within Eclipse? Who needs Swing when there's Eclipse?
    <
    Granted, Eclipse is more than just a 'free IDE' from IBM's point of view. And who knows, maybe SWT was created, not only because of performance requirements, but to create a lock-in situation as well. There is a reason why each major J2EE vendor has their own IDE.

    I do not think Swing is going anywhere. Java GUIs are more than Eclipse afterall. I read about Swing GUIs being embeddable to SWT as well, so there are many options. I also think that SWT is a great thing for users of Swing because it gives additional incentive for Sun to improve Swing.

    Eclipse plugins are very nice to have. Not because of their overall poor quality, but because some gems will always rise to the top. Eclipse creates a platform that removes a lot of overhead from building tools, which should give us more selection and quality with lower prices (assuming there is competition due to same reasons).
  14. Plugin development too easy?[ Go to top ]

    Eclipse plugins are very nice to have. Not because of their overall poor quality, but because some gems will always rise to the top.

    Eclipse has dozens of plugins. Are any of them best-of-breed tools?
  15. Maybe its not Eclipse that is slow, understand that XP is much slower than windows 2000.
    I have 3.0 running well on a 500Mhz machine (win2k)... but XP couldn't do that cause its a hog...



    -jp
  16. Every time I evaluate Eclipse, I abandon it. Release 3 is no exception. The performance on Windows XP still sucks...


    I run Eclipse 2.1.1 under XP on an old 600 MHz P3 with 256 MB of RAM, usually with iTunes and Outlook 2000 running in the background. Runs great, debugs Tomcat very nicely with the Sysdeo plugin.
  17. Brian, these interoperability issues that you flag are 'on target'.

    Why don't people look at JMI for use in MDA? In fact, EMF has large overlap with JMI - which is acknowledged by Eric Gamma in his book on EMF - because they evolved at the same time.

    Poseidon for UML supports JMI, so it does have traction, although I don't know of any other UML vendors supporting it. However, it is a JSR so it is properly under the JCP umbrella.
  18. I disagree strongly on 2 points. First, eclipse performance is far superior to just about any major Java IDE I've used, including JBuilder, IDEA, etc. To each their own, but on Windows XP I can't use anything else because it's so much faster than everything else.

    Second, I also disagree that XSLT has any place whatsoever in MDA model transformations. XSLT has to be the worst, most unintuitive language I've ever worked with. I think that scripting languages, velocity, and even Java itself are far better ways to work with a model, even if it starts as XMI, than something like XSLT. XMI itself is no joy to work with; it's designed for standardization and verbosity, not simplicity of use. Turning an XMI representation into some other intermediate representation, as a number of MDA tools do, is a far better option than working directly with the XMI. Once you've done that, there is absolutely no need at all for XSLT, and good riddance to it.
  19. What planet do you live on?[ Go to top ]

    to suggest that Eclipse is fast. I am a cheap skate so, i always used eclipse which drove me crazy because it ate up all my resources, and was slow as hell. friggin thing also has the most weirdest,confusing UI i have ever seen as well. Who the hell came up with the stupid idea of perspectives.
    And i agree with the plugins, they are pain in the arse, badly maintained.
    My employer just gave me a copy of IDEA three months ago, and I don't know how i could have lived without it. Eclipse is a badly designed, a slow work horse, and just because Erich Gamma has his name on it, doesn't make it worthy considering so far. Forget it. I will spend the money on IDEA on my own, but won't go back to Eclipse.
  20. What planet do you live on?[ Go to top ]

    ... has the most weirdest,confusing UI i have ever seen as well. Who the hell came up with the stupid idea of perspectives.


    I have to smile when I read something like this. I too was a bit perplexed with perspectives when I first started using Eclipse. Then I realized a perspective is just a configured set of "views". A perspective combines the views that are most relevant for some given task, ie debugging, CVS, Web, J2EE, etc. If you don't see a perspective you want, create your own. Bear in mind there are far too many views to combine into one perspective but hey, if you don't like 'em, close all but your own custom perspective. What's not to like about that?
  21. totally wrong[ Go to top ]

    sorry but I have other experiences with Eclipse. And although what you say about MDA has nothing to do with the the interview of Erich Gamma, I would like to reply on that part, because I have also been looking around in that area lately and I do not agree with you on the use of XSLT.
    XMI is, as the acronym tells, an exchange format for model data based on MOF metamodels. That's it's only purpose. It is not very human readable, not object oriented, so your XSLT transforms will be difficult to develop and even more difficult to organize and maintain. Suppose you want to make EJB generators, and want to support EJB1.1 and EJB2, then further specialize towards specific EJB containers or BMP implemenations (hybernate, ORB, custom ORmapping). Clearly you need a hierarchy of cartridges. With XSLT this is impossible to do.
    So a first step is to have an OO representation of your model, hence the use of JMI, and use OO based generators.
    Second obvious step is not to use hardcoded generators, but use JSP like template driven generators. It increases productivity and readability. There are plenty MDA implementations around that use jsp like templates (like JET), other use scripting languages Velocity or even jPython.
    The really sofisticated MDA implementations go further and abandon templates in favor of more sofisticated code generation frameworks. It seems a step back to get rid of templates, but when you make really big catridges, and a lot of them, you run in scalability issues with templates. In short term templates seem a productivity gain, in the long run they become a maintenance nightmare. The next level of code generators therefore rely on more sofisticated code generation frameworks with additional capabilities like roudtrip support, cartridge inheritance, callbacks from the framework (like support for progress indication and logging), compilation, tuning, and validation.
    The most evolved generation framework I have encountered is the CARAT framework build into ArcStyler (no, I do not work for them). What is really brilliant about the approach is that the framework is so mature that they even developed a MDA cartridge to generate CARAT catridges. What this means is that you can develop a new MDA cartridge by using MDA approach!
    There is an extensive chapter on the evolution of the CARAT generation framework in the documentation of Arcstyler (see the "extensibility guide" pdf). You will see, they are five years further then what you have been thinking of, so try to practice some modesty and learn from the pro's.
  22. What I can say? Each and every Eclipse release borrows more and more features from the Intellij Idea EAP builds, the only advantages that I can see in eclipse is SWT and price, I still find Intellij Idea EAP more intuitive and easy to use, of course this is personal.
  23. I like Intellij quite a bit - but I like Eclipse too - I used it with the EMF and Hibernate plugins to help generate an implementation of the CWM. Worked beautifully - I didn't find it confusing or slow Windows 2K and XP), in general.

    Cheers
    Ray
  24. Yes I also find IDEA more intuitive. IDEA is easier to use. Compared to IDEA, Eclipse's UI is very complicated with all those perspectives and stuff. IDEA just feels better, I feel at home!

    Ara.
  25. Yes I also find IDEA more intuitive. IDEA is easier to use. Compared to IDEA, Eclipse's UI is very complicated with all those perspectives and stuff. IDEA just feels better, I feel at home!

    >
    > Ara.

    As others have said, it's a personal thing. I personally love all these
    perspectives so that when I work on certain things, only the relevant
    windows are open for me. Complicate? Just a little. Powerful? Definitely.

    I have also used IDEA before, but I like eclipse much much better.

    Just a personal taste.
  26. I find eclipse much easier than IntelliJ. I have been using it for more than 2 years now. It is not confusing at all to use perspectives. You just have to get used to them.

    IntelliJ is not free
  27. I'm really baffled by people trashing JDT here.

    > I find eclipse much easier than IntelliJ.

    The guy I pair-program with on a "weekends" project has IDEA on his PC. I have Eclipse 3.0M6 on mine. He likes them both, and so do I. Eclipse JDT seems to have bigger set of warnings.

    ...both are infinitely better than vi that some people in the office are working with... :)

    "Slooooow" experience happened to me when using default Eclipse installation with a huge (1000+ KLOC) codebase. -vmargs ms256m mx256m or some such, plus upgrade of Java to 1.4, plus maybe 30 bucks worth of extra RAM - helped in all such cases to date.

    Several seconds freeze-ups sound like full GC run on a big heap of garbage, by JRE 1.3 GC (?)
  28. What I can say? Each and every Eclipse release borrows more and more features from the Intellij Idea EAP builds, the only advantages that I can see in eclipse is SWT and price, I still find Intellij Idea EAP more intuitive and easy to use, of course this is personal.


    You could easily say the reverse as well. Eclipse had much better multi-project management a long time before IDEA, the CVS integration was quite a bit better, hot-code replace was in there first, the debugger was in general (arguably) better, etc.

    It is completely natural that each IDE will as time goes on add useful features which are found in other IDEs. In any case, at the end of the day, it's all about what makes sense for _you_. While I was an IDEA user late 2001/early 2002 timeframe, at this point, given its (3.0M5 or 3.0M6) feature set vs. what I see in the latest IDEA EAP builds, and considering the price, Eclipse for my needs is better all-around...

    Regards,
    Colin
  29. Hi,

    I'm running Eclipse 3.0 M6 (Win2k) on a 1,7 GHz CPU with 512 MB RAM. But sometimes (quite frequently) Eclipse seems to freeze for a few seconds when I'm pulling the vertical scrollbars down. Does anyone of you know why that is? Is there any debug code in M6 which causes M6 to be slower than the final version?

    I'm a bit irritated be Gamma's statement "What we want to do is to minimize the time you have to wait because the system is already processing another request. An obvious trick to do that is to run operations in the background."

    Obviously that is not working for me. Eclipse 2.1.2 feels much snappier and I've never witnessed such freezes. However, I'll remain a big fan of eclipse (maybe I'll work with 2.x until 3.x starts to feel snappy again). At least Gamma's statement indicates that they are working on it.

    BTW: It's EriCH Gamma not Erik Gamma. The name is swiss and so is he ;-)
  30. I'm a bit irritated be Gamma's statement "What we want to do is to minimize the time you have to wait because the system is already processing another request. An obvious trick to do that is to run operations in the background."

    >

    Don't forget that Eclipse 3.0 is about 6 months away from a final release!

    Geoff
  31. Re: Responsive UI not yet working?[ Go to top ]

    As stated in another comment 3.0 is still work in progress, however we take performance issues very seriously and attacked them in the latest integration build (I20040121). I suggest to download this build and give us feedback using bugzilla if you still encounter performance problems.

    Dani
  32. NetBeans has improved a lot[ Go to top ]

    I tried NetBeans 3.5.1 after a long time. It's performance is much better now.
  33. I think eclipse's editor is the best choice, but very pool support j2ee development. Some j2ee plugin has pool function and bad performance, my eclipse is platform + jdt, nothing more than.

    eclipse 3.0M6 is toooooooooooo bad
  34. I would like to ask the people that think badly of Eclipse to invest a bit more time into it. I think the project has a great potential, since both IBM employees and the open-source community are working on it. I personally have found it invaluable for developing academic projects, and easy to extend.

    As to bad quality plugins... this reminds me of the first days of Java, when everyone was doing Web applets, and most of them were of pretty bad quality. You just need to give developers time to adjust to the platform... the good ones will adapt and their products will emerge, while the less motivated ones will shift their interest to something else. The community will evolve a system to filter the plugins by quality.

    That's about it... go Eclipse team!