java.net: Classpath vs. libgcj Comparison

[Anthony Green <green at cygnus dot com>]

FYI...

------- Start of forwarded message -------
Date: Sun, 16 Apr 2000 18:49:36 -0500
From: "Aaron M. Renn" <arenn@urbanophile.com>
To: classpath@gnu.org
Cc: gs@sevenmountains.no
Subject: java.net: Classpath vs. libgcj Comparison
Mail-Followup-To: classpath@gnu.org, gs@sevenmountains.no
Content-Type: text/plain; charset=us-ascii
Organization: GNU's Not Unix!
Resent-From: classpath@gnu.org
X-Mailing-List: <classpath@gnu.org> archive/latest/2159
X-Loop: classpath@gnu.org
Precedence: list
Resent-Sender: classpath-request@gnu.org

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 (arenn@urbanophile.com) http://www.urbanophile.com/arenn/
------- End of forwarded message -------