Tony Wu wrote:
Hi Regis
+ // only comparing ASCII, so assume english locale
+ osName = (osName == null ? null : osName.toLowerCase(Locale.ENGLISH));
I believe we have Util.toASCIILowerCase(), it's simpler and faster.
On Fri, Feb 13, 2009 at 3:06 PM, Regis <[email protected]> wrote:
Jim Yu wrote:
2009/2/12 Regis <[email protected]>
Jim Yu wrote:
Hi Regis,
I reproduced this failure on my Linux platform. Since the specs
says SO_REUSEADDR "is used only
for MulticastSockets in java, and it is set by default for
MulticastSockets." So as you said, the default value
I can't find this statement in specs. And at:
You can find the statement in the spec from the description for
SO_REUSEADDR
field of SocketOptions. .
http://java.sun.com/j2se/1.5.0/docs/api/java/net/ServerSocket.html#setReuseAddress(boolean)
it says "Enabling SO_REUSEADDR prior to binding the socket using
bind(SocketAddress) allows the socket to be bound even though a previous
connection is in a timeout state. " and it really affect behaviors of
bind.
for SO_REUSEADDR in ServerSocket which is not defined is reasonable.
IMO,
it
is a non-bug difference between
Harmony and RI.
I incline to follow RI. Because there are already lots of code depends on
RI's behaviors: create a new ServerSocket which reuse address default, no
need to set it explicit.
If Harmony set the default value to false, many applications may not be
able to bind address correctly.
The spec says "the initial setting of SO_REUSEADDR is not defined."
However, it sounds reasonable to follow RI.
2009/1/23 Regis <[email protected]>
did anyone notice the failures on linux? or it just happen on my local
env?
junit.framework.AssertionFailedError: Unexpected exception when
setReuseAddress is the default case and we
bind:Harmony-L3NEK37/127.0.0.1:55891:java.net.BindException: The
address
is not available
at junit.framework.Assert.fail(Assert.java:47)
at
org.apache.harmony.luni.tests.java.net.ServerSocketTest.test_setReuseAddressZ(ServerSocketTest.java:760)
at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
at java.lang.reflect.Method.invoke(Method.java:317)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
I found the default value of ServerSocket.getReuseAddress() on Linux
should
be true, but on Harmony is false, following simple test show this:
ServerSocket serverSocket = new ServerSocket();
System.out.println(serverSocket.getReuseAddress());
and I found it's introduced by commit r723103, and the code set default
value is removed intended, so I think there must be a reason. From
spec,
it's undefined:
When a ServerSocket is created the initial setting of SO_REUSEADDR is
not
defined
So both Harmony and RI are reasonable.
Should we follow RI or mark it as non-bug difference and correct the
test
case?
--
Best Regards,
Regis.
--
Best Regards,
Regis.
I attach a patch for this issue. It test the platform and set SO_REUSEADDR
after ServerSocket created if on Linux.
I don't like this way, because it contains platform depended code in java
code, and I think it's better to do this in native. But ServerSocket and
Socket use the same native method to create socket fd, we can't know the
caller is ServerSocket or Socket.
Do anyone has better ideas?
A natural idea came to my mind, just make another method for
ServerSocket which set the extra options and then call the original
method to create a fd.
It is what old way(before netwok code refactor) did, which use different
implementations, PlainServerSocketImpl for ServerSocket and
PlainSocketImpl for Socket, now they all use PlainSocketImpl. But maybe
I could hack PlainSocketImpl, and add createServerStreamSocket in
INetworkSystem again, just like before refactor.
--
Best Regards,
Regis.
--
Best Regards,
Regis.
