Slashdot Mirror


Open Source is out of the Java process

Yogidabear writes: "According to the Apache group, Open Source has been officially locked out of the Java process with JSR 99 (Java Specification Participation Agreement). The article on the Jakarta site notes that IBM in particular voted against this JSR and many others noted that they were not happy with the stance Sun was taking against Open Source. What does this mean for the Open Source community as it relates to Java? And, better yet, what does this mean for Java?"

18 of 38 comments (clear)

  1. Bizarre by sydb · · Score: 2

    I thought Jakarta was Sun's official (partial) J2EE reference implementation.

    What are Sun up to? They are going to alienate a lot of people. Like me. Not that they care about me :-(

    --
    Yours Sincerely, Michael.
    1. Re:Bizarre by sydb · · Score: 2

      OK, I meant to say Tomcat is used in the official Sun reference implementation.

      --
      Yours Sincerely, Michael.
  2. Sun is cutting thier own throat by SoftwareJedi · · Score: 2, Insightful

    This is just going to make it harder for Java to proliferate.
    They have basically done what they claim the are trying to avoid. By limiting the ability of Open Source developers to develop/test/validate there solution implementations Sun is locking itself into a situation where the Java implementation will be come a fragmented mess of proprietary implemenetations that all differ from specifications just a little bit because it is a feature that the vendor thought would be neat!

  3. The only way to protest is... by leviramsey · · Score: 3, Informative

    To boycott the following companies, who voted to exclude Open Source:

    • Apple (though they raise some concerns... cut your Apple purchasing plans in half)
    • HP
    • Borland
    • Fujitsu
    • Oracle
    • Caldera (see Apple)
    • IONA
    • Nokia
    • SUN
    1. Re:The only way to protest is... by alonsoac · · Score: 2, Insightful

      before starting the boycott read the comments here: http://jcp.org/jsr/results/99-7-1.jsp

      Many agree with the concerns of Apache although they voted yes.

  4. More Info? by __past__ · · Score: 2

    Would anyone care to explain what's going on? The Jakarta article doesn't state what exactly locks OS out (and out of what), and the linked "requirements" page, well, mentions requirements, but not how they are not met.

    1. Re:More Info? by inertia187 · · Score: 2, Interesting
      Apache was unhappy with the specifications, and stated as much in their "jspa-position" which they give four issues, then sums it up with:
      • Apache in its reading of the document had believed there had been some progress on these issues. However, Apache recently learned that in Sun's legal opinion none of these (save the first) has changed in status since the currently in-force JSPA.
      So I guess Apache defines what is good for OS and what isn't.
      --
      A programmer is a machine for converting coffee into code.
  5. Reference to Doom by fm6 · · Score: 4, Insightful
    No, Jakarta is strictly an Apache thing. As with all things Java, Sun does its own reference implementations.

    Let's face it. Java's worst enemy is not Microsoft. It's Sun. It's true that Microsft did a pretty good job of screwing up Java. But they didn't do it out of malice or greed. The folks in Redmond simply suffer from the arrogant believe that only they know how to architect software platforms -- and so do the folks in Menlo Park.

    1. Re:Reference to Doom by sydb · · Score: 2

      Please read this.

      Yes it's only Tomcat, but Tomcat is a big part of Jakarta.

      --
      Yours Sincerely, Michael.
  6. 100% the opposite actually by Anonymous Coward · · Score: 2, Insightful

    How exactly are things going to become a mess of proprietary implementations?

    Commercial products will continue to get certification because people want it.

    Some open source products will get certification.

    Uncertified open source products are pretty much ignored until they have a solid track record. People are afraid to use the proprietary ones because if the project bogs down, you're fucked. It's not a mistake you make twice.

    I'd much rather see the money going towards making the reference implementations not suck than towards paying the license or testing fees for a particular group. A hell of a lot more people benefit from a good reference than any particular reimplementation.

  7. But many said Apache/OS was important! by ChiefPilot · · Score: 4, Informative
    Apple, Caldera, Phillips, Seimens, Palm, and Moto all voted 'yes' while noting in their comments that Apache/Open Source participation in the JCP was important.

    Sun, TI, Nokia, HP, Borland, Fujitsu, and IONA all voted 'yes' without comment.

  8. et tu Caldera? by baptiste · · Score: 2
    This JSR stuff is bizarre. I cannot believe Caldera voted against Apache while stating "Caldera agrees with a lot of the concerns expressed by Apache. We would like to see more to be done to protect the interests of open source providers." What gives? If they supported Apache's position, why did they vote to approve?

    And the fact that Sun voted Yes with no comment speaks volumes.

  9. Vote was to release for Public Review by sdowney · · Score: 2, Informative
    The vote was to release the new Java Specification Participation Agreement for public review. Companies that voted Yes with negative comments are apparently hoping that the flaws are fixable, and should be done publically.

    Or, they believe that the advantages of the changes made so far outweigh the disadvantage of staying with the current agreement.

  10. Tomcat -- Reference? by fm6 · · Score: 2
    Well, the Apache page refers to Tomcat as something "used in the official Reference Implementation for the Java Servlet and JavaServer Pages". Which are only two parts of J2EE, not the whole thing. So we have a big part of Jakarta that's also (or maybe not, see below) a small part of the J2EE RI). That means that Jakarta and J2EE RI overlap, sort of. Not exactly equivalent.

    Also, the Sun site refers to Tomcat as "an implementation of the Java Servlet 2.3 and JSP 1.2 specifications." Not "the reference implementation". I haven't looked at the servlets or server pages lately, but I worked at Sun they had an in-house reference implementation. But Javasoft reference implementations do not have a good rep, and presumably the Apache implementation is much better. Which is why Sun would rather distribute Tomcat with the J2EE SDK.

    Except they want to do it as part of the Sun "community process". Which Sun seems to consider sufficiently like Open Source to satisfy everybody. Alas, it only seems to satisfy Sun.

    Obviously the Apache folks like working with Sun, but don't like their attitude towards Open Source. Hence the current hassle.

  11. The comments by nyjx · · Score: 2, Informative
    Below are the comments posted on the JCP site. It seems that most people who voted yes were basically aiming to get this into a wider deabte (beyond the EC) and that's their reason for voting yes - hopefully the current wording will get shot down in the next review cycle.

    On 11-Mar-2002, Apple voted YES with the following comment: Apple fully supports the issues that have been raised by Apache and others, but the new JSPA represents a good step forward relative to the current one. We believe taking this to community review may provide the input that is needed to refine the JSPA before it goes to public review. During the community review, we would like to work with the PMO to refine the JSPA to better reflect the needs of those participating in open source efforts.

    On 11-Mar-2002, HP voted YES with no comment.

    On 11-Mar-2002, Borland voted YES with no comment.

    On 11-Mar-2002, Fujitsu voted YES with no comment.

    On 11-Mar-2002, Oracle voted YES with no comment.

    *** On 11-Mar-2002, Macromedia voted NO with the following comment: The free and creative spirit of the JCP should be directly and clearly manifested and protected legally. The major objections from the open source community argue that this is not the case, and we feel that the current language does not directly quell these concerns. We would like to see the issues that Apache raises on behalf of the open source community resolved in the JSPA itself before moving forward.

    *** On 11-Mar-2002, BEA voted NO with the following comment: After considerable soul searching, BEA has decided to vote NO on this revision of the JSPA. While considerable effort has been exerted by all concerned and significant progress has been made, we still are not convinced that this JSPA would provide the level playing field we have long advocated for Java technologies. The concerns voice by Apache and the open source community is one avenue of concern as is the autocratic power that continues to be vested in spec leads enabling them to attempt mischief to obtain competitive advantage by controlling both the pace of innovation and the availability of that innovation to the marketplace. Unless and until these issues can be satisfactorily addressed, we prefer to stick with our current agreements.

    On 11-Mar-2002, Caldera voted YES with the following comment: Caldera agree with a lot of the concerns expressed by Apache. We would like to see more to be done to protect the interests of open source providers.

    *** On 11-Mar-2002, Compaq voted NO with the following comment: Compaq shares Apache's concerns and IBM's concerns that the JSPA proposed revision provides insufficient protection for interests of open source providers and competitors (as enumerated at http://jakarta.apache.org/site/jspa-position.html) . Compaq must therefor vote no on this proposed revision

    On 11-Mar-2002, IONA voted YES with no comment.

    On 09-Mar-2002, Doug Lea ABSTAINED FROM VOTING with the following comment: I share most of Apache's concerns. However, I also think that it would be useful to open this up to the scrutiny of all JCP members, not just the EC. These two factors cancel themsleves out, hence I abstain.

    On 08-Mar-2002, Nokia Networks voted YES with no comment.

    *** On 06-Mar-2002, IBM voted NO with the following comment: IBM has consistently worked within the Java Community Process since its very inception to create a truly open environment with a level playing field where no single vendor has the ability to exert unnecessary control over Java technologies for their own proprietary advantage. While the current draft of the JSPA is an improvement over prior agreements, we believe we should do more to guarantee specifications, implementations and test suites developed under this agreement will be developed with a broader view of Java communities in mind, and to guarantee they are licensed under terms and conditions that allow the widespread adoption of compliant Java technologies. The JSPA amendments proposed under JSR 99 do not provide these guarantees.

    IBM has always believed it is absolutely critical the Java community include Apache as well as the rest of the open source community in order to ensure the long term health and competitive vitality of the Java environment. As a result, IBM is fully supportive of the open source community's need for Sun resolve all the issues raised by Apache at http://jakarta.apache.org/site/jspa-position.html directly and unambiguously in the JSPA agreement itself.

    *** On 05-Mar-2002, Apache voted NO with the following comment: Apache is unsatisfied the JSPA revision provides sufficient protection for our interests (as enumerated at http://jakarta.apache.org/site/jspa-position.html) . While we and others have worked long and hard on the JSPA revision and believe we have made progress from the previous JSPA, we cannot support a legal agreement which does not unequivocably satisfy these requirements.

    On 05-Mar-2002, Sun voted YES with no comment.

    --
    .sig
  12. Java is beyond hope by mmusn · · Score: 3, Interesting
    Seven years ago, Sun promised to keep Java open and free. What do we have today? A bloated set of APIs implemented by only a single vendor and a process that takes years to add even the simplest improvements to the Java language and libraries. And Sun has failed to take any actions that would guarantee to Java users that Java remains freely available--Sun could start charging for it any day, and you couldn't even download binaries anymore.

    I think Sun Java and the JCP is beyond hope. Open source developers should either define their own core "Java" implementation and libraries that discards most of the overly complex and Sun proprietary stuff, or just join up with the Mono project (Microsoft is no better than Sun, but Mono is producing a fully open source implementation of C#, and that's what counts).

    1. Re:Java is beyond hope by Skapare · · Score: 2

      I guess I'm now glad I put off learning Java. It looks like Java is headed down the other side of the hill, now. I still worry that things won't be any better with C# and .NET whatever Mono does. Microsoft could pull the same stunt as Sun, and we know Microsoft is very inclined to do such things.

      What the world needs is a new clean combination procedure and object oriented language at a higher level (C++ is just OO retrofited to a low level pretending to be a HLL). Further, this language needs to come in TWO forms: (1) a purely compiled form producing fast native object code implemented on a variety of platforms (maybe generating C as an intermediate result would be one way to accomplish it) ... and (2) a virtual platform hosted form (what JVM and .NET are). How the hell is my server going to share executeable code between 1000's of processes running the same program if each process is generating it's own Just-In-Time machine code as it runs in its own address space? While I might trust this to be a safe platform for more secure execution, it certainly isn't sharing memory very well, and hence puts more load on the server virtual and real memory that would be the case with the execution model we now have with C/C++/F77 and some others. This would be even worse if the libraries supporting such a thing are themselves also JIT compiled. This is why I want to have a tradition execution model as an option.

      --
      now we need to go OSS in diesel cars
  13. That's how democracy works... by software_non_olet · · Score: 2, Insightful

    not all can share the same opinion. But it's good that the decision process is done in public and including explicitly a phase of public feedback.

    I'm not getting angry at Sun. They put it a lot of effort into Java and their actual standpoint is - allthough taking a step backwards - somewhat understandable.

    Now is the time to participate. Let's not burry our heads in the sand but cast our votes as software developers. I will use the opportunity and object the draft during the following public review. Open Source Software is a must in the 21st century, playing the same role for the computer industry as academic freedom was for science.

    And if a large enough number and the majority of us developers is taking a similiar position _and_ participating actively in the public review, the members of the JCP cannot ignore it. We are their potential customers as well as partner in this.

    No need to give up too early.