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