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
