Re: Please review: surrogate fiddle

2013-03-18 Thread Martin Buchholz
On Mon, Mar 18, 2013 at 7:44 PM, Masayoshi Okutsu < masayoshi.oku...@oracle.com> wrote: > Thank you for catching this bug. AbstractStringBuilder.**codePointAt(int) > should have called Character.codePointAt(char[], int, int). > > As for duplicating code, I originally duplicated similar code everyw

Re: Please review: surrogate fiddle

2013-03-18 Thread Martin Buchholz
On Mon, Mar 18, 2013 at 3:37 PM, Xueming Shen wrote: > ** > > The spec of both affected methods says "the char at the index is returned, > if > the following conditions are not true > > 1) hi-surrogate && > 2) next index < count && > 3) char at next is lo-surrogate > > So it is the right thing to

Re: Please review: surrogate fiddle

2013-03-18 Thread Masayoshi Okutsu
Thank you for catching this bug. AbstractStringBuilder.codePointAt(int) should have called Character.codePointAt(char[], int, int). As for duplicating code, I originally duplicated similar code everywhere for performance. But someone told me probably during code review that hotspot inlining wa

hg: jdk8/tl/jaxws: 8007803: Implement javax.lang.model API for Type Annotations

2013-03-18 Thread jonathan . gibbons
Changeset: 0ab59cba6167 Author:jjg Date: 2013-03-18 18:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/0ab59cba6167 8007803: Implement javax.lang.model API for Type Annotations Reviewed-by: darcy ! src/share/jaxws_classes/com/sun/tools/internal/jxc/model/nav/ApNavigator.

Re: RFR 8009517: Disable fatal compiler warning in the old build

2013-03-18 Thread Brad Wetmore
Sorry for the delay in response, I've been pulled in yet another direction, and this has come back up in priority. On 3/9/2013 12:11 AM, Chris Hegarty wrote: I agree about warning creeping problems. This is a temporary solution, we should soon be fixing the underlying hashcode/equals problems.

Re: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket

2013-03-18 Thread David Holmes
Hi Serguei, On 19/03/2013 2:47 AM, serguei.spit...@oracle.com wrote: I already reviewed this, and it is a good fix. Please, see my email attached. You are not an OpenJDK Reviewer [1] . Staffan needs an official Review from a Reviewer before it can be pushed. That doesn't mean your review is

Re: Please review: surrogate fiddle

2013-03-18 Thread Xueming Shen
The spec of both affected methods says "the char at the index is returned, if the following conditions are not true 1) hi-surrogate && 2) next index < count && 3) char at next is lo-surrogate So it is the right thing to do to simply return the char at index, if it is the last char in the buffe

Re: Please review: surrogate fiddle

2013-03-18 Thread Martin Buchholz
It does change the behavior. The existing behavior is clearly a bug, since it reads a char that should be inaccessible. I don't believe AIOOBE exception is thrown, with or without my fix. On Mon, Mar 18, 2013 at 3:08 PM, Mike Duigou wrote: > This change would seem to change the result when a

Re: Please review: surrogate fiddle

2013-03-18 Thread Mike Duigou
This change would seem to change the result when a high surrogate is the last char in the String/StringBuilder/StringBuffer. Rather than throwing an ArrayIndexException it will return the high surrogate char. I am going to defer to Sherman on this. I don't know that returning the character is

Please review: surrogate fiddle

2013-03-18 Thread Martin Buchholz
Hello Jim, Mike, I'd like you to do a code review: http://cr.openjdk.java.net/~martin/webrevs/openjdk8/surrogate-fiddle/

Re: java encoding charset suggestion

2013-03-18 Thread Helio Frota
Hi Martin, Is not interesting to favor one country or language. I read some documents including the link you shared ( opengroup ). Only one thing i found is the python language that try to found defined values on others variables. http://docs.python.org/2/library/locale.html But after absorbing

Re: java encoding charset suggestion

