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]
