Hi, On Wed, 2003-11-19 at 14:13, Michael Koch wrote: > > --- /var/tmp/PROJECTS/classpath//./java/net/ServerSocket.java Fri Oct 17 > > 19:05:29 2003 > > +++ java/net/ServerSocket.java Wed Oct 22 21:32:21 2003 > > @@ -339,7 +339,8 @@ > > */ > > public void close () throws IOException > > { > > - impl.close (); > > + if (impl != null) > > + impl.close (); > > > > if (getChannel() != null) > > getChannel().close (); > > After thinking about this patch, its more and more bogus in my eyes as > impl never may be null. I provided a better fix to libgcj. When its > approved I will merge it into classpath too.
You are right. I saw your patch on the java-patches mailinglist to make sure impl will never be null. Sorry for not investigation the root cause before committing it. But it looked like having an extra sanity check here wouldn't hurt. I hope to propose a bit more formal patch/commit strategy in the next couple of weeks (like libgcj already has). Now that we are attracting more and more developers with different background it would be nice to have more formal procedure so that a) patches are not lost, b) all patches are actually reviewed. > What would really interest me is the testcase from Guilhem that > triggered this. Yes, that would be nice. I did test it against Mauve with Kissme before checking in (please never check something in if you cannot test it against Mauve and some VM). But since there were multiple tests broken already I hope that I can cleanup Mauve enough before next week (when we will create the 0.07 snapshot release) to activate a autobuilder which we can use to track failures. But Currently Mauve is still to fragile for this. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath