Re: [concurrency-interest] URI + RFC3986 compliance
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
+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@saxonica.com +44 (0118) 946 5893 On 9 Jul 2014, at 12:10, Alan Bateman <alan.bateman@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
participants (2)
-
Alan Bateman
-
Michael Kay