Chris,
Thanks for your feedback. And actually, picky is good! I much prefer
picky feedback to no feedback at all.
I have updated the JavaDoc with your suggestions:
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20922&forumID=1463
However, on the question of...
> How about [getParameterValues] returning an empty list if the
parameter does not exist?
...I guess this comes down to whose behaviour it makes more sense to
model. Do we model the behaviour of getParameterNames, as you suggest,
and return an empty List, or do we model the behaviour of
getParameterValue (it's non-plural version) and return null if the
parameter does not exist?
I've leaned towards the latter, but I am open to reasons to lean toward
the former.
Regards,
Richard.
Christopher Hegarty - Sun Microsystems Ireland wrote:
Some initial (picky) comments:
1) "Thread Safety
Instances of UrlEncodedQueryString are not not synchronized."
Typo: "not not".
I would expand this a little. Maybe taking wording similar to
java.util.HashMap:
"Note that this implementation is not synchronized. If multiple
threads access a query string concurrently, and at least one of the
threads modifies the query string, it must be synchronized
externally. This is typically accomplished by synchronizing on some
object that naturally encapsulates the query string."
2) Consistency when documenting to how separators are handled.
parse(java.net.URI uri)
"...When parsing, all separators from the Separators enum are
recognised."
I would change this as follows:
"...When parsing, all Separators are recognised."
3) getParameterValues
"Returns an array of String objects containing all of the values
the named parameter has, or null if the parameter does not exist.
If the parameter has a single value, the array has a length of 1."
Should read:
"Returns a List of String objects containing all of the values
the named parameter has, or..."
How about returning an empty list if the parameter does not exist?
Similar to getParameterNames, "an empty Iterator if there are no
parameters"
Also, typo in @returns
"an List of String objects..." -> "a List of String objects..."
-Chris.
Richard Kennard wrote:
Michael,
I have further updated URLEncodedQueryString to incorporate
everybody's JavaDoc feedback:
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20908&forumID=1463
Hoped to hear from you soon,
Richard.
