java.net.URL.getBasePath() --> time to have it?
Hey folks, To be able to get the basePath of a URL, so we can load other stuff somewhere else, defined as a relative path, it is common to see people coding stuff like this: https://gist.github.com/4355670 I don't know if there's something in the Java API that offers this, but it would be a great increment to the java.net.URL class (and perhaps java.net.URI as well), to offer this out of the box. Thoughts? PS: apparently, I sent this message during holidays, that's why nobody replied? --> http://mail.openjdk.java.net/pipermail/net-dev/2012-December/005374.html -- Bruno Borges Principal Product Manager | JavaEE WebLogic GlassFish Oracle LAD PM Team| Cloud Application Foundation +55 11 5187 6514 (Work) | +55 11 99564 9058 (Mobi)
hg: jdk8/tl/langtools: 8006224: Doclint NPE for attribute with no value
Changeset: bc1023e0e533 Author:jjg Date: 2013-01-15 13:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bc1023e0e533 8006224: Doclint NPE for attribute with no value Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/AnchorTest.java + test/tools/doclint/AnchorTest.out
hg: jdk8/tl/langtools: 8006344: Broken javadoc link in javax.lang.model.element.Element
Changeset: f805b5e3c9d1 Author:chegar Date: 2013-01-15 20:38 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f805b5e3c9d1 8006344: Broken javadoc link in javax.lang.model.element.Element Reviewed-by: lancea, alanb, jfranck ! src/share/classes/javax/lang/model/element/Element.java
hg: jdk8/tl/jdk: 8005618: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently
Changeset: 44d6cabc9a3f Author:robm Date: 2013-01-15 19:58 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44d6cabc9a3f 8005618: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently Reviewed-by: alanb, martin, dholmes ! test/java/lang/ProcessBuilder/Basic.java
Re: Code Review Request: 7171415: java.net.URI.equals/hashCode not consistent for some URIs
Looks good to me too. Thanks Kurchi. -Chris. On 01/15/2013 01:25 PM, Vitaly Davidovich wrote: Looks good. You can move ch, i, and index declarations into the for loop scope, but it's fine as-is. Thanks Sent from my phone On Jan 14, 2013 3:05 PM, "Kurchi Hazra" mailto:kurchi.subhra.ha...@oracle.com>> wrote: Thank you all for your comments. Here is an updated webrev where URI.hashCode() calculates the hashCode itself instead of relying on String.hashCode(): http://cr.openjdk.java.net/~khazra/7171415/webrev.01/ Thanks, Kurchi On 08.01.2013 20:29, Vitaly Davidovich wrote: Yes, I also thought about range checks not being eliminated if using charAt() but I guess that depends on how smart the JIT is - if charAt is inlined there's technically enough info there for the compiler to see that range checks aren't needed. Whether that happens or not I haven't checked. toCharArray brings us back to having allocations unless, again, EA helps out. I think a microbenchmark would help here (along with verbose GC logging) to see which is better if this is a concern. Why do you say you need to duplicate String.hashCode to be consistent with what people are using already? As long as the hash quality is at least as good as today (or not significantly worse) shouldn't you be able to change the impl? If someone's relying on specific value for some input then their code is broken. Besides, doing toUpper will change the hash for URIs with % anyway. Perhaps I misunderstood your point though ... Vitaly Sent from my phone On Jan 8, 2013 11:04 PM, "Kurchi Subhra Hazra" mailto:kurchi.subhra.ha...@oracle.com>> wrote: On 1/8/13 6:55 PM, Vitaly Davidovich wrote: Also, I'm not sure how hot this method is in practice but allocating StringBuilder seems a bit heavy (maybe it gets partially escape analyzed out though). Can you instead loop over all the chars in the string and build up the hash code as you go along? If you see a % then you handle next 2 chars specially, like you do now. Or are you trying to take advantage of String intrinsic support in the JIT? I guess if perf is a concern you can write a micro benchmark comparing the approaches ... That did occur to me, but I guess we have to be consistent with the value that people have already been using, and that means I have to duplicate the code in String.hashCode() (that is what the original implementation was calling) - I was trying to avoid that. Also, String.hashCode() uses its internal char[] - whereas charAt() will involve several additional bound checks - but using toCharArray() may be better. Let me take another look at this, and get back with another webrev. Sent from my phone On Jan 8, 2013 9:45 PM, "Vitaly Davidovich" mailto:vita...@gmail.com>> wrote: Hi Kurchi, In the hash method, I suggest you move handling of strings with % into a separate method to keep the hash method small for common case (no %). Otherwise, there's a chance this method won't get inlined anymore due to its (newly increased) size. - Yep, will do. Also, I realize toLower does the same thing, but why does toUpper return an int whereas it's really a char? Might be cleaner to declare return type as char and do the cast inside the method as needed. - I followed the format of toLower(). But I agree this way it will be cleaner. Thanks a lot, Kurchi Thanks Sent from my phone On Jan 8, 2013 8:20 PM, "Kurchi Hazra" mailto:kurchi.subhra.ha...@oracle.com>> wrote: Hi, According to RFC 3986[1], hexadecimal digits encoded by a '%' should be case-insensitive, for example,%A2 and %a2 should be considered equal. Although, URI.equals() does take this into consideration, the implementation of URI.hashCode() does not and returns different hashcodes for two URIs that are similar in all respects except for the case of the percent-encoded hexadecimal digits. This fix attempts to construct a normalized string from the string representing a component before calculating its hashCode. I converted to upper case for the normalization(and not lower case) as required by [1]. For testing the fix, I added an additional test scenario to an existing test (jdk/test/java/net/URI/Test.java). While I was there,
Re: Code Review Request: 7171415: java.net.URI.equals/hashCode not consistent for some URIs
Looks good. You can move ch, i, and index declarations into the for loop scope, but it's fine as-is. Thanks Sent from my phone On Jan 14, 2013 3:05 PM, "Kurchi Hazra" wrote: > Thank you all for your comments. Here is an updated webrev where > URI.hashCode() calculates the hashCode itself > instead of relying on String.hashCode(): > > http://cr.openjdk.java.net/~khazra/7171415/webrev.01/ > > Thanks, > Kurchi > > On 08.01.2013 20:29, Vitaly Davidovich wrote: > > Yes, I also thought about range checks not being eliminated if using > charAt() but I guess that depends on how smart the JIT is - if charAt is > inlined there's technically enough info there for the compiler to see that > range checks aren't needed. Whether that happens or not I haven't > checked. toCharArray brings us back to having allocations unless, again, > EA helps out. I think a microbenchmark would help here (along with verbose > GC logging) to see which is better if this is a concern. > > Why do you say you need to duplicate String.hashCode to be consistent with > what people are using already? As long as the hash quality is at least as > good as today (or not significantly worse) shouldn't you be able to change > the impl? If someone's relying on specific value for some input then their > code is broken. Besides, doing toUpper will change the hash for URIs with > % anyway. Perhaps I misunderstood your point though ... > > Vitaly > > Sent from my phone > On Jan 8, 2013 11:04 PM, "Kurchi Subhra Hazra" < > kurchi.subhra.ha...@oracle.com> wrote: > >> On 1/8/13 6:55 PM, Vitaly Davidovich wrote: >> >> Also, I'm not sure how hot this method is in practice but allocating >> StringBuilder seems a bit heavy (maybe it gets partially escape analyzed >> out though). Can you instead loop over all the chars in the string and >> build up the hash code as you go along? If you see a % then you handle next >> 2 chars specially, like you do now. Or are you trying to take advantage of >> String intrinsic support in the JIT? I guess if perf is a concern you can >> write a micro benchmark comparing the approaches ... >> >> That did occur to me, but I guess we have to be consistent with the value >> that people have already been using, and that means I have >> to duplicate the code in String.hashCode() (that is what the original >> implementation was calling) - I was trying to avoid that. Also, >> String.hashCode() uses its internal char[] - whereas charAt() will >> involve several additional bound checks - but >> using toCharArray() may be better. Let me take another look at this, and >> get back with another webrev. >> >> Sent from my phone >> On Jan 8, 2013 9:45 PM, "Vitaly Davidovich" wrote: >> >>> Hi Kurchi, >>> >>> In the hash method, I suggest you move handling of strings with % into a >>> separate method to keep the hash method small for common case (no %). >>> Otherwise, there's a chance this method won't get inlined anymore due to >>> its (newly increased) size. >>> >> - Yep, will do. >> >> Also, I realize toLower does the same thing, but why does toUpper >>> return an int whereas it's really a char? Might be cleaner to declare >>> return type as char and do the cast inside the method as needed. >>> >> - I followed the format of toLower(). But I agree this way it will be >> cleaner. >> >> Thanks a lot, >> Kurchi >> >> >> >> Thanks >>> >>> Sent from my phone >>> On Jan 8, 2013 8:20 PM, "Kurchi Hazra" >>> wrote: >>> Hi, According to RFC 3986[1], hexadecimal digits encoded by a '%' should be case-insensitive, for example,%A2 and %a2 should be considered equal. Although, URI.equals() does take this into consideration, the implementation of URI.hashCode() does not and returns different hashcodes for two URIs that are similar in all respects except for the case of the percent-encoded hexadecimal digits. This fix attempts to construct a normalized string from the string representing a component before calculating its hashCode. I converted to upper case for the normalization(and not lower case) as required by [1]. For testing the fix, I added an additional test scenario to an existing test (jdk/test/java/net/URI/Test.java). While I was there, I also made minor changes to the test so that it does not produce rawtype and other lint warnings. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171415 Webrev: http://cr.openjdk.java.net/~khazra/7171415/webrev.00/ URI.compareTo() still suffers from the same problem - I am not sure if it should be dealt with as a separate bug. Thanks, Kurchi [1] http://tools.ietf.org/html/rfc3986#section-6.2.2.1 >>> >> > -- > -Kurchi > >
hg: jdk8/tl/jdk: 8005406: HTTP server implementation should use Base64 API
Changeset: 4b012af44f24 Author:chegar Date: 2013-01-15 11:44 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b012af44f24 8005406: HTTP server implementation should use Base64 API Reviewed-by: khazra, alanb, chegar Contributed-by: Mark Sheppard ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java
Re: RFR: (JDK-8005406) HTTP server implementation should use Base64 API
On 01/15/2013 08:29 AM, Alan Bateman wrote: On 14/01/2013 22:24, Mark Sheppard wrote: Hi, Request for review of JDK-8005406, this time! This is the second in a series of refactorings which migrate base64 support in various packages to utilize the base64 support from java.util.Base64. This is the modification of com.sun.net.httpserver.BasicAuthenticator.java to use java.util.Base64. This makes changes to the BasicAuthenticator class to use java.util.Base64.Decoder, and removes a package private Base64 class. webrev located at http://cr.openjdk.java.net/~chegar/8005406 This looks good to me and great to see it changed to use java.util.Base64. Minor comment is that the import of Base64.Decoder doesn't appear to be needed. Agreed. The old package-private Base64 implementation seems to have been copied from prefs. It includes an alternative implementation, but that never seems to be used. Your changes make this code much cleaner. I can push this for you. -Chris. -Alan
Re: RFR: (JDK-8005406) HTTP server implementation should use Base64 API
On 14/01/2013 22:24, Mark Sheppard wrote: Hi, Request for review of JDK-8005406, this time! This is the second in a series of refactorings which migrate base64 support in various packages to utilize the base64 support from java.util.Base64. This is the modification of com.sun.net.httpserver.BasicAuthenticator.java to use java.util.Base64. This makes changes to the BasicAuthenticator class to use java.util.Base64.Decoder, and removes a package private Base64 class. webrev located at http://cr.openjdk.java.net/~chegar/8005406 This looks good to me and great to see it changed to use java.util.Base64. Minor comment is that the import of Base64.Decoder doesn't appear to be needed. -Alan
