RFR: 8294241: Deprecate URL public constructors [v2]

Jaikiran Pai jpai at openjdk.org
Sat Oct 29 12:05:07 UTC 2022


On Wed, 26 Oct 2022 17:51:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

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

I think `URL.of(URI, URLStreamHandler)` is fine.

As for `URL.of(URI)`, whose implementation I suspect will just do `uri.toURL()` on the passed `URI`, I don't think we need it. It might add to unnecesary confusion on whether/when to use `URL.of(URI)` and when to use `URI.toURL()`

In the case of `URL.of(URI, URLStreamHandler)` it's pretty clear that you use it (only) when you have a specific `URLStreamHandler` to use for the constructed `URL`.

-------------

PR: https://git.openjdk.org/jdk/pull/10874


More information about the serviceability-dev mailing list