On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
> to parse or construct any URL.
>
> The `java.net.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 issues in the past. 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. This 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 a URL from
> a 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`, in order to provide a stronger warning about
> their potential misuses. To construct a URL, using `URI::toURL` should be
> preferred.
>
> In order to provide an alternative to the constructors that take a stream
> handler as parameter, a new factory method `URL::fromURI(java.net.URI,
> java.net.URLStreamHandler)` is provided as part of this change.
>
> Places in the JDK code base that were constructing `java.net.URL` have been
> temporarily annotated with `@SuppressWarnings("deprecation")`. Some related
> issues will be logged to revisit the calling code.
>
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
The change to security-related code looks fine to me.
-------------
PR: https://git.openjdk.org/jdk/pull/10874
