java.net.InetAddress

Sat Jun 21 12:10:00 GMT 2003

> This line is surely be wrong. It should read like follows:
>> 192.168.0.2 linuxpresario.mydomain.com linuxpresario

I'm not an exegete on network issues, so my objections are definitely not
authoritative.
But would it make sense to say that such entry could potentially (in
particular circumstances) conflict with dhcp-assigned numbers? What if I transient
network conditions lead to the inability to obtain a valid ip quad? Would all
machines with such entry advertise that they are the legitimate holder of ip quad
"192.168.0.2"? Would that possibly create havoc on the network? Would that not
potentially be worse than having no ip quad assignment at all?
> We can only imitate JRE behaviour, not guess what the user/developer 
> of the software means. I've found no library for mind-reading on the 
> web yet. Perhaps some day ...
> For the Win32 port we have to wait for Mohan. He does this port. And 
> if he says SUNs JRE behaves the same as our implementation I'm okay 
> with it. I think some parts are still missing in the Win32 port.

I really wasn't criticizing the GCJ team.
I think the GCJ has done a great and very respectable job! And indeed I don't expect
any of the people on the team to start mind-reading. It's not that I think that Mohan
has an obligation to me or anybody else to do any work on the win32 port!
I just feel that I cannot rely on the exact content of the /etc/hosts file on linux
or the equivalent file on win32. These machines may be a bit misconfigured (I really
can't judge that), but this misconfiguration is so common that I have to accept it as
being a normal operating condition -- from any practical point of view.
Almost any client machine that I could conceivably deploy on, will get it's
authoritative ip quad from a dhcp server somewhere.
> It would be great if you could test your application with SUNs latest 
> JRE to look what it does.

Both the java2/1.4.1 implementation on linux/Mozilla as the MsJava1 implementation on
win2k/IE return "127.0.0.1" to the question
InetAddress.getLocalHost().getHostAddress(). So I don't think there is anything wrong
with GCJ doing the same.
As I read it, the JRE doesn't want to advertise the actual machine's IP address for
security reasons; unless it's signed; even though there is a workaround
(socket.getLocalAddress().getHostAddress()) that will reveal it to the applet anyway.
You can find an example of this workaround at
http://www.u.arizona.edu/~trw/games/nat_or_not.php. So far, so good for the JRE
security manager and all this silly confusion. I assume GCJ will attempt to be
bug-for-bug compatible with all of this.
I personally try to avoid deploying software that relies on such brittle foundations
(applets, mobile code, security manager, jre, ...). Instinctively, I feel it will
invariably come back to haunt me... 
I just wish that people who don't need or otherwise elect to stay away from this
circus, wouldn't be required to pay the price for it.