Request for comments: Bug 6306820

[Richard Kennard]

Alan,

Great to hear from you again!

I am not at all opposed to making the changes you suggest. However, 
permit me to explain why it is the way it is first, and then you can 
counter my points :)

If I understand you correctly, what you are suggesting is a more 
'functional' (as opposed to OO) approach to the design. That is, have a 
bunch of static methods that operate on a Map<String, List<String>>, and 
let the user worry about passing that Map around. I would have the 
following concerns to this approach:

1. The Map itself would be very unwieldy. To retrieve a parameter from a 
query string, you'd have to do...

    map.get( "param1" ).get( 0 );

...as opposed to...

    query.getParameter( "param1" );

To set a parameter, you'd have to do...

    map.put( "param2", Arrays.asList( new String[]{ String.valueOf( 3 ) 
} ));

...as opposed to...

    query.setParameter( "param2", 3 );

To add a parameter, you'd have to do...

    List list = map.get( "param1" );

    if ( list == null )
       list = Arrays.asList( new String[]{ String.valueOf( 3 ) } ));
    else
       list.add( String.valueOf( 3 ));

    map.put( "param1", list );

...as opposed to...

    query.appendParameter( "param1", 3 );

...the former makes the concept of multi-valued parameters explicit and 
'in your face', even though they are seldom used. This is a problem 
wrestled with by the Java EE team, which I believe first deprecated and 
then un-deprecated getParameterValue (as opposed to getParameterValues).

2. The existing class still allows the benefit of using the Collection 
APIs to manipulate the Map: you can call .getParameterMap() and go from 
there. However, I would expect this to be an advanced use-case.

3. To add a method to java.net.URI that accepts a Map and turns it into 
a 'www-form-urlencoded' query string would be to incorporate details 
from the HTML spec into the URI class. At present, the URI class is only 
concerned with the RFC 2396 URI spec - not anything HTML specific. I 
thought you'd prefer it to stay that way? Indeed, that was one of your 
objections to some of my earlier designs, many months ago.

Look forward to hearing from you,

Richard.