RFR: 8294241: Deprecate URL public constructors

Wed Oct 26 22:53:52 UTC 2022

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.
  * 
  * This class replaces java.net.URI functionality.
  * 
  * 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.
  * 
  * 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.
  * 
  * 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.
  * 
  * 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 <xuelei at 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