+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 m...@saxonica.com +44 (0118) 946 5893 On 9 Jul 2014, at 12:10, Alan Bateman <alan.bate...@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 >
