On Wed, 26 Oct 2022 17:09:20 GMT, Xue-Lei Andrew Fan <xue...@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
>
> src/java.base/share/classes/java/net/URL.java line 852:
>
>> 850: * @since 20
>> 851: */
>> 852: public static URL fromURI(URI uri, URLStreamHandler streamHandler)
>
> What do you think to have this method in URI instead:
> URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?
`URLStreamHandler` really belongs to `java.net.URL`, and is an implementation
detail of the infrastructure/SPI that makes it possible to eventually call
`URL::openConnection`. I do not think it would be appropriate to have such a
method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and
is not something that a regular developer will need to do, and it is better if
it isn't too prominent.
-------------
PR: https://git.openjdk.org/jdk/pull/10874
