This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: YA Socket timeout patch
- From: Nic Ferrier <nferrier at tf1 dot tapsellferrier dot co dot uk>
- To: java-patches at gcc dot gnu dot org
- Date: Sun, 16 Dec 2001 23:34:12 +0000
- Subject: Re: YA Socket timeout patch
>Perhaps this approach is not without merit, however it deviates from the
>convention followed elsewhere in classpath. If you want to change it,
>you'd really have to take up the issue on classpath@gnu.org.
Hmmm... I don't think the Classpath project is the arbiter of these
decisions. That's why we setup the javaweb-people list. It's for inter
project issues like this.
I might well raise it there... more and more I am being asked what the
GNU project's coding standards are, I might have to add them to the
existing document, consensus is obviously needed before that happens.
Bryce said (of initializing variables):
>I don't agree. In this case there is no superclass that is going to mess
>with the value, it is safe and more efficient to not explicitly
>initialize it. I'd prefer if you removed them.
Safer to not initialize? How can it be safe to not initialize? I don't
understand your issue here really, if it does cause increased size
it's only tiny... Surely it's better to have explicit initialization
and pay for the very small increase?
Bryce said (of final vs native for inner class methods):
>OK. (btw "final" probibly wont make any difference to efficiency because
>it will be a virtual call anyway, but there is no harm in specifying
>it).
Of course. But it will give GCJ the opportunity to optimize it. The
methods should be final anyway, it's a class that user's shouldn't be
able to override.
>Also, you still have a redundant check for errno == ECONNRESET in the
>read() methods?
Ok. I'll fix that.
Nic