为什么java.net.URL的哈希码将主机解析为IP？

Question

第一个决议之后的想法是否依赖于操作系统缓存？这似乎效率低下,并且在多个域解析为相同IP的情况下,这是不正确的.我错过了什么？

Answer 1

为什么java.net.URL的哈希码将主机解析为IP？

有两个原因.首先是:

• 在URL类的行为被设计成一个URL为网络访问资源的定位模型.具体而言equals,如果它们找到相同的资源,hashCode()则设计为使两个URL实例相等.这要求将DNS名称解析为IP地址.

事后看来,我们知道以下内容:

1. 该URL.equals方法不能¹可靠地确定两个URL字符串是对同一资源定位器.原因包括虚拟主机,HTTP 30x转发和URL的服务器内部映射等.

2. 对于没有经验的Java程序员来说,IP解析行为URL.equals并且URL.hashcode是一个陷阱,尽管它已被清楚地记录下来.

3. 即使在导致正确答案的情况下,IP分辨率URL.equals也可能是意外(和不需要的)性能损失.

简而言之......设计的那个方面URL是错误的.

这带来了第二个更重要的原因.

• 行为是URL.equals(Object)在很久以前定义的,如果不打破(可能)数百万个已部署的Java应用程序,现在就无法进行更改.这排除了Sun(现在的Oracle)将改变它的任何可能性.

也许Java类库的(假设的)继承者的设计者可以解决这个问题(以及其他问题).当然,为了实现这一点,必须抛弃与现有Java程序的向后兼容性.

最后,Java应用程序开发人员的真正答案是简单地使用URI类.(真正的软件工程就是尽可能地完成工作,而不是抱怨你提供的工具.)

^{1 - 当我说"不能"时,我的意思是理论上不可能.处理一些更困难的情况需要更改HTTP协议.即使假设的HTTP 2.0"修复"了这个问题,我们仍然会在20年内处理遗留的HTTP 1.1服务器...... URL.equals因此仍然会被打破.}

Answer 2

很多人认为这是一个非常糟糕的主意.

这是来自URI的Javadoc的一些解释.这个问题也很有用.

Answer 3

hashCode()密切相关equals()。文档中对此行为的解释如下equals()：

如果两个主机名可以解析为相同的 IP 地址，则认为两个主机是等效的；否则，如果任一主机名无法解析，则主机名必须相同，无论大小写；或者两个主机名都等于​​ null。

来源：java.net.URL.equals()文档。