The URL class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. This has lead to many usability issues, sometimes even to vulnerabilities when the calling code did not take this into consideration.

Indeed, if used improperly, there is no guarantee that URL::toString or URL::toExternalForm will lead to a URL string that can be parsed back into the same URL, which can lead to constructing misleading URLs. Another issue is with equals() and hashCode() which may have to perform a lookup, and do not take encoding/escaping into account.

In Java SE 1.4 a new class, java.net.URI, has been added to mitigate some of the shortcoming of java.net.URL. Conversion methods to create an URL from an URI were also added. However, it was left up to the developers to use java.net.URI, or not.

This RFE proposes to deprecate all public constructors of java.net.URL, to provide a stronger warning that these constructors can be misused. To construct a URL, using URI::toURL should be preferred.