Request for comments: Bug 6306820

[Michael McMahon]

Richard Kennard wrote:
> What we have left appear to be some fairly small details. If I may 
> summarise, you are saying...
>
Yes, I think that is true.
> 1) java.net.URL is discouraged, therefore we shouldn't support it in 
> our API nor follow its naming convention (even though we'll sit 
> alongside it in the java.net package)
I would agree with Alan on this. The problem with java.net.URL is that 
it contains a lot of legacy
behavior which we cannot touch, much of which is contrary to the RFC 
specification for URIs.
The more people are encouraged to use it, the more they will encounter 
these problems, and complain
about them. URI on the other hand, was designed from the start to behave 
correctly with respect
to the URI RFC, so the developers should be encouraged to use it, 
instead of URL.
> 2) We should move the 'apply' method into java.net.URI
In my view, apply() is fine where it is in this class.
> 3) Keeping the method names familiar to javax.servlet.ServletRequest 
> developers is less important than neatness of code during method chaining
>
Again, and I suppose we are both coming from a Java SE perspective, but 
I would
concur with Alan on this. I don't see a compelling reason to use 
excessively long
method names, just to remain compatible with the servlet spec. This is a 
new API,
and arguably there is no harm at all in looking a bit different from the 
servlet spec.
We can defer the question though, if you feel particularly strongly 
about it.
> I'm happy either way on 1 and 2, though I disagree with you on 3, but 
> none of these seem like they should be major obstacles to CCC 
> approval? With your permission, then, I'd like to leave them to the 
> larger consensus?
>
I just have a couple more questions to ask relating to encoding and 
interpretation of '&' and ';'
What if a string to be parsed uses ';' as separator, but contains '&' 
chars embedded within it,
which are not to be interpreted as separators?
If this situation could arise, would we then need a variant of parse() 
which takes a Separator char
and then only uses that char as the separator?

I think the docs should explicitly state that UTF-8 is the default 
character set used, which leads
to another question. Should we have the possibility to specify the 
character set, perhaps
in the toString() method? In my experience, in some parts of the world, 
particularly Asia,
other character sets are often used for web applications.
> Regards,
>
> Richard.
>