Re: [Fwd: Re: Fixing compiler warnings]
Hi Petteri, Yes, we'd better to fix this. It is a straightforward one. A new CR, 6562614, has been filed against this. You could check it in bugs.sun.com. And now I need to figure out how to go through internal process before I could finally put back the code on your behave. Will keep you posted. Best regards, Edward Petteri Räty wrote: Next stop: net-dev. Alkuperäinen viesti / Orig.Msg. Aihe: Re: Fixing compiler warnings Päiväys: Thu, 24 May 2007 18:55:39 +0100 Lähettäjä: Alan Bateman <[EMAIL PROTECTED]> Vastaanottaja: Petteri Räty <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Viittaukset: <[EMAIL PROTECTED]> Petteri Räty wrote: This silences some QA warnings given by GCC. I don't have access to Solaris so it would probably be safest to test there before committing although man gettimeofday is claiming that the function is quite standard: CONFORMING TO SVr4, 4.3BSD. POSIX.1-2001 describes gettimeofday() but not settimeofday(). I haven't signed the SCA but this is hardly copyrightable. Regards, Petteri -- Gentoo/Java project lead Petteri - the networking libraries is the net-dev@openjdk.java.net mailing list so I would suggest posting the patch to that list. -Alan.
Re: Request for comments: Bug 6306820
Alan, Thanks for sticking with me - your comments and support have definitely improved my code, and I am grateful to you as a result. I have updated the version at... https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20129&forumID=1463 ...to include: a) toString(ParameterSeparator) b) Better JavaDoc around the 'parse' methods for ParameterSeparator What we have left appear to be some fairly small details. If I may summarise, you are saying... 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) 2) We should move the 'apply' method into java.net.URI 3) Keeping the method names familiar to javax.servlet.ServletRequest developers is less important than neatness of code during method chaining 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? Regards, Richard.
Re: Request for comments: Bug 6306820
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.
Re: Request for comments: Bug 6306820
Michael, >> 1) java.net.URL is discouraged... I would agree with Alan on this. Fair enough: I shall remove those methods. Can you confirm you want the naming convention changed to Url? It's just that everything else in the package uses uppercase URL (for legacy reasons, I'm sure). Note that the class is called URLEncodedQueryString because it models a 'www-form-urlencoded' query string, not because of the java.net.URL class. > What if a string to be parsed uses ';' as separator, but contains '&' chars embedded within it, > which are not to be interpreted as separators? When parsing, ALL separators are recognised. So if a string contains a mix of ';' and '&' both will be recognised. You do not specify the separator to use at parsing time - only at toString() time. > 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. Earlier versions of URIBuilder did this, but either Alan or yourself thought it complicated matters too much. The HTML spec's recommendation is UTF-8... http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars ...note that this only applies to URIs - it is a quite separate issue than what character set is used on the HTML page. Regards, Richard.
Re: [Fwd: Re: Fixing compiler warnings]
Hi Petteri, Two things. One is that seems 6562614 still doesn't show up in bugs.sun.com. I guess it's still on its way from our internal bug database to public one. You could check it later on. The other is that I encourage you to sign SCA. Then I can incorporate your code into OpenJDK code base. Here is how to do it: http://openjdk.java.net/contribute/ It should be simple enough. Thank you for your participation in improving Java technology and we look forward to hearing back from you. Best regards, Edward Edward Wang wrote: Hi Petteri, Yes, we'd better to fix this. It is a straightforward one. A new CR, 6562614, has been filed against this. You could check it in bugs.sun.com. And now I need to figure out how to go through internal process before I could finally put back the code on your behave. Will keep you posted. Best regards, Edward Petteri Räty wrote: Next stop: net-dev. Alkuperäinen viesti / Orig.Msg. Aihe: Re: Fixing compiler warnings Päiväys: Thu, 24 May 2007 18:55:39 +0100 Lähettäjä: Alan Bateman <[EMAIL PROTECTED]> Vastaanottaja: Petteri Räty <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Viittaukset: <[EMAIL PROTECTED]> Petteri Räty wrote: This silences some QA warnings given by GCC. I don't have access to Solaris so it would probably be safest to test there before committing although man gettimeofday is claiming that the function is quite standard: CONFORMING TO SVr4, 4.3BSD. POSIX.1-2001 describes gettimeofday() but not settimeofday(). I haven't signed the SCA but this is hardly copyrightable. Regards, Petteri -- Gentoo/Java project lead Petteri - the networking libraries is the net-dev@openjdk.java.net mailing list so I would suggest posting the patch to that list. -Alan.
