TheServerSide reports on Java Tools Community Press Conference

Discussions

News: TheServerSide reports on Java Tools Community Press Conference

  1. TheServerSide listened in on a press conference given by members of the newly formed Java Tools Community. The conference talked about the role of the Java Tools Community, and how it is to work alongside the JCP. It has been modeled on the telco alliance that wrapped around the JAIN APIs. The organization aims to offer domain knowledge around toolability to the Java platform. This will involve increasing the interop of tools and extensions.

    Toolability was defined as a measure of how easy it is to built tools around a standard or technology. The group feels that Java has been weak in this area, and has focused more on the runtime of standards.

    The JTC itself is NOT a standards body, as it will work WITH the JCP for those requirements. We should see some of the following come out of the group:

    - common build API
    - common Project Object Model, meta-data model, preferences
    - common way to deploy components
    - common views on deployment descriptors

    The community has been created at http://javatools.org

    Membership is free, and explained at http://www.javatools.org/membership.csp

    The call was quick to point out that there were three stewards of Eclipse on the call. This is trying to show that we can all work together, and that this group doesn't compete with Eclipse in anyway.

    Here are some questions and comments on the answers:

    Q. What do you hope to achieve, since IBM and Borland are not on the list

    They are not focusing on the who... but with how many. They think the group has a great mix of vendors and customers. This group will succeed based on contribution.

    Q. What are the finer points for JCP communication / processes

    The JTC has been modeled on the community around JAIN APIs (telco world). The JCP will be used for all standards work. Committee work will be done outside of the JCP, where the community can get full involvement. Then feedback will be taken to the JCP expert groups.

    Q. Will there be JTC certification? or TCKs?

    There will not be a JTC certification. There is talk about tools becoming "JTC endorsed", but this will not involve TCKs.

    Q. What will an end user developer be able to do as a result of your efforts?

    Struggle: tools keeping up with Java. This makes toolability an integral part of the JCP. Tools will be able to follow specs closer, which will mean that there will be a faster uptake of innovation. Tool vendors spent a lot of time on simple things such as deploying a web app in a container, as this task wasn't specified. Hopefully this will not happen in the future, and there will be a standard baseline for all tools.

    Q. How doesn't this not conflict with Eclipse? Another level of bureaucracy

    SAP is in both JTC and Eclipse (as is Oracle and SAS). Eclipse should comply/benefit from java standards and commonality between frameworks helps extension writers. Eclipse is NOT a standard organization, and does not want to become one.

    JCP owns the standards. JTC helps drive standards. Eclipse is an open source framework. All very exclusive.

    Q. What do you want to tackle first. Plug-ins? What about JSR 198?

    Toolability is the large pie. One piece of that pie is interoperability. JSR 198 is a large goal, and this group sees many small goals that can come first (as mentioned above: project object model, etc).

    Q. Will the JTC become a venue for interoperability between Java and .NET?

    This is a job for other groups such as WS-I. This isn't a major role for the JTC.

    News around the net on this topic

    Read the Press Release: Software Vendors Come Together to Launch Java Tools Community

    Java Group Set to Launch

    Threaded Messages (45)

  2. Please Show Some Integrity[ Go to top ]

    This is trying to show that we can all work together, and that this group

    > doesn't compete with Eclipse in anyway.

      This group doesn't compete with Eclipse in anyway? How come IBM isn't on board? What's next? Saying this group doesn't compete with Visual Studio in anyway.
  3. Let's look at some PR reprinted verbatim on the Server Side:

    > Eclipse is NOT a standard organization, and does not want to become one.

    Well, dare I say that Eclipse is the DE FACTO INDUSTRY STANDARD. It doesn't need an endorsement from Sun, BEA or Oracle.

    > JCP owns the standards.

    Well, the truth is Sun's owns the Java Cartel Process (JCP) and thus the whole JCP IP portfolio. The JCP is not an independent organization and thus doesn't qualify as a standard organization.
  4. Eclipse is NOT a standard organization, and does not want to become one.

    >
    > Well, dare I say that Eclipse is the DE FACTO INDUSTRY STANDARD. It doesn't need an endorsement from Sun, BEA or Oracle.

    ... And here I thought XUL was the "DE FACTO INDUSTRY STANDARD.", or have I been reading too much propaganda.

    Rob
  5. And here I thought XUL was the "DE FACTO INDUSTRY STANDARD.", or have I been

    > reading too much propaganda.

     Well, XUL is on its way to become a defacto industry standard. With or without Sun. With or without Oracle. With or without BEA. Just watch as XUL is going to show the Java Server Follies (JSF) Java Cartel Process (JCP) production how to keep it simple, stupid.

      - Gerald
  6. Viva - Let's kill Eclipse too![ Go to top ]

    Gerald: Well, dare I say that Eclipse is the DE FACTO INDUSTRY STANDARD. It doesn't need an endorsement from Sun, BEA or Oracle.

    ... nor from you. Gerald, the worst thing that could ever happen to Eclipse is for it to garner your support. You've almost killed XUL already; please don't kill Eclipse.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  7. Viva - Let's kill Eclipse too![ Go to top ]

    ... nor from you. Gerald, the worst thing that could ever happen to Eclipse is for it to garner your support. You've almost killed XUL already; please don't kill Eclipse.


    Heh... well said.... Gerald, Microsoft is hiring right now, I'm sure many people on here will be happy to be a reference for you with them.

    Cheers,

    Rob
  8. Tools for their trade??[ Go to top ]

    Great Idea, but are they not trying to re-invent the wheel.
    If their main objective is, to act as bridge between us developers and the JCP why develop YAJF (Yet Another Java Forum). If the likes of SUN, IBM and BEA start taking note of java forums such as this, things would be far more effective.

    Anyway one hopes this effort really brings about some welcome changes in the way SUN brings about it's JSRs.
  9. Whose Your Daddy?[ Go to top ]

    If the likes of SUN, Oracle and BEA start taking note of java forums such as

    > this, things would be far more effective.

      It's all about who's in control and who's running the show. Don't forget, at the end of the day Sun, Oracle and BEA wants your money. They are no charities. Nonwithstanding all this "community" rhetoric as in Java "Community" Process or Java Tool "Community".

      - Gerald
  10. Whose Your Daddy?[ Go to top ]

    Nonwithstanding all this "community" rhetoric as in Java "Community" Process or Java Tool "Community".

    I also find Sun using the word 'community' misleading. Sun seems to use it as a synonym for 'licensees', or at least as a euphemism for the leading vendors. Rick Ross did well to found JavaLobby, since its alone serves as a Java community run for the exclusive benefit of Java developers. But has JavaLobby ever succeeded at steering the evolution of Java?
  11. Tools for their trade??[ Go to top ]

    Great Idea, but are they not trying to re-invent the wheel.

    > If their main objective is, to act as bridge between us developers and the JCP why develop YAJF (Yet Another Java Forum). If the likes of SUN, IBM and BEA start taking note of java forums such as this, things would be far more effective.
    >
    > Anyway one hopes this effort really brings about some welcome changes in the way SUN brings about it's JSRs.

    Okay, I'll bite. What "welcome changes in the way Sun brings about its JSRs" are on your mind?

    Best regards,
    Onno Kluyt
    Director, JCP Program Office
    Sun Microsystems, Inc
  12. Okay, I'll bite. What "welcome changes in the way Sun brings about its JSRs" are

    > on your mind?

      Allow me to quote XML Guru Extraordinaire Elliotte Rusty Harold from the article titled "The Java Gated Community Process" to get the discussion started online @ http://www.ibiblio.org/javafaq/editorials/jcp.html

     Here we go:

     To me this makes it pretty clear, that this process is not an open one. If you're still not convinced, ask yourself these questions:

       0. Can anyone tell Sun No? Can anyone keep Sun from putting something into the spec they want to put it in? Or put something in that Sun wants to keep out?

       1. Can Sun's enemies (e.g. Microsoft, HP, etc.) participate in this process on an equal footing with Sun? Can they even participate at all?

      When you actually read the fine print, what the Java Community Process says is that Sun agrees to let other companies contribute their time, money, and knowledge to help Sun do what it wants to do anyway. That may be intelligent business, but it's not an open, community based process for developing standards.

      Now allow to close with a question: Why would anyone contribute to the Sun-led Java Tool "Community" if you can contribute to the open-source Eclipse project that guarantees you that you can freely use, change and redistribute your code and is not locked up in Sun's IP portfolio?
  13. That write-up is 4+ years old, from Sept '99. JCP 2 addressed all those concerns.

    Onno.
  14. Onno Please Explain[ Go to top ]

    That write-up is 4+ years old, from Sept '99. JCP 2 addressed all those

    > concerns.

      Can you expand on how JCP 2 addresses all those concerns? How come IBM kicked off the Eclipse initiative? How come they didn't join your Java Tool "Community"?

      - Gerald

    PS: How come IBM adds the following statement to its JCP voting logs:

    IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
  15. Onno Please Explain[ Go to top ]

    That write-up is 4+ years old, from Sept '99. JCP 2 addressed all those

    > > concerns.
    >
    >   Can you expand on how JCP 2 addresses all those concerns?
    JCP 2 came after that write-up.

    >How come IBM kicked off the Eclipse initiative?
    That is called competition and free trade; competition to NetBeans by the way. Neither Eclipse nor NetBeans compete with the JCP.

    >How come they didn't join your Java Tool "Community"?
    You will need to ask IBM that.

    >
    >   - Gerald
    >
    > PS: How come IBM adds the following statement to its JCP voting logs:
    Again, ask IBM.

    >
    > IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
  16. Can you expand on how JCP 2 addresses all those concerns?


    > JCP 2 came after that write-up.

      Sure. But that doesn't change a thing all those concerns are still valid. If I may repost them:

       9. When the process is done, Sun owns the copyright and other intellectual property rights related to the spec. As owner, they will not allow derivative works they decide are incompatible.

    To me this makes it pretty clear, that this process is not an open one. If you're still not convinced, ask yourself these questions:

       0. Can anyone tell Sun No? Can anyone keep Sun from putting something into the spec they want to put it in? Or put something in that Sun wants to keep out?

       1. Can Sun's enemies (e.g. Microsoft, HP, etc.) participate in this process on an equal footing with Sun? Can they even participate at all?

    When you actually read the fine print, what the Java Community Process says is that Sun agrees to let other companies contribute their time, money, and knowledge to help Sun do what it wants to do anyway. That may be intelligent business, but it's not an open, community based process for developing standards.

      After all those years it's still the same old, same old. The JCP is not an independent organization as you make the world believe. If I may quote from your signature: Onno Kluyt, Director, JCP Program Office, Sun Microsystems, Inc. Your JCP "election" is just a farce as nobody can replace Sun from its controlling and dominating position and on and on.

    >> How come IBM kicked off the Eclipse initiative?

    > That is called competition and free trade; competition to NetBeans by the way.
    > Neither Eclipse nor NetBeans compete with the JCP.

     Onno, you're the head of the Java Cartel Process and you lecture me on competition and the free market. How ironic. Evidently, you haven't grasped the concept yet. Eclipse doesn't compete with the JCP or the Java Tool Cartel? Huh, come again.

    >> PS: How come IBM adds the following statement to its JCP voting logs:

    > Again, ask IBM.

      Onno, aren't you the Director of the JCP Program? Can you comment on what's Sun's position on IBM's concerns?

      - Gerald
  17.    9. When the process is done, Sun owns the copyright and other intellectual property rights related to the spec. As owner, they will not allow derivative works they decide are incompatible.


    Not true. The spec lead owns the copyright on the resulting spec. See section 5.A of the JSPA.

    >    0. Can anyone tell Sun No? Can anyone keep Sun from putting something into the spec they want to put it in? Or put something in that Sun wants to keep out?

    Yes, they can tell Sun no. The EC members vote on all JSRs. Look at JSRs 76 and 78 for example: Sun JSRs that were voted down.

    >
    >    1. Can Sun's enemies (e.g. Microsoft, HP, etc.) participate in this process on an equal footing with Sun? Can they even participate at all?

    Well, HP is an EC member so the answer must be yes.

    Onno.
  18. 9. When the process is done, Sun owns the copyright and other intellectual

    >> property rights related to the spec. As owner, they will not allow derivative
    >> works they decide are incompatible.

    > Not true. The spec lead owns the copyright on the resulting spec. See section
    > 5.A of the JSPA.

      Well, the spec lead is just a puppet on a string. If I may quote the JSPA:

      Similarly, if with respect to a particular JSR You cease to be the Spec Lead before that JSR is completed, then any and all of the comments, specifications, materials or ideas provided by You hereunder, to the extent incorporated into any form of Output, shall be considered Contributions licensed pursuant to Sections 4.A and 4.B.

      And so forth. Clearly once you sign the JSPA you hand over all your rights to Sun. Isn't it telling that the JSP agreement/contract is between you and Sun?

      Care to comment on IBM's licensing concerns. If I may quote:

    IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
  19.   Well, the spec lead is just a puppet on a string. If I may quote the JSPA:

    >
    >   Similarly, if with respect to a particular JSR You cease to be the Spec Lead before that JSR is completed, then any and all of the comments, specifications, materials or ideas provided by You hereunder, to the extent incorporated into any form of Output, shall be considered Contributions licensed pursuant to Sections 4.A and 4.B.

    Yes, Contributions to the new Spec Lead - which could Sun or IBM or HP or JBoss Group or ....
    Even so, through the JCP you never depart from ownership of your IP. You grant rights to its use for the purpose of developing the JSR, but your IP continues to be your IP. That has always been the case.

    Onno.
  20. Who owns the TCK?[ Go to top ]

    9. When the process is done, Sun owns the copyright and other intellectual

    >> property rights related to the spec. As owner, they will not allow derivative
    >> works they decide are incompatible.

    > Not true. The spec lead owns the copyright on the resulting spec.

    If you claim it's not true does this now mean Sun will allow derivative works Sun decides are incompatible? Can you clarify?

    Also if I may quote from the Apache site: A TCK license is required (not optional) when performing an independent implementation and TCK licenses often cost tens of thousands of dollars, the JSPA must require all TCK licenses be easy to obtain by a non-profit (open source or academic) group. Note that "hoping the spec lead grants a special-case free waiver" does not count as "easy to obtain".

    Now can you clarify who owns the TCK?
  21. Who owns the TCK?[ Go to top ]

    Also if I may quote from the Apache site: A TCK license is required (not optional) when performing an independent implementation and TCK licenses often cost tens of thousands of dollars, the JSPA must require all TCK licenses be easy to obtain by a non-profit (open source or academic) group. Note that "hoping the spec lead grants a special-case free waiver" does not count as "easy to obtain".

    >

    That's another old quote of a situation that has been resolved in the JCP sometime ago. Apache's own Geronimo project illustrates that a satisfactory solution was reached.

    > Now can you clarify who owns the TCK?

    Sure. The Spec Lead.

    Onno.
  22. Onno, first thanks for your clarifications. Rest assured your effort is not wasted as I will create a write-up so everybody benefits.

    >> Now can you clarify who owns the TCK?

    > Sure. The Spec Lead.

    Now does this mean the spec lead can license the TCK to the world? And will Sun allow derivative works Sun decides are incompatible? Can you clarify?

    Also can you give examples of individuals (spec leads) who own TCKs?
  23. Now does this mean the spec lead can license the TCK to the world?


    The JSPA obligates the spec lead to license the TCK on fair, reasonable and non-discriminatory terms. So, the answer to your question seems to be a firm yes.

    > And will Sun allow derivative works Sun decides are incompatible? Can you clarify?

    The JSPA describes that the spec lead shall license the specification those who build compatible implementations. Whether the implementation is derived or independent is irrelevant to this regard.

    > Also can you give examples of individuals (spec leads) who own TCKs?

    There are a few individuals who lead JSRs. These JSRs have not finished yet so we'll have to wait and see what each spec lead together with his or her expert group come up with.

    Onno.
  24. To wrap up allow me to post some closing questions about the challenges that lie ahead for the JCP and JTC.

    * Do you see any need to rethink or reform the JCP? Any plans for JCP v3.0?

    * Do you think the JCP will still be relevant in three years? Or will it just be an archaic left-over from Sun's glory days?

    * What is your position/opinion on the Java Republic initiative?

    * Do you see a need to rethink your Java above all else doctrine? How about opening up to other language like Eclipse or Viva?

    * And finally, some personal questions about your role: How did you end up Director of the Java Community Process? Did somebody elect you or did Sun just appoint you? Are you accountable to anybody other than Sun? Whose interests to you push and defend?
  25. * What is your position/opinion on the Java Republic initiative?

    If it ever gets more than one member, I'm sure he'll think about forming an opinion.
  26. Cameron:
    If it ever gets more than one member, I'm sure he'll think about forming an opinion.

    You're not being fair, Cameron, I have seen a few benevolent rich Nigerians show some interest in this effort on their mailing-list.

    --
    Cedric
  27. To wrap up allow me to post some closing questions about the challenges that lie ahead for the JCP and JTC.

    >
    > * Do you see any need to rethink or reform the JCP? Any plans for JCP v3.0?
    I don't think we're ever done with evolving/improving/reforming the JCP. To save me some typing here, look at my January column in JDJ for some of the things I am looking at.

    >
    > * Do you think the JCP will still be relevant in three years? Or will it just be an archaic left-over from Sun's glory days?
    Yes, I do think that.

    >
    > * What is your position/opinion on the Java Republic initiative?

    For a moment I thought you were referring to Indonesia. I am re-reading "Max Havelaar" by Hildebrand. One of those books you had to read in order to pass Dutch high school exams. Hated it then and looking to see if my enjoyment is any better now :-) It's plays during the Dutch colonial days in Indonesia. Anyways. I am not familiar with this initiative you're mentioning so I don't have an opinion at this time.

    >
    > * Do you see a need to rethink your Java above all else doctrine? How about opening up to other language like Eclipse or Viva?

    I don't believe such a doctrine exists. I also don't believe Eclipse is a language, by the way. Many other languages already run on top of the JVM. Most Ada programs and even Cobol.

    >
    > * And finally, some personal questions about your role: How did you end up Director of the Java Community Process? Did somebody elect you or did Sun just appoint you? Are you accountable to anybody other than Sun? Whose interests to you push and defend?

    Sun appointed me back in Oct 2000. Sun staffs the Program Office. This is outlined in Appendix A of the JCP process document. What I push and defend is the evolution of Java technology and the proliferation of compatible implementations of that technology.

    Onno.
  28. easy come easy go[ Go to top ]

    Sun showed great cunning - two times promised to deliver Java to a standards body and two times withdrawed the offer - giving time for Java to grow as everybody thought that it was more or less "Open Source". Now they own (control) to 100% something that was mainly developed by the international community - not Sun. But in a couple of months Mono 1.0 will be released and then it doesn't matter anymore. Both Sun and Microsoft can sit on their property as long as they want:) The certainly is some moral in this story.

    Regards
    Rolf Tollerud
  29. easy come easy go[ Go to top ]

    Sun showed great cunning - two times promised to deliver Java to a standards body and two times withdrawed the offer - giving time for Java to grow as everybody thought that it was more or less "Open Source". Now they own (control) to 100% something that was mainly developed by the international community - not Sun. But in a couple of months Mono 1.0 will be released and then it doesn't matter anymore. Both Sun and Microsoft can sit on their property as long as they want:) The certainly is some moral in this story.

    I agree with this post of yours, though you've left some things unsaid. Sun has some minimal protections on its intellectual property: Sun owns the specifications for the language and the virtual machine; Sun also has patents on virtual machine optimization. But none of this stops a rival implementation. Eg, Kaffe is limited only by its ability to recruit users and uncontaminated developers. But Microsoft's .NET patent sweepingly claims an entire system stack. It could be used as a club with which to hurt Mono. I mean dude, if I take the risk of switching to Mono, what hope do I have of not getting further entangled in corporate property? I might as well switch to Python and escape the corporate drag net entirely.
  30. I hope you perceive your mistake,[ Go to top ]

    which is of a fundamental nature.

    You are confusing "what is" with "might be".

    MS does not receive any money from Novel/Ximian and the relation is good, Ximian many times mentioned positively on MS sites. In fact they have clearly stated that "One of the key considerations that went into the design of the Rotor's shared source license is that a programmer should be able to look at the Rotor source without becoming tainted." Nevertheless, nobody that has seen any Rotor code is allowed to work on Mono.

    They will not get any money from Mono in the future either, because:

    1) Everything in Mono that is not standard ISO/ECMA is a clean-room implementation.

    2) Even if a - MS had any legal ground they would not do anything because it is in Microsoft’s own interest to have .NET on Linux as a weapon against Java.

    3) Even if a - MS had any legal ground, and b - wanted to exercise it, the political situation and the public opinion (the "third power" in the world) being what it is would never allow it.

    On the contrary, Sun takes money for the Technology Compatibility Kits, license to Borland, Weblogic, et al, bully JBoss and IBM, don't allow distributing with Linux, make it a problem to distribute something from SDK with your application, control JCP and so on and so on. In fact Sun earns a lot of money from Java it is a secret how much of course.

    Regards
    Rolf Tollerud
  31. I hope you perceive your mistake,[ Go to top ]

    Everything in Mono that is not standard ISO/ECMA is a clean-room implementation.

    Clean room regards copyrighted material, not patented innovation such as .NET.
  32. I hope you perceive your mistake,[ Go to top ]

    Software patents is useless and with god reason, there is always prior art. Computers and software could not exist as they do today if it weren't for the ability for one person to be inspired by another's ideas and take those ideas further. The ideas relies on pioneering work and intellectual contributions done by thousands of individuals before them. Both IBM and Microsoft routinely files software patents that they never exercise.

    So you think that Open Source will not be able to "steal from" .NET when Berkley took from A&T, Linux from SCO, Apple from Xerox, MS from Java, etc etc?

    Please.

    Regards
    Rolf Tollerud
  33. I hope you perceive your mistake,[ Go to top ]

    Software patents is useless and with god reason, there is always prior art.

    You don't sound at all like a lawyer.
  34. Nothing Changed - Same Old, Same Old[ Go to top ]

    That write-up is 4+ years old, from Sept '99. JCP 2 addressed all those

    > concerns.

    Quit a statement. Allow me to repost Elliote's conclusion and follup with a question:

    When you actually read the fine print, what the Java Community Process says is that Sun agrees to let other companies contribute their time, money, and knowledge to help Sun do what it wants to do anyway. That may be intelligent business, but it's not an open, community based process for developing standards.

    Now on to the question: Can you explain how fair and open the Java "Community" Process (JCP) v2.x is when all IP (intellectual property) ends up in Sun's portfolio and how this matches with Sun's "community" rhetoric?
  35. Nothing Changed - Same Old, Same Old[ Go to top ]

    That write-up is 4+ years old, from Sept '99. JCP 2 addressed all those

    > > concerns.
    >
    > Quit a statement. Allow me to repost Elliote's conclusion and follup with a question:
    >
    > When you actually read the fine print, what the Java Community Process says is that Sun agrees to let other companies contribute their time, money, and knowledge to help Sun do what it wants to do anyway. That may be intelligent business, but it's not an open, community based process for developing standards.
    >
    > Now on to the question: Can you explain how fair and open the Java "Community" Process (JCP) v2.x is when all IP (intellectual property) ends up in Sun's portfolio and how this matches with Sun's "community" rhetoric?

    Yes, I can because that is not the case. Contributed IP remains the ownership of its contributor.
  36. Now on to the question: Can you explain how fair and open the Java "Community"

    >> Process (JCP) v2.x is when all IP (intellectual property) ends up in Sun's
    >> portfolio and how this matches with Sun's "community" rhetoric?

    > Yes, I can because that is not the case. Contributed IP remains the ownership of
    > its contributor.

      Well, let's look at a case study: The Apache Jetspeed Portlet API, shall we? Allow me to quote from Kevin Burton's (Apache Jetspeed founder) weblog story titled "Jetspeed and the JSR" online @ http://www.peerfear.org/rss/permalink/2003/08/01/JetspeedAndTheJSR

      Andrew C. Oliver talks about Jetspeed (an Open Source project under Jakarta I created about 5 years ago) and the JCP:

        Just a little history for you Jetspeed was the basis for JSR-168. Thus this means Sun + IBM took OPEN SOURCE code and CLOSED off a section of the community. This is what supporting open source means to Sun. "Source" from the open source community and "close" it. Its like a big ol bucket of free labor to build a companies IP portfolio! It makes me lean towards more radical forms of open source which protect against this kind of nonsense. When Simon give me this line it makes me not want to work with him, but against him. I'm trying to find common ground, but I'm getting stonewalled. I'm curious people think of NDAs for open standards? Is the NDA-laden JCP conducive to working with open source?

      I stopped being involved in Jetspeed about 2 years after its creation to move onto other projects.

      There as some strong discussion while I was still involved to take my Portlet API and the IBM Portlet API contribution and create a JSR to standardized the API across vendors. I vetoed the decision 3 or 4 times before I left Apache. If we couldn't be open during the entire JSR it made no sense to me to move forward.

      Looks like I was partially right (would have rather be wrong).

      Any comments?
  37. Onno, just to let you know that I kicked off a quote collection that archives your "answers" to critics. I hope that more exposure gets a serious dialog going and gets us beyond your everbody-loves-the-Java-Cartel-Process-and-likes-to-work-for-free-for-the-greater-glory-of-the-Sun-empire fare.
  38. Shut Up and Contribute[ Go to top ]

    Okay, I'll bite. What "welcome changes in the way Sun brings about its JSRs" are

    > on your mind?

      Just witness the Sun Java 1.5 Alpha disaster. You can download it after you agree to a NDA (non-disclosure agreement). You're not allowed to talk to anyone but the Sun titanic.

      So if you feel courageous today why not answer the following to questions:

      * Can you explain how NDAs (non-disclosure agreements) foster "community" spirit?

      * Can you explain how fair it is that all IP (intellectual property) ends up in Sun's portfolio and how this matches with Sun's "community" rhetoric?

      - Gerald

    PS: Don't get me started on your JCP "election". Can I run for Java President and kick Sun out of office for all the broken promises?
  39. Shut Up and Contribute[ Go to top ]


       * Can you explain how NDAs (non-disclosure agreements) foster "community" spirit?

    They don't but just because an Alpha release is delivered with an NDA (a very common practice) doesn't mean there is no Java community.

    Your fictive XUL community might be non-existent but the Java community is alive and vibrant.


    > * Can you explain how fair it is that all IP (intellectual property) ends up in Sun's portfolio and how this matches with Sun's "community" rhetoric?

    Richard Stallman, is that you speaking? Where is your flute?

    And now I'm gonna get you started on the JCP election...


    > PS: Don't get me started on your JCP "election".

    Ah, I guess not then. Too bad.

    --
    Cedric
  40. "Richard Stallman, is that you speaking? Where is your flute?"


    Stallman? Why is he coming in the discussion? Cedric, you must have associated too much with Cameron.

    And can you tell me (and remember to keep it really simple so even a Microsoft Hacker can understand): Why do people hate Eclipse so much? It's certainly the only decent Java desktop application I ever seen..

    Regards
    Rolf Tollerud
  41. And can you tell me (and remember to keep it really simple so even a Microsoft Hacker can understand): Why do people hate Eclipse so much?

    No, Rolf, I can't tell you, you would have to ask "them".

    Simple enough?

    --
    Cedric
    (who enjoys yours posts besides that)
  42. Rolf = ROFL?[ Go to top ]

    Rolf: Cedric, you must have associated too much with Cameron.

    What can you say? The guy has good taste. (He's French, after all. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  43. Ok here it goes[ Go to top ]

    1. Take Swing out of the J2SE core and give us the ability to plug in either SWT or Swing at runtime. Flexibilty in the development Java GUIs in extremely important for a thriving tools community to evolve. Look at the Windows platform for example. If I wanted to develop simple app like a "Download Manager" I could use MFC, wxWindows..... With Java I will always have to use Swing which at the present moment does not integrate well the Windows desktop and despite all claims to the contrary does not feel like a Native App.
    <br/>
    2. Consolidate the JDO and EJB CMP mechanism and give an API which the uses the best of both.Make sure you involve Hibernate too. Tool developers like us have to grapple with the impedance mismatch of java code and the relation model every time we try to develop a tool. Ideally any java to rdbms or-bridge should not depend on an app server.
    <br/>
    3. Tool developers need not just a great code editor but a good Tool Development Environment as well. The core java apis are great but I would think that the JCP needs to look at developing specific apis for tools development that allows tools to look, feel like native apps and integrate tightly with the desktops (exe launchers etc).
    <br/>
    4. When do we get the shared JVM ???
    <br/>
    5. Installing Java Softwares is still a big pain. Product companies like our have to pay for and learn products like InstallShield, Install Anywhere etc. Is it possible for JCP to develop a common API which all Java Based Installtion products will follow. Call this the Java Sofware Installation System, if you will.
  44. Ok here it goes[ Go to top ]

    1. Take Swing out of the J2SE core and give us the ability to plug in either SWT or Swing at runtime. Flexibilty in the development Java GUIs in extremely important for a thriving tools community to evolve. Look at the Windows platform for example. If I wanted to develop simple app like a "Download Manager" I could use MFC, wxWindows..... With Java I will always have to use Swing which at the present moment does not integrate well the Windows desktop and despite all claims to the contrary does not feel like a Native App.

    >
    I hope too that there will be better integration /coordination between Swing and SWT. I doubt though that Swing would be taken out of core. A main issue here is backward compatibility where shippings and installed base assume that Swing is there.

    > 2. Consolidate the JDO and EJB CMP mechanism and give an API which the uses the best of both.Make sure you involve Hibernate too. Tool developers like us have to grapple with the impedance mismatch of java code and the relation model every time we try to develop a tool. Ideally any java to rdbms or-bridge should not depend on an app server.
    > <br>
    This appears indeed one of the things that the JavaTools initiative should focus on. You inferring that you are a tool developer so I hope that you'll be participating in the initiative?

    > 3. Tool developers need not just a great code editor but a good Tool Development Environment as well. The core java apis are great but I would think that the JCP needs to look at developing specific apis for tools development that allows tools to look, feel like native apps and integrate tightly with the desktops (exe launchers etc).
    > <br>
    Ted Farrell earlier on this thread commented that many JSRs focus mainly on runtime and less so on the tools-side. That is what the term 'toolability' refers to so this indeed the main focus for the initiative.

    > 4. When do we get the shared JVM ???
    > <br>
    I am checking with the Tiger team.

    > 5. Installing Java Softwares is still a big pain. Product companies like our have to pay for and learn products like InstallShield, Install Anywhere etc. Is it possible for JCP to develop a common API which all Java Based Installtion products will follow. Call this the Java Sofware Installation System, if you will.

    Have you looked at JSR 38 by any chance?

    Onno.
  45. Ok here it goes (VM sharing)[ Go to top ]

    Checked with the Tiger folks on shared VM.

    It's in and you'll see it the upcoming beta release. The shared VM feature allows sharing of standard Java classes across JVM processes. It's a high risk feature so feedback on how it behaves will be very welcome. One should not anticipate miracles, as in great decreases in memory usage. Research by the engineers shows that most of the memory usage by an application comes from application specific data and classes so the impact that VM sharing can have is constrained.

    Hope this helps,
    Onno.
  46. so touching[ Go to top ]

    I have to dry away a tear, Cameron and Cedric fighting together to the last, "sniff"

    Sun is virtually a solved problem, they are sick company who cannot continue to compete. Lets us all try together to help find other jobs for these guys!

    By the inexorable logic of competition, 200-dollar players have no place in a
    2000-dollar team.

    Regards
    Rolf Tollerud
    "advocatus diaboli"