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...)
geir
On Jun 3, 2005, at 2:22 PM, Tom Tromey wrote:
"Sven" == Sven de Marothy <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
