Hi, On Tue, 2005-05-10 at 15:00 +0200, Matthew French wrote: > Basically you have this API with lots of function calls, many > unimplemented. Trying to pin the libraries to a particular version is > almost impossible, so the result is developers implement the library calls > when they find a program that uses them. This also makes it easer to test, > since you now have a test case to compare to. > > I am guessing the Classpath project has the same issue. Is it really > practical (right now) for an open source java library to be 100% compliant > with J2SE 1.3/4/5?!? Would it not be more pragmatic to allow people to add > the features they need?
This is indeed how we handle the issue in GNU Classpath at the moment. We are targetting full 1.4 in general, but only have full 1.0 and 1.1 coverage. The actual coverage is somewhere between 1.2 and 1.4 depending on package and class. Kaffe has a list for their implementation: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-kaffe.html We do have a separate CVS development branch for the new generics support in 1.5 that we hope to merge in as soon as all free compilers and runtimes properly support the new 1.5 language features. > I am sure the Classpath people have experience with out-of-sync API's. > Just how much of a problem is this? If a large application like JBoss can > run successfully, how much of an issue is it that we are missing 15% of > the functionality? Or that we have 1.6 functionality polluting a 1.3 base? It is largely a non-problem. People want their programs to work. So either they use the available functionality and everything just works, or they use functionality that isn't available yet and it just doesn't work. We try to encourage people to just use the functionality that is available by using a free platform like gcj or kaffe for all their development. Then it will automatically work on any platform. But it is a problem for someone that buys a book in a store about java and expects everything described in the book to just work. That is of course a real problem. That is why GCJ, Kaffe and GNU Classpath are not java (yet?). Cheers, Mark
signature.asc
Description: This is a digitally signed message part
