Re: [concurrency-interest] URI + RFC3986 compliance

[Peter Firmstone <pe...@zeus.net.au>]

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.


I've also attached copies of our Uri implementation and included 
RFC3986URLClassLoader.

Regards,

Peter.




On 2/07/2014 8:44 PM, Alan Bateman wrote:
> On 02/07/2014 08:10, Peter Firmstone wrote:
>>
>> How does one go about it? I'm not on any lists or part of the project.
> This is the best place to start:
>   http://openjdk.java.net/contribute/
>
> At a high-level then the types of improvements that you listed in your 
> summary seem to be very good. It's probably best to start out small 
> and propose one or two small changes first to get used to contributing 
> and also because some of the changes are likely to require detailed 
> review and discussion.
>
>
>> :
>>
>>>
>>> On RFC 3986 (you mentioned this a number of times) then there were 
>>> previous attempts bring URI up to this, unfortunately had to be 
>>> backed out due to compatibility issues and other breakage. It's 
>>> definitely something that needs to be looked at again.
>>
>> Yes turns out RFC 3986 is very useful.  Our implementation is 
>> strictly compliant, with the exception of making upper case path 
>> comparisons for file URI's on certain platforms, it's based on 
>> Harmony's URI, but has been refactored with immutability; final 
>> class, final fields, isn't serializable etc.  The parser is called 
>> during construction using static methods.  Exceptions thrown by 
>> constructors are thrown by static methods prior to Object's default 
>> constructor being called, to avoid creating partially constructed 
>> objects.
> java.net.URI is based on the older RFC 2396 and 2732. I think bringing 
> it up to RFC 3986 while maintaining compatible could be a major 
> project (previously attempts to do this back in JDK 6 were backed out 
> due to the breakage that it caused). It's a good topic to bring up on 
> the OpenJDK net-dev list where URI is maintained, it's definitely 
> something that needs to happen at some point.
>
> -Alan