On Thu, 3 Nov 2022 10:56:28 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
>
> Daniel Fuchs has updated the pull request incrementally with three additional
> commits since the last revision:
>
> - Update src/java.base/share/classes/java/net/URL.java
>
> Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
> - Update src/java.base/share/classes/java/net/URL.java
>
> Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
> - Update src/java.base/share/classes/java/net/URL.java
>
> Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
src/java.base/share/classes/java/net/URL.java line 152:
> 150: * provide any guarantee about its conformance to the URL
> 151: * syntax specification.
> 152: * <p>
I wonder do we need a stronger statement about potential incompatibility here
(line 149 - 151)?
Something to the effect that - due to URI's stricter parsing rules not all
existing URL instances can be represented as URI's and some that are may turn
out to be opaque unexpectedly instead of hierarchical.
-------------
PR: https://git.openjdk.org/jdk/pull/10874
