>>>>> "Dalibor" == Dalibor Topic <[EMAIL PROTECTED]> writes:
Dalibor> Given that classes outside JAXP (beans, imageio) depend on Dalibor> it, I'd be for making GNU JAXP (or another JAXP Dalibor> implementation, if necessary) a hard requirement. Me too, for the same reasons. It is just like the PKI thing Casey asked about last week. Classpath's core has to be self-contained, meaning all dependencies have to be integrated. Dalibor> If someone really needs a JDK 1.0 subset of Classpath, they'll have to Dalibor> put enough work into rewriting the core classes anyway that it would Dalibor> warrant a fork, in my opinion. If someone just needs a simple way to Dalibor> jar a subset of classes in the build, then that should be fairly Dalibor> trivial to implement. I think that things like J2ME and the various small profiles exist because the reference implementation is not free software. We can do better than that. For instance, someone could write a tool to cut down the class library to custom-fit your application. Or we could mark up the library source with Classpath-specific 1.5 attributes that end up in the class files, and that are used to remove parts of the classes later on. (There are probably lots of cool things we could do with attributes, something worth brainstorming about.) I know this approach avoids some of the things needed for real compatibility, for instance when semantics change over time. But is anyone really clamoring for JDK 1.0 compatibility? My impression is that when this has come up on this list it is just as a way to get a release out that has 100% compatibility with *something* -- but for me that is not an interesting end in and of itself. In fact, I think a release that is compatible with just JDK 1.0 is kind of laughable at this date. Tom _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
