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<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 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
