JDK-8019345 & 8294241: Deprecate URL public constructors

[Alan Bateman]

On 10/11/2024 07:05, Peter Firmstone wrote:
> So we have an RFC3986 compliant URI implementation, that's not 
> compatible with Java's RFC2396 URI and now we use deprecated URL 
> public constructors...
>
> But I guess they're only deprecated, not going to be removed, we can't 
> change our code to use RFC2396 URI without unintended 
> consequences...   Having said that, I would discourage developers from 
> writing any new code that uses RFC2396 URI.
>
> My understanding is Java's RFC2396 cannot be changed for backward 
> compatibility reasons, it's not strictly compliant with RFC2396 and 
> varies from the spec with a larger allowed character set (unescaped)...
>
> Perhaps a new RFC3986 URI implementation could utilise a provider 
> mechanism, with some static methods that allow the developer to select 
> which RFC compliant URI version they want to use?
>
> We haven't used Java's URI class for a long time, as there are 
> significant performance benefits to using RFC3986 et al, such as not 
> relying on DNS lookup for identity.

It's probably best to bring discussion about RFC 2396 vs. 3986 to 
net-dev as that is where both java.net.URI and legacy java.net.URL are 
maintained. Also make sure to clearly distinguish the two APIs in any 
discussion as it might confuse lurkers to bring up DNS lookup in the 
context of parsing input as a URI. As regards efforts to move to the 
newer RFC then I think you know the previous effort to upgrade to the 
newer RFC had to be backed out (before the release GA) due to 
compatibility issues. There have been efforts since then, including 
prototyping several API directions. I can't tell if you are asking about 
that or specifically the legacy URL constructors that have been 
deprecated for several releases, so maybe make that clearer in your mail 
to net-dev too.

-Alan