[concurrency-interest] URI + RFC3986 compliance

[Michael Kay]

+1.

As the author of a library that uses the URI class, I need control over how it is behaving, and I cannot assume that other libraries in the same VM want the same options as I do.

Michael Kay
Saxonica
mike at saxonica.com
+44 (0118) 946 5893



On 9 Jul 2014, at 12:10, Alan Bateman <alan.bateman at oracle.com> wrote:

> On 09/07/2014 11:38, Peter Firmstone wrote:
>> I've had some time to think about how to make java.net.URI comply with RFC3986 as well as retain the existing implementation for backward compatibility:
>> 
>>  1. Strip out the existing URI class and Parser, create an abstract
>>     private delegate, move URI's implementation into a concrete
>>     delegate.  Create a new delgate for RFC3986.
>>  2. Use a system property to determine whether URI uses the existing
>>     implementation or RFC3986.
>>  3. Retain existing Serial form, represented by a String.
>>  4. Use one transient volatile field to refer to the delgate, remove
>>     all other fields from the encapsulating URI class, the delegates
>>     are not Serializable. Alternatively we may make all fields final
>>     by reworking Serializable code to ensure only the String field is
>>     written and read from the stream and by updating the delegate
>>     final field reference during deserialization.
>>  5. Make the delegate implementations final and immutable, don't
>>     lazily initialize.
>>  6. All methods refer to the delegate, the implementation of which is
>>     determined by the system property and instantiated at construction
>>     and during deserialization.
> The OpenJDK net-dev list would be the best to start a new thread on this.
> 
> At a high-level then I don't think system-wide configuration (#2) to toggle between RFC 2396 and 3986 is really feasible, particularly when you have an application that is built from libraries coming from many places. Also what would this mean for specification, particularly opaque URIs and specification dealing with the scheme specific part. Also think testing, is an implementation required to support both and does it mean running tests with both settings?
> 
> For the discussion on net-dev then I think it would be good to get into the major differences between the two RFCs and also the history and the previous attempt to rev java.net.URI. There have been a number of suggestions since then on what APIs might need to be added. My gut feel is that the overall effort is not going to be trivial and will likely need a JEP.
> 
> -Alan
>