Discussions

News: Sun aiming for unified plug-in standard if they join Eclipse

  1. The Eclipse group (led by IBM) has invited Sun to join in. Sun is pondering this invitation, but have said that if they do join, they would have an agenda to "have a unified plug-in standard for plugging in tools into different Java development environments".

    The Eclipse group (led by IBM) has invited Sun to join in. Sun is pondering this invitation, but have said that if they do join, they would have an agenda to "have a unified plug-in standard for plugging in tools into different Java development environments".

    "That would be our agenda in joining Eclipse, to be part of that community [and] make sure they pursue Java standards in the right way and look at how we as the Java community can serve developers better," said Joe Keller, vice president of Java Web Service & Tools Marketing at Sun.

    The Eclipse group has even said that they are willing to change their name, as Sun feels that it is a direct attack on them. IBM denies this.

    Sun would not abandon the development of NetBeans.

    Sun still pondering Eclipse move

    Threaded Messages (27)

  2. JSR-198[ Go to top ]

    JSR 198 is a proposal to create a standard interface for adding extensions to Java Integrated Development Environments (IDEs). This will allow vendors to write an IDE extension once, and have it work on any J2SE-compliant IDE.

    http://www.jcp.org/en/jsr/detail?id=198
  3. JSR-198[ Go to top ]

    This is JCP's most important unimplemented JSR. Using an IDE is where a hacker spends so much of his time. The entry barrier would be minimized, and the potential audience would be maximized. The opportunity for tiny ISV startups or open source projects would be increased. This would spur innovation. It would also boost Java's competitiveness in the MS DevStudio arms race.
  4. JSR-198[ Go to top ]

    I would say that Java is already quite competitive WRT ides, especially when the competition is VS.NET. VS.NET offers some interesting features, and a lot of nice wizards for beginners. But it has nothing close to the features offered in pretty much every major Java IDE out there. The refactoring support alone, now offered by JBuilder, Eclipse, and IDEA, is something that VS.NET desperately needs. Once you reach a certain level of development competence, VS.NET actually hampers your productivity. The Java dev tools, having had more time to mature, enhance developer productivity for those building anything more complicated than a "Hello, World" website.
  5. have a unified plug-in standard[ Go to top ]

    It would be fine to have a general porpose "unified plug-in standard", to forge the whole java stack from j2se to j2ee and up, as a plugged-in architecture.
  6. All,

    We are using the Eclipse plugin framework for standalone (non-IDE) applications and J2EE components with great success. See http://www.choicemaker.com/EclipsePlugins.htm.

    Regards,

    Martin


    Abstract
    --------
    The Eclipse core runtime engine provides the benefits of component-based development and the Plugin Development Environment (PDE) provides a convenient means to create plugins, fragments, and features. However, the runtime engine lacks some features for building standalone applications and Java 2 Platform, Enterprise Edition (J2EE) components. We address this in two ways.

    First, we enhance the existing runtime engine with practical tools for reporting errors, launching without a workspace, using external libraries, deserializing objects, remote method invocation (RMI), and installing Eclipse-based applications with WebStart.

    Second, we introduce an alternative runtime engine that is suitable for J2EE components because it supports Eclipse products in a single JAR archive, does not modify shared singleton resources, and collaborates with the security manager. This runtime, which is based on Eclipse code, supports only part of the original’s functionality—-most importantly extension points.
  7. Hi,
    nice work. But what I meant is a little different.

    I suggest that webapp, ejbs, connectors, apps, be deployed in a consistent and
    extensible pluggability framework such that of eclise.

    For example, if you mind, an 1.5 connector is and 'extension' in that it can be deployed to the j2ee container which defines the 'connector extension point'; it also defines an 'extension point' for message driven beans to be deployed against (namely, 'extend').

    This pluggability framework would:

    1) Let assemble the j2ee stack from single components, I mean a servlet container, a jms implementation, an ejb container, ...

    2) Let the developer extend uniformly the j2ee stack with her/his own 'extension point' which would have the same 'status' as regular
    containers.

    Maybe the point here is that it should be recognized that
    (j2ee) 'container' is the same as (eclipse) 'extension point' and
    that (j2ee) 'component' is the same as (eclipse) 'extension'.

    Please,
    I would like to have replies.
  8. AWT and Swing must be OPENSOURCE[ Go to top ]

    To kick Eclipse but, Sun must make AWT and Swing Open Source, and with power of Sun, make IBM team up with AWT. :) so Eclipse will run on top of AWT, but next version of AWT. which is fast. Swing is slow
  9. See SwingWT. Not tried in yet, I'd be interested in options from thos that have.
  10. Completely agree with you. In my opinion, the main contribution of Eclipse to Java community could be expressed in three words: 'dependency', 'extension point' and 'contribution'. Although you can put class-path entries to manifest.mf in your .jar, that's just no dependency management. The Eclipse's plugin framework is simple and consistent and because each plugin has its own classloader (great idea, although not invented by Eclipse), developers are forced to think about structure of their application, because otherwise it won't compile and run. We are using the Eclipse's plugin core even for completely non-visual applications, for me there's no way back to the times when app consisted of 20-40 jars in /lib dir. I don't understand why so much people are thinking that "Eclipse == IDE == SWT". SWT is nice, but that's not the point.
  11. epecially when sun is saying that it wont stop net beans effort .
    Please stop sun in coming into our own nice real open source effort. We are happy withought sun.
      And anyway SUN can never make good IDE. ( history shows it)
  12. Sean said:
    > Please stop sun in coming into our own nice real open source effort. We are happy withought sun.
    > And anyway SUN can never make good IDE. ( history shows it)

    +1.
    Netbeans was very cool before Sun made it slow and bloated (so I switched from NetBeans), I expect same to happen to Eclipse.

    IntliJ does not do CVS, so it can be used for small projects. Eclipse has best CVS I have seen.

    What about Vi (gVIm.org), isn't that the main thing? Fast is good.

    .V

  13. > IntliJ does not do CVS, so it can be used for small projects. Eclipse has best CVS I have seen.
    >

    IntelliJ is so productive that you'll have a lot of time to waste using an external cvs client and reading tss ;)
  14. IntelliJ CVS support[ Go to top ]

    IntliJ does not do CVS, so it can be used for small projects. Eclipse has best

    > CVS I have seen.

    This is blatantly false. IntelliJ has very good support for CVS in its current 3.0.x series and the CVS support is being totally overhauled in the new Aurora/4.0 product line. True, it does use an external CVS executable (I typically use the cvs.exe from TortoiseCVS), but IntelliJ maintains color codings of changed and new files, prompts for CVS Add when adding new files to the project, and prompts for CVS Remove when a file is being deleted. Even their refactorings are smart about CVS repositories.

    BTW, IntelliJ's new native CVS support for Aurora comes from/is influenced by SmartCVS (http://www.smartcvs.com/).

    Just setting the record straight.

    Regards,

    -- chris bartling --
  15. Is That Really Useful?[ Go to top ]

    I'm wondering what sort of meaningful standard could come from that. There may be some non-visual APIs that could be standardized, but how do you standardize the visual components? NetBeans uses Swing doesn't it? If it exposes Swing and Eclipse exposes SWT/JFace APIs, I don't see how we could have a common plugin API that is very rich in UI behavior.
  16. What's so really special about Eclipse?

    Ok, it may be a useful IDE for some people. My personal impression is that this is a beautiful rather than useful IDE. Is it better than NetBeans from a developer's point of view? I don't know. But it does look better. It is faster. It eats less memory. It is more user-friendly. This is a great example what a Java-based program based on native widgets may be -- fast and pretty-looking, yet portable. Much less resource-consumptive than a Swing-based one.

    Sorry for being somewhat off-topic, but... It was said so many times -- and everybody seems to agree -- Swing is a cool API, but a user's experience of a Swing-based program is usually far from perfect( it's slow! it eats my memory like hell!) I've heard people telling their JBuilder runs as fast as MS Office. Not true! MS Office (or any other win32 app) is so much faster! :( But Sun doesn't seem to listen. :(

    Is SWT perfect? No! Not yet at least. Swing has a more advanced API -- it is a real MVC, and SWT is not. Each Swing's component's model is clearly separated from its view, as is its controller. For example, a JTable has a separate TableModel; a JTree has separate TreeModel etc. This allows me to easily plug-in a third party database-driven table/tree model without modifying my application architecture. Furthermore, SWT doesn't have a real table: the org.eclipse.swt.widgets.Table doesn't support different components for cells, swapping columns and many other features a user might expect from a full-featured grid component.

    The weak support for client-related features in Java platform in general, and the lack of support for native widgets in particular is one of the reasons why people choose .Net over Java. It's time for Sun & IBM to stop stupid wars that lead to nothing but Java fragmenation and to unite and create the next generation Java GUI toolkit, with the best features from Swing and SWT. People don't want many average toolkits. They want a single cool toolkit.

    Sun, you've done excellent job in creating a robust and secure programming environment. IMHO it has no competition on the server side. Now it's time to improve it's usability from the client's perspective.

    The following features would also improve Java experience:

    1. Java applets and applications should be based on native widgets to improve performance and memory consumption. What about making SWT a Swing-compatible library? Ideally, SWT could have been just another pluggable look and feel... Man, I'm dreaming...
    2. Java should be able to show a splash screen and a progress for loading applets, instead of that gray box. It should also support download resuming if a client gets disconnected during the libraries downloading. A great example is Macromedia's Shockwave Flash technology. Hmm, why not hire Macromedia to do this?
  17. <sarcasm>Swing is slow</sarcasm>[ Go to top ]

    You're right, noone would ever use a Swing application. Except for one of the most popular Gnutella clients out there: Limewire.

    And I see SWT applications out there in abundance. I mean, there's Eclipse. And umm, Eclipse. Oh yeah, and Eclipse.

    It's about time that people stop rapping the windowing technology, because it's the people using the technology that determine whether the final product is useful.

    If you want to see some nice Swing applications, check this out:

    http://java.sun.com/products/jfc/tsc/sightings/S19.html
  18. <sarcasm>Swing is slow</sarcasm>[ Go to top ]

    You're right, noone would ever use a Swing application. Except for one of the most popular Gnutella clients out there:


    Limewire.

    Did I say that "no one would ever use a Swing application"? I am a user of Swing-based apps (NetBeans, DBVisualizer,

    JBuilder, JDeveloper). I can tell you my impression as a user: the software is cool but... it's slow! Don't tell me it's not

    because it is. On my Pentium 2.4!

    Will anyone explain me why people defend non-native GUI so fervently? No native GUIs! What's the problem with them? I'd like

    choice! If some people like apps based on non-native GUI, no problem, use WindowsLookAndFeel, MetalLookAndFeel,

    PlasticXPLookAndFeel, whatever. I'd like NativeLookAndFeel (based on native widgets!). I'd like native widgets based on Swing

    API (not SWT). My clients are asking me for apps based on native widgets (not those that 'look like native'). Now we need to

    use a non-Java GUI builder (Delphi) to make a good GUI and integrate it with Java-based backend. In fact, I'd like more native-based stuff in Java (for example java.util.NativeVector), but that's another story.

    I don't care about the fact that someone is using some applications I don't use. I don't care about Limeware. I do care about

    the fact that in my company there is a fragmented (integrated?) development environment, thought it could be completely

    Java-based, which could make my life so much easier.
     
    > And I see SWT applications out there in abundance. I mean, there's Eclipse. And umm, Eclipse. Oh yeah, and Eclipse.

    Well, the situation could have changed if SWT is a part of JRE. Right now, people need to download swt.dll + swt.jar, which in total over 1 MB. Again, let it be SWT or com.sun.java.swing.NativeLookAndFeel, I don't care. But let it be real native widgets.

     
    > It's about time that people stop rapping the windowing technology, because it's the people using the technology that

    determine whether the final product is useful.
    >
    Oh really? How much time is that?

    I am one of those 'people'. My clients are. Guess what our common conclusion is.


    > If you want to see some nice Swing applications, check this out:
    >
    > http://java.sun.com/products/jfc/tsc/sightings/S19.html

    Again, I don't care abouth those apps. They are not useful neither to me, nor to my clients.
  19. Swing and SWT[ Go to top ]

    I think Sun should stick to Swing. Swing is a better GUI than SWT. Have you tried to install Eclipse GTK in older Linux? Gee, you have to update many things in your Linux and it still does not work! The Eclipse Motif L&F is really horrible! If you use Swing apps, it will work in both platforms (Win and Linux) smoothly... no need to upgrade your Linux libraries.

    I agree that many Swing apps don't look so good because of the Metal L&F, but it's not a must. Check this Eclipse Fake L&F in Swing out:
    http://www.jgoodies.com/freeware/metamorphosis/images/elegantui.gif

    So, you can make a very nice Swing L&F app. It depends only on YOU.

    Maybe IBM should rework Eclipse and change SWT into Swing? IntelliJ or JBuilder are also fast although they are written in Swing. If Eclipse uses Swing, it would be a lot more easier to install it in any other operating systems... and IBM can help Sun to optimize Swing... (I know, I'm dreaming here ;-))

    Greets,
    Lofi.
    http://www.openuss.org
  20. Swing and SWT[ Go to top ]

    Lofi,

    > I think Sun should stick to Swing. Swing is a better GUI than SWT. Have you tried to install Eclipse GTK in older Linux? Gee, you have to update many things in your Linux and it still does not work! The Eclipse Motif L&F is really horrible! If you use Swing apps, it will work in both platforms (Win and Linux) smoothly... no need to upgrade your Linux libraries.
    >

    Why do we have all these discussions? Because we are stupid users that do not understand how cool Swing is? Or may be there are problems with Swing that exist for quite a long period of time?

    I agree, Swing is a much better designed API. No, I've never tried to install Eclipse GTK on older Linux. I don't need to. In my company there are some 250 workstations. All win32-based. Guess how many custom Swing-based apps running there? Almost none...

    Sometimes I think Java emphasizes portability more than needed. For example, in my environment I'd like to use services provided by Windows, yet use Java language. If I cannot do that, I will have to find another approach... .Net? To address this, JRE could have provided some 'non-portable extentions' that allow usage of such services; they could have been documented as 'non-portable'. Again, people would have choice whether or not to use them. Anyway, Java is for real life, not for museum, right?

    > I agree that many Swing apps don't look so good because of the Metal L&F, but it's not a must. Check this Eclipse Fake L&F in Swing out:
    > http://www.jgoodies.com/freeware/metamorphosis/images/elegantui.gif
    >
    > So, you can make a very nice Swing L&F app. It depends only on YOU.
    >

    In my company we used applets and skin them with PlasticXP. They look much better than those that use standard looks. Even work somewhat faster, I think. But equally hungry for resources.

    > Maybe IBM should rework Eclipse and change SWT into Swing? IntelliJ or JBuilder are also fast although they are written in Swing. If Eclipse uses Swing, it would be a lot more easier to install it in any other operating systems... and IBM can help Sun to optimize Swing... (I know, I'm dreaming here ;-))
    >

    This is where I agree completely with you. I'm dreaming with you :)

    > Greets,
    > Lofi.
  21. [Sergei]
    My personal impression is that this is a beautiful rather than useful IDE
    [/Sergei]

    The emperor has no clothes! I don't know how people put up with Eclipse. I'm forced to use it (having been using IntelliJ for the previous year), and I hate it, I still do. I've finally figured out what's wrong with Eclipse, too. It's flow. It has no flow. It's impossible to get into the zone and keep coding, because it keeps interrupting you with stupid dialogs, forcing you to use the mouse and hogging the processor endlessly or VM exiting randomly. I don't think that it's SWT related though :-)

    On an even more unrelated note, there's one pet peeve with Swing... it's sucks over terminal services...
  22. What's so really special about Eclipse?

    It has the most plugins. Though JSR 198 could change that.
  23. I think it would really be good to have sun and ibm work together to create the uber-java IDE. I've been using both netbeans and eclipse for years in a lot of projects and I like the possibility that the best features of those IDEs could be merged could become a reality.

    But the real issue here is in the way the platform could be extended.
    The mechanisims for extending the IDEs are very different and have somewhat steep learning curves and it would be nice to have a uniform way of doing it.

    This is a really nice development if it goes through.
  24. if the want the ultimate IDE why don't the just buy the company JetBrains and use IntelliJ?
  25. IntelliJ vs. Eclipse[ Go to top ]

    It is kind of funny that generally anyone who badmouthes Eclipse is using IntelliJ.

    I use Eclipse because it is free. If I had the money I'd use IntelliJ. The company I work for endorses Eclipse, so it's used there as well.

    Eclipse is 'good enough' for most people though. After going from Visual Age to Forte to Eclipse, it seems world's better. Only someone who has used IntelliJ would think Eclipse is a bad IDE.

    I actually thought Forte was a pretty good IDE, just slow compared to Eclipse.
  26. Unified Plugin is a great idea.

    Now if they work on the Unfied Plugin, that would be the best idea. Developers can use one or the other platform according to their needs with the best features available to both.

    Also if both the IDE's can read each others projects that will be great too.

    If for some petty reason one team/company comes up with their own version og the ToolKit, that is not a very good idea. (ex: SWT).

    Swing is a pretty good set of API and provides an excellent UI. I have been using Swing since 0.x versions. At that time there were lot of bugs and drawbacks (performance, crashes etc).

    But Swing has now come a long way and some of its current drawbacks can be improved teaming together the licensces and partners or with the Open Source Community.

    As verybody is talking about Eclipse, my 2 cents:

    I have used/tried Eclipse installed (both Motif and GTK 1.x versions) on Linux. It was a horrible experience (including crashes).

    On GTK 2.x Eclipse was string and looking good (Using SuSE 9.0 default theme). Windows version was the only one I ever liked.

    Compare this to JBuilder/NetBeans used on Windows and Linux (irrespective GTK or Motif versions). It provided very consistent UI Look and Feel.

    I would like to see IBM and Sun leave their ego/pride apart and work together on the already existing UI API's either AWT or Swing and overcome the existing problems/issues.


    Cheers
    Harimohan
  27. Well, each time a message about eClipse pops up, Swing and SWT are compared to each other, NetBeans is compared to eClipse...

    Personally, I have been quite fan of NetBeans for years. In my last project, I have been using eClipse (though it took me some time to migrate from NetBeans to eClipse). In my humble opinion, eClipse gives more productivity than I have ever had with any other Java tool. I hope that NetBeans comes up with similar productivity.

    Regarding Swing versus SWT, I would like to welcome the competition. The competition helps improve the technology. Being still a fan of Swing, I do not see any problem if someone uses SWT to develop a GUI application. Is not "freedom of choice) just the reason why we all like Java?

    In the above discussions, someone stated that Swing is real MVC. Well, I am not quite sure about that. Currently, we are running a big project (20 000 hours) using Swing. Our experience says something else. Having actually looked at various projects and source codes, one wonders what MVC actually means? Obviously, it means different thing to different people. And that is why you see people use Swing quite differently, and all claim that their approach is Swing approach. Being a powerful framework, Swing has simply too many buttons to press on that makes it difficult for many developers to use it properly. I read the foreward by James Gosling in a book on Swing which just confirmed what I just said about the complexity of Swing.

    One more comment on Swing: Swing has grown up to become a solid foundation for developing rich graphical user interface. During the last couple of years, many applications have been developed in Swing and it seems that it is accelarting. The performance is good enough if you like to sacrifice some 1/2 second for the sake of platform independency.
  28. Jim Cushing's blog[ Go to top ]

    http://weblogs.java.net/pub/wlg/651