Java 17 depends on DNS lookups for hashing a web URL

[sandGorgon]

https://twitter.com/floydophone/status/1469775366562541571

[brunoborges]

This was discussed over and over, including here on HN in 2019. [1]

java.net.URL was introduced in Java 1.0, the very first public release of Java back in 1996.

In 2001, Java 1.4 included a new class java.net.URI that addressed this and other improvements.

Since then, it is well known by average experienced Java developers to a) read javadocs, b) not use URL class, and c) use URI.

It's been 19 years this problem has been fixed.

As to why not remove it, I'd suggest to dig through the OpenJDK mailing list.

[1] https://news.ycombinator.com/item?id=21765788

[sandGorgon → brunoborges]

>Since then, it is well known by average experienced Java developers to a) read javadocs, b) not use URL class, and c) use URI

P.S. not trying to flame here.

so im looking here https://docs.oracle.com/en/java/javase/17/docs/api/java.base... and I couldnt see any place where it is specifically recommended to NOT use java.net.url and instead use java.net.URI

thinking from the perspective of someone new to Java.

Also when i search for "java url class" on Google...i only see java.net.url

[EvanKnowles → sandGorgon]

Yeah, my team of experienced devs were all surprised by this. To the source they went, and found it was true. Not that we'd generally end up hashing a URL, but still.

[fistynuts → brunoborges]

It's been 19 years since this problem has been fixed and yet the bad code is still there.

[brunoborges → fistynuts]

I'd suggest you assess first the amount of code that depends on java.net.URL both in Java SE itself and then in the ecosystem, before you can say it would be "easy" to remove java.net.URL.

Hint: same reasons java.util.Date, and java.util.Vector are still there.

[londons_explore]

The implementation isn't even really correct...

Given a bunch of URL's, they may have a colliding hashcode just because they resolve to the same IP address. For example because they are all cloudflare websites that resolve to the same cloudflare endpoint.

[sandGorgon → londons_explore]

yes. that is specifically what Google pointed out. this behavior is disabled on android.

https://github.com/AndroidSDKSources/android-sdk-sources-for...

[armchairhacker]

also does a DNS lookup for URL equality, and equality can change depending on whether or not you’re connected to WiFi.

I got this from an earlier HN post. Apparently it’s a relic of old Java and they can’t change it for some compatibility reason (?)

[winrid → armchairhacker]

They almost never break backwards compatibility, even if the legacy functionality is insane.

In this case, I do see it probably moving to behind some configuration flag at some point.

[sandGorgon → armchairhacker]

android code specifically disables this.

[pjmlp → sandGorgon]

I am waiting for the day Java compatibility is declared officially dead and is Kotlin all the way down across the AOSP codebase.

[syspec]

Here's the code in question: https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/c...