Sun: No plans to join Eclipse

Discussions

News: Sun: No plans to join Eclipse

  1. Sun: No plans to join Eclipse (63 messages)

    Joe Keller, VP of marketing for Java Web Services and Tools at Sun Microsystems said in an interview with infoworld that at one point, joining Eclipse was evaluated but they decided it was not appropriate. There are no current plans to join Eclipse and Sun feels that there is "room for choice in development tools".

    The portions of the interview related to Eclipse:
    InfoWorld: There was a lot of talk this morning about the NetBeans open source tools platform. I think it could be argued that NetBeans doesn’t really have the reception in the market that Eclipse does, although some would disagree with that. So where is NetBeans headed?

    Keller: We’re going to continue to invest in NetBeans. We think there is room for choice in development tools and we’ll continue to drive that. We’ll continue to be, if you will, supportive of Java communities, like Eclipse and others. We support Java communities and will continue to do that. We think there is room for a development tool that provides functionality for those who are developing for all of the Java platforms and provides a set of good choices out there. So we’ll continue to invest in NetBeans and I think you saw a number of demonstrations of that technology supporting development of applications for the Java Micro Edition platform. Earlier in the week you saw continuing support for developers who are looking for an easy-to-develop tool set in Java Studio Creator. And you saw the movement forward [of] our enterprise developers in a number of different projects.

    IW: Are there any discussions anymore about Sun joining Eclipse?

    Keller: Not currently. It’s something that we went through and evaluated, but we decided that it wasn’t something that was appropriate for Sun to do and that we would continue investing in excellent tools.

    What do you think? With BEA, Borland and IBM all building their IDE's off Eclipse, and with Eclipse at over 60% marketshare in NA and even greater marketshare internationally - should Sun maintain course or join the club?

    Threaded Messages (63)

  2. I don't think it's necessarily a blank and white issue. Even though Sun's Glassfish project is setup to work well with NetBeans, they have started an IDE/Plugin project for integrating into Eclipse and other tools.
  3. NetBeans and Eclipse IDE could be merged I think.

    (Qiwei Yin)
  4. I think one defect of Eclipse is it does not based on Swing. I lile Eclipse, it's smart editor, strong refactoring capabilities, wonderful CVS integraty ... But, in the future, the biggest defect of Eclipse may be SWT. Swing has got dramasticly improvement since JDK 1.4.2/1.5, from then on I think SWT can retire. The overall design of Eclipse 3.x if beutiful, but when you look at the details - components/controls - it is outlandish in XP, although it's wonderful in Windows 2000. Eclipse in Linux is ugly enough.
    I don't like the look and feel of Netbeans either, but that's not fault of Swing, it is because not well designed. When you run JDeveloper 10.1.3 or DBVisuliser 4.x you will find how Swing applications can designed beutiful.
    Also, you have to download sereral 100 M files when you want to use Eclipse on different platforms, compared a single zip file for all platforms for Netbeans. It's the fault of SWT.
    One contribution of SWT is it makes Swing in evolve - if no SWT, today's Swing may be looks like 3 years before.
    I think we should not surprise if Eclipse rewrited in Swing some day in the future.
  5. Its not really SWT that's making Eclipse look "weird". Its actually the developer's choice that makes things look weird. I was asking about why the buttons look rectangular instead of something that matches my Windows VS, they said that it was because of branding issues that they made Eclipse look the way it is.

    http://bugs.eclipse.org/bugs/show_bug.cgi?id=50827
  6. I don´t think so[ Go to top ]

    I think otherwise. All those developers asking for custom widgets are a pain. The same way I have a hatred for Flash. What I hate about Netbeans or Swing: Yeah you open up your "Open File" Dialog and the texts and icons are clipped. Just because it´s a German windows and not an English one. Next you find out that you can not do your usual "right-click" actions in that dialog - no rename, nothing. You don´t have all "views" (like thumbnails): It´s those little things why I perfer SWT by far over Swing. Btw, Sun is going the exact same way they despise so much in their marketing talk: Components like the JDIC will not be offered on all platforms (afaik).

    Swing is a beauty from a scientific standpoint. It really is - MVC everywhere, fully customizable: all very nice. It just doesn´t cope well with the needs you might have for an ordinary desktop app. SWT is ugly, yet pragmatic. (Btw, that´s where Microsoft is king - making "working" pragmatic decisions).

    SWT will probably look good on Longhorn from day 1: Something SUN has to put hard work in for Swing.

    On the real topic, I think it´s good if we have two free IDEs that evolve faster than they used to. I didn´t bother not having had a Java 5 compatible Eclipse for a year. I wouldn´t recommend using Java 5 by now anyway (for the lacking backward compatibility of the bytecode).

    (On a side note I guess could´ve been built on Swing. The biggest feature is not SWT, but it´s platform.)

    (On a second side note there is some effort for a SWT-on-SWING project)
  7. I don´t think so[ Go to top ]

    SWT will probably look good on Longhorn from day 1

    This seems optimistic, since it still isn't looking good on XP after many years.
    Something SUN has to put hard work in for Swing.

    It has been doing this. In the next release of Java Swing will have native support for Longhorn.
    (On a side note I guess could´ve been built on Swing. The biggest feature is not SWT, but it´s platform.)

    Indeed.
  8. AMEN - choice rules[ Go to top ]

    It's unbelievable that FREE choices are somehow perceived as bad, by some. We need MORE choices, in our standards and our implementations. I think we all learned our lesson from EJB, that the one size fits all, "one uber-standard to rule them all" matra failed for specifications. There's no reason consolidation in IDE's should be any better for the community.
  9. AMEN - choice rules[ Go to top ]

    I think we all learned our lesson from EJB, that the one size fits all, "one uber-standard to rule them all" matra failed for specifications. There's no reason consolidation in IDE's should be any better for the community.

    You cannot seriously compare Eclipse with EJB.
    One is "design by committee", another is a live platform that became de-facto standart.

    It is not about choice (which is always good). It is about best technology, becoming standart due its merits.
    Sun can refuse to see it as long as they want. That does not change anything.
    Industry have made a choice.
  10. AMEN - choice rules[ Go to top ]

    I use NetBeans and love it. I am amazed that Java was invented to give people more options, not less. To be open, not closed. I don't see more application servers, but less. Now you only want one IDE. Why is there this pressure? Have we become Microsoft?
  11. AMEN - choice rules[ Go to top ]

    It is not about choice (which is always good). It is about best technology, becoming standart due its merits.
    Sun can refuse to see it as long as they want. That does not change anything.

    Industry have made a choice.

    I'm not sure I see your point. Even if Eclipse is a defacto standard (right now), doesn't mean that other IDE's should not be supported. I use Eclipse and NetBeans. I'm very impressed with both products, they both have strengths and weaknesses.

    Eclipse is not all powerful. For example when I need to do EJB development I use NetBeans, as it is the stronger IDE for EJB develoopment. To get compairable features in Eclipse you need to buy MyEclipseIDE. I know this will change when the Eclipse Web Toolkit is finished, but Netbeans is there now.
  12. AMEN - choice rules[ Go to top ]

    It is about best technology, becoming standart due its merits.

    Although I like Eclipse in many ways, and now use it for many projects, I disagree with this statement, at least taken generally. NetBeans has better technologies in many areas - J2EE, J2ME, Profiling.

    My impression is that things will get interesting in the near future. Eclipse has (in my view) been through a period in which it has lagged behind other IDEs in its support for modern Java features, and this has driven some developers away. My prediction is that Eclipse will remain dominant, but there will be plenty of room for other IDEs as well.
  13. AMEN - choice rules[ Go to top ]

    It is about best technology, becoming standart due its merits.Sun can refuse to see it as long as they want. That does not change anything.Industry have made a choice.

    Hah! It is about price. I always thought Netbeans is appalling, but then again Eclipse was trash until 3.0 as well.
  14. Are we that tough to please?[ Go to top ]

    So does Mikey like anything?

    http://www.weht.net/WEHT/pics/mikey.jpg
  15. AMEN - choice rules[ Go to top ]

    +1

    Couldn't say it any better, so I won't even try ;-)
  16. Bold Journalism[ Go to top ]

    Also, don't miss Infoworld's incisive interview with the Meterology Institute. Here's a brief excerpt:
    InfoWorld: There was a lot of talk this morning about the sky. I think it could be argued that the sky is blue, although some would disagree with that. Not that we're trying to be controversial. Sir. Please keep buying ads from us.
  17. Plugins Standard[ Go to top ]

    I don't mind to have multiple Java IDEs, but I think it would be nice if we can have a standard way to implement plugins for all those Java IDEs. Currently, if you want to provide a plugin, you have to write different version for Eclipse, NetBeans, IntelliJ, JBuilder etc!
  18. Competition builds quality[ Go to top ]

    I’m an Eclipse user, and I think it is great that there are multiple IDEs.

     First, because competition builds quality. Not always, but usually when there is a monopoly quality slides due to lack-of-motivation to stay competitive.

    Second, I disagree with the idea that standardizing on an IDE will help a company. What can happen is you force development to use tools that where usually chosen due to political reasons. Developers will usually choose what helps them do their jobs best. Standardization is for core technologies, which I believe IDEs are not.
  19. Sun: No plans to join Eclipse[ Go to top ]

    Good.
    Majority is using internet explorer but I prefer to have option of firefox.
  20. It sucks[ Go to top ]

    The thing about Eclipse is that it sucks.
    The thing about Netbeans is that it's worse than Eclipse.

    But they're both still better than JBuilder.
  21. Eclipse sux more every day[ Go to top ]

    Unfortunately I work in a big shop which uses RAD 6.0 the IBM excuse for Eclipse 3.0. I used to like ( no LOVE ) Eclipse as I used it on my personal projects and on smaller development projects, but seeing how it performs on large projects, and the unfortunate "value added" version IBM sells for absurd amounts of money (ie RAD) , Im about to head for the text editor and ant.

    It was a great idea, but it cant really handle large scale development. Im not sure about the other tools. But having used Visual Age, Eclipse, WSAD, and RAD on large projects, they dont really live up to the goal when it comes down to it. And they are all the same basic code base in one form or the other.

    We have developers who can barely work due to the cycles RAD consumes when building all day long. Some literaly type a character then watch the build kick off and wonder what the hell it was they were doing when they come back 20 mins later to their machines. (The machines arent the problem, I know someone who has run the exact same stuff on the fastest machine available to the public and its still churning like butter.)

    As for open source, Eclipse is not. Its not open or source. Its just some code that IBM lets people see and play with and they pretty much rule Eclipse. I dont see Eclipse as open source in the way anything by Apache or JBoss is at all. Eclipse is a front for IBM's java takeover.

    As far as NetBeans goes whatever, I have yet to see the end of Java IDEs that suck. I wish someone would take the concepts that have been worked out in Eclipse and make it not a total pain to use.
  22. Re: Eclipse sux more every day[ Go to top ]

    As for open source, Eclipse is not. Its not open or source. Its just some code that IBM lets people see and play with and they pretty much rule Eclipse. I dont see Eclipse as open source in the way anything by Apache or JBoss is at all. Eclipse is a front for IBM's java takeover.
    Eclipse is completely independent of IBM. What you've said here may have been plausible in 2003, but it is definitely not true today. (I covered this not that long ago at http://milinkovich.blogspot.com/2005/05/eclipse-independence.html)

    Eclipse has evolved from a single project hosted on an IBM web site to an independent not-for-profit foundation with a community-based open source development process inspired by Apache's. We have seen enormous growth in the number of projects at the Eclipse community, which you can see at http://www.eclipse.org/proposals/main.html.

    The Eclipse community is most assuredly as open source as Apache and JBoss. Each community has its own variations, but we are all open, transparent and meritocratic.

    Mike Milinkovich
    Executive Director
    Eclipse Foundation
  23. Eclipse is completely independent of IBM. What you've said here may have been plausible in 2003, but it is definitely not true today.

    Mike, I think he was trying to say what Kirill Grouchnikov recently talked about in his blog: While Eclipse is an open source project, it is still heavily influenced by IBM (which is reasonable), but there seems to be a lot marketing types trying to gloss over or hide that fact (which is strange). For example, you're doing it just now when you say "Eclipse is completely independent of IBM". That's simply not true, so people are bound to wonder why you would say that. (Sure, it's technically independent, but not when you consider that nearly all the work done on it is done by current IBM employees.) I think that's what he was trying to say.

    Rob Harwood
    Software Developer
    JetBrains, Inc.
    http://www.jetbrains.com
    "Develop with pleasure!"
  24. Eclipse sux more every day[ Go to top ]

    As far as NetBeans goes whatever, I have yet to see the end of Java IDEs that suck. I wish someone would take the concepts that have been worked out in Eclipse and make it not a total pain to use.

    My goodness, there are so many people who seem to have never heard of IntelliJ IDEA. Your wish has already been granted (5 years ago!). :-) Ever wonder where Eclipse gets most of its ideas from? Here are a couple of demos here and here.
  25. Eclipse sux more every day[ Go to top ]

    Ever wonder where Eclipse gets most of its ideas from?

    My memory of things is that Eclipse got most of its ideas from its predecessor - IBM's VisualAge for Java, which in turn came from VisualAge for Smalltalk. Almost all the features - the browsing, the refactoring, the continuous build are classic Smalltalk. The Eclipse Scrapbook page was a direct replacement for the Smalltalk Workspace.
  26. Eclipse sux more every day[ Go to top ]

    For example, you're doing it just now when you say "Eclipse is completely independent of IBM". That's simply not true, so people are bound to wonder why you would say that.
    You're right. I said that wrong. What I should have said is the Eclipse Foundation is completely independent of IBM. And I can say that because I know it is true. I live it every day.

    When I talk about Eclipse independence, I am usually thinking of the governance model, where IBM truly set Eclipse free to evolve in the future as an independent entity. The fact that fierce IBM competitors such as BEA, Borland and Computer Associates feel comfortable with the Eclipse governance model to join the board speaks for itself IMO.

    With regard to the Eclipse projects, IBM still has over half of the committers working on them. So it is neither a secret nor a surprise that they are still carrying the load on many of the projects that were started before the creation of the Foundation. But the interesting data is the trend line on *new* projects such as BIRT, where 0% of the committers work for IBM. Kirill Grouchnikov's list of projects was more than a little self serving. It reminds me of the old line about "lies, damn lies and statistics". For every project you can point to which has a lot of IBMers on it, I can point to another which has few or none.

    Yes, it will take time to evolve the older projects to have more diverse committer populations. But there is no way the Eclipse community wants IBM to slow down its investment in Eclipse. The more the merrier, we say. The goal is to grow the committer community and lower IBM's percentage of a much bigger pie. And new projects like GMF (Borland), DSDP (Wind River) and DTP (Sybase) are moving us quickly in that direction.
  27. Eclipse sux more every day[ Go to top ]

    Ever wonder where Eclipse gets most of its ideas from?

    That will definitely be true if replace "Eclipse" with "Visual Studio.NET". A lot of IntelliJ features (even the basic looks and feels) have been copied to VS.NET, with more of them to appear in VS.NET 2.0.
  28. Eclipse sux more every day[ Go to top ]

    Ever wonder where Eclipse gets most of its ideas from?
    That will definitely be true if replace "Eclipse" with "Visual Studio.NET". A lot of IntelliJ features (even the basic looks and feels) have been copied to VS.NET, with more of them to appear in VS.NET 2.0.

    I'm afraid I doubt this very much. There is a lot of misunderstanding about how IDEs have developed. An example is the wikipedia entry for IntelliJ which states "The first version of IntelliJ IDEA appeared in January, 2001 and quickly became very popular, as the first Java IDE with a set of integrated refactoring tools that allow programmers to quickly redesign their code."

    This is obviously nonsense, as I was using refactoring tools in VisualAge for Java in 1997!

    If you want to see the real influence on Microsoft IDEs, you need to look at the IDEs of the late 80s and early 90s. Systems such as Digitalk Smalltalk and Actor. Both Java and Microsoft IDEs have been working to try and provide the rich and sophisticated features that these languages provided 15-20 years ago.
  29. Eclipse sux more every day[ Go to top ]

    The 2 obvious from IntelliJ you will notice immediately when using VS.NET for your very first program are:

    1. Auto hide and pushpin (though the appearances of the pushpins are slightly different between the two IDE).
    2. IntelliJ auto code completion (even MS calls it IntelliJ something here).
  30. Eclipse sux more every day[ Go to top ]

    The 2 obvious from IntelliJ you will notice immediately when using VS.NET for your very first program are:1. Auto hide and pushpin (though the appearances of the pushpins are slightly different between the two IDE).2. IntelliJ auto code completion (even MS calls it IntelliJ something here).

    IntelliJ first appeared in 2001. Visual Studio auto code completion ('IntelliSense') appeared in Visual Studio 6.0 in 1998. So, I think it is reasonably clear that Visual Studio probably did not get such ideas from IntelliJ. Auto hide and pushpins are very old ideas indeed, the latter appearing in GUI systems in the 1980s. Again, somewhat before IntelliJ.
  31. Eclipse sux more every day[ Go to top ]

    Visual Studio auto code completion ('IntelliSense') appeared in Visual Studio 6.0 in 1998.
    I think it appeared even before that. I am pretty sure it was available in at least VS 5. I googled a few refs that say that. (I actually thought it was earlier but couldn't remember - good thing I googled)

    I [sadly] see alot of VS6 in VS.Net. I wish they had borrowed some concepts from Java IDEs instead. For example the VAJ heirarchy views and other class views.
  32. Eclipse sux more every day[ Go to top ]

    Yes, IntelliSense (not IntelliJ) is a feature introduced and popularized by Visual Stutio,

    http://en.wikipedia.org/wiki/IntelliSense

    Never seen 'IntelliSense' mentioned in official Eclipse documentation. The closest seems 'content assist'.
  33. Eclipse sux more every day[ Go to top ]

    Yes, IntelliSense (not IntelliJ) is a feature introduced and popularized by Visual Stutio,http://en.wikipedia.org/wiki/IntelliSenseNever seen 'IntelliSense' mentioned in official Eclipse documentation. The closest seems 'content assist'.

    The point is that this makes the claim that Eclipse copied this from IntelliJ hard to justify.
  34. It's not about IDE's[ Go to top ]

    quote:

    What so upsets Sun about Eclipse (besides the name) is not that it's an IDE that competes with NetBeans. There are plenty of those. The concern is that Eclipse is a complete development platform that makes large parts of Java irrelevant. It effectively takes control of Java away from Sun and puts it in IBM's hands. In other words, it's not Eclipse that worries Sun. It's the SWT and the RCP.

    Thus what's really of interest is not the comparison between the IDEs. It's the comparison between the development platforms. That's why Sun is suddenly pushing Netbeans so hard after abandoning and ignoring IDE after IDE for the last ten years. (Java Workshop anyone?) Sun doesn't need to produce an IDE for Java. They're quite happy for Oracle and Borland and others to serve that market. But they desperately need to prevent developers from defecting to the SWT. That means they have to produce a Swing-based, cross-platform IDE that can compete with Eclipse. So far they haven't done that. Eclipse, built on top of the SWT, runs just fine on the Mac. It's certainly not perfect, but it's good enough. NetBeans isn't. If NetBeans can only run acceptably on Windows, then Sun has failed; and their failure proves that Swing is not a viable cross-platform development environment. IBM wins.

    source: http://www.cafeaulait.org
  35. It's not about IDE's[ Go to top ]

    quote:What so upsets Sun about Eclipse (besides the name) is not that it's an IDE that competes with NetBeans. There are plenty of those. The concern is that Eclipse is a complete development platform that makes large parts of Java irrelevant. It effectively takes control of Java away from Sun and puts it in IBM's hands. In other words, it's not Eclipse that worries Sun. It's the SWT and the RCP.Thus what's really of interest is not the comparison between the IDEs. It's the comparison between the development platforms. That's why Sun is suddenly pushing Netbeans so hard after abandoning and ignoring IDE after IDE for the last ten years. (Java Workshop anyone?) Sun doesn't need to produce an IDE for Java. They're quite happy for Oracle and Borland and others to serve that market. But they desperately need to prevent developers from defecting to the SWT. That means they have to produce a Swing-based, cross-platform IDE that can compete with Eclipse. So far they haven't done that. Eclipse, built on top of the SWT, runs just fine on the Mac. It's certainly not perfect, but it's good enough. NetBeans isn't. If NetBeans can only run acceptably on Windows, then Sun has failed; and their failure proves that Swing is not a viable cross-platform development environment. IBM wins.source: http://www.cafeaulait.org
  36. It's not about IDE's[ Go to top ]

    Exactly which parts are those?
    java.awt and javax.swing
    Control of Java is in the hands of the JCP.
    not always. hence Eclipse, Hibernate, Struts, SDO
    Opensource projects now contibute for a verry large part of the Java ecosystem
    My impression is that SWT has never really taken off.
    Not yet. Eclipse has taken off though. client-side java in general hasn't taken off. Seems that most companies opt for zero install webbased applications these days.
    I have not heard of many applications that use it, and it has had well-documented performance problems on, for example, Linux.
    Linux suffers from GUI desease, just like Java before SWT.
    All performance issues can be related to GTK, Xwindows
    If Liunx GUI get's its act together. (read XGL) then SWT will be just as snappy on Linux as it is on Windows.
    and the quality of the Swing GUI (especially with Java 5.0) has improved
    I heard. Buttons etc.. will be renderd by the OS etc.. Is't that what SWT is all about.
    NetBeans
    no comment
  37. It's not about IDE's[ Go to top ]

    Exactly which parts are those?
    java.awt and javax.swing

    That is certainly not the case, as there are many Eclipse plugins written in Swing - some for writing Swing applications!
    Control of Java is in the hands of the JCP.
    not always. hence Eclipse, Hibernate, Struts, SDOOpensource projects now contibute for a verry large part of the Java ecosystem

    Control of the a large part of the 'ecosystem' is not the same as 'control of Java'. An interesting trend is that open source projects (Groovy, Hibernate, BeanShell etc.) are increasingly moving towards either becoming JCP specifications or contributing significantly towards them.
    My impression is that SWT has never really taken off.
    Not yet. Eclipse has taken off though.

    I believe your point was that Sun was afraid of SWT. Use of Eclipse does not necessarily relate to the use of SWT in applications developed using Eclipse.
    client-side java in general hasn't taken off.

    I thought this until recently - now I believe it is a myth. There are many commercial and open source companies providing GUI components for Swing, and they seem to be doing well. This would not be the case unless there was a large community of developers writing client-side Java.
    Seems that most companies opt for zero install webbased applications these days.

    That does not mean there aren't a reasonable number of internally used client-side applications, deployed with mechanisms such as WebStart.
    Linux suffers from GUI desease, just like Java before SWT. All performance issues can be related to GTK, XwindowsIf Liunx GUI get's its act together. (read XGL) then SWT will be just as snappy on Linux as it is on Windows.

    I would strongly dispute that. I have no GUI performance problems on Linux at all; indeed, I find Linux/KDE to be more responsive that Windows XP on the same hardware. As for Java GUIs, there performance problems with SWT on Linux (so bad that they are listed as a bug), but this is not the case with Swing.
    and the quality of the Swing GUI (especially with Java 5.0) has improved
    I heard. Buttons etc.. will be renderd by the OS etc.. Is't that what SWT is all about.

    Perhaps, but the fact is that it is Swing that is doing it, not SWT. Swing is moving ahead.
  38. It's not about IDE's[ Go to top ]

    (Sorry for the previous post - the result of a browser bug)
    quote:What so upsets Sun about Eclipse (besides the name) is not that it's an IDE that competes with NetBeans.

    That is exactly what it is.
    The concern is that Eclipse is a complete development platform that makes large parts of Java irrelevant.

    Exactly which parts are those?
    It effectively takes control of Java away from Sun and puts it in IBM's hands.

    Control of Java is in the hands of the JCP.
    In other words, it's not Eclipse that worries Sun. It's the SWT and the RCP.

    My impression is that SWT has never really taken off. I have not heard of many applications that use it, and it has had well-documented performance problems on, for example, Linux.
    That's why Sun is suddenly pushing Netbeans so hard after abandoning and ignoring IDE after IDE for the last ten years.

    Sun has hardly been ignoring IDEs! NetBeans/Forte have been under continuous development for years.
    (Java Workshop anyone?)


    That was a very long time ago.
    Sun doesn't need to produce an IDE for Java. They're quite happy for Oracle and Borland and others to serve that market.

    Then why are they developing NetBeans/Sun Studio/Studio Creator so actively?
    But they desperately need to prevent developers from defecting to the SWT. That means they have to produce a Swing-based, cross-platform IDE that can compete with Eclipse. So far they haven't done that.

    That might be true of there was evidence of defection. I may be mistaken, but I haven't seen much. On the contrary, recent versions of NetBeans seem to have gained somewhat in popularity, and the quality of the Swing GUI (especially with Java 5.0) has improved dramatically.
    Eclipse, built on top of the SWT, runs just fine on the Mac. It's certainly not perfect, but it's good enough.

    NetBeans isn't. If NetBeans can only run acceptably on Windows, then Sun has failed; and their failure proves that Swing is not a viable cross-platform development environment. IBM wins.

    What failure?

    I use NetBeans on Windows XP and it is fast and looks far more like a native XP app than Eclipse (a least on the version I last tried on Windows - 3.0). I use NetBeans on Linux, and again the GUI is fast (well, fast enough for me not to complain).

    As far as I know NetBeans runs perfectly well on MacOS/X:

    From developer.apple.com:
    "NetBeans 4.1 is a complete open-source tool for programming in the Java language. Thanks to the excellent support for Java in Mac OS X, and a bit of Mac-specific tuning, using NetBeans on the Macintosh is an great experience for beginners and experts alike."
  39. It's not about IDE's[ Go to top ]

    Sorry Jalki, but I agree with Steve.
    If NetBeans can only run acceptably on Windows, then Sun has failed; and their failure proves that Swing is not a viable cross-platform development environment.

    Your kidding right? Have you ever tired Netbeans on a MAC?

    For the record I use NetBean on WinXP and OSX and it works fine on both. I have not tried Eclipse on the my MAC so I can't give personal insight into which works better.

    But they desperately need to prevent developers from defecting to the SWT.

    I know there is a lot of talk back and fourth about Swing and SWT from the point of view of technical merit. Personally I have not see much in the way of SWT. Mostly example applications, or people playing around. Hobbie programmer are always defecting to something new. Does SWT have much industry support? If so then I must have missed it.
  40. It's not about IDE's[ Go to top ]

    Does SWT have much industry support? If so then I must have missed it.

    Yes you did. :)) Wave of anouncements of Eclipse support (and for this matter SWT of course) from almost all major java companies. :))

    As far as applications built on SWT, i'm using Azureus, one of the most popular BitTorrent clients.
  41. It's not about IDE's[ Go to top ]

    Does SWT have much industry support? If so then I must have missed it.
    Yes you did. :)) Wave of anouncements of Eclipse support (and for this matter SWT of course) from almost all major java companies. :))

    Announcements of support for Eclipse by IDE and tool companies don't mean that developers will be using Eclipse to produce SWT applications, any more than an increased use of NetBeans would imply that developers would produce more Swing apps.
    As far as applications built on SWT, i'm using Azureus, one of the most popular BitTorrent clients.

    Yes, Azeureus is one of just four projects that use SWT that are mentioned on the SWT Community Page. I'm sure there are more, but compare this to the list of companies and groups providing Swing components on Sun's Swing Depot site. These include high-quality and popular components such as JFreeChart. This component alone has had over 24,000 downloads in the last month. So much for the often-repeated myth that client-side Java is dead and no-one uses Swing! The 'Swing Sightings Index' (an occasional series on java.sun.com) lists hundreds of applications, including one of my favourites: Oxygen, the XML editor.
  42. It's not about IDE's[ Go to top ]

    These include high-quality and popular components such as JFreeChart. This component alone has had over 24,000 downloads in the last month. So much for the often-repeated myth that client-side Java is dead and no-one uses Swing!

    Well, using JFreeChart as an example in this regards is certainly not very relevant in advocating massive use of Swing-based GUI's. I know of many projects using JFreeChart, including a few of my own, and NONE of them are making anything related to Swing GUI's.

    In some of my latest projects, I have used JFreeChart to generate the grahpics in web applications, sometimes in companionship with the CEWolf tag library, which is a JSP tag library that wraps JFreeChart.
  43. It's not about IDE's[ Go to top ]

    These include high-quality and popular components such as JFreeChart. This component alone has had over 24,000 downloads in the last month. So much for the often-repeated myth that client-side Java is dead and no-one uses Swing!
    Well, using JFreeChart as an example in this regards is certainly not very relevant in advocating massive use of Swing-based GUI's. I know of many projects using JFreeChart, including a few of my own, and NONE of them are making anything related to Swing GUI's.

    A quick check on the support forums for JFreeChart seems to suggests that a reasonable proportion of the developers using it do so for Swing GUIs. (And this is just for one Swing component, albeit a highly popular one).

    I am not suggesting massive use of any Java GUI for client-side development. Obviously, client-side Java programming is not what the majority of developers do. However, my point was that client-side Java development is definitely going on - it is far from dead - and the vast majority of it uses Swing.
  44. It's not about IDE's[ Go to top ]

    These include high-quality and popular components such as JFreeChart. This component alone has had over 24,000 downloads in the last month. So much for the often-repeated myth that client-side Java is dead and no-one uses Swing!
    Well, using JFreeChart as an example in this regards is certainly not very relevant in advocating massive use of Swing-based GUI's. I know of many projects using JFreeChart, including a few of my own, and NONE of them are making anything related to Swing GUI's.
    A quick check on the support forums for JFreeChart seems to suggests that a reasonable proportion of the developers using it do so for Swing GUIs. (And this is just for one Swing component, albeit a highly popular one). I am not suggesting massive use of any Java GUI for client-side development. Obviously, client-side Java programming is not what the majority of developers do. However, my point was that client-side Java development is definitely going on - it is far from dead - and the vast majority of it uses Swing.
    Well, if one is using JFreeChart, they are using Swing, which was your original point (not Swing GUIs).
  45. It's not about IDE's[ Go to top ]

    The 'Swing Sightings Index' (an occasional series on java.sun.com) lists hundreds of applications, including one of my favourites: Oxygen, the XML editor.

    Oxygen is also provided as Eclipse plugin, written in SWT.
    So your own example shows adoption of SWT among 3-rd party providers.

    Besides, do not forget that swing had a headstart. And at the begining people believed in java client apps and put lot's of effort in swing apps and swing components. But they never took off. That's why much later, when SWT apeared, people did not ruch to write SWT apps and SWT components.
  46. It's not about IDE's[ Go to top ]

    The 'Swing Sightings Index' (an occasional series on java.sun.com) lists hundreds of applications, including one of my favourites: Oxygen, the XML editor.
    Oxygen is also provided as Eclipse plugin, written in SWT.So your own example shows adoption of SWT among 3-rd party providers.Besides, do not forget that swing had a headstart. And at the begining people believed in java client apps and put lot's of effort in swing apps and swing components. But they never took off. That's why much later, when SWT apeared, people did not ruch to write SWT apps and SWT components.

    I did not say that there was no adoption of SWT; just that there is not much evidence that it is significant. Plugins for eclipse are not equivalent to desktop applications. The motive for re-writing in SWT in these cases is simply for integration into Eclipse, not because SWT is good for stand-alone client side applications. I'm afraid the evidence simply does not seem to back up your statement that Swing components and applications 'never took off'. I'm not saying it is a huge and dominant part of Java development, but my impression is that there are certainly Swing projects out there, and far more than for SWT.
  47. It's not about IDE's[ Go to top ]

    I did not say that there was no adoption of SWT; just that there is not much evidence that it is significant. Plugins for eclipse are not equivalent to desktop applications. The motive for re-writing in SWT in these cases is simply for integration into Eclipse, not because SWT is good for stand-alone client side applications.

    That's because most people are talking about those applications as Eclipse RCP application, not SWT. With the RCP, Eclipse provides a framework for building GUI applications that goes way beyond anything you can do with Swing today. With the major enhancements to the RCP in Eclipse 3.1, you're going to see RCP applications everywhere. Already the number of vendors who are porting their tools to Eclipse RCP is overwhelming: Borland, BEA, Oracle, Sybase, Actuate, etc etc. All these are, or will be, SWT applications.

    To make an analogy with web application development, the scrap between Swing and SWT is like the choice between bare Servlets and CGI. These days nobody writes a significant web application just with Servlets, they use a framework like Struts or JSF or whatever. In the future, nobody will tackle a significant GUI development project just with Swing or SWT. They'll use a framework like Eclipse RCP or Spring Rich Client or whatever the NetBeans effort is called. Today, by far the most mature of those frameworks is the Eclipse RCP. For me, that makes the choice between SWT and Swing somewhat secondary.
  48. It's not about IDE's[ Go to top ]

    That's because most people are talking about those applications as Eclipse RCP application, not SWT. With the RCP, Eclipse provides a framework for building GUI applications that goes way beyond anything you can do with Swing today. With the major enhancements to the RCP in Eclipse 3.1, you're going to see RCP applications everywhere.

    I doubt this, honestly. The move in Java seems to be towards lighter systems. The idea of using Eclipse (or NetBeans) as a framework for a GUI app seems wildly excessive. I can see there might be some specialised applications where such a framework could be of benefit, but not generally.
    Already the number of vendors who are porting their tools to Eclipse RCP is overwhelming: Borland, BEA, Oracle, Sybase, Actuate, etc etc. All these are, or will be, SWT applications.

    No they won't be, at least not in the term as I understand 'application'. They will be tools for Eclipse. A tool is not an application.
    To make an analogy with web application development, the scrap between Swing and SWT is like the choice between bare Servlets and CGI. These days nobody writes a significant web application just with Servlets, they use a framework like Struts or JSF or whatever. In the future, nobody will tackle a significant GUI development project just with Swing or SWT.

    I see your point, but I don't agree. A more appropriate analogy is with Spring, which can integrate GUI, model structure and persistence.
    They'll use a framework like Eclipse RCP or Spring Rich Client or whatever the NetBeans effort is called. Today, by far the most mature of those frameworks is the Eclipse RCP. For me, that makes the choice between SWT and Swing somewhat secondary.

    RCP frameworks would seem to me suited for a small and specialised range of uses. If Java is going to grow on the desktop it needs a GUI framework that can allow general-purpose lightweight applications to be written. Java would benefit from the same kind of ease-of-use of GUI development as VB or Delphi. To suggest that large numbers of GUI apps will based on an Eclipse framework is equivalent to suggesting that even the lightest database apps should use Oracle! I also thing that the future is for a range of styles of GUI to be presented from central servers both within organisations and externally - lean websites, richer AJAX-based systems, all the way to applets and WebStart-deployed Swing Applications - systems that scale to whatever presentation technology is used. I see a decreasing role for large workstation-installed systems.

    Of course, I may be missing something important here - I am open to being convinced otherwise!
  49. It's not about IDE's[ Go to top ]

    I think that you're confusing "Eclipse the Java IDE" with "Eclipse the platform". The Java IDE that most people think of when they think about Eclipse is really only one of the kinds of application that can be built using RCP. The Eclipse platform itself is just a microkernel that manages plugins.

    You also seem to think that the word "framework" implies something heavyweight and restrictive - it doesn't, as the Spring framework demonstrates. Fortunately Eclipse is far more like Spring than Oracle!

    Eclipse RCP applications are lightweight because they use only the Eclipse microkernel the supporting plugins they choose. They do NOT include a Java IDE, and in fact need not look anything like an IDE at all. The Java IDE that people mostly think of when they think of Eclipse is really just one example of the kinds of application that can be built using the platform.
    RCP frameworks would seem to me suited for a small and specialised range of uses. If Java is going to grow on the desktop it needs a GUI framework that can allow general-purpose lightweight applications to be written.

    Right! And that's exactly what an RCP offers.
    I also thing that the future is for a range of styles of GUI to be presented from central servers both within organisations and externally - lean websites, richer AJAX-based systems, all the way to applets and WebStart-deployed Swing Applications

    I agree, but replace WebStart-deployed Swing Applications with WebStart-deployed RCP applications. And delete applets, does anybody still use them??
  50. It's not about IDE's[ Go to top ]

    Ooops sorry for the repetition repetition. Cut and paste error :-(
  51. It's not about IDE's[ Go to top ]

    I think that you're confusing "Eclipse the Java IDE" with "Eclipse the platform".

    I thought I might be!
    Right! And that's exactly what an RCP offers.
    You have got me interested! I did not realise things could be that lightweight.
    I also thing that the future is for a range of styles of GUI to be presented from central servers both within organisations and externally - lean websites, richer AJAX-based systems, all the way to applets and WebStart-deployed Swing Applications
    I agree, but replace WebStart-deployed Swing Applications with WebStart-deployed RCP applications.

    You can WebStart an RCP, but I would imagine it is harder with an SWT RCP because SWT is not part of standard JREs.
    And delete applets, does anybody still use them??

    Yes - the myth of the death of the applet is like the myth of the death of client-side java - a myth.

    I can see what you are saying. However, I still think that SWT has quite a bit of catching up to do before it is an high-performance and good-looking GUI toolkit on all platforms. And, Eclipse RCP or not, I just don't (yet) see the SWT apps out there.
  52. It's not about IDE's[ Go to top ]

    You can WebStart an RCP, but I would imagine it is harder with an SWT RCP because SWT is not part of standard JREs.
    Not really, it's just jars. When's the last time you wrote an application that didn't depend on any 3rd party jars?
    I can see what you are saying. However, I still think that SWT has quite a bit of catching up to do before it is an high-performance and good-looking GUI toolkit on all platforms. And, Eclipse RCP or not, I just don't (yet) see the SWT apps out there.
    I think you will start seeing more of them within a year or so. There are only a few at the moment because Eclipse 3.1 (only just released) is the first version in which the RCP is really stable and useful. Mostly these applications will be a vote for the RCP rather than for SWT - personally I don't believe SWT is necessarily better than Swing.
  53. It's not about IDE's[ Go to top ]

    You can WebStart an RCP, but I would imagine it is harder with an SWT RCP because SWT is not part of standard JREs.
    Not really, it's just jars. When's the last time you wrote an application that didn't depend on any 3rd party jars?

    I don't think it is just jars. If you are using SWT you will need the platform-dependent libraries for native GUI integration.
    Mostly these applications will be a vote for the RCP rather than for SWT - personally I don't believe SWT is necessarily better than Swing.

    But then why should this involve Eclipse? Eclipse seems to have gained enormous popularity as development platform and developers tools platform. Why should this relate to its use as an RCP, where there are almost certainly going to be others - indeed, others that are probably easier to deploy? After all, Eclipse's popularity for development has not led to a widespread use of SWT.
  54. It's ALL about IDE's :o)[ Go to top ]

    Hi,

    Home users are used to download and install in a snap any kind of of software over 8Mbps DSL lines, from new versions of IE/Firefox to latest bit-torrent client. If they have the proper usage, they will download and run, and will not care about a couple of jars or libs included in the distrib.

    But from a developer point-of-view, what is the best (from a productive point-of-view) graphical development tool to build Rich Client Application ? And of course the library of widgets has to be responsive and good looking. Why ? Because the more visually attractive you are, the more likely your software will be successful (ok, it also has to be useful :o)

    In other words : what is the VB of Java world ? Ok, don't flame me :o)

    I do develop some small java application or applets, that mainly display database values. These are used by business users as helper to quickly get the info they want in a personalized way. Things started very small with notepad, but after some months it is dfferent. So you i have some basic GUI framework that dislays an explorer on the left, some tabbed panes on the right with tables and labels within, and some pop-up for properties, plus some menus. Everybody is happy.

    The basic look-and-feel of swing is really ok for such a use, but in no way is the application looking like a native Windows application. This is not fundamental for tools for my collegues and family, but it certainly affects negatively the perception of these tools compared to, le'ts say... a VB program that would have the very same functionnalities !

    I think to have a Windows look-and-feel could be done (only basic widgets here) but i do not want to spend time on looking for the proper controls or settings, i would like it to by default look like Windows applications.

    On the other side, my Eclipse IDE does not look like a native Windows application at all ! How do you compare MS Outlook look-and-feel and Eclipse look-and-feel ? User experience is so different. So i would be wiling to pay a few money for a true Windows look-and-feel based on Swing. Because i believe it is more about graphics than about controls, i mainly need a good graphics designer.

    So where is the interest to switch to Eclipse RCP, now that i know the Swing basics and more ? Also, is there any GUI tool to visually and easily build an Eclipse RCP based application ? As easily as i can build a VB GUI application ?

    Additionally, i am actually much more interested into portability of my code than anything else, even regarding the look-and-feel. Unless the distributions mechanism handles 100% of the compatibility problems for me, something which i dount would ever happen.

    Christian
  55. It's not about IDE's[ Go to top ]

    <Yes, Azeureus is one of just four projects that use SWT that are mentioned on the SWT Community Page.

    Speaking of Azureus & SWT, here's what the developer of the email client Columba, written in Swing, had to say:

    7. Did you ever seriously consider SWT?

    fdietz: [...] I really like Eclipse IDE (using it for Columba development everyday and also at work) and of course SWT. But just looking at the number of bug-reports submitted by the authors of the Azureus and RSSOwl projects, shows that SWT is still behind Swing in terms of stability. I'm working with Swing applications for almost 8 years now and never submitted as many bug reports as these two projects combined. Additionally, SWT has proven to be really great when using very easy dialogs, where you only use default SWT components. If you create custom components, like we do in Columba, SWT can become really painfully. All these discussions about SWT vs. Swing are really boring to me, because they are mostly about the look or the responsiveness and also very subjective and non-technical. Usually, these are not the reasons why you should use SWT over Swing in real life projects But, there are of course several very nice things about SWT, which make me revaluate which toolkit I'm going to use for new projects every time. The main problem I currently see with SWT, is that they have to write lots of native code, they have to support for many platforms. This is a hugh effort and they are still behind Swing in some areas. Nevertheless, its amazing how fast SWT and the Eclipse Platform are evolving and only time will tell what will happen next.

    http://www.clientjava.com/blog/2005/07/05/1120579318910.html
  56. It's not about IDE's[ Go to top ]

    Hobbie programmer are always defecting to something new. Does SWT have much industry support? If so then I must have missed it.

    When SWT first came out, it seemed to be a seriously good idea. At the time, Swing was suffering from major performance problems and was distinctly ugly (there was considerable effort by various groups to develop better looks and feels). However, the situation is now almost reversed. There are still problems with Swing 'native' look and feel on some platforms, but it is getting much better, and Swing on MacOS/X has always been of high quality. The new Java 5.0 cross-platform look and feel is, I feel, actually rather attractive. Swing can also be dramatically accelerated with the use of DirectX and OpenGL. Swing on Longhorn will apparently work closely with the Windows API and be indistinguishable from native applications. It seems to me that, in terms of client GUIs, Swing is where the momentum and innovation is. SWT almost seems to have been a mistake.
  57. It's not about L&F[ Go to top ]

    new Java 5.0 cross-platform look and feel is, I feel, actually rather attractive. Swing can also be dramatically accelerated with the use of DirectX and OpenGL. Swing on Longhorn will apparently work closely with the Windows API and be indistinguishable from native applications. It seems to me that, in terms of client GUIs, Swing is where the momentum and innovation is. SWT almost seems to have been a mistake.
    SWT is not just about L&F, it is about having native controls and native OS/shell features backing the controls, for example, drag-n-drop.
  58. It's not about L&amp;F[ Go to top ]

    SWT is not just about L&amp;F, it is about having native controls and native OS/shell features backing the controls, for example, drag-n-drop.

    The idea of using native controls was to give native look and feel and native performance. There is nothing intrinsically good about having native controls - why should a user care how a control is implemented? As for drag and drop and similar features, they work fine with Swing.
  59. SWT vs. Swing[ Go to top ]

    SWT is not just about L&amp;F, it is about having native controls and native OS/shell features backing the controls, for example, drag-n-drop.
    But having a separate native component set has several drawbacks that more than weigh up for any advantages this gives over Swing: You add a native component that needs to be distributed with your app (and installed somewhere on the lava.library.path); writing a new control og extending another can involve coding C/C++ for a multitude of platforms, with all the pitfalls that entails; and "native" doesn't mean they will actually look or behave like other native widgets in the window system used - witness the differences between Windows versions.

    All in all, Swing will live on since it's simply there with no further effort.
  60. Sun should not join Eclipse[ Go to top ]

    I think, a race between products have a positive effect. It make products willing to improve themselves.

    Eclipse does not need Sun. Eclipse is growing, alive, and getting stronger and stronger without Sun.

    Beside, will Eclipse become better, or worse, if Sun join Eclipse? No body know.
  61. Every now and then someone asks Sun if they want to
    a) open source Java
    b) join Eclipse

    The answers are always the same
    a: No (well, we mean Java is already kind of Open Source, at least open source enough for our definition of OS ;)
    b: No

    Why journalists keep asking these questions?

    (Maybe there was some big event related to Eclipse that would judge a rethinking of Suns decision, but I haven't seen such thing in the last weeks)
  62. Sun: No plans to stop sucking[ Go to top ]

    Programmers are given to manifestos so here goes:

    1) Screw Eclipse

    2) Screw Java

    3) Screw MVC

    4) Screw Patterns

    5) Screw OOP pretense

    6) Do the rolling with ruby on rails tutorial (then forget you did it)

    7) STOP - trying to refine 20 year old ideas

    8) Be an engineer, inventor, scientist, something of use and stop lapping at the "standard" APIs which you are fed to give you someting stupid and redundant to do which usually works like crap.

    9) STOP - trying to make assembly code look cool

    10) STOP - believing giving your code away makes you cool

    11) Take us forward.

    12) We are still programming the CPU like a bunch of machine language cretins. Putting parms on the stack and calling functions. The code just looks pretty now.

    How many syntaxes, APIs, patterns, frameworks, integrations , standards, testing regimes, programming methodologies or whatever do you think is going to make this stuff stop sucking? NONE of it. Because its ALL THE SAME.

    13) Start SOMETHING TRULY DIFFERENT.
  63. Sun: No plans to stop sucking[ Go to top ]

    12) We are still programming the CPU like a bunch of machine language cretins. Putting parms on the stack and calling functions. The code just looks pretty now. How many syntaxes, APIs, patterns, frameworks, integrations , standards, testing regimes, programming methodologies or whatever do you think is going to make this stuff stop sucking? NONE of it. Because its ALL THE SAME.

    13) Start SOMETHING TRULY DIFFERENT.

    Again, your wish has been granted. Still in its super-early stages. Be gentle. ;-)
  64. Communities will promote the process of Java, I hope SUN can realize that!