javax.naming work (Classpath vs ClasspathX)
Nic Ferrier
nferrier@tf1.tapsellferrier.co.uk
Mon Oct 22 04:34:00 GMT 2001
Nic said:
> There is a clearly logical separation between java.* and
> javax.*. Classpath should do java.* and a few javax.* things (like
> swing, because it's so machine specific) and ClasspathX should do all
> other extension implementations.
Mark replied:
>But here I disagree. The GNU Classpath project is setup to provide
>all the standard java class libraries. I don't see why we should put
>some of standard classes in another project just because they are in
>another package. If people expect to have some classes standard
>available then the Classpath project should provide them.
>I would even go so far as to say that if at some point some
>classes/packages become a standard that people expect to find
>available in any implementation that implements the Java
>Specification (such as for example to JAXP classes) which were just
>experimental in the past then we should make them part of the
>standard Classpath project.
The Classpath project is never going to be the sort of thing a user
just downloads.
The Classpath project is mainly a downstream supplier of class
librarys to VM implementations.
As such the Classpath project exists to manage the development of
that code base.
The ClasspathX project is also a downstream supplier of class libs to
VM implementations.
The two projects are separate because it's easier to organise
resources that way.
Nic Ferrier
PS Sorry some of my responses are a bit delayed. I've just become a
dad!
More information about the Java
mailing list