给JDK提交了一个bug, 然而...

这实际上是去年就踩的一个坑了, 以前又踩到一个相似的, 因而想起在这里来分享一下. 背景是这样的:

咱们的项目依赖于一个外部服务, 该外部服务提供 REST 接口供我方调用, 本地测试和测试环境都没有问题, 可是一上生产环境就发现网络不通. (本地测试/测试环境, 生产环境网络经过不通的域名访问该外部服务), 且在生产环境经过 curl 等命令可以正常调用对方接口. 最终排查缘由出如今域名上, 在生产环境中经过 java 的 httpclient (该第三方包依赖java.net.URI) 调用未发出请求. 该域名形如 http://test_1.tanglei.name

下面来重现一下该案例.

server 端准备

这里用 nginx 模拟了一下 上文提到的 REST 服务, 假设调用正常返回 "Hello, World\n", nginx 配置以下:

server {
    listen    80;
    server_name test_1.tanglei.name;
    location /testurl {
        add_header Content-Type 'text/plain; charset=utf-8';
        return 200 "Hello, World\n";
    }
}

client

curl 命令

curl 请求

请忽略上面的两个重复的header(nginx 默认有一个header, 上面的配置又加了一个), 能够点击这里查看效果 http://test_1.tanglei.name/testurl. （对，我解析了这个域名）

python requests

python 也是调用OK

java

咱们来看一下经过 Java 调用.

上面的这个方法 String getContent(java.net.URL url) 传入一个构造好的 java.net.URL 而后 get 请求, 并以 String 方式返回 response.

String srcUrl = "http://test_1.tanglei.name/testurl";
java.net.URL url = new java.net.URL(srcUrl);
System.out.println("\nurl result:\n" + getContent(url)); // OK

上面的语句输出正常, 结果以下

url result:
Hello, World

换 java.net.URI 试试? (这里不展开讲URL和URI的区别联系了, 能够简单的认为URL是URI的一个子集, 详细的可参考 URI、URL 和 URN, wiki URI)
直接经过java.net.URI构造, 再调用 URI.toURL 获得URL，调用一样正常。关键的来了

URI(String scheme, String host, String path, String fragment)
Constructs a hierarchical URI from the given components.

我用这个方法构造URI, 会构造失败(详细异常信息见文末)。

new java.net.URI(uri.getScheme(), uri.getHost(), uri.getPath(), null) error: protocol = http host = null
new java.net.URI(url.getProtocol(), url.getHost(), url.getPath(), null) error: Illegal character in hostname at index 11: http://test_1.tanglei.name/testurl

因此问题发现了, 咱们的项目中依赖的第三方httpclient包底层用到了 java.net.URI, 刚好在 java.net.URI 中是不容许如下划线(_)做为 hostname 字段的。 即这个表达式 uri.getHost() == uri.toURL().getHost() 不必定成立。这是 JDK 的 Bug 吗？

从官网上还真找到了关于包含下划线做为hostname的bug提交ticket, 戳这里 JDK-8132508 : Bug JDK-8029354 reproduces with underscore in hostname ， 而后发现该 “bug” reporter 的状况貌似跟个人差很少，只不过引爆bug的点不同.

该 “bug” reviewer 最后以 “Not an Issue” 关闭，给出的理由是

RFC 952 disallows _ underscores in hostnames. So, this is not a bug.

确实, rfc952 明确说了域名只能由 字母 (A-Z), 数字(0-9), 减号 (-), 和 点 (.) 组成。

那 OK 吧, 既然明确规定了 hostname 不能包含下划线, 为啥 java.net.URL 确容许呢? 形成 java.net.URI 和 java.net.URL 在处理 hostname 时的标准不一致, 且自己 java.net.URI 在构造的时候也带了 “有色”眼镜, 经过静态方法 java.net.URI.create(String) 或者经过带1个参数的构造方法 java.net.URI(String) 都能成功构造出 URI 的实例，经过带4个参数的构造方法就不能构造了. (同一个url字符串).

