[concurrency-interest] URI + RFC3986 compliance

[Alan Bateman]

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