JDK-8041621 : java/net/Inet4Address/textToNumericFormat.java fails on Solaris and Mac
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-04-23
  • Updated: 2016-07-05
  • Resolved: 2014-04-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u20Fixed 9 b12Fixed
Related Reports
Duplicate :  
JDK-8041622 - InetAddress.getByName incorrectly parses "4294967296"
Relates :  
JDK-8040747 - Improve performance of IP address parsing
Description
A recent change, JDK-8040747, increased the test coverage in this area, and now textToNumericFormat.java can be seen to fail on several platforms, Solaris and Mac, with

java.lang.RuntimeException: Bad Address parsed: [4294967296]
	at textToNumericFormat.main(textToNumericFormat.java:85)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:484)
	at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(M

The source change in JDK-8040747 appears correct, but it also expands the test coverage to include a textual string IPv4 address greater than the allowable max, 4294967296. And it is this that is causing the failure.

The expanded test also fails without the source part of the change, i.e. it fails with JDK 8 FCS.
Comments
Actually, it's debatable whether this is a bug. The question hinges on whether 4294967296 is a valid name for lookup in a name service (such as DNS). DNS allows all labels of a name to be fully numeric except for the top level (eg .com .org) However, resolvers typically allow incomplete names to be be provided to the lookup function, where they append preconfigured suffixes (.eg .foo.com for lookup). In that context, 4294967296.foo.com would be a valid DNS name. It's interesting that on Linux, 4294967296 can be put in the /etc/hosts file and it will return whatever IP address it is configured with. So, I am thinking now - we should resolve this issue by removing this specific (ambiguous) test.
25-04-2014
So, the test is fine and just exposes a long standing parsing bug.
23-04-2014
If the parsing that converts the IPv4 address, in its textual presentation form into its numeric binary form, fails ( IPAddressUtil.textToNumericFormatV4(String) ), then getByName will continue to try to resolve the given string host using the systems native resolver. It would appear that on Mac and Solaris that this does not result in an Exception being thrown. It actually returns 4294967296/0.0.0.0.
23-04-2014