Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Java Software Programming Apache

Open Source is out of the Java process 38

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?"
This discussion has been archived. No new comments can be posted.

Open Source is out of the Java process

Comments Filter:
  • 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 :-(
    • OK, I meant to say Tomcat is used in the official Sun reference implementation.
    • Reference to Doom (Score:4, Insightful)

      by fm6 ( 162816 ) on Thursday March 14, 2002 @08:14PM (#3165669) Homepage Journal
      No, Jakarta is strictly an Apache thing. As with all things Java, Sun does its own reference implementations [sun.com].

      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.

      • Please read this [apache.org].

        Yes it's only Tomcat, but Tomcat is a big part of Jakarta.
        • 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.

          • I'd have to agree the sun reference implementation isn't as good as Tomcat. The jakarta group has done a lot of great work on Tomcat. It used to be that tomcat was one of the slowest servlet containers, but the latest tomcat 4.0.2 performs better than Orion 5.2 for 0-75 simultaneous connections. I did some benchmarking recently and was happily surprised.

            Honestly the passing of JSR-99 doesn't change my mind about using Java. Sure Sun isn't being nice to open source, but I highly doubt they would charge for the jdk or implement costly licensing. Sun isn't stupid. They are in the business of enterprise hardware and services. Sun wouldn't be able to make enough on licensing to make a significant dent in the net earning department. In fact, it would probably cost Sun more money to implement a licensing scheme, than keep it free. Think about the staff needed to handle all the support and licensing issues.

            In my mind, it is a way to keep charging for certification and make sure open source implementation don't limit Sun's partners from making money. If the open source version is certified, a lot of medium to small business will choose open source. Making it harder for open source to get certification gives Oracle and the other companies something to claim in their marketing. ie, "we are certified

            • Sure Sun isn't being nice to open source, but I highly doubt they would charge for the jdk or implement costly licensing.

              If Sun Microsystems owns stock in at least one European telephone company, then Sun is (indirectly) charging for access to the J2SDK. The license for the J2SDK does not permit redistribution outside an organization. The J2SDK is available free of charge over the Internet, but it takes an hour and a half to download over a 56K connection, and many European telcos bill local telephone calls (e.g. to ISPs) by the minute at rates approaching $2/hour in some areas. If the telco turns a profit, and Sun owns part of the telco, then Sun gets part of the dividends.

              Anti-trollbait disclaimer: Yes, trolls, I know that such charges are a drop in the bucket, but parent stated that Sun is probably not charging at all. No, trolls, I don't know whether or not Sun has any European telco holdings.

              • Have to admit that is a possibility considering how slow broadband deployment is in Europe. But on the otherhand, as broadband deployment increases, that angle doesn't look as attractive. In either case, Sun has more to gain by keeping it free. Especially now that Microsoft is pushing hard into enterprise services by riding on IBM's coat tails. Ok that last sentence is flame bait, but given IBM has much more experience in the enterprise services world than Microsoft there's truth to that statement. After all, a recent interview posted on /. about microsoft's push with .NET said they didn't know the business side of enterprise services too well at this point.
  • 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!
    • by Anonymous Coward
      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.
  • by leviramsey ( 248057 ) on Thursday March 14, 2002 @07:16PM (#3165309) Journal

    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
    • What about SunSource [sunsource.net]?

      Even if Sun made questionable decisions with the JSR 99, don't forget that Sun's Open Source involvement goes beyond Java.
    • by ChiefPilot ( 566606 ) on Thursday March 14, 2002 @08:42PM (#3165812)
      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.

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

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

      • before starting the boycott read the comments here: {DELETED FOR BREVITY --LR} Many agree with the concerns of Apache although they voted yes.

        I mentioned those companies which expressed reservations while voting yes. However, their comments do not change the fact that they took action knowing the damage that this could cause the Open Source community. This is analogous (though not as severe) as someone voting for the Nazi Party and saying, "We'll address the concerns of Kristallnacht and Mein Kampf later."

        Especially damning is that two of these companies (Apple and Caldera) have used open source to further their corporate aims. While I have no problem with that, I do have a problem with them stabbing the community in the back on this. Apple and Caldera have fallen below my respect for this, and I respect Microsoft. I would cheer if Windows XP was ported to the PowerPC and drove MacOS X into an early grave. I would consider it a step forward if every shop running Caldera switched tomorrow to the appropriate flavor of Windows for their application.

    • Send an email explaining to Sun that we will embrace open source .NET implimentations (like Portable.NET and Mono) at their expense if they are intent on locking us out.

      I HAD great hope that Java open source implimentations would be good competition to .NET, but this may not be the case...
  • 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.
    • Re:More Info? (Score:2, Interesting)

      by inertia187 ( 156602 )
      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.
    • The cheap 20 second answer: Basically if Apache works on a JSR specification, once it becomes a standard, well then they can pay an Oracle or Sun for the privilage to use the standard including the part that Apache worked on. Same goes for everyone else who participates, what a great community process eh?
  • 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.

    • No, it's because Caldera (and Apple for that matter) believe that it would be best to move the discussion out of the relatively small group of people who have been talking about it recently into the public domain.

      Similar to what happend with the W3C and their patent policies recently.

      While I wish they would have voted no, they do have a good point that this issue is one that should be discussed with the general computing public.

      David
  • 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.

  • Isn't the power of open source in the fact that it always comes up with something better or just as good for free? and with great documentation (most of the time)?

  • The comments (Score:2, Informative)

    by nyjx ( 523123 )
    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.

  • Java is beyond hope (Score:3, Interesting)

    by mmusn ( 567069 ) on Sunday March 17, 2002 @10:38PM (#3179024)
    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).

    • 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.

  • 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.

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Working...