javax.naming work (Classpath vs ClasspathX)

Sun Oct 21 15:29:00 GMT 2001

Hi,
On Sat, Oct 20, 2001 at 10:42:34PM +0100, Nic Ferrier wrote:
> >>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:
>> Mark> Actually the distinction is not about java.* vs javax.*. The GNU
> Mark> Classpath project was setup to give us a set of free standard
> Mark> java library classes. So in principle all standards defined by
> Mark> what Sun calls J2SE (Java 2 Standard Edition) will become part
> Mark> of Classpath (some day). Whatever package they are in.
>> Actually I disagree with this.
>> I think Classpath should exist to do the core language classes. 
>> GNU projects should not become slaves to Sun marketing strategy
> because that's all that decides what classes go into what
> distribution.
That is true. People should feel free to mix and match whatever "standard"
packages they feel make the most sense.
 
> 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.
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.
Of course we must make sure that if some classes or packages can be used
logically in isolation of the rest of the library that we then make it
possible to build only that part of it in a seperate library (jar). But I
think that can be better done while having one source tree and not by having
multiple source trees for every subpackage. libgcj tries to do the same
with their separation in core-classes, awt-classes, rmi-classes, etc.
Cheers,
Mark
-- 
Stuff to read:
 < http://www.toad.com/gnu/whatswrong.html >
 What's Wrong with Copy Protection, by John Gilmore