If you try to create a multicast InetAddress using InetAddress.getByName e.g.

  InetAddress.getByName("224.0.0.1")

you'll get an UnknownHostException. This used to work ok in earlier
versions of the JDK. It looks like you can't create an InetAddress unless
it corresponds to some hostname. Multicast addresses never do so you
can't create them.

The description field as copied from bug report 1262624 follows:

This
1) is a duplicate of bug 1253518
2) has been fixed in 1.1 for a while

-brown



The behavior of InetAddress.getByName is different between Solaris, Win32, and Mac
versions of the jdk1.0.2. This must be fixed.

THE CODE:

import java.net.*;

public class NetTest {
   NetTest () {}

   public static void main (String argv[]) {
    try { System.out.println(InetAddress.getByName("samnkona.eng.sun.com"));
} catch (Exception e) { System.out.println("one"); }

       try { System.out.println(InetAddress.getByName("129.144.173.103"));
  } catch (Exception e) {System.out.println("two"); }

try { System.out.println(InetAddress.getByName("129.144.173.150"));
} catch (Exception e) {System.out.println("three"); }
   }
}


THE RESULTS:

SunSolaris:
samnkona.eng.sun.com/129.144.173.150
129.144.173.103/129.144.173.103
129.144.173.150/129.144.173.150

Win32:
samnkona.eng.sun.com/129.144.173.150
two
129.144.173.150/129.144.173.150

Mac:
samnkona.eng.sun.com/129.144.173.150
129.144.173.103/0.00.29
129.144.173.150/129.144.173.150




This test was a response from the following mail to fp.bugs.

>From: "Stephen R. Pietrowicz" <###@###.###>
This does not look like form output to me.


I submitted a bug report against 1.0.1's networking code. It was fixed
under UNIX, but the fix was not applied to Win95/WinNT. I suspect the
problem may exist under Mac as well, since this is a fix that has to
be applied to the native library code.

Here's a description of the problem that I submitted before:

--------
 
Basically, if you do:
                
                InetAddress.getByName("141.142.2.2");
 
using some internet address (that one above is newton.ncsa.uiuc.edu)
other than the machine you are running the test on, and exception is
thrown.
 
I just spent a few minutes looking for this, and found the problem.
 
The problem is that the native library routine that handles the lookup.
The routine getAllByName eventually will call the lookupAllHostAddr()
method, which turns into the native call:

 java_net_InetAddress_lookupAllHostAddr()
 
That call throws an exception if it sees a digit in the first place of a
host's name:
 
>From socket.c in src/solaris/net:
 
    javaString2CString(host, hostname, sizeof (hostname));
    if (isdigit(hostname[0])) {
        SignalError(0, JAVANETPKG "UnknownHostException", hostname);
        return 0;
    } else if ((hp = gethostbyname(hostname)) != NULL) {
 
 
In the routine, java_net_InetAddress_lookupHostAddr(), it's handled
correctly:
 
    javaString2CString(host, hostname, sizeof (hostname));
    if (isdigit(hostname[0])) {
        /*
         * This is totally bogus. inet_addr returns a 4-byte value
         * by definition, thereby making the transition to 64-bit IP
         * addresses much harder. It should instead write into a
         * user-supplied "struct in_addr"! We'll deal with this
         * later when 64-bit IP addresses are more of a reality -
         * csw.
         */
        unsigned long iaddr = inet_addr(hostname);
 
[stuff to check and copy the iaddr deleted]
 
As the comment says, once 64-bit addresses are around, this has to be
revisited, but if java_net_InetAddress_lookupAllHostAddr() would
attempt to decode the hostname using inet_addr, it will fix the bug
until the net goes 64-bit.

------------
This same code exists under win32/net/socket.c. As I said, the fix
was applied to UNIX, but it wasn't applied to Windows 95/NT.

Thanks for fixing this. This craters our stuff right now, and we're
attempting to get a workaround together before our announced release of
our project.

Steve

--

fyi. The bug id 1243494 was assigned to Steve's first report of the problem