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