Open, community developed, test suite for Java

Discussions

News: Open, community developed, test suite for Java

  1. David Herron has posted "Open, community developed, test suite for Java," a blog entry talking about an idea being developed to sponsor an open source test suite, pointing out that "much of the knowledge about Java quality and compatibility problems are in the minds of application developers." In light of the recent discussions between Apache and Sun on the Java TCK, there's a lot of potential here, for various reasons. David's looking for feedback on: "... some plans we have for a quality community for the OpenJDK project. The quality community will offer ways to contribute to testing and test suite development of the OpenJDK. We are still planning what the test suite development will look like, and we would like to know your thoughts about this."
  2. In light of the recent discussions between Apache and Sun on the Java TCK, there's a lot of potential here...
    How? The TCK is a very special test suite because of the IP rights it transfers via the terms of the JSPA. I think an open source (don't care what license) community developed test suite for Java is a great idea - there's lots out there already (like Mauve), but it doesn't have any bearing on the TCK/JCK. geir
  3. In light of the recent discussions between Apache and Sun on the Java TCK, there's a lot of potential here...


    How? The TCK is a very special test suite because of the IP rights it transfers via the terms of the JSPA. I think an open source (don't care what license) community developed test suite for Java is a great idea - there's lots out there already (like Mauve), but it doesn't have any bearing on the TCK/JCK.

    geir
    I agree with Geir that David's proposal is not related to ASF's open letter, it comes from a similar direction like Mauve, and is a great idea, in my opinion, as well. Regarding TCK licensing, it would be a good thing for the developer community if spec leads at BEA, IBM, Intel, Oracle, Sun, Google, Red Hat, Apache, etc. managed to secure the release of their TCKs under Free Software licenses (and I don't care which one, either) for their current and future JSRs. Doug Lea demonstrated that it can be done, even under the current JSPA. I'm happy to see the new trend among spec leads move towards having Free Software RIs, transparent discussions, and hopefully, sooner or later, open compatibility testing mechanisms.
  4. In light of the recent discussions between Apache and Sun on the Java TCK, there's a lot of potential here...


    How? The TCK is a very special test suite because of the IP rights it transfers via the terms of the JSPA. I think an open source (don't care what license) community developed test suite for Java is a great idea - there's lots out there already (like Mauve), but it doesn't have any bearing on the TCK/JCK.

    geir


    I agree with Geir that David's proposal is not related to ASF's open letter, it comes from a similar direction like Mauve, and is a great idea, in my opinion, as well.

    Regarding TCK licensing, it would be a good thing for the developer community if spec leads at BEA, IBM, Intel, Oracle, Sun, Google, Red Hat, Apache, etc. managed to secure the release of their TCKs under Free Software licenses (and I don't care which one, either) for their current and future JSRs.

    Doug Lea demonstrated that it can be done, even under the current JSPA. I'm happy to see the new trend among spec leads move towards having Free Software RIs, transparent discussions, and hopefully, sooner or later, open compatibility testing mechanisms.
    I agree with Dalibor, but wish to make it clear that the ASF-Sun disagreement has nothing to do with whether or not the JCK is open source. That's an unrelated issue. geir
  5. It in fact has a lot to do with it. An OS TCK would effectively mean that Sun (and the JCP) looses control over the language specification (for which the TCK is the benchmark test), which is exactly the result IBM/Apache want to achieve.
  6. It in fact has a lot to do with it.
    An OS TCK would effectively mean that Sun (and the JCP) looses control over the language specification (for which the TCK is the benchmark test), which is exactly the result IBM/Apache want to achieve.
    Why do you say that? I don't think you completely understand the JCP or the issue between Sun and the ASF. The ASF isn't even asking for the JCK to be open source, so your statement is illogical. An opensource JCK simply means that anyone would be able to read the code, modify the code, and give it to others. But any derivative work of the JCK wouldn't be the JCK - it would simply be Yet Another Java Test Suite. Only the software created by the spec lead for the purpose of testing compatibility of implementations of the spec is called the TCK for that spec (JCK for Java SE), and only by passing the TCK can you both claim compatibility *and* get all necessary IP from the spec lead and expert group members. The ASF just wants to get the JCK (the current proprietary, closed-source one) under a license from Sun that doesn't restrict what users can do with the software that we test with the JCK. When I say "license from Sun", I don't mean an open-source license, but rather a contract to use the software as-is. Finally, having the TCK under an open source license doesn't imply any change of control over the spec. The spec is created by the spec lead (not whoever has a copy of the TCK), and the acceptance of Java specifications are always governed by the JCP Executive Committee. Note also that Sun has a veto on any change to the Java SE specification anyway, so even is Sun wasn't the spec lead, they can still veto any change.
  7. How? Given Sun's current non compliance with JSPA concerning open source licensing of TCKs.. The idea itself does have value its the implementation that might have holes in it..
  8. It already exists[ Go to top ]

    There is already such a suite. The suite is called Mauve: http://sourceware.org/mauve/ The project was started in 1998. CVSWEB: http://sources.redhat.com/cgi-bin/cvsweb.cgi/mauve/?cvsroot=mauve FAQ: http://sourceware.org/mauve/faq.html