org.jnode.net.ipv4.IPv4Address class

Submitted by markhale on Wed, 02/18/2004 - 20:02.

JNode-Net

Having used this class a few times, I would like to suggest/discuss possible tighter integration with java.net.Inet4Address. I see two ways to do this:
1) subclassing by making Inet4Address non-final.
2) moving methods to Inet4Address.

I believe it will be necessary to do a mixture of both. Although this requires making changes to the GNU classpath Inet4Address source, the public API should be uneffected. In fact, some minor integration could be done without source changes by moving IPv4Address to the java.net package so it has access to Inet4Address's protected methods. The benefit of all this would be to simplify programming by removing the need for conversions between IPv4Address and Inet4Address.

IPv4Address -> Inet4Address

Submitted by markhale on Thu, 02/26/2004 - 15:40.

If there are no objections, I would like to do the following:

Create static equivalents of the instance methods in IPv4Address, which work directly with Inet4Address objects. E.g.

public static Inet4Address readFrom(SocketBuffer skbuf, int offset)

public static void writeTo(SocketBuffer skbuf, int skbufOffset, Inet4Address address)
Deprecate the instance methods.
Update net package to use Inet4Address objects rather than IPv4Address.

There are objections

Submitted by admin on Thu, 02/26/2004 - 18:44.

Hi,

The problem is that for the net framework to be nicely extendable to anything other then tcp, the ProtocolAddress was introduced as base class. Since we cannot extend Inet4Address from another class (ProtocolAddress) without breaking the java compatibility we need this other class.

Swap ProtocolAddress for InetAddress

Submitted by markhale on Sun, 02/29/2004 - 14:57.

Here is yet another suggestion. Why not use InetAddress as the base class instead of ProtocolAddress? Since there is a ProtocolAddress.toInetAddress() method, any subclass of ProtocolAddress has to be able to turn itself into an InetAddress subclass. If it can do that, it can just as easily extend InetAddress directly.

ProtocolAddressHelper

Submitted by markhale on Thu, 02/26/2004 - 20:14.

I think it is still possible to maintain extendability by adopting a different approach. Instead of the address classes directly implementing ProtocolAddress, one could have a lookup mechanism to find a "ProtocolAddressHelper" for a given address class.

I still don't understand what you mean by "breaking Java compatibility" if we extend Inet4Address. I checked the lang. spec.:

13.4.2 final Classes
If a class that was not declared final is changed to be declared final, then a VerifyError is thrown if a binary of a pre-existing subclass of this class is loaded, because final classes can have no subclasses; such a change is not recommended for widely distributed classes.

Changing a class that was declared final to no longer be declared final does not break compatibility with pre-existing binaries.

Although, I think it might be more appropriate to subclass the other way round, that is Inet4Address extends IPv4Address extends InetAddress. This would also not break binary compatibility.

Why

Submitted by admin on Thu, 02/19/2004 - 06:22.

Hi Mark, I don't understand why this is necessary. Also we should avoid changing the java.* classes as much as possible, because (1) it breaks java compatibility and (2) it is not allowed.

Which class to use when

Submitted by markhale on Thu, 02/19/2004 - 20:53.

I just find it a bit disconcerting having two ipv4 container classes. I've used IPv4Address for most of the stuff I've done so far, but I could have equally done it with InetAddress. Should I be preferring one class over the other? I think all the methods in IPv4Address could be made static, operating on Inet4Address objects. This would be another way to just have one container class.

Re: (1), I don't understand why, for instance, making Inet4Address non-final would break Java compatibility. I should still behave like final to the outside world. Just internal to jnode, it will be non-final, an undocumented API hook if you like. Re: (2), Why wouldn't such changes be allowed? GNU Classpath is under GPL,so there should be no obstruction...

Oh, here's another possibility. Create a java.net.VMIPv4Address wrapper class for Inet4Address. Since it is in the same package, VMIPv4Address could publicly expose the protected methods in Inet4Address.