avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Xerces development screwed [ was Re: DOMImplementationFactory ]
Date Sun, 04 Nov 2001 00:06:25 GMT
On Sat, 3 Nov 2001 22:07, Paul Hammant wrote:
> Peter Donald wrote:
> >>Incidentally, I do not think sun should put Crimson in rt.jar for
> >>JDK1.4.  Age old interface/impl argument.
> >
> >I don't think they should put about 90% of the stuff in there that they
> > do. However they do realize that by removing choice from users they get
> > more power over how "standards" evolve. Jdk 1.4 includes several such
> > "solutions" - watch for more in the future for 1.5/tiger release ;(. It
> > gets even worse if you look at J2EE releases. It would not be too hard to
> > see something like struts + parts of taglib included in the j2ee.jar.
> >
> >Combining this with poor implementation of extension mechanisms and some
> >cycnical people would say that it is a cunning strategy for certain aims
> > ;)
>
> Can we do something like get a petition going?

petitions actually working on Sun? Do you also believe in the tooth fairies ? 
;)

> One any package structure is in the rt.jar, it's development is
> essentially halted or pointless in incraments quicker than JDK releases.

right and you have one company that dictates when API is released, under what 
license it is released and whether or not you have to pay for it etc.

> Sun could package several *non* *sun* APIs in seperate jars that the
> executable loads by default but a special option "-noload xerces;xalan"
> could switch this off for those who wanted to be bleeding edge and have
> them back in the classpath 

Alternatively they could set up a decent shared library system, similar to 
what almost every other platform has. They can easily learn from mistakes of 
past but instead they seem doomed to repeat em.

However many of the engineers at sun that I have talked to think it is a good 
thing that all these libraries are included and that you get no choice in 
implementations. The reasons they give are usually
a) you may need library X one day
b) it is better to have one library which can improve each JDK version rather 
than multiple implementations

It will be interesting to see how Sun/Java fairs over next few years. They 
still think like a hardware company, they are slow, react to the environment 
and have repeatedly screwed over developers in favour of users. Compare this 
to MS who are relatively agile, initiate changes in environment and see 
developers as one of the 4 pillars on which to build an empire ;) Now who 
would you put your money on given this ?

If it had not of been for IBM lending legitimacy to java, java would have 
never gone anywhere. Its a bit different now as java is largely respectable 
and with J2EE in place many big buisnesses will make the switch.

Whats interesting is that *supposedly* IBM has been working on a VM for the 
.NET platform (forget what it is called ... CLR + RTI ????). I have also 
heard that they have java working on this platform. Now if this is true (and 
Im not sure it is) then it would be interesting to see how things evolved for 
java after that. Especially if they OSed it (which IBM have a tendency to do 
with experimental JVMs etc).

> It's not too late the JDK is still in Beta.

unfortunately it is way too late for this iteration. They don't change much 
in beta if they can help it. Even those changes they do make is only after 
heavy wrangling or so I am told 8)

-- 
Cheers,

Pete

-----------------------------------------------------
First, we shape our tools, thereafter, they shape us.
-----------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message