You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/11/03 09:50:54 UTC

DOMImplementationFactory

Peter,

Given that you cleaned up the standards in this source file ( sorry dude 
;-), does that mean that this is now approved?

Incidentally, I do not think sun should put Crimson in rt.jar for 
JDK1.4.  Age old interface/impl argument.

Regards,

- Paul H


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: DOMImplementationFactory

Posted by Paul Hammant <Pa...@yahoo.com>.
On closer inspection I think this is compete rubbish.  Stand by for CVS 
deletion :-(

- Paul




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Xerces development screwed [ was Re: DOMImplementationFactory ]

Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,

A nice rant, a shame you don't have a wider audience.  When we're all 
using JDK1.4 several teams will have to change their package names just 
so they can continue dev/testing.

Regards,

- Paul H



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Xerces development screwed [ was Re: DOMImplementationFactory ]

Posted by Peter Donald <do...@apache.org>.
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Xerces development screwed [ was Re: DOMImplementationFactory ]

Posted by Paul Hammant <Pa...@yahoo.com>.
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?

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

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  It's not too late the JDK is still in Beta.

Regards,

- Paul H




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: DOMImplementationFactory

Posted by Peter Donald <do...@apache.org>.
On Sat, 3 Nov 2001 19:50, Paul Hammant wrote:
> Given that you cleaned up the standards in this source file ( sorry dude
> ;-), does that mean that this is now approved?

I don't have an opinion really ;)

I would implement it slightly differently though. ie Create a new interface 
like

interface DOMFactory
{
 DOMImplementation getImplementation();
}

because that simplifies the interface and allows people who know about 
DOMImplementation outside of phoenix will work the same as inside.

> 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 ;)

-- 
Cheers,

Pete

*------------------------------------------------*
| The student who is never required to do what   |
|  he cannot do never does what he can do.       |
|                       - John Stuart Mill       |
*------------------------------------------------*

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>