Slashdot Mirror


IBM Collaborating With Open Source Java Project

lord_rob the only on writes "According to news.com, IBM has begun participating in the open-source Java project Harmony and intends to contribute code to the initiative, according to a Big Blue executive. At this point, IBM's participation is limited to thoughts on design, but the company has plans to contribute code to the project in the future." From the article: "We really like to see the community get started, and they're still working out the rough edges of what they want to deliver. And we didn't want to disrupt that,"

6 of 149 comments (clear)

  1. Talk about fragmenting the standard... by jarich · · Score: 4, Insightful
    Sun's reasoning for not open sourcing Java is that they didn't want to fragment the Java language with competing verions of Java.

    Looks like ~not~ open sourcing Java is fragmenting the Java language after all!

    1. Re:Talk about fragmenting the standard... by ballstothat · · Score: 4, Insightful
      I completely agree with Sun's stance on not fragmenting their code. While their licensing isn't agreeable, there are millions of java powered items out there. If Java turned into a bunch of different flavors (insert mocha, vanilla, hazelnut joke here), then it would be a headache.

      The JRE for Windows XP is already 15.4 MB. If there was 5 different REs that I had to download to use all the Java flavors, that wouldn't be cool.

      I feel that Sun's thinking is sound from a business and usefulness perspective, even if it is starting to backfire.

      --
      10
      20 Print "Balls To That"
    2. Re:Talk about fragmenting the standard... by Jason+Earl · · Score: 3, Insightful

      No matter how compliant Harmony purports to be it is still going to be different than Sun's JVM. Any sysadmin that has ever had to juggle multiple JVMs can tell you that Sun's Write Once Run Anywhere motto can quickly become Write Once Debug Everywhere.

      It's also entirely possible that Harmony won't even try for complete compliance. Don't forget that IBM is still pushing their non-Java SWT instead of Swing. Red Hat already has its own Java stack that's good enough to run most Java Free Software (including Eclipse), but no one is pretending that it's Java.

      Sun has stated that it doesn't want to "free" its J2SE stack because it is afraid that source availability would lead to forks. However, no fork of Sun's code is likely to diverge from Sun's fold as much as a completely new Free Software Java-like implementation.

    3. Re:Talk about fragmenting the standard... by Knome_fan · · Score: 3, Insightful

      "No matter how compliant Harmony purports to be it is still going to be different than Sun's JVM. Any sysadmin that has ever had to juggle multiple JVMs can tell you that Sun's Write Once Run Anywhere motto can quickly become Write Once Debug Everywhere."

      But this is a general problem of having different JVMs. So now also having one that is open source doesn't change the situation in any way.

      "It's also entirely possible that Harmony won't even try for complete compliance. Don't forget that IBM is still pushing their non-Java SWT instead of Swing. Red Hat already has its own Java stack that's good enough to run most Java Free Software (including Eclipse), but no one is pretending that it's Java."

      It's possible, but not very likely considering that the statet goal of Harmony is to "create a compatible implementation of J2SE 5".
      As to Red Hat, it isn't Java, because it isn't mature enough and only implements parts of the Java specs. But doesn't this example show that your worries are unfounded, as Red Hat is neither trying to create something different from Java, nor to call something Java that doesn't meat the criteria?

      "Sun has stated that it doesn't want to "free" its J2SE stack because it is afraid that source availability would lead to forks. However, no fork of Sun's code is likely to diverge from Sun's fold as much as a completely new Free Software Java-like implementation."

      Again, you are supposing it is a free software java-like implementation, whereas the goal is to create a free java implementation.
      While you are of course right that having such an implementation would make it easier to fork Java, I don't see why anybody should try to do this, as the chances for the success of such a fork are minimal at best.

  2. Re:Eclipse? by bluGill · · Score: 3, Insightful

    I'm a programmer. I've been burned by bugs in my tools before. Sure MOST bugs are my fault, but once in a while I'm pretty sure it is the tool's fault. With open source I can fix those bugs and move one. With closed source I'm at the mercy of vendors who rarely care about my project.

    Then too, a lot of documentation is bad. Either it doesn't exist, or the program doesn't work like the docs say. The source code is definitive about what is really going to happen, and I can read it. IF you are not a programmer it doesn't matter because you can't read the source, but I can, so it matters.

  3. Re:Eclipse? by Pxtl · · Score: 3, Insightful

    Simple - what happens if the platform goes away? What happens if microsoft moves away from .NET, and you want to move to a new platform (PowerPC for example). Hell, what happens if 20 years from now you find you need an old tool you made in C#? Will it still work? Will there be a compatible .NET run-time for 256-bit computers?

    Part of the commercial reason to use opensource is to future-proof yourself against long-term eventualities like this. If Java decides to stop letting you bundle the JVM with your OS, then you can't provide OpenOffice anymore without paying them. If MS stops supporting a platform, then you're screwed if there's an unworkable bug and you're stuck on the platform.

    Fundamentally, when you invest labour on designing products and infrastructure based on a closed-license platform, you gain fealty to them. They now control you - they can make you lose the use of the product of your labour. They can stop providing their product, they can refuse to fix un-workaround-able bugs, or they can just go out of business and leave you high and dry.

    With opensource, you can lose your support provider, but you can never lose the platform - at worst, you may have to maintain it yourself.

    Yes, you may even have a solid, bullet-proof contract with your provider - but what happens when they go out of business?