<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>When Java 9 was released, our use of RFC3986 meant that modules
with jrt:/ URL's were supported out of the box, as it was
compliant with the same configuration files running on Java 8,
even though we weren't loading these files. Had we used URL
without a jrt provider, it would have caused runtime failures.<br>
</p>
<p>Reading OpenJDK code, I see that CodeSource has been replaced
with CodeSourceKey or similar in various places replacing URL's
with a semi normalized string or unmodified string form.</p>
<p>When the class below was written, SecureClassLoader still used
CodeSource as a key, now it uses a string, however the URL string
has been RFC3986 normalized, so String comparison is still valid.<br>
</p>
<p><a
href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/RFC3986URLClassLoader.java">JGDMS/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/RFC3986URLClassLoader.java
at trunk · pfirmstone/JGDMS</a></p>
<p>JGDMS loads classes from many places, eg local file system, local
network, IPv6 global network, JGDMS requires end to end
connectivity, so only supports IPv4 on local networks, however we
need consistent normalized form for IPv6. <br>
</p>
<p>Our RFC3986 Uri implementation has a few methods to fix common
issues with malformed URL's, such as those with escaped characters
that shouldn't be escaped, or characters that aren't that need to
be etc, we use it to clean up file paths or url's prior to opening
a file or making a url connection.<br>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter</pre>
<div class="moz-cite-prefix">On 13/11/2024 7:13 am, Peter Firmstone
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:07C84457-D501-492B-AD8B-4260830A9D61@zeus.net.au">
<pre wrap="" class="moz-quote-pre">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
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">On 12 Nov 2024, at 12:59 AM, Alan Bateman <a class="moz-txt-link-rfc2396E" href="mailto:alan.bateman@oracle.com"><alan.bateman@oracle.com></a> wrote:
On 10/11/2024 12:04, Peter Firmstone wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">:
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.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
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.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
</pre>
</blockquote>
</body>
</html>