Hi Naoto,
The change looks good. Thanks for fixing this. We're seeing it regularly in our
test infrastructure where we're running Mac systems with German locale.
Best regards
Christoph
> -Original Message-
> From: i18n-dev On Behalf Of
> naoto.s...@oracle.com
> Sent: Montag, 6. Januar
Thank you, Matthias.
From: Baesken, Matthias
Sent: Freitag, 20. September 2019 10:07
To: Langer, Christoph ;
jdk-updates-...@openjdk.java.net
Cc: i18n-dev@openjdk.java.net
Subject: RE: [11u] RFR: 8212970: TZ database in "vanguard" format support
Hello Christoph, looks good to
Hi,
please review this backport to JDK11 updates:
Bug: https://bugs.openjdk.java.net/browse/JDK-8212970
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212970.11u-dev.0/
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8
This backport is prerequisite to JDK-8228469: (tz)
Sounds great. Thank you.
> -Original Message-
> From: naoto.s...@oracle.com
> Sent: Donnerstag, 27. Juni 2019 23:16
> To: Langer, Christoph ; i18n-
> d...@openjdk.java.net; core-libs-dev
> Subject: Re: [13] RFR: 8226876: Assertion in
> sun/util/locale/provider/C
Thanks Naoto.
I'll hold back the push (in JDK13) until JDK-8226876 is in.
/Christoph
> -Original Message-
> From: naoto.s...@oracle.com
> Sent: Donnerstag, 27. Juni 2019 18:03
> To: Langer, Christoph ; i18n-
> d...@openjdk.java.net; Java Core Libs
> Cc: Ying Zho
> > The change looks good to me. But I would say the assertion in
> CalendarDataUtility in line 266 is pointless now, isn't it?
>
> Yes, but would not hurt leaving it. It would catch error if yet another
> case is installed (and it forgot to provide a default value) in the
> switch statement. So I
Hi Naoto,
thanks for providing a fix so quickly.
The change looks good to me. But I would say the assertion in
CalendarDataUtility in line 266 is pointless now, isn't it?
Best regards
Christoph
> -Original Message-
> From: i18n-dev On Behalf Of
> naoto.s...@oracle.com
> Sent: Donnerst
Hi,
Please, first of all, review a little test fix. Java level assertions should be
enabled in test java/util/Locale/LocaleProvidersRun.java. It was (probably
inadvertently) removed by refactoring the test with JDK-8210403 (Refactor
java.util.Locale:i18n shell tests to plain java tests).
Resol
+1
> -Original Message-
> From: i18n-dev On Behalf Of Ichiroh
> Takiguchi
> Sent: Dienstag, 2. Oktober 2018 18:30
> To: awt-...@openjdk.java.net; i18n-dev@openjdk.java.net
> Subject: RFR[12]: 8211393 Memory leak issue on
> awt_InputMethod.c
>
> Hello.
> Could you review memory leak fix
> Sent: Freitag, 1. Juni 2018 18:12
> To: Phil Race ; Langer, Christoph
> ; i18n-dev@openjdk.java.net
> Cc: Ichiroh Takiguchi
> Subject: Re: JDK-8201429 - Support AIX Input Method Editor
> (IME) for AWT Input Method Framework (IMF)
>
> The issue in the current naming scheme (s
Hi,
I was just asked to include i18-n dev in the review of the change for this Item.
Bug: https://bugs.openjdk.java.net/browse/JDK-8201429
Last webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.3/
Unfortunately this request came a bit too late and the change has already been
pushed: h
Hi Thomas,
your change looks good. I'm also forwarding this to i18n-dev as issues in
TimeZone implementation are mostly handled there.
One remark: Can you take the opportunity to also remove the blank between the
cast and malloc in line 150: "(struct dirent64 *) malloc..."?
Unfortunately I'm n
Hi Nishit,
this looks good and aligns with other places which were hardened for EINTR.
But I'm not a reviewer, so you need to get a higher vote, still :)
Best regards
Christoph
> -Original Message-
> From: i18n-dev [mailto:i18n-dev-boun...@openjdk.java.net] On Behalf Of
> Nishit Jain
>
/>
>
> Thanks,
> Rachna
>
> > On Jul 29, 2016, at 4:35 PM, Langer, Christoph
> wrote:
> >
> > Hi Rachna,
> >
> > In general, the fix looks good to me.
> >
> > However, there are a few indentation flaws, in lines 830, 831 and 834 - 841.
>
Hi Rachna,
In general, the fix looks good to me.
However, there are a few indentation flaws, in lines 830, 831 and 834 - 841.
Please make sure you use 4 chars indentation.
And you should remove the blank between the cast to (time_t) and the variable
in line 832.
Also, please note that I'm no r
amersoff [mailto:dmitry.samers...@oracle.com]
Sent: Mittwoch, 9. September 2015 09:12
To: Langer, Christoph
Cc: jdk9-...@openjdk.java.net; i18n-dev@openjdk.java.net; Roger Riggs
Subject: Re: Fix for small leak in TimeZone_md.c
Christoph,
Looks good for me.
663 it might be better to use str
t/~simonis/webrevs/2015/8134505.v1/
Best regards,
Christoph
-Original Message-
From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
Sent: Samstag, 5. September 2015 19:47
To: Langer, Christoph ; Roger Riggs
Cc: jdk9-...@openjdk.java.net; i18n-dev@openjdk.java.net
Subject: Re: Fix
Hi,
I updated the webrev at line770 and removed the platform specific #ifdefs.
Best regards
Christoph
From: Langer, Christoph
Sent: Mittwoch, 26. August 2015 16:34
To: 'i18n-dev@openjdk.java.net'
Subject: RFR: 8134505: Cleanup of "TimeZone_md.c"
Hi,
when working on Tim
Here is the updated webrev:
http://cr.openjdk.java.net/~simonis/webrevs/2015/8134505/
-Original Message-
From: Langer, Christoph
Sent: Donnerstag, 3. September 2015 12:25
To: 'Roger Riggs' ; jdk9-...@openjdk.java.net
Cc: 'i18n-dev@openjdk.java.net'
Subject: RE: F
javatz = strdup(tz);
free((void *) freetz);
} else {
/* we are good if we already work on a freshly allocated
buffer. */
javatz = tz;
}
#endif
$.02, Roger
On 8/26/2015 5:34 PM, Langer, Christoph wrote:
> Hi Andrew,
>
&
Hi,
when working on TimeZone_md.c lately, I found it worthwhile to do some cleanup
on it. Please review my changes.
Bug: https://bugs.openjdk.java.net/browse/JDK-8134505
Webrev: http://cr.openjdk.java.net/~goetz/webrevs/8134505-timeZone/webrev.01/
I basically did the following things:
- clean up
...@oracle.com]
Sent: Dienstag, 25. August 2015 04:58
To: Aleksej Efimov ; Langer, Christoph
; i18n-dev@openjdk.java.net
Subject: Re: FW: RFR(XS): 8133830: [solaris] Fix for potential
memory leak in TimeZone_md.c, function findJavaTZ_md()
Looks good to me too. Thank you for fixing this bug.
Aleksej, it&#
Hi,
I'm also posting this RFR here.
Is this the right place for my change? Is anyone willing to sponsor this?
Thanks a lot in advance
Christoph
From: Langer, Christoph
Sent: Donnerstag, 20. August 2015 12:22
To: 'core-libs-...@openjdk.java.net'
Subject: RFR(XS): 8133830: [s
23 matches
Mail list logo
