RFR: 8294241: Deprecate URL public constructors [v2]

[Peter Firmstone]

Some additional information that may be helpful:

org.apache.river.api.net.Uri has method signatures in common with 
java.net.URI, due to its development history.

    The implementation was originally part of Apache Harmony which was
    RFC2396 compliant (Harmony's implementation of java.net.URI), it was
    copied and updated to RFC3986 in Apache River, breaking
    compatibility with RFC2396, both projects are now in Apache Attic
    (no longer under development).   JGDMS (a fork of Apache River, also
    known as Jini donated by Sun Microsystems to Apache) added support
    for RFC5952 and RFC6874. The provenance / development history is known.

    Implementation classes:

    https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/URIEncoderDecoder.java

    https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java

    https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/UriParser.java

org.apache.river.api.net.Uri is not Serializable, however java.net.Uri 
only has one serializable field.

If you wanted to document and understand what RFC3986 breaks in the JDK, 
it would be possible to temporarily copy paste the implementation of 
org.apache.river.api.net.Uri into java.net.URI and run the test suite.

That might assist in deciding whether to update java.net.URI or to 
create a new URI RFC3986 implementation leaving java.net.URI as it is 
and deprecating it.

Regards,

Peter.


On 1/11/2022 8:02 am, Phil Race wrote:
> On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs<dfuchs at 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>>
>>   - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>>   - Merge branch 'master' into deprecate-url-ctor-8294241
>>   - Fix whitespace issues
>>   - 8294241
> Deprecate URL constructors.
> Developers are encouraged to use java.net.URI to parse or construct any URL.
> ...
> To construct a URL, using URI::toURL should be preferred.
>
> You have jumped through some refactoring hoops to be able to apply the deprecation suppression
> to as little code as possible .. having made such changes, then why didn't you just make the
> recommended change instead ?
>
> Should I presume that the recommended route will have some nasty little incompatibilities
> we will need to be careful of first ?
>
> And what about Peter Firmstone's comment
> "We stopped using java.net.URI some years ago as it's obsolete.?"
>
> I can't reconcile that with the recommendation to use it ..
>
> -------------
>
> PR:https://git.openjdk.org/jdk/pull/10874
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221101/62d4f609/attachment-0001.htm>