要知道, 在 coding 过程当中，尽早反馈异常信息更有利于软件开发持续迭代的过程. 咱们在开发过程当中也应该遵循这一点原则。

JDK(java.net.URL) 中的 “bug” ?

我记得去年我就到JDK官网提交了一个 bug, 大意是说 java.net.URI 和 java.net.URL 在处理hostname的时候标准不一致, 容易使开发人员埋藏一些潜在的bug. 不过当初提交以后就没有反应了。 (为啥没有收到相应的邮件通知 report 状态? 也bug了?)

直到前两天, 又把该问题提交到 stackoverflow.

I am wondering, if hostname with underscore is not valid, why the result is differrent between java.net.URI and java.net.URL? Is it a bug or a feature? Here is the example.

java.net.URL url = new java.net.URL("http://test_1.tanglei.name");
System.out.println(url.getHost()); //test_1.tanglei.name
java.net.URI uri = new java.net.URI("http://test_1.tanglei.name");
System.out.println(uri.getHost()); //null

过了1天才发现原来我去年提交的bug有更新状态了. bug 详细信息见 JDK-8170265 : underscore is allowed in java.net.URL while not in java.net.URI, (openjdk JDK-8170265 更详细）。 然而该 bug 状态也以 “Not an Issue” 了结.
不过其中一个reviewer仍是认可了这个问题, 说的是 java.net.URL 遵循的是 RFC 2396 规范, 确实不容许含有下划线的hostname，java.net.URI 作到了， 而 java.net.URL 没有作到。

As per RFC 2396:
“Hostnames take the form described in Section 3 of [RFC1034] and
Section 2.1 of [RFC1123]: a sequence of domain labels separated by
“.”, each domain label starting and ending with an alphanumeric
character and possibly also containing “-“ characters. The rightmost
domain label of a fully qualified domain name will never start with a
digit, thus syntactically distinguishing domain names from IPv4
addresses, and may be followed by a single “.” if it is necessary to
distinguish between the complete domain name and any local domain.
To actually be “Uniform” as a resource locator, a URL hostname should
be a fully qualified domain name. In practice, however, the host
component may be a local domain literal.”

URI class is following the above, but URL class doesn’t seem to follow the same rules.

To reproduce the issue , run the attached test case.
Following is the output on various JDK versions:
JDK 8 - Fail
JDK 8u112 - Fail
JDK 8u122-ea - Fail
JDK 9-ea + 141 - Fail

重点来了, 而后, 被上一级 reviewer 直接个毙了. 缘由是 java.net.URL 构造方法中，api文档中说了原本也不会作验证即 No validation of the inputs is performed by this constructor. 在线 api doc 戳这里 (能够点链接，进去搜索关键字 “No validation”)

The constructors of URL class (e.g., http://download.java.net/java/jdk9/docs/api/java/net/URL.html#URL-java.lang.String-java.lang.String-java.lang.String-) specifically mention about the validation:

“No validation of the inputs is performed by this constructor.”

So not throwing an exception isn’t an issue here.

其实就算 “No validation of the inputs is performed by this constructor.” 是合理的, 里面也只有3个构造函数有这样的说明，按照这样的逻辑是否是说另外的构造函数有验证呢….. (示例中的默认的构造函数都没有说呀)

这里有java.net.URL 的源码, 看兴趣的同窗能够看看.

恩，以上就是结论了。
不过，反正我本身感受目前Java API 关于这里的设计不太合理, 欢迎你们讨论。(也对SO上某答案表示赞同, 哈哈)

The review is somewhat terse, but the reviewer's point is the URL constructor is behaving in accordance with its specification. Since the specification explicitly states that no validation is performed, this is not a bug in the code. This is indisputable.
What he didn't spell out is that fixing this inconsistency (by changing the URL class specification) would break lots of peoples' 20+ year old code Java code. That would be a really bad idea. It can't happen.
So ... this inconsistency is a "feature".

搞个投票, 说说你的意见?

点击原文连接能够看到本文所附代码.