Gaute Smaaland wrote and asked if he could contribute to java.net. I
asked him to do a comparison between the implementations in Classpath
and the ones in libgcj. I figured since he was an outside party,
he could be neutral in his evaluation. I am including his comments
below for comment. Assuming no major objections, I plan to implement
his merger suggestions. Where necessary, I will copy the best features
of Classpath/libgcj into the merged version (eg. Classpath javadoc
comments). Certainly the choices can be revisited at a future date
if necessary.
Again, the major problem is the native code, where I presume Cygnus
is using CNI and wants to continue to do so. I may defer merging
classes which use native code for the time being.
Here are Mr. Smaaland's comments and a very big Thank You to him
for doing this relatively thankless task.
Comparison libgcj - classpath for the package java.net
java.net.Authenticator : Onlyt exists in classpath
java.net.BindException : Identical, ClassPath more/better comments
java.net.ConnectException : Identical, ClassPath more/better comments
java.net.ContentHandler : Identical, ClassPath more/better comments
java.net.ContentHandlerFactory : Identical, ClassPath more/better comments
java.net.DatagramPacket : libgcj checks arguments for validity, classpath does
not.
The checks done in ligcj concerning offsets and length
should be included (negative offset is
definitely an illegal argument).
I prefer: libgcj.
java.net.DataGramSocket libgjc has not implemented all methods, classpath has,
even though connect() is not operational it seems.
In general, the classpath version is cleaner and more
complete.
java.net.DataGramSocketImpl 100% abstract class, classpath is more appealing,
because of good comments.
java.net.FileNameMap 100% abstract class, classpath is more appealing,
because of good comments.
java.net.HttpURLConnection Two differences that puzzles me: In the libgcj
version, in setFollowRedirects(boolean b), a call to SecurityManager is done for
checkSet,
to me this is far from intuitive, but I'm not sure.
Secondly, libgcj in setRequestMethod, checks whether we are connected prior to
assigning.
I cannot say which is better as I do not know whether
the securitymanager check should be included.
java.net.InetAddress Really liked the caching mechanism of the classpath
implementation, this classpath class seems very strong, and is preferable
to the libgcj version. This comparison should
definitely include some real world testing, but unfortunaltely, i don't have time.
java.net.MalformedURLException No comments. Equal.
java.net.MulticastSocket Again, the libgcj version (this is recurring,
seems to me the developers come from a design-by-contract-environment (which I tend to
like))
checks input arguments heavily (bounds, validity).
Otherwise two similar implementations.
java.net.NetPermission Exists only in classpath
java.net.NoROuteToHostException : Identical, ClassPath more/better comments
java.net.PasswordAuthentication Exists only in classpath
java.net.PlainDatagramSocketImpl Hard to have an opinion on this one, as it is
mostly calls to native code.
java.net.PlainSocketImpl Hard to have an opinion on this one, as it is
mostly calls to native code.
The two above have some things in common. The stream
operations are delegated to SocketOutputstream in the classpath
version, while libgcj works with filedescriptors. I
prefer the classpath design as it is more intuitive.
java.net.ProtocolException Identical, ClassPath more/better comments
java.net.ServerSocket
&
java.net.Socket Differs quite a lot. Classpath makes a call to
SecurityManager both in setFactory and in the constructor,
libgcj only in the constructor. I believe both calls
should be included.
The other differences are details, but reading the
libgcj versions is torture
compared to the classpath versions. (This goes for the
whole package: classpath has excellent comments)
java.net.SocketException Identical, ClassPath more/better comments
java.net.SocketImpl Partly abstract, the implemented methods are
equal apart from toString().
java.net.SocketImpl 100% abstract. Equal.
java.net.SocketInputStream Exists only in classpath.
java.net.SocketOptions Abstract interface. Equal.
java.net.SocketOutputStream Exists only in classpath.
java.net.SocketPermission Exists only in classpath.
java.net.UnknownHostException Equal.
java.net.UnknownServiceException Equal.
java.net.URL -classpath: setURLStreamHandlerFactory does not call
SecurityManager.checkSetFactory
-libgcj:the constructor does not call
SecurityManager.checkPermission
Although the appearance of the two classes differs a
lot, the implementation
are almost identical. Once again I prefer the
classpath version mostly because of its readability.
As for the parsing code, it is hard to say which
veresion is better without some
testing. I go for :Classpath.
java.net.UrlConnection Much like the above comments, calls to
SecurityManager, in addition the private
setContentHandler() method of the libgcj version
contains voodoo code which begs for
testing. I go for :Classpath.
java.net.UrlDecoder Very elegantly done in libgcj, I prefer this
one.
java.net.UrlEncoder Cleaner in classpath.
java.net.URLStreamHandler Boils down to parsing, which looks correct
(did not test this) in both implementations.
java.net.URLStreamHandlerFactory 100% abstract class, classpath is more
appealing, because of good comments.
All in all both implementations are impressing. The Classpath package is in addition
extremely well documented, a fact
that might have influenced me in my work. Great work!
-Gaute Smaaland
Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
