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
