6 ms·

Java 17 depends on DNS lookups for hashing a web URL

28 points by sandGorgon 5y ago

syspec 5y ago
Here's the code in question: https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/classes/java/net/URL.java#L874 https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/c...
armchairhacker 5y ago
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 (?)
- sandGorgon 5y ago
  android code specifically disables this.
  - pjmlp 5y ago
    I am waiting for the day Java compatibility is declared officially dead and is Kotlin all the way down across the AOSP codebase.
- winrid 5y ago
  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.
londons_explore 5y ago
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 5y ago
  yes. that is specifically what Google pointed out. this behavior is disabled on android. https://github.com/AndroidSDKSources/android-sdk-sources-for-api-level-31/blob/master/java/net/URL.java#L850 https://github.com/AndroidSDKSources/android-sdk-sources-for...
brunoborges 5y ago
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 https://news.ycombinator.com/item?id=21765788
- fistynuts 5y ago
  It's been 19 years since this problem has been fixed and yet the bad code is still there.
  - brunoborges 5y ago
    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.
- sandGorgon 5y ago
  >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/java/net/class-use/URL.html 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 5y ago
    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.

28 points by sandGorgon 5y ago

Here's the code in question: https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/classes/java/net/URL.java#L874 https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/c...

armchairhacker 5y ago

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 (?)

sandGorgon 5y ago
android code specifically disables this.
- pjmlp 5y ago
  I am waiting for the day Java compatibility is declared officially dead and is Kotlin all the way down across the AOSP codebase.
winrid 5y ago
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.

londons_explore 5y ago

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 5y ago
yes. that is specifically what Google pointed out. this behavior is disabled on android. https://github.com/AndroidSDKSources/android-sdk-sources-for-api-level-31/blob/master/java/net/URL.java#L850 https://github.com/AndroidSDKSources/android-sdk-sources-for...

brunoborges 5y ago

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 https://news.ycombinator.com/item?id=21765788

fistynuts 5y ago
It's been 19 years since this problem has been fixed and yet the bad code is still there.
- brunoborges 5y ago
  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.
sandGorgon 5y ago
>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/java/net/class-use/URL.html 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 5y ago
  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.