2013-03-18 Thread Martin Buchholz
On Mon, Mar 18, 2013 at 11:34 AM, Helio Frota wrote: > > Please try to use á é í ... > > But I think the operating system should set the default, not the >> application. On my Ubuntu system I see the traditional ASCII English >> default: >> > > I agree, but the JVM could not be pro-active ? Ho

Re: java encoding charset suggestion

2013-03-18 Thread Louis Wasserman
This would probably be likely to break lots of existing users depending on the default charset, depressingly enough. On Mon, Mar 18, 2013 at 11:34 AM, Helio Frota wrote: > Hi Martin Buchholz, > > I believe (but I could be wrong) that only java applications exhibit this > behavior, programs made

Re: java encoding charset suggestion

2013-03-18 Thread Helio Frota
Hi Martin Buchholz, I believe (but I could be wrong) that only java applications exhibit this behavior, programs made with GTK or QT are not affected, they probably look at the level of the X11 case are not in variable LANG or assume a default locale. > $ (unset LC_ALL LC_COLLATE LANG LANGUAGE

Re: java encoding charset suggestion

2013-03-18 Thread Martin Buchholz
It *would* be nice if the world agreed on using UTF-8 as a universal encoding for all text. However: Standard says http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html """If the LANG environment variable is not set or is set to the empty string, the implementation-defined defa

java encoding charset suggestion

2013-03-18 Thread Helio Frota
Hi All, Sorry if here is not the right place to do a suggestion of this subject. Please take a look on this post: http://www.heliofrota.com/blog/2013/03/18/understanding-java-encoding/ I would suggest taking en_US.UTF-8 as default when the LANG variable is not set to avoid problems with encoding

Re: RFR(S): 8006637 Failure to filter out native frame events on Solaris

2013-03-18 Thread serguei.spit...@oracle.com
It is just a remainder that I reviewed this as well (the fix is good too). My email is attached. Thanks, Serguei On 3/18/13 7:14 AM, Staffan Larsen wrote: I still need an official Review for this change. Thanks, Staffan On 7 mar 2013, at 09:10, Staffan Larsen wrote: Adding core-libs-dev a

Re: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket

2013-03-18 Thread serguei.spit...@oracle.com
I already reviewed this, and it is a good fix. Please, see my email attached. Thanks, Serguei On 3/18/13 7:13 AM, Staffan Larsen wrote: Can I get an official Review of this change? Thanks, /Staffan On 7 mar 2013, at 12:54, Staffan Larsen > wrote: Here is a

hg: jdk8/tl/langtools: 8005220: RFE to write javap tests for repeating annotations.

2013-03-18 Thread jonathan . gibbons
Changeset: 1f8c28134ffc Author:jjg Date: 2013-03-18 08:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1f8c28134ffc 8005220: RFE to write javap tests for repeating annotations. Reviewed-by: jjg Contributed-by: peter.jen...@oracle.com + test/tools/javap/output/Repeati

Re: RFR 8005696: Add CompletableFuture - JEP 155

2013-03-18 Thread Doug Lea
On 03/15/13 09:43, Chris Hegarty wrote: On 15/03/2013 12:00, Doug Lea wrote: Yes, thanks! This keeps the exception specs consistent across similar methods. Now that I reread these method descriptions, I think thenAcceptBothXXX suffer the same problem: Yes; thanks. And also a few other cases

Re: RFR(S): 8006637 Failure to filter out native frame events on Solaris

2013-03-18 Thread Staffan Larsen
I still need an official Review for this change. Thanks, Staffan On 7 mar 2013, at 09:10, Staffan Larsen wrote: > Adding core-libs-dev and re-asking for a review. > > Thanks, > /Staffan > > On 27 feb 2013, at 15:59, Staffan Larsen wrote: > >> Please review the following test fix. >> >> web

Re: RFR(S): 8009397 test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket

2013-03-18 Thread Staffan Larsen
Can I get an official Review of this change? Thanks, /Staffan On 7 mar 2013, at 12:54, Staffan Larsen wrote: > Here is a webrev for fixing this problem. I actually removed all of our own > tokenization code in dll_build_name() and replaced it with calls to strtok_r > (strtok_s on windows) ins