--- Patrick Tullmann <[EMAIL PROTECTED]> wrote: > Jukka wrote: > I think the way the libraries have been written to > this point, is to > follow the most recent available spec as much as > possible. I think
Yes, as far as I'm concerned ;) > trying to support different versions of the JDK spec > is probably far > more work than we can do. And, I think postponing there has been demand for different flavors of kaffe's class libraries, i.e. profiles like CDC. That's not too hard to achive as long as the separation happens at the package level. But basic classes like java.lang.Class use reflection to their work, so in the jdk 1.1 case you end up having to include features from 1.2 in your profile, or to hack the sources. Supporting different versions of the spec is a different story, due to bugs in the spec often being only fixed in later versions. So in my eyes it's preferrable to hold on to the latest spec you can get, filling the gaps with the Java Class Libraries books by Chan, Lee & Kramer . > changes that bring > in recent updates is not productive. If an app > doesn't work with > Kaffe because Kaffe's libraries are out of date, > that's a bug. I don't think there is a "postponing new features" policy in place. If you look through the library code, you'll find features from 1.0. to 1.3. Contributions implementing features specified in 1.4 are most welcome . They are also welcome during a "feature freeze" before a release, they just don't get commited immediately ;) > Perhaps its a big bug (like lack of NIO support, or > broken weak > references), but its just a bug. I agree. Contributions fixing these bugs, or implementing java 2d, or swing are most welcome. Or any other jdk 1.4 package we are lacking. The same goes for volunteers wanting to help with the merge of pocketlinux and janosvm fixes. > > Considering the present release is titled "release > candidate", it > > would make sense to allow only patches to critical > problems that > > can't wait. > > Yeah, Dalibor had the same reaction. That's the two > votes I was > looking for. :) (They're both "no" votes in this > case, but that's > fine.) > > I guess we should at least mention the problem in > the Known Bugs > file, then? > FileInputStream does not throw an exception when > passed a > directory (either as a File or a String name of a > directory). Thanks for keeping an eye on these things, I'll add it to the known bugs file on the rc branch. I'll keep it the way it is for trunk, and simply apply the patch as soon as 1.0.7 is out, i.e. soon. cheers, dalibor topic __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
