>On Thu, 21 Mar 2002 20:47:26 0100 Ceki =?iso-8859-1?Q?G=FClc=FC?= <[EMAIL PROTECTED]> wrote. >All very good points. The question on my mind is whether these >problems can be corrected in the future by opening up the (JCP) Java >Community Process or whether the closed-like-a-clamp is a symptom >of a more serious and profound disease - my suggested name would >be "clampitis." > >Does anyone has a satisfactory answer? For one, Sun has been >uttering (muttering?) the correct noises lately. However, it is hard >to say whether they are sincere or just pre-JavaOne acting. > >As you say, the issues are not related solely to licensing. When I >stop and ask: "what is in it for Sun?" the answers are not very >encouraging. >
better APIs and free developers in the upcoming fight with Microsoft. (Sun has to wake up and smell the Java burning first) But first Sun needs to decide what kind of witch it wants to be. A hardware witch or a software witch or "why I'm not a witch at all" and then find a place on the sidelines. Sun's never been very good at selling software. What are their Java products... an IDE that only got decent when they opensourced it (pattern forming with that), and the reminants of Netscape's app server business. Big iron hardware is fading. . Sun needs to build cheaper fast little servers for the many mini-me's strategy that is now popular in IT versus the "big server". And thats whats wrong with its hardware bizz. So Sun is trying to sell its tools now... Look at this months DDJ, lots of spreads on "the netbeans platform" and Forte. What's your next product Sun? I have a novel concept... it Ain' java licensing fees. They need real products, and for Java, they need open development of it. Come up with some products though! geesh. -Andy >At 14:12 21.03.2002 -0500, you wrote: > >>Somebody asked on the axi-user mailing list why they should use Axis >>instead of JAXM. I offered some comments, but tried not to stray >>too off topic. In light of a recent JCP-related thread, I thought >>there might not be any objections on general@jakarta if I vented for >>a minute. >> >>When you use JAXM, you'll run up against all sorts of limitations and >>the best you can do is send a suggestion/comment to an email address. >>With Axis, or any Apache project, if you run up against a limitation, >>you can discuss it on a mailing list and submit a patch. >>Hypothesis: JCP JSRs that have more frequent feedback iteration cycles and >>provide source code tend to produce better results than those with fewer >>feedback cycles. I'll use JAXM and JAX-RPC as examples. JAXM >>had no mailing list for developer discussion/feedback as it was being >>designed/developed with only the usual JCP JSR comment address. JAX-RPC >>has a jaxrpc-interest mailing list that has helped the spec evolve into >>something more likely to be useful to developers. With something as >>simple as a mailing list a JCP JSR can gather much better requirements. >>However, neither JSR provided source for their reference implementations, >>making debugging and patch submission an impossibility. >> >>The problem with the JCP is not merely the licensing. It is also the >>basic JSR procedures. The objective of a new API is to meet some set >>of developer requirements in a particular application domain. If you >>don't consult with your users, the target developer group, you probably >>won't develop a useful result. JSRs would produce better results if run a >>little more like Apache projects, with more opportunity for user feedback >>in an open forum to mold the ultimate result into something useful. >> >>daniel >> >> >> >>-- >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > >-- >Ceki > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
