Danny Angus wrote: > > >>>> Why create something in official Java APIs/Products when there >>>> is allready a good OSS alternative. >>> > >>> To standardise it. Why is OSS any different? >> > >> Exactly! So why bother "standardizing" it via Sun. If there is a >> ubiquitous Apache standard already, then there is NO need for a Sun >> standard. > > Personally I think the danger is, as Andy pointed out, that Sun > including a lot of functionality in the core distribution of Java JSE > or in JEE limits the ability of third parties to develop solutions, > in a way very similar to M$'s inclusion of extended functionality in > the basic Windows OS installation. >
*and* bloats Java. I have a JAXP and TRAX implementation in Sun's JRE,
that I need to override, because it does not work with most projects,
for instance. I have the whole Swing, even if I don't use it in my
tomcat VMs or with ant/maven... Those could be pluggable (as JAXP or TRAX, or JAAS, or even parts of JDBC, used to be).
> Standards should not be taken to mean "product most widely used" or > "the product officially supported" they are something else. IMO > standards are, and should be, benchmarks against which people can > compare their work and say either it does or it does not support > standard x,y or z. Standards compliance can be a goal of any software > project. Standards compliance as a goal of un-related projects > results in the kind of interoperability that is fundamental to the > character of the internet. > > Open Source has standards as a cornerstone because it allows loosely > coordinated groups to produce interoperable systems simply by > supporting common, published, contracts. >
A wholehearted +1.
> Sun's use of JSR's to add core functionality, as far as I can see, > goes way beyond the standardization of contracts to include > implementations, and these implementations are often bundled with > Java in one form or another. > > The result is that if you are interested in the contract you don't > need to go elsewhere to find software implementing it, its right > there already, and its free, so why bother? > > As far as I can see Apache's position in the JSR review defends the > right of third parties to be allowed to implement contracts approved > by JSR and adopted by Sun on an equal footing with the JSR's > participants and cash rich commercial organisations. >
While Apache is taking advantage of this with Tomcat and other projects, I'm not sure it is a good thing.
and then Andrew C. Oliver wrote: > Therefore, supporting JSRs where there are already good dominant > Apache projects is against Apache's interest. You either get > sidestepped like the JSP vs Velocity thing or you move the decision > making process into Sun which is apt to happen with Jetspeed.
I don't think the Original proposal for the Portlet API is bad (I don't know yet the outcome of the process). It was a light weight API, modelled after the Servlet API, and offered possibilities for use.
But the whole discussion has been held behind doors. And the process has frozen possible evolutions of the project in the wait (this is possibly a tactical mistake on our part, coupled with one of the main developers being forced to a very difficult position under NDA).
Also, like Danny wrote, the fact that the JSR comes with a RI coming from the outside and "for free", brings a danger to kill possible alternative designs.
All of this kills cyberdiversity. I imagine that it has helped a lot to promote java as a programming platform and make it "feature complete", but the times are coming where it is no longer a good policy.
Just Random Thoughts
Santiago
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
