JDK-8019345, RFC3986, RFC2396 and java.net.URI

[Peter Firmstone]

They are incompatible.

The existing URI implementation is backward compatible, but its use should be discouraged in new applications, so use diminishes over time.   It's unique to Java.

RFC3986 is good for unique identity and high performance, best for computer processed data, we use it for identity, checking URL strings prior to establishing URL connections, it's also the current standard.

RFC3987 IRI - good for human readability, but not performance, eg manual typing of IRI.

Thinking out loud:
Would a provider mechanism be appropriate, as the existing api is suitable for all implementations?  Serialized form is a simple string, parsed during deserialization, but how to distinguish, or does the provider order choose?

Regards,

Peter.



Sent from my iPhone

> On 12 Nov 2024, at 12:59 AM, Alan Bateman <alan.bateman at oracle.com> wrote:
> On 10/11/2024 12:04, Peter Firmstone wrote:
>> :
>> 
>> Java doesn't implement RFC2396 strictly, as it has an expanded character set that doesn't require escaping and can result in more than one normalized form.   My understanding is its these types of corner cases regarding character escaping are what prevented Java's URI implementation from being upgraded to RFC3986.
> 
> java.net.URI (as opposed to legacy and JDK 1.0 era java.net.URL) rigorously specifies the deviations from RFC 2396, and the reasons for the deviations.
> 
> A big part of the difference between RFC 2396 and 3986 is how the authority component is treated. With RFC 2396 it gets parsed as either a registry-based or server-based authority so very different to the newer RFC.  Relative Resolution (in the new RFC) is another significant difference, if URI were upgraded then its resolve method would produce very different results.
> 
> -Alan.