Home

News: IBM commits a full time employee to the Harmony Project

  1. IBM has committed a full time employee to work on the Apache Harmony open source JVM and class library. IBM is being careful to let the Harmony community set it's own direction and is limiting it's contributions to thoughts on design, at this point, although IBM VP Rod Smith he "is sure" that code contributions will come later.

    Update - TSS sources have reported that the person from IBM who will work on Harmony is named Tim Ellison (NOT Elliot). Tim works out of IBM Hursley, UK, and comes with a lot of experience working on class libraries and has a detailed understanding of all aspects of the JVM.

    Threaded Messages (52)

  2. Good.
    They could not make Sun release java OpenSource.
    So instead they are going to create an open source java.
    I'm all for it.
    I hope whe Harmony catches up with latest java version, it will be included in all Linux distributions.
    That's where we will start seing exploded java development.
    With open source and free java App servers, java IDEs, java databases, thousands of excelent open source java libraries and products, readily available on any linux distribution !
  3. src.zip[ Go to top ]

    And they wont be tempted to look at existing J2SE source code.

    Right!
  4. src.zip[ Go to top ]

    And they wont be tempted to look at existing J2SE source code.Right!

    When you think about how long it took to develop Java up to now, I would be VERY surprised if they are able to produce something in any reasonable time. In the meanwhile, Sun has time to ponder opensourcing their JSE.

    Worst case scenario, they do copy a lot of Sun's JSE and the legalities ensue-- who's going to look like the bad guy?
  5. This could be exciting[ Go to top ]

    If IBM contributes J9 to this project, this would very quickly turn into a serious, credible project. I hope that is what Rod means when he says IBM may contribute code to this project.

    Bob Griswold
    Terracotta, Inc.
  6. This could be exciting[ Go to top ]

    If IBM contributes J9 to this project, this would very quickly turn into a serious, credible project. I hope that is what Rod means when he says IBM may contribute code to this project.Bob GriswoldTerracotta, Inc.

    BEA should open source JRockit. Its a much better VM and their doing cool inovative stuff...

    Unfortunately, BEA is too busy thinking liquid to turn opensource vaporware into a solid VM.

    Bill
  7. This could be exciting[ Go to top ]

    Thanks for the praise, Bill... Now, BEA is a Sun licensee. How do you think Sun would act if we open sourced JRockit?
  8. Open sourcing JRockit[ Go to top ]

    Yes, BEA signed a SCSL. But, there are plenty of parts of JRockit that are not at all derived from Sun. I'm sure the Harmony project would really appreciate some of these parts if BEA chose to contribute.
  9. This could be exciting[ Go to top ]

    BEA should open source JRockit. Its a much better VM and their doing cool inovative stuff...Unfortunately, BEA is too busy thinking liquid to turn opensource vaporware into a solid VM.Bill

    Haha the irony of you having "...turn opensource wapourware into a solid..." is too much.
  10. Open Sourcing J9?[ Go to top ]

    I am agree with you Bob,

    IBM want to get SUn's Java market, but push endorse the Harmony, I think the Harmony Team, must make a J2ME version.

    I think that IBM is more close than Sun, by keeping his J9 still there.

    Anyway, anyone use this J9 before?
  11. Open Sourcing J9?[ Go to top ]

    I can be wrong, but it looks like IBM just uses this project and Apache to make noise to "eclipse" SUN.
  12. that might be true[ Go to top ]

    And they wont be tempted to look at existing J2SE source code. Right!

    When you think about how long it took to develop Java up to now, I would be VERY surprised if they are able to produce something in any reasonable time. In the meanwhile, Sun has time to ponder opensourcing their JSE.

    Worst case scenario, they do copy a lot of Sun's JSE and the legalities ensue-- who's going to look like the bad guy?

    I highly doubt the developers of Harmony would risk breaking the law. The task is monumental, but it's not impossible. With deligent work and attention to detail, I'm hopeful harmoney will bear some fruit in 3-4 years.

    peter
  13. that might be true[ Go to top ]

    And they wont be tempted to look at existing J2SE source code. Right!
    When you think about how long it took to develop Java up to now, I would be VERY surprised if they are able to produce something in any reasonable time. In the meanwhile, Sun has time to ponder opensourcing their JSE.Worst case scenario, they do copy a lot of Sun's JSE and the legalities ensue-- who's going to look like the bad guy?
    I highly doubt the developers of Harmony would risk breaking the law. The task is monumental, but it's not impossible. With deligent work and attention to detail, I'm hopeful harmoney will bear some fruit in 3-4 years.peter

    Regardless, this is an interesting point. There are bound to be points of similarity in code, even if Harmony doesn't look into the J2SE source. If Sun decides to get vindictive, Harmony may be in for a patent/copyright infringement fight (think linux v. SCO). I think the Harmony folks better be very careful (read: document everything and CYA) if they hope to avoid this.
  14. that might be true[ Go to top ]

    If Sun decides to get vindictive, Harmony may be in for a patent/copyright infringement fight (think linux v. SCO). I think the Harmony folks better be very careful (read: document everything and CYA) if they hope to avoid this.

    Why would Sun get vindictive? All they are after is having a defined Java standard - it is not like they make any money out of J2SE implementations.
  15. that might be true[ Go to top ]

    Why would Sun get vindictive?

    Why does the JVM spec and the lang spec begin with a warning of Sun patents? What's Sun's motivation for warning everyone?
  16. that might be true[ Go to top ]

    And they wont be tempted to look at existing J2SE source code. Right!
    When you think about how long it took to develop Java up to now, I would be VERY surprised if they are able to produce something in any reasonable time. In the meanwhile, Sun has time to ponder opensourcing their JSE.Worst case scenario, they do copy a lot of Sun's JSE and the legalities ensue-- who's going to look like the bad guy?
    I highly doubt the developers of Harmony would risk breaking the law. The task is monumental, but it's not impossible. With deligent work and attention to detail, I'm hopeful harmoney will bear some fruit in 3-4 years.peter
    Regardless, this is an interesting point. There are bound to be points of similarity in code, even if Harmony doesn't look into the J2SE source. If Sun decides to get vindictive, Harmony may be in for a patent/copyright infringement fight (think linux v. SCO). I think the Harmony folks better be very careful (read: document everything and CYA) if they hope to avoid this.

    We are being extemely careful :)

    Copyright should be easy for us to monitor, as we could have a third party with a license to the Sun code look for similarity and warn us. Such actions would be immediately heeded to resolve the problem ASAP.

    As to patents, they are always a worry. But, one of the benefits of the JCP and certifiying implementations of specifications is that compatible implementations of JCP specs receive patent licenses for any patents necessary for implementation that are held by members of the expert group.

    Since our goal is a certified implementation of J2SE, I don't expect too many patent issues.

    geir
  17. that might be true[ Go to top ]

    And they wont be tempted to look at existing J2SE source code. Right!
    When you think about how long it took to develop Java up to now, I would be VERY surprised if they are able to produce something in any reasonable time. In the meanwhile, Sun has time to ponder opensourcing their JSE.Worst case scenario, they do copy a lot of Sun's JSE and the legalities ensue-- who's going to look like the bad guy?
    I highly doubt the developers of Harmony would risk breaking the law. The task is monumental, but it's not impossible. With deligent work and attention to detail, I'm hopeful harmoney will bear some fruit in 3-4 years.peter
    Regardless, this is an interesting point. There are bound to be points of similarity in code, even if Harmony doesn't look into the J2SE source. If Sun decides to get vindictive, Harmony may be in for a patent/copyright infringement fight (think linux v. SCO). I think the Harmony folks better be very careful (read: document everything and CYA) if they hope to avoid this.
    We are being extemely careful :)Copyright should be easy for us to monitor, as we could have a third party with a license to the Sun code look for similarity and warn us. Such actions would be immediately heeded to resolve the problem ASAP.As to patents, they are always a worry. But, one of the benefits of the JCP and certifiying implementations of specifications is that compatible implementations of JCP specs receive patent licenses for any patents necessary for implementation that are held by members of the expert group.Since our goal is a certified implementation of J2SE, I don't expect too many patent issues.geir

    This reinventing the wheel is why this project will fail. Java's SE libraries are just too huge to rewrite *and* keep up to date with recent bug fixes and API additions (JDK 5). Just look at how long it takes IBM to come out with it's JDK after Sun releases a new one. It was some 1.5 years after JDK 1.4 came out that IBM released theirs. And IBM is a HUGE company with almost unlimited resources.

    IBM should open source *their* JDK under Harmony for those anal types who don't feel Sun's current offering isn't. You would think the anal types would like Sun's open source license requiring you to pass a test suite compatability test. Nope.

    W/o passing a test suite compatability test I wouldn't have much faith in any version of Java.
  18. now, now...[ Go to top ]

    ...that's a bit negative, bryan, but i agree though that the wheel is being reinvented and would like to see some real reasons why the world needs an open-source version of a free product.

    not this kind of wishy-washy save-the-world crap from from the apache mailing list:
    Project Harmony
    ===============

    Motivation
    ----------

    There is a clear need for an open-source version of Java 2, Standard
    Edition (J2SE) runtime platform, and there are many ongoing efforts
    to produce solutions (Kaffe, Classpath, etc). There are also efforts
    that provide alternative approaches to execution of Java bytecode
    (GCJ and IKVM). All of these efforts provide a diversity of
    solutions, which is healthy, but barriers exist which prevent these
    efforts from reaching a greater potential.

    What's the clear need?
  19. now, now...[ Go to top ]

    Jon :
    ...that's a bit negative, bryan, but i agree though that the wheel is being reinvented and would like to see some real reasons why the world needs an open-source version of a free product.not this kind of wishy-washy save-the-world crap from from the apache mailing list:
    Project Harmony===============Motivation----------There is a clear need for an open-source version of Java 2, StandardEdition (J2SE) runtime platform, and there are many ongoing effortsto produce solutions (Kaffe, Classpath, etc). There are also effortsthat provide alternative approaches to execution of Java bytecode(GCJ and IKVM). All of these efforts provide a diversity ofsolutions, which is healthy, but barriers exist which prevent theseefforts from reaching a greater potential.
    What's the clear need?

    I wrote that "crap" :)

    The motivations are pretty straightforward. The problem is that they aren't aimed at the average developer, who - as you noted - is perfectly satisfied with getting the JDK for $0 from Sun, BEA or IBM. The needs are :

    - Get the community (open source, free software, research and commercial) to collaborate on a modular architecture for implementing the platform. This allows interchangability and areas of innovation like JITs, memory management, etc.

    - Collaboratively produce an implementation under an open source license (the Apache License) that allows the platform to be a) broadly ported, b) allow for compatible innovation (see what Azul is doing for an example of the technical innovation I mean) and c) used in environments where open source is a requirement, such as in the Linux community as well as developing economies such as Brazil.

    There are other reasons as well, and I'm happy to continue to discuss this on the Apache Harmony list. You can find mail list info at the site :

    http://incubator.apache.org/harmony

    geir
  20. now, now...[ Go to top ]

    The motivations are pretty straightforward. The problem is that they aren't aimed at the average developer, who - as you noted - is perfectly satisfied with getting the JDK for $0 from Sun, BEA or IBM. The needs are [...]

    Here's the problem, Geir - I'm afraid you didn't list any motivations or needs. You have defined solutions and ways to get to those solutions. But you have not defined what the actual problem is that you're trying to solve.

    You see, there have already been innovations on JITs, memory management, etc. This has occured without Harmony. Where is the _actual_ need for Harmony? Not perceived, not theoretical. The real, actual need by some real organizations or individuals that are not fulfilled by the existing JVMs.

    As others have said it's your (collective) time and do with it as you will. It just seems a shame that people are willing to throw so much effort into something with so little payback, and so little chance of success.
  21. now, now...[ Go to top ]

    But you have not defined what the actual problem is that you're trying to solve.

    Is Linux distribution bundled with java is such a small thing for you that you do not notice it ?
    IBM is one of the largest linux players, and IBM is one of the largest java players. Can you add 2 and 2 ?
  22. now, now...[ Go to top ]

    What's the clear need?

    Licensing.

    Apache can't ship a certified JVM with any of their projects because the Sun license is incompatible with the Apache License. Ditto for the Linux vendors (at least with regards to the base editions of their products). Note that this isn't because Sun or Apache did anything wrong. It's just what it is.

    If you question the need for Harmony, then you are simultaneously questioning the benefit of bundling a JVM with a JSE/JEE product. I won't argue with you, as that's a matter of opinion, but I think it's certainly within a vendor's rights to have that option.
  23. FreeBSD ports[ Go to top ]

    One reason I would like this to come out is to be able to
    cd /usr/ports/java/jdk150
    make install clean

    And that's it for installing java compiled with -O2 -march=pentiumpro turned on.
  24. now, now...[ Go to top ]

    So licensing is a single problem this project is going to solve. Do you know how many users need jvm bundled with tomcat ? Have you ever asked about it your users ? I respect your work, but this project seems more political than pragmatic.
  25. now, now...[ Go to top ]

    So licensing is a single problem this project is going to solve. Do you know how many users need jvm bundled with tomcat ? Have you ever asked about it your users ? I respect your work, but this project seems more political than pragmatic.

    I'm not involved in the Harmony project, so don't take what I say as gospel. Licensing as it relates to bundling is a clear need many vendors have. Another less obvious clear need is the fact that Harmony will help the Open Source JVM community (which now includes Kaffe and GCJ, among others) produce a JVM that's certifiable. Most Linux distributions ship Kaffe or GCJ in their base install because they can't ship Sun's code, and those implementations, while admirable in effort, are not quite up to snuff in terms of standards.

    What I don't get is the vocal antipathy some developers have over a project that seems to them to be an unnecessary duplication of effort. If duplication of effort is a universal bad, then how many developers should be canned because they're working on another AR or HR system?
  26. now, now...[ Go to top ]

    Plus Harmony will cover platforms Sun doesn't. HP-UX, AIX, non-x86 versions of Linux, for example.
  27. now, now...[ Go to top ]

    There are already JDK's on those platforms. IBM on AIX and Linux/PPC, HP on HP-UX. And JRockit is being ported to some of these, so there will be some choice for the user base.

    Personally, I think a more interesting side of Harmony is bringing Java to less "mainstream" platforms - the various BSD's, to name one example - that that large JVM vendors (including BEA) does not find it commercially feasible to support.

    Henrik Ståhl
    BEA JRockit
  28. now, now...[ Go to top ]

    What's the clear need?

    I have spoken in depth to the Brazilians working on the Javali project, which is another attempt at an open source JVM + class libraries (Bruno Souza from Javali is also a key Harmony guy).

    The reasons for the Javali project are the same as most of the reasons for Harmony, here are some of the keypoints, phrased as problems to be solved for both projects (as I understand them).

    Problems:
    - Betting your infrastructure on technology from on vendor (Sun) who could one day stop it's offerings
    - Java can't come shipped/supported by some Linux
    - Limited traction for desktop Java apps due in part to the linux problem
    - You can't ship a custom JVM with your application.
    - Java is not available on all platforms that could benefit from it
    - The US goverment might embargo our country and cut us off.

    I've gone into a lot more detail on each of these points on my blog.

    Floyd
  29. now, now...[ Go to top ]

    - Java can't come shipped/supported by some Linux
    To make this clear[er] to all the ill-informed i-hate-opensource types around here, Sun specifically prohibits the distribution of its JVM with other programs that are in any way competing against it, or meant to replace it. Since most of the modern linux distros today choose to distribute GCJ, Classpath and at least one free JVM - there you go.
    - Limited traction for desktop Java apps due in part to the linux problem
    - You can't ship a custom JVM with your application.
    - Java is not available on all platforms that could benefit from it
    - The US goverment might embargo our country and cut us off.

    GCJ/Classpath also provides:
    - compilation of Java applications to native code
    - statically linked code, stand-alone Java apps that do not require any runtime libraries
    - better and faster integration with native code, including natural integration with C++ classes
    - lack of certification :)
  30. now, now...[ Go to top ]

    - Java can't come shipped/supported by some Linux

    To make this clear[er] to all the ill-informed i-hate-opensource types around here, Sun specifically prohibits the distribution of its JVM with other programs that are in any way competing against it, or meant to replace it. Since most of the modern linux distros today choose to distribute GCJ, Classpath and at least one free JVM - there you go.

    I didn't realize that. How do they word such a thing in the license? Or is this one of the things that they stipulate one-on-one with the licensees who are attempting to redistributed the JRE or JDK? And if so, how did you learn of it?

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  31. now, now...[ Go to top ]

    - Java can't come shipped/supported by some Linux
    To make this clear[er] to all the ill-informed i-hate-opensource types around here, Sun specifically prohibits the distribution of its JVM with other programs that are in any way competing against it, or meant to replace it. Since most of the modern linux distros today choose to distribute GCJ, Classpath and at least one free JVM - there you go.
    I didn't realize that. How do they word such a thing in the license? Or is this one of the things that they stipulate one-on-one with the licensees who are attempting to redistributed the JRE or JDK? And if so, how did you learn of it?Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java
    <code>
    [root@rpopescu jdk1.5.0_03]# pwd
    /usr/java/jdk1.5.0_03
    [root@rpopescu jdk1.5.0_03]# cat LICENSE | grep replace
    Sun's option to replace Software media or refund the fee paid for
    (iii) you do not distribute additional software intended to replace
    is intended to be a replacement or substitute for the Software; (viii)
    [root@rpopescu jdk1.5.0_03]#
    </code>
  32. now, now...[ Go to top ]

    Sorry Cameron, I guess that didn't come out with proper context, but at least it shows where you can find such requirements.
    Now, on to the specific paragraphs:

    (iii) you do not distribute additional software intended to replace any component(s) of the Software

    (iii) you do not distribute additional software intended to supersede any component(s) of the Redistributables (unless otherwise specified in the applicable README file)

    (vii) You may not include any third party software on the Media which is intended to be a replacement or substitute for the Software;

    Cheers
  33. now, now...[ Go to top ]

    (iii) you do not distribute additional software intended to replace any component(s) of the Software
    (iii) you do not distribute additional software intended to supersede any component(s) of the Redistributables (unless otherwise specified in the applicable README file)

    IANAL etc. but these appear to be normal clauses. I'm pretty sure we do similar clauses for redistribution, so that our software is intact. In other words, Sun doesn't want you changing the binaries when you redistribute, and they don't want you changing the behavior of the JDK/JRE by "overlaying" or "substituting" or "replacing" those binaries either.
    (vii) You may not include any third party software on the Media which is intended to be a replacement or substitute for the Software

    OK, that's certifiably bogus. That means you could not ship two versions of the JDK/JRE on the same media, for example.

    I haven't seen any terms like that before except from Microsoft (Windows OEM contracts), and they got in big trouble for those terms.

    Out of curiousity, was that the JDK, the JRE or both?

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  34. now, now...[ Go to top ]

    (iii) you do not distribute additional software intended to replace any component(s) of the Software(iii) you do not distribute additional software intended to supersede any component(s) of the Redistributables (unless otherwise specified in the applicable README file)
    IANAL etc. but these appear to be normal clauses. I'm pretty sure we do similar clauses for redistribution, so that our software is intact. In other words, Sun doesn't want you changing the binaries when you redistribute, and they don't want you changing the behavior of the JDK/JRE by "overlaying" or "substituting" or "replacing" those binaries either.

    That gets really interesting as soon as you have applications using -Xbootclasspath to try to work around buggy (say, XML parser) code in the JDK/JRE.
    (vii) You may not include any third party software on the Media which is intended to be a replacement or substitute for the Software
    OK, that's certifiably bogus. That means you could not ship two versions of the JDK/JRE on the same media, for example.I haven't seen any terms like that before except from Microsoft (Windows OEM contracts), and they got in big trouble for those terms. Out of curiousity, was that the JDK, the JRE or both?

    I believe that one is both.

    cheers,
    dalibor topic
  35. now, now...[ Go to top ]

      
    (vii) You may not include any third party software on the Media which is intended to be a replacement or substitute for the Software
      OK, that's certifiably bogus. That means you could not ship two versions of the JDK/JRE on the same media, for example.I haven't seen any terms like that before except from Microsoft (Windows OEM contracts), and they got in big trouble for those terms. Out of curiousity, was that the JDK, the JRE or both?
    I believe that one is both.cheers,dalibor topic

    The JRE does not have that requirement afaik.
  36. that might be true[ Go to top ]

    Bryan :
    You would think the anal types would like Sun's open source license requiring you to pass a test suite compatability test. Nope.W/o passing a test suite compatability test I wouldn't have much faith in any version of Java.

    I'm not sure what license you are talking about. IIRC, Sun has one open source license, and that is the CDDL. I'd be *thrilled* if J2SE 5 was released under CDDL.

    As for compatibility, I agree- the goal of Apache Harmony is to pass the J2SE 5 TCK, and then any subsequent version as well.

    geir
  37. that might be true[ Go to top ]

    I'm hopeful harmoney will bear some fruit in 3-4 years.peter

    that's quite some time, and i'm sure the java language will evolve quite a bit during that period. not only implementing what's already out there, but keeping up with the changes is another large task.

    i wonder if ibm is holding off on releasing an updated jvm until this project has something they can use? i haven't heard any talk about them producing a java 1.5 jvm/jdk version. the main reason they have their own jdk is because they have their own hardware they make a pretty penny from. once consumers really begin to get tied to java 1.5, their pSeries machines and such will not be as attractive.
  38. that might be true[ Go to top ]

    And they wont be tempted to look at existing J2SE source code. Right!
    When you think about how long it took to develop Java up to now, I would be VERY surprised if they are able to produce something in any reasonable time. In the meanwhile, Sun has time to ponder opensourcing their JSE.Worst case scenario, they do copy a lot of Sun's JSE and the legalities ensue-- who's going to look like the bad guy?
    I highly doubt the developers of Harmony would risk breaking the law. The task is monumental, but it's not impossible. With deligent work and attention to detail, I'm hopeful harmoney will bear some fruit in 3-4 years.peter

    We are *absolutely* committed to ensuring that Apache Harmony is done without inappropriately using the property - intellectual and otherwise - of anyone, including Sun.

    We will not copy Sun's J2SE source - as a matter of fact, we are trying to find ways that we can proactively work to ensure that such code doesn't enter our codebase.

    Apache Harmony is a worthwhile endeavour only if the resulting software is useful and usable, and that's why we're working so hard to ensure that our contribution and legal framework and other related facets are well worked out before we begin the major work.

    geir
  39. harmony needs to pass JCK[ Go to top ]

    When you think about how long it took to develop Java up to now, I would be VERY surprised if they are able to produce something in any reasonable time.

    I totally agree! If harmony wants to be a competent JSE implementation it needs to satisfy all tests of the JCK. That is a huge requirement!
  40. And they wont be tempted to look at existing J2SE source code.Right!

    There needs to be a clear procedure for handling Sun sourcecode. For example, any contributors could be required by contract to not look at SUN source code. Developers are not complete dummies, in general, they know importing Sun code would be a huge disservice to the project.
    The counterexample is the current court case of SCO against IBM. If IBM could have made it reasonably clear that they had proper procedures in place that people working on Linux didn't have access to UNIX source, SCO would have been laughed out of court on day one.
  41. Ahhh I love you guys, thanks for providing me with a good old fat troll on this boring day at work
    When you think about how long it took to develop Java up to now, I would be VERY surprised if they are able to produce something in any reasonable time. In the meanwhile, Sun has time to ponder opensourcing their JSE.

    I couldn't agree more....catching up is almost impossible in a timely manner...by the time harmony reaches full 1.5 compliancy (which means things like full Swing implementation, which is not a small thing), sun is likely to release 1.6 or 1.7 ...for instance Sun has already 1.6 snapshots working, while harmony is still setting up...I can't see how you'll fill the gap
    If IBM contributes J9 to this project, this would very quickly turn into a serious, credible project. I hope that is what Rod means when he says IBM may contribute code to this project.

    That's the only way I can see this happen...starting from scratch is just too much

    @ all : on the risks side, I wonder how they will avoid similarities...this is a huge work to review code and compare it to make sure it's not breaking any copyright...this means you'll have to check every single commit, again, I can't see how you're going to do this

    @ geir : it's always nice to see someone with faith, and with the courage to do what he/she believes in, but honnestly the obstacles are really huge : you got time pressure (if the first working 1.5 release you make is in let's say 2 years (which would already be a very short delay), Sun would probably have released it 1.6 by the time...so no one will use your work because it will be lagging out...moreover, given java is a standard, I cannot see why anyone would use your product rather than the implementation produced by SUN itself...and don't oppose me J2EE : sun never intended to be a major player in J2EE : their implementation is more a reference than anything else...plus a lot of major actors (IBM, BEA, jBoss, Apache, ObjectWeb) caught up on time to make compatible relases...in J2SE, the situation is way different : SUN has almost no challengers...
    This reinventing the wheel is why this project will fail. Java's SE libraries are just too huge to rewrite *and* keep up to date with recent bug fixes and API additions (JDK 5). Just look at how long it takes IBM to come out with it's JDK after Sun releases a new one. It was some 1.5 years after JDK 1.4 came out that IBM released theirs. And IBM is a HUGE company with almost unlimited resources.


    and



    What's the clear need?

    'nuff said IMHO

    why don't you set up JSR's instead, to bring on things you need ? The best exemple to me is the thing that allow classes to be shared...this was made by apple, but by virtue of cooperation, this was retrofitted in 1.5 ...and then can benefit to everyone...I think java users deserve to have the best possible version, not x differents versions that all have their little nice things...JSR allows that, and 1.5 is a good evidence that it's working well
  42. Ahhh I love you guys, thanks for providing me with a good old fat troll on this boring day at work

    That was indeed a good fat troll. Exquisitly ignorant yet lacking the vigor that makes Slashdot an enjoyable read, regardless of the asshat level of the posters.

    Dude, if you don't know shit about the subject at hand, why bother? Go post on flexbeta or something.

    This Harmony is just noise so far. BUT there are seriously viable, granted requiring a bit of faith and not suitable to all projects, free alternative Java runtimes. And these could be using in Harmony.
    The latest incarnation of RedHat's free desktop, Fedora Core 4, ships with native versions of Eclipse 3.1, Tomcat5 and huge amount of jakarta packages and other code, such as antlr and whatnot. Oh and a free java development environment: GCJ+Classpath.
    "Caching up is almost impossible in a timely manner"... ignorance and arrogance they make an ugly pair.
  43. The latest incarnation of RedHat's free desktop, Fedora Core 4, ships with native versions of Eclipse 3.1, Tomcat5...

    I wonder with which native compiler does Tomcat perform better: HotSpot or GCJ?

    One thing's for sure about Harmony: since Apache is producing it, it'll be biased toward the server side. Client features such as Swing and WebStart will suck, in much that same way that Apache is incapable of offering a web browser, and Apache's only attempt at a fat client, Batik, is a joke. That said, I love Apache.
  44. Tomcat benchmark[ Go to top ]

    I wonder with which native compiler does Tomcat perform better: HotSpot or GCJ?

    Maybe JRockit?

    "...JRockit was roughly 2x faster than Sun"
    http://forums.bea.com/bea/message.jspa?messageID=600006020&tstart=0

    Sorry, couldn't resist ;-)
  45. Tomcat benchmark[ Go to top ]

    I wonder with which native compiler does Tomcat perform better: HotSpot or GCJ?
    Maybe JRockit?"...JRockit was roughly 2x faster than Sun"http://forums.bea.com/bea/message.jspa?messageID=600006020&tstart=0Sorry, couldn't resist ;-)

    Since I'm the one who ran those tomcat benchmarks, all blame for errors or bad methodology is my fault and not BEA's. Having said that, more tests are needed to establish a clear picture of how different VM's perform under a variety of "realistic" scenarios. My simple test was heavy on XML and not necessarily a predicter of how well either Sun JDK or JRockit will perform in production.

    I look forward to playing with the first release of harmony and see how well it performs.

    peter
  46. Dude, if you don't know shit about the subject at hand, why bother? Go post on flexbeta or something.
    Well "m8", how can you assume I don't know "shit" about the subject ? I'm a java developper as well, I read quite a lot about the market, and I'm working in a fairly big company that uses java only for web stuff.
    This Harmony is just noise so far. BUT there are seriously viable, granted requiring a bit of faith and not suitable to all projects, free alternative Java runtimes. And these could be using in Harmony
    I love the "a bit of faith"...consider the age of the Sun's implementation, consider the age of all its competitors (some of the are quite old as well), consider Harmony is almost starting from scratch, and then you'll see why A LOT of faith is required
    The latest incarnation of RedHat's free desktop, Fedora Core 4, ships with native versions of Eclipse 3.1, Tomcat5 and huge amount of jakarta packages and other code, such as antlr and whatnot.Oh and a free java development environment: GCJ+Classpath.
    I don't get the point...these are OSS software that are using a JVM, not the JVM itself... plus, can you remind me of the coverage of advanced functionnalities of Swing, or other from the JVM ??? hum hum, that's what I thought...try running somthing with complicated trees and stuff on Classpath for instance...(this said, I think they still did a great job but still there is quite a lot to do)

    From the site, as compared to 1.4 :
    javabean : done 87%
    imageio : done 80% (in the 20% there is missing support of JPEG, which is quite a problem)
    no sound support at all
    almost every CORBA, RMI, etc... done at 80%
    metal PLAF done at 34%
    HTML support : 20%

    get just a look at missing stuff in javax.swing.*

    I'm sorry, but this is not of production quality (or we do not share the same standards...)

    and consider it started in late 2003, so 1.5 years later, they are still quite far of full 1.4 compliancy...consider 1.5 was a huge release, I can't see how they could catch up...
    "Caching up is almost impossible in a timely manner"... ignorance and arrogance they make an ugly pair.
    maybe, but you still haven't demonstrated how Harmony is going to achieve what no other open source project achieved, given they will have less time, and even more to do
  47. only time will tell[ Go to top ]

    everyone can speculate about how, why and when Harmony will or won't produce a JDK, but in the end, the developers working on it have control over the destiney. If they stay focused and ignore all the noise, I don't doubt they can pull off the magic trick. Though really, it's not magic. It's just hard work and dedication. It's not a job for most programmer, but given the right combination of developers, it can happen.

    peter
  48. Well "m8", how can you assume I don't know "shit" about the subject ? I'm a java developper as well, I read quite a lot about the market, and I'm working in a fairly big company that uses java only for web stuff.
    It's rather obvious from your original message.
    The latest incarnation of RedHat's free desktop, Fedora Core 4, ships with native versions of Eclipse 3.1, Tomcat5 and huge amount of jakarta packages and other code, such as antlr and whatnot.Oh and a free java development environment: GCJ+Classpath.
    I don't get the point...these are OSS software that are using a JVM, not the JVM itself...
    Wrong mate, that's OSS software running on a JVM alternative, namely Classpath + GCJ. That's Java code compiled to native code instead of bytecode, and running with the support of natively compiled Classpath and the libgcj provided services.

    Given that it runs the lastest Tomcat, Eclipse, Ant and uses a bunch of jakarta common packages, given that RedHat has been building and distributing native code compiled Eclipse since a couple of years now, in their RHEL OS releases, I'd say that it's pretty solid for a bunch of stuff. Swing is definitely not there yet, but work is under way.

    And I really don't mean to demonstrate that Harmony is going to sweep you off your feet, I'm just setting some facts straight, proving your allegations wrong and responding to the unfounded sarcasm and mockery in your original post.
  49. Fasten your seatbelt[ Go to top ]

    I don't want to disappoint you, but fortunately GNU Classpath is progressing at a really high pace. See http://object-refinery.com/classpath/statcvs/ for details.

    The corba stuff you peg at 80% has been at 0% just three months ago. Swing, was thought to be way too much work for anyone to implement this time last year. Turned out that was completely wrong, and now swing is seeing daily updates, bug fixes and improvements and increasingly complex code runs. Sound has been implemented as part of Tritonus project, pretty much 100%, and is shipped as part of Kaffe, for example. And so on, and so on. :)

    If you started following the development of GNU classpath, you'd notice that things are moving really, really quickly. Wrt to 1.4 API coverage, I believe 15% were implemented last year alone, and it's definitely growing in numbers, and ranks. Eclipse3, OpenOffice.org2, JOnAS ... there is a lof of interesting stuff happening right now with various runtimes.

    Obviously, writing a better class library than the proprietary implementation does not happen overnight, even with the best developers around. GNU classpath has been going on for years, and just started reaching the critical mass early this year. It takes the right people, of course, but so far, GNU Classpath has been steadily attracting the right people. I don't see that change in the future.

    If a particular application you need does not run yet, you might be interested in spending some of your resources making it work. That worked for numerous other people, projects and companies, and might work for you, if you need a good class library implementation under a business/research/distribution-friendly license. Whether you need that depends on what you are doing, of course and where you see your opportunities/what makes economically sense for you in your situation.

    cheers,
    dalibor topic
  50. Is this good or bad?[ Go to top ]

    Making another version of JVM could imply a bad indication. I think it would be better if we let Sun do the standards making Java. So we're facing two problems: opensource vs standards. :-D
  51. Lighter, Faster JDK.[ Go to top ]

    There is a very big reason I see to have project like this:

    Provide second JDK implementation which just doesnt have to care about backwards compatibility.

    Let the community be free to remove deprecated methods or even refactore class and interface declarations the way they should have been.
  52. Lighter, Faster JDK.[ Go to top ]

    The only problem with that is that removal or change of interfaces would violate the TCK, which also tests library compatibility. So doing that - while useful - would invalidate the whole point.

    Now, that doesn't mean it wouldn't be worthwhile for Sun to look at changing the TCK such that deprecated or bad behaviour wasn't part of things....
  53. definition of copyright[ Go to top ]

    What are people defining as copyright and copyright infringement? I thought copyright meant someone else cannot copy and paste a piece of work and call it their own. Copyright infringement therefore would need to show 2 things: intent and direct copying.

    I'm definitely NOT a lawyer, but similarities does not constitute copyright infringement. Of course, that doesn't mean a company is going to behave accordingly. I still believe there is value in harmony, even if it take 10 years to catch up to the official SUN jdk.

    peter