Slashdot Mirror


Sun Drops Bid To Join Eclipse

ilovestuff writes "According to ZDNet, Sun Microsystems has decided not to join the Eclipse open-source tools effort backed by rival IBM. In addition to dropping the plan to join Eclipse, Sun said Wednesday that it will no longer try to merge the Sun-sponsored NetBeans.org open-source Java tools project with Eclipse. The Eclipse open-source project, founded by IBM in 2001, is an IBM-owned consortium which has gained the membership of several development tools companies over the past year."

26 of 80 comments (clear)

  1. Title by Anonymous Coward · · Score: 3, Funny

    Let me just say that, at first glance, that title confused me terribly. I mean, I didn't know that the sun had say in such matters, and an eclipse certainly wouldn't happen without it.

  2. In other news... by Alphanos · · Score: 3, Funny

    In other news, Red Hat, Mandrake, Debian and Gentoo have decided they will not merge. Strangely, the same choice has been made regarding the (im)possible merger of NetBSD, OpenBSD, and FreeBSD. Weird decisions, eh:)?

    --
    Alphanos
  3. Should have been under: Science - Astronomy by Domini · · Score: 4, Funny

    Perhaps Sun has a problem with the name ' Eclipse', fearing they may lose out?

    -grin-

  4. Real reason by jsse · · Score: 4, Interesting

    Can be found in the last paragraph of the article:

    Apart from the technical differences between Eclipse and NetBeans, Sun had some concerns that Eclipse was dominated by IBM, Green said. In September, Eclipse set out to restructure its membership model to gain independence from IBM and established a board.

  5. Sad, but no surprise by jtheory · · Score: 5, Insightful

    I think almost everyone involved agreed (and still agrees) that it would be cool for NetBeans and Eclipse to share a plug-in architecture, and even underlying framework code. It would allow a great leap in pooling OSS development resources, and would be a boon for plug-in developers, which in turn would help to make Java with *free* tools a better platform than competing MS technologies.

    I wrote a version control plugin for JBuilder -- yet another IDE with its own plugin architecture -- and I'm currently learning the Eclipse plugin architecture so I can port it... yes, it sure would be nice if I could just deploy it as is to other IDEs!

    But... I suspect that the whole merging idea was mostly conceived by management types who got a rude awakening when they started talking to the tool developers and found out what kind of effort it would take to actually do it.

    The work involved would be mind-boggling... and it's not the sort of thing that would draw open-source developers. It definitely scratches an itch to implement that feature you've been longing for in your IDE of choice (which is why it's often easy to get lots of contributors to a good IDE; look how quick the Eclipse community grew!). But I'll be damned if I'm going to reimplement the same thing two years later for free.

    The next version of any tool after it's been ripped apart and reassembled is usually much worse than the last version, too. I remember when JBuilder first switched to a version written in Java (3.5)... it hurt to see how many important features were broken or removed. Sure, you understand that this will help in the long run, but you don't want to be around while it fights it way back to mature status.

    So would Sun and IBM be willing to pay what it would really take to get there? It would have been nice, but I'm not surprised the answer was no.

    --
    There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
    1. Re:Sad, but no surprise by erlando · · Score: 2, Interesting
      I wrote a version control plugin for JBuilder -- yet another IDE with its own plugin architecture -- and I'm currently learning the Eclipse plugin architecture so I can port it... yes, it sure would be nice if I could just deploy it as is to other IDEs!
      Why port it? Eclipse already has full CVS-integration with the features of your plug-in under JBuilder.
      --
      Remember, there are no stupid questions. But there are a lot of inquisitive idiots.
    2. Re:Sad, but no surprise by Adhoc · · Score: 2, Informative

      Check out Subclipse. I haven't tried it myself (since I don't use subversion yet). It looks fairly feature complete though.

  6. Why the hell haven't they just bought IntelliJ? by GOD_ALMIGHTY · · Score: 4, Insightful

    Seriously, JetBrains can't be much. It's a company with one product that is based in the Czech Republic with offices in Russia and Boston.

    IntelliJ is light years better than Eclipse or Netbeans. Why is Sun still putzing around? Buy JetBrains and call IntelliJ NetBeans.

    Not to mention that Eclipse has got a hell of a better chance of competing with IntelliJ than NetBeans. They really need to move NetBeans into something more complete. MS is running so many circles around Sun in dev tools it's not funny. The goal of 10 mil Java developers ain't happenin until Sun pulls it's head out of it's ass and makes sure that the Java platform has top notch tools that can compete for novice developers with MS.

    --
    Arrogance is Confidence which lacks integrity. -- me
    1. Re:Why the hell haven't they just bought IntelliJ? by Antity-H · · Score: 2, Interesting

      You forget a big point.

      Even if IntelliJ is one of the best tools around, it can't be fashionnable as there is no open source version of it (or at least all I could find was a 30 days limited demo version).

      Today, open source _is_ fashion. Companies and people ask more and more for Open Source. Whether they are or not related to computer programming (maybe even more so if they aren't).

      Additionnaly it seems that community support has become an important requirement for such tools as IDE. And I personally agree with this last point. I think that having at least a community edition for non commercial use is a good way to get the best of both ways.

    2. Re:Why the hell haven't they just bought IntelliJ? by GOD_ALMIGHTY · · Score: 2, Insightful

      That argument makes no sense.

      Sun bought OpenOffice and OpenSourced it, I'm pretty sure they did the same with NetBeans. IntelliJ is simply a "better" product than NetBeans or Eclipse. I'm willing to shell out of my pocket for IntelliJ because it makes me so much more productive than NetBeans or Eclipse. That's what Sun needs. MS has been making the case, successfully, that their tools make developers more productive. Sun and IBM can't make that case. Borland could maybe make that case, but I've honestly never liked JBuilder for anything other than GUI stuff.

      I switched from vi to IntelliJ, and I've been using vi for 20 years, it just helps me be that much more productive.

      --
      Arrogance is Confidence which lacks integrity. -- me
  7. No loss by Earlybird · · Score: 5, Insightful
    Eclipse doesn't need Sun. Eclipse has, all on their own, managed to create an incredible piece of engineering that brings Sun's technology work to shame.

    As an Eclipse user and plug-in developer, I would rather see Eclipse evolve freely than see it encumbered by the huge porting effort required to merge it with Sun's technology.

    The fact that SWT (Eclipse's GUI toolkit) and Swing (Sun's) are incompatible as far as philosophy and vision are concerned is also significant.

    SWT lets Eclipse and users develop portable programs that look and behave exactly like native applications: on Windows my app will look like a Windows app, on Linux it will look like a GTK+ app, and so on. Swing, on the other hand, is a platform in itself; it does provide some hooks for native technologies (printing, mouse wheels, etc.), but it will never adapt to changes of the local platform. SWT apps, since they use native APIs, do; for example, on Windows 2000 Eclipse looks like a Win 2000 app; on XP it looks like an XP app, with no additional theming support needed in the toolkit.

    1. Re:No loss by liloldme · · Score: 3, Informative

      What the original poster neglects to mention is SWT only works on a fairly limited number of platforms, whereas Swing works wherever you can get a modern Java VM running.

    2. Re:No loss by DevilM · · Score: 2, Insightful

      Swing can be implemented using native widgets just look at Mac OS X, which did exactly that.

    3. Re:No loss by Lao-Tzu · · Score: 4, Informative

      The difference is significant, actually. For example, the Aqua look and feel has been considered one of the most complete Swing L&F engines. However, the file chooser dialog looks the same in a Swing application running in Panther as it did running in Jaguar. And in fact, it does not resemble neither Jaguar nor Panther's file open dialog.

      The new implementation of tabs (NSTabView/JTabbedPane) in Panther is a row of buttons instead of tabs. The buttons do appear in a Swing application using JTabbedPane, _but_, the inside of the tabbed pane is only partially shaded when it's supposed to be entirely. This looks terrible since it's partially native but not-quite-there.

      Eclipse's SWT has neither of these problems, nor does it have dozens of other problems that Swing has in Aqua.

    4. Re:No loss by Earlybird · · Score: 2, Interesting
      Hmm, so what if I want to use your program on sparc solaris? Or maybe x86 solaris? Or BSD of some kind? Or sparc/ppc/whatever linux?

      Eclipse runs on Solaris/SPARC. It probably also runs on the other platforms you mention, but there are no official binaries, and it might need a few patches to run on, say, FreeBSD. However, this being open source and all, nothing is stopping anyone from implementing suppport for these platforms.

      How exacly does it make it possible to use native widgets on every platform where java works?

      It doesn't. SWT only runs on supported platforms. The supported GUIs are currently Win32, GTK+ 2, Motif and Carbon. The supported platforms are Windows 98/ME/2000/XP, Linux/x86, Solaris/SPARC, MacOSX/PPC, AIX/PPC and HP-UX/HP9000.

      Does it provide everything in a huge bundle that has to be installed along with your java program?

      SWT is a library that consists of Java code plus native bindings implemented using JNI. You obviously need the SWT JAR, and you need the binding for your platform, which is a single, quite small shared object file (the Win32 SWT DLL is ~270KB).

    5. Re:No loss by Earlybird · · Score: 4, Insightful
      What the original poster neglects to mention is SWT only works on a fairly limited number of platforms, whereas Swing works wherever you can get a modern Java VM running.

      Yes, Swing runs wherever you want, but the problem is that (a) it looks like crap, and (b) it doesn't integrate fully with the parent operating/windowing system. The former is less important if you only care about functionality; the latter is extremely important, period.

      Non-native-looking/-behaving apps alienate users. Swing apps aren't affected by native themes, for example. I remember back when Swing didn't support the mouse wheel on Windows. Swing apps don't use Windows' native file dialogs. Consider accessability; Windows, Mac and GTK2 all have extensive APIs and technologies for screen reading and so on. Does Swing support them?

      SWT already runs on a wide variety of platforms, and it's "driver" is small enough that adding support for new platforms isn't that much work. And the benefits are enormous.

    6. Re:No loss by cxvx · · Score: 2, Informative

      A lot of the points you make have been (somewhat) solved with the JDK 1.4.2.

      With the GTK+ and Windows XP look 'n feels, Swing programs look like native programs, and adjust themselves to whatever theme you have set up (it only supports the Bluecurve engine for GTK though).

      There's more info on it at GnomeDesktop.org

      The integration problems you talk about unfortunately still exist, but at least it can look better than plain old metal look 'n feel.

      --
      If only I could come up with a good sig ...
  8. Right by jtheory · · Score: 2, Insightful

    I think you're catching on to why Sun backed out...

    --
    There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
  9. Java VM does not mean working Swing by Anonymous Coward · · Score: 3, Informative

    Swing depply depends on presence of working AWT implementation, it just does not use widgets defined by AWT but rather render them on its own. On the other hand SWT does not need anything from java.awt.

    There are many clean room implementations of JVM (kaffe, gcj and a few proprietry projects) that do not provide working AWT and it is simpler to implement SWT for them then the AWT subset required for Swing. That is why one can already uses gcj to compile SWT applications but not Swing ones.

  10. It's understandable, really... by Lendrick · · Score: 2, Funny

    If your company is named Sun, joining something called Eclipse can't possibly be good for you.

  11. Re:what a shame by fender_rules · · Score: 2, Informative

    What are the most useful features do you think VB provides which Eclipse lacks? Especially with new Visual Editor Project(VEP), I don't think Eclipse actually falls behind VB even it's VB.NET. On the other hand, I think strong refactoring support and variety of third party plugins (which counts over 400 already) are what made Eclipse popular today. And both of these are non-existent in any of the VS.NET products.

  12. VB == scripting language for ActiveX controls by Latent+Heat · · Score: 3, Insightful
    I think of VB as a scripting language for ActiveX controls -- it is not so much VB as the software components that you can use VB to hook up. An ActiveX control can be written in C++, Delphi, and even VB itself, and it has full access to the Windows API so it can do near anything -- none of this lowest-common denominator across multiple GUI's thing. ActiveX controls are usable in everything from Visual Basic to Delphi to Matlab to IE to all the .NET languages to even SWT (Windows only). Your VEP won't hook up ActiveX controls let alone SWT controls -- it is currently restricted to Swing.

    Yeah, you can have Swing controls and JBuilder has been doing the Delphi-like thing with them. While Swing is cross platform and one language (and Delphi VCL is one platform and perhaps two languages: Delphi Pascal and C++ Builder, and perhaps another platform depending on your thoughts on the success of Kylix), ActiveX is one platform but a whole bunch of languages, more so than the .NET world of many skins on the one CLR language. There are big advantages to cross language -- call me a relic, call me what you will, but I like that old-fashioned Object Pascal as a development language, but none of my customers want anything to do with it.

    So what is to prevent a VB dude from switching to Eclipse and VEP (besides having suffered neurological damage learning Visual Basic)? That mass collection of 3rd party ActiveX controls that do all kinds of not only cool but essential application-specific stuff for numerous niche requirements. ActiveX may be crufty and a bear to develop for with its IDispatch and variants and BSTR's and all kinds of restrictions on data types depending on your target, but it is the success story of components as a means to reusable software. Java might have the killer library for everything else, but ActiveX is the killer software pool for the GUI.

    1. Re:VB == scripting language for ActiveX controls by fender_rules · · Score: 2, Informative

      I know SWT is not yet ready for prime yet. And surely any Java IDE can't compete with VS in making desktop applications running on Win32. But, I believe the whole point of the original post is whether Eclipse as an IDE is superior to VB or not. It's not the question of if SWT-Java is more suitable to ActiveX-VB in developing win32 desktop applications. All of the features you've mentioned are of ActiveX, not VB and not VS. And while I admit language independence is a nice thing, I don't think it's more important than platform independence in most of the cases. You can easily find some successful cross platform softwares, but you won't find too many successful projects which are built by 2 VB programmers, 1 Cobol programmers, 3 C programmers, and etc. - It won't affect customers at all, while being complete disaster in management aspect . And as far as cross platform capability is concerned, VB.NET won't help you much. Anyway, even in end user desktop applications, I believe Java/SWT/Eclipse/GCJ combination have tremendous potential than you might expect. Current VEP is for Swing only as you've mentioned, but SWT version will arrive at the 1st quarter of next year. And with these combination, you can easily build cross platform native applications. Third party SWT/JFace components maeket is non-existent yet, but you should consider there're much more high quality opensource third party non-GUI Java libraries than MS counter part. And to return to the original point, I think Eclipse is far superior to VB as long as features as IDE are concerned.

  13. Re:Sun? by JestEnough · · Score: 2, Insightful

    Sun doesn't get where the market is heading.

    It got lucky on big iron in the 90's and did/does a terrific job with java. But it's feet are full of bullet holes where it shot/shoots itself in the foot.

    There is a massive exodus of developers here in Dallas to Eclipse, and it is all based on attraction. Same with the open source projects I work with. Netbeans can do what it wants, but the most likely outcome is to be ignored to death.

    In the same vein, SWT rocks, and I say that being a swing enthusiast.

    People vote with their feet, and that is the only vote that counts. There will always be laggards and people going in the other direction, but the traffic is going in the direction of the better mousetrap, in this instance.

  14. Perhaps I'm stating the obvious, but... by g_lightyear · · Score: 2, Interesting

    Everyone had to know, all along, that it would be very difficult for Sun to support Eclipse when Eclipse is not 100% java. It's marketing seppuku - proof that big applications would need native code to really work. The fact that there's truth in that is all the more reason for Sun to not get anywhere near it. You only need to use netbeans for a day, and switch back to Eclipse, to really see the difference in UI performance. Sun can change that, over time - it may improve the performance of Swing, and a Swing that rendered native could indeed be built (and has been done - by Apple - so it does work and work well). Whether or not Sun will bite? Who knows. Future versions of java on Linux are said to indeed use a GL canvas for some rendering. I'll say this - it's going to be a tough slog for Sun to get the JDK up to par with what SWT does today in terms of native performance; and any advance they make to the JDK immediately provides the opportunity for SWT to improve its own performance through similar API. I'll say this though: Everyone should have seen this coming. IBM isn't going to budge from its native direction, as it's practical, and Sun can't possibly go down that road. The two architectures are so fundamentally different that it's nigh-on impossible to imagine them merging, especially when IBM is going through such huge core changes in the way that plugins are soon to be dynamically loaded and unloaded from the core through OSGi. Sun doesn't stand a chance; it's unfortunate that they're unable to move out of the way of that oncoming train, from NetBeans as market-leader to lagging well behind.

    --
    -- A mind is a terrible thing.
    1. Re:Perhaps I'm stating the obvious, but... by buckinm · · Score: 2, Insightful

      It's marketing seppuku - proof that big applications would need native code to really work.

      It doesn't really prove that native code is required. It just proves that Swing is crap.

      I have a bunch of java applications that run fine without native code. They just aren't GUI apps.

      The problem with Swing isn't that it's java, but Swing's overall design. After all, swing calls native methods to display stuff eventually, just not as early as SWT.

      I think Sun could fix Swing if they really wanted to. I just am not sure they really want to.

      --
      This isn't any ordinary darkness. It's advanced darkness.