Interesting. Is this RFR a done deal?
While I like the concept and and understand the reasoning of URL not
having a public constructor, I think this may have been thought of in
isolation, I'm not sure how a custom URI, that strictly complies with
RFC 3986 will behave, if it must also be parsed by java.net.URI, which
is loosely compliant with RFC 2396 and RFC 2732. Has anyone done any
investigation? We stopped using java.net.URI some years ago as it's
obsolete. The change will have some performance impact, by requiring
redundant parsing.
Just thought I'd mention it, in case it hasn't been thought of. If you
do an internet search there are other implementations of RFC3986 in java
also.
https://github.com/pfirmstone/JGDMS/blob/e4a5012e71fd9a61b6e1e505f07e6c5358a4ccbc/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L1966
We have a strict URI 3986 implementation, which we use to create all URL
instances from.
This is how we avoid unnecessarily incurring accesses to file systems
and DNS, this implementation had a massive performance and scalability
improvement for us.
/**
* This class represents an immutable instance of a URI as defined by
RFC 3986.
* <p>
* This class replaces java.net.URI functionality.
* <p>
* Unlike java.net.URI this class is not Serializable and hashCode and
* equality is governed by strict RFC3986 normalisation. In addition
"other"
* characters allowed in java.net.URI as specified by javadoc, not
specifically
* allowed by RFC3986 are illegal and must be escaped. This strict
adherence
* is essential to eliminate false negative or positive matches.
* <p>
* In addition to RFC3896 normalisation, on OS platforms with a \ file
separator
* the path is converted to UPPER CASE for comparison for file: schema,
during
* equals and hashCode calls.
* <p>
* IPv6 and IPvFuture host addresses must be enclosed in square
brackets as per
* RFC3986. A zone delimiter %, if present, must be represented in
escaped %25
* form.
* <p>
* In addition to RFC3896 normalization, IPv6 host addresses will be
normalized
* to comply with RFC 5952 A Recommendation for IPv6 Address Text
Representation.
* This is to ensure consistent equality between identical IPv6 addresses.
*
* @since 3.0.0
*/
Regards,
Peter.
On 27/10/2022 3:57 am, Daniel Fuchs wrote:
On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
`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.
I see your point. It may be more appropriate if URI.toURL was designed as
URL.fromURL.
I was wondering to have application developers a consistent way to get an URL
instance. Now there are two methods in different classes URI.toURL and
URL.fromURI. It might be easier to use the old URI.toURL form.
Never mind, it is just my personal preference. It is fine to me to have a new
URL.fromURI method.
One thing we might do is change the name of the method into `URL.of(URI,
StreamHandler)`. It's named `fromURI` merely because there was a pre-existing
package protected `fromURI` method. However since we're making it public now,
it could be fair game to change its name. Possibly adding an overload
`URL::of(URI)` method could be considered, but then there really would be two
paths to do the same thing - so I'd rather not add such an overload - unless I
get some more feedback on that from the CSR/PR review.
-------------
PR: https://git.openjdk.org/jdk/pull/10874
