On Thu, 2002-03-21 at 14:47, Ceki G�lc� 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." >
I like that...and for slang: "Oh don't mind him, he's got the clamp" ;-) Sounds like an STD, gotta love that. > 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]> > -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
