Request for comments: Bug 6306820

[Richard Kennard]

Alan,

I read some distinct 'themes' into your last e-mail. Please permit me to 
respond to the 'themes', rather than your exact points:

1. java.net.URL

You said:

'I would suggest ignoring java.net.URL completely... is parse(URL) 
needed? ... is apply(URL) needed? ... I believe naming conventions would 
suggest this be should Url* instead'

I actually encounter java.net.URL quite often in my daily work - many 
APIs seem to use it, and don't seem to offer a java.net.URI alternative? 
I think it is still quite active and shouldn't be ignored?

2. Servlet API

You said:

'it's not clear to me why any of the method names need the word 
"Parameter" in them... It's not clear to me that we have to be 
consistent with the Servlet API.'

I think consistency with the Servlet API is important because it is the 
only example in the JDK (well, Java EE DK) of an API that deals 
specifically with www-form-urlencoded query strings: it is mature and 
very familiar to many developers?

It also has some naming quirks around returning String versus String[] 
for getParameter and getParameterValues. Those quirks are the necessary 
because of the HTML spec, so I'd rather match the Servlet API's naming 
quirks than introduce a brand of quirks of our own?

3. Separators

You said:

'Is this enum needed? ... maybe the create method can specify the 
separator? ... what if [the query string to be parsed] uses a different 
separator? ... Do you have examples in mind where a query would be 
parsed using one separator but then converted to use a different separator?

I'm afraid I thought I'd explained this already? It's also in the JavaDoc:

"ALL separators are recognised when parsing query strings. ONE separator 
may be passed to 'getQuery' and 'apply' when outputting query strings"

I agree on your point around removing 'getQuery' and just having 'toString'.

Regards,

Richard.