harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr. <ge...@apache.org>
Subject Re: ClassLib implementations WAS some ideas
Date Sun, 05 Jun 2005 09:28:46 GMT
I suspect the motivation behind the original post by Peter was more  
about formal modularization of the class library than general java  
package separation.  I think that there has been some good work in  
this area in other places, such as larger scale J2EE systems via OSGi  
or -ish.  Certainly modularization of the class library is in scope  
here (I think...)


On Jun 3, 2005, at 2:22 PM, Tom Tromey wrote:

>>>>>> "Sven" == Sven de Marothy <sven@physto.se> writes:
> Sven> Depending on non-public parts of other API packages is to be
> Sven> avoided as far as possible. And if there is Classpath-specific
> Sven> behaviour in the public API, then that is likely a bug. (or the
> Sven> absence of a Sun bug)
> One thing I've seen in user code is that it sometimes incorrectly
> depends on properties of a particular implementation.  E.g., more than
> once I've run across Comparable implementations which are not
> symmetric, but which "work" because Sun's collections classes compare
> in a certain order.
> It isn't impossible that Classpath has some kind of subtle dependency
> like this somewhere.  However, stuff like that, if it even exists,
> would just be a bug.
>>> i.e. how possible would it be to use say java.sql.* with another
>>> implementation of java.lang?
> Sven> Why wouldn't it be possible? It'd be horrible coding if it were
> Sven> any other way.
> Totally agreed.  Most code in Classpath doesn't use native code, or VM
> code, or anything but the public API of classes in other packages.
> Tom

Geir Magnusson Jr                                  +1-203-665-6437

View raw message