Re: RFR: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows

On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes early `CHECK_NULL_RETURN` results > not releasing native `jchar` array returned by `GetStringChars()`. Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pul

Re: RFR: 8257733: Move module-specific data from make to respective module [v6]

Magnus, This proposal does not address the previous concerns. As before, you are proposing to put the data files used to generate the classes for jdk.localedata and jdk.charsets into src/java.base and I don't think we should do that. I really think this PR needs to be withdraw n or closed unt

Re: RFR: 8257733: Move module-specific data from make to respective module [v6]

On 16/03/2022 08:44, Magnus Ihse Bursie wrote: : If you have such strong opinions on the data files shared between java.base and jdk.charsets/jdk.localedata, I propose we leave them in make/data for the time being, clean up the associated mess, and then work out where they actually should be.

Re: RFR: 8257733: Move module-specific data from make to respective module [v9]

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by

Re: RFR: 8257733: Move module-specific data from make to respective module [v9]

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by

Re: RFR: 8284893: Fix typos in java.base

On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those > changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in c

Re: RFR: 8285370: Fix typo in jdk.charsets

On Thu, 21 Apr 2022 11:34:14 GMT, Magnus Ihse Bursie wrote: > `codespell` could just find a single typo in the files covered by the i18n > alias. Just fixing the typo did not make the comment more readable, so I > rewrote it slightly. Marked as reviewed by alanb (Reviewer). src/jdk.charsets/s

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v2]

On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy >> conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not >> assignment compatible with the type of the variable, a c

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v3]

On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy >> conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not >> assignment compatible with the type of the variable, a c

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v3]

On Fri, 13 May 2022 04:41:03 GMT, ExE Boss wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Updated copyrights >> Fixed cast style to add a space after cast, (where consistent with file >> style) >> Improved cod

[Fwd: [PATCH] Load currency.data via ClassLoader]

Locale related utility classes are maintained by the i18n group - right? --- Begin Message --- Hi there, in java.util.Currency, the currency.data is loaded from $JRE_DIR/lib. I'm having a problem with this in the JamaicaVM, when an application is built into a single bundle for use on an embedded

Re: Level 1 Unicode support for Java regexes: overview

Tom Christiansen wrote: : [1] http://download.java.net/jdk7/docs/api/java/util/regex/Pattern.html Is the source for that available? If it were, I'm sure many questions I have I could easily answer myself. Have you cloned the forest? If so then it's in jdk/src/share/classes/java/ut

Re: Fwd: Some differences on Window UDC area

Charles Lee wrote: Original Message Subject:Some differences on Window UDC area Date: Thu, 24 Mar 2011 09:34:20 +0800 From: Charles Lee To: i18n-dev@openjdk.java.net, litt...@linux.vnet.ibm.com Hi guys, Given the test case below, some UDC are printed out.

7026507: Bidi initialization fails if AWT not present

Masayoshi - do you mind reviewing this change to sun.text.bidi.BidiBase? This one is modularity related and only arises if Bidi is used when the client/desktop module is not present (not an issue for 7 of course). In that scenario then the initialization will throw a ClassCastException as the

Re: Fwd: Some differences on Window UDC area

Charles Lee wrote: : It looks similar. How can I find the patch quickly? I notice it says "the list is attached to this CR". Is it CR-6183404? Since cr has the pattern cr.openjdk.java.net/~username/id, how can I know who is the committer to this CR? cr.openjdk.java.net is the place where we p

Re: Codereview request for 7033561: Missing Unicode Script aliases

Xueming Shen wrote: It appears the aliases mapping for Character.UnicodeScript is not updated accordingly when we upgraded the Unicode support to 6.0 for JDK7. The difference between the previous version (5.2) and 6.0 of the aliases are these 3 missing names reported in #7033561. The webrev

Re: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties

Xueming Shen wrote: Thanks Mark! Let's go with UNICODE_PROPERTY, if there is no objection. I went through the updates to the javadoc and the approach looks good and nicely done. A minor comment is that the compile(String,int) method repeats the list of flags that are allowed so that should be

Re: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties

Xueming Shen wrote: : UNICODE_CHARACTER_CLASS is clear and straightforward. I am OK with it. The webrev, ccc and api docs have been updated accordingly. Yes, I still need a reviewer for the implementation changes. Tom has helped review the doc (and the definition of those properties). I've g

Re: code review for 7067811: Update demo/sample code to state it should not be used for production

Nils Loodin wrote: : Finally on the documentation of applications, such as the lightweight HTTP server, that are shipped for testing/debugging, the following disclaimer should be added: Applications such as the lightweight HTTP server are shipped with the JDK to help developers deploy and t

Re: testcase failure

I haven't seen it but Olivier Lagneau asked me off-list recently about the same issue (same test, same failure mode). I've cc'ed the i18n folks in case they recognize it. My guess is that this is an implementation bug in LocaleServiceProviderPool rather than a test bug. -Alan. Kelly O'Hair

Re: testcase failure

Chris Hegarty wrote: Trivially, should the main thread in the test be waiting on the three other threads to complete before exiting? I think jtreg will try to cleanup once the main thread completes. The main thread should keep an array of the threads it creates and invoke join() on each of th

Re: testcase failure java/util/Locale/Bug6989440.java

Chris Hegarty wrote: Alan, Naoto, David I filed CR 7098100: java/util/Locale/Bug6989440.java fails intermittently. If you're ok with it please review the patch (below) and I can push it to the tl repo. Job done! I assume there is also some underlying issue in the Locale code and this might

Re: testcase failure java/util/Locale/Bug6989440.java

Chris Hegarty wrote: Naoto, Forgot to add, you can probably just push the changes for the test along with your source changes. I modified it a little since last review. Reproduces one in about every ten times on one of our Dual core Linux x64 boxes. Is it the CME that duplicates for you? I'm

Re:

On 04/11/2011 12:03, Heiko Wagner wrote: Hi Tom, thanks for your reply. I am using JNI in a different,propably never designed to be used that way, kind of scenario. I use JNI to bring Java to a legacy Smalltalk based product[1]. The Smalltalk code does directly invoke the JNI calls from its own

Re:

On 07/11/2011 00:19, David Holmes wrote: There are a handful of places in the JDK where this kind of stack-based check is used and the assumption is always that there is a "client" Java caller in the stack. Given this kind of code is unaware of the context in which it is called in general, wh

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

On 13/02/2012 17:36, Xueming Shen wrote: : The webrev is at http://cr.openjdk.java.net/~sherman/4153167/webrev The changes look reasonable to me and looks like you have all the combinations of redirection covered. I'm not sure about the sun.std*.encoding properties as folks will find them.

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

On 16/02/2012 20:18, Xueming Shen wrote: Thanks Alan, webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/4153167/webrev -Sherman This looks reasonable to me, will be interesting to see if anyone notices. -Alan.

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

On 09/03/2012 16:00, Seán Coffey wrote: Issue seen on somewhat irregular linux system configuration where /etc/localtime is a symbolic link to a directory outside of /usr/share/zoneinfo. In past, when a symbolic link was seen, the end target file was assumed to be under /usr/share/zoneinfo an

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

On 12/03/2012 14:31, Seán Coffey wrote: Ok - good point on the stat change Alan. I think this is what you're after : http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.2/ At L295 then I assume itshould open DEFAULT_ZONEINFO_FILE, otherwise if the sym link is a relative path then it would

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

On 12/03/2012 15:11, Seán Coffey wrote: Yes - good catch. I hadn't tested the sym link being a relative path. We should always open whatever is pointed to from DEFAULT_ZONEINFO_FILE. This simplifies the code. Tested and looks good. I assume this is the latest: http://cr.openjdk.java.net/~coff

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

On 13/03/2012 09:38, Seán Coffey wrote: Update made. Hopefully the last iteration ;) http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.4/ Looks okay to me. For bonus points, open, fstat and read should be restarted if interrupted (EINTR). -Alan.

Re: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled

Deven, The test with this fix seems to be a manual test but doesn't seem to be tagged as such (/manual). I assume this means it will fail on all platforms. Do you mind re-examining it? Masayoshi may have some advice on how configuration like this can be tested. It may be that it's just not po

Re: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled

On 25/05/2012 10:32, Masayoshi Okutsu wrote: Hi Deven, Sorry. I didn't review the test case... You can use applet to write a manual test. You will find some manual tests under test/java/awt such as: test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.{html,java} Thanks, Masay

Re: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled

On 25/05/2012 11:05, Masayoshi Okutsu wrote: Another option would be to write a native program to change the system setup and run a Java program to detect the change. But it requires the administrator privilege and is a bit risky. A test failure may leave a test machine in an unusual state.

Re: Fwd: Some differences on Window UDC area

On 04/06/2012 07:52, Xueming Shen wrote: Hi It has been confirmed (thanks Jacky) that Solaris' iconv GBK actually uses (shares) the GB18030 mappings as showed at http://src.opensolaris.org/source/xref/nv-g11n/g11n/src/lib/iconv/inc/unicode_gb18030.h which is same as the MS936 for that par

Re: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X

On 22/06/2012 19:02, Mike Duigou wrote: : Won't this cause problems on case sensitive file systems? The MacOSX filesystem is by default case insensitive but case sensitive file systems are not entirely uncommon. It shouldn't cause any issues accessing files, this is really just about equals,

Re: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X

On 26/06/2012 07:00, Xueming Shen wrote: On 6/25/12 10:58 PM, Xueming Shen wrote: Hi, While I still believe that case-insensitive is the right choice for File/Path on MacOSX, it is suggested that we might want to be a little conservative in this patch, with the assumption that this patch will

Re: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X

On 27/06/2012 04:33, Xueming Shen wrote: Alan, Webrev has been updated accordingly at http://cr.openjdk.java.net/~sherman/7130915/webrev with changes (1) added a CFStringCreateMutable(...) != null check in both io and nio native, though it is unlikely to fail here because we are passin

Re: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

On 10/07/2012 21:42, Naoto Sato wrote: Hello, Please review the JDK8 changes for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data (http://openjdk.java.net/jeps/127). The webrev is located at: http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ There's a lot here, lots of g

Re: hg: jdk8/tl/jdk: 7180362: RFE: Implement date cutover functionality for currency.properties file

On 07/09/2012 21:19, sean.cof...@oracle.com wrote: Changeset: fffbb33df102 Author:coffeys Date: 2012-09-07 21:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fffbb33df102 7180362: RFE: Implement date cutover functionality for currency.properties file Reviewed-by: naoto !

Re: [PATCH] Review Request: Add bug 7196199 into ProblemList

On 14/09/2012 02:35, Eric Wang wrote: Hi Naoto, Thank you to be my sponsor. I have checked the nightly results, this error also occurred on Linux as well. http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=98081.CORELIBS-JDK8-NIGHTLY-JTREG-16 These links are Oracle internal l

Re: [PATCH] Review Request: Add bug 7196199 into ProblemList

On 14/09/2012 17:38, Naoto Sato wrote: I questioned this because of the following comment line in ProblemList.txt # More than one label is allowed but must be on the same line. Which suggests that we could express the line like, java/text/Bidi/Bug6665028.java solaris-all linux-all But I co

Re: [PATCH] Review Request: Add bug 7196199 into ProblemList

On 17/09/2012 22:53, Naoto Sato wrote: OK, I filed a CR 7198984 for this and intend to push Eric's fix as it is. Alan, will you be a reviewer for this? Naoto That's fine. -Alan

Do developers or end-users create currency.properties?

As part of preparing for modules in the future [1], we need to look at configuration (and other) files in the JDK and see whether such files could eventually move to module-private locations. The Currency classes allows people to override the currency data that comes with the JDK by creating

Re: Do developers or end-users create currency.properties?

On 15/10/2012 17:05, Alan Bateman wrote: As part of preparing for modules in the future [1], we need to look at configuration (and other) files in the JDK and see whether such files could eventually move to module-private locations. The Currency classes allows people to override the

Re: [8]Review request: 8001231 : Move locale data out of rt.jar (except the US locale)

On 30/10/2012 16:33, Naoto Sato wrote: Hello, I need someone to review my changes to the following bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001231 The fix is to move locale data out of rt.jar into localedata.jar which will be optional in the compact profile (http://openjdk.ja

Re: Do developers or end-users create currency.properties?

On 16/10/2012 17:50, Naoto Sato wrote: The idea was that "currency.properties" was intended for the "emergency" situation, where JRE's update could not keep up with customers' needs. The assumption was JRE's lib/currency.data should contain the latest currency data with the JRE updates. Naoto

Re: Do developers or end-users create currency.properties?

On 21/11/2012 20:32, Naoto Sato wrote: Hi Alan, I think it's a good idea to provide a way to specify the currency properties file location. As to whether it belongs to spec or not, I think we need make it as part of spec, otherwise it may not conform to the existing spec, i.e., lib/currency.p

Re: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo

On 27/11/2012 10:22, Staffan Larsen wrote: Please review this fix for the java/util/TimeZone/Bug6912560.java test. The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main()

Re: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo

On 27/11/2012 10:22, Staffan Larsen wrote: Please review this fix for the java/util/TimeZone/Bug6912560.java test. The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main()

Re: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo

On 27/11/2012 12:26, Staffan Larsen wrote: : The test installs a security manager and that has to be present during the call to getDefault() when getDefault() does the real work (not just reading from the cache). Setting -Duser.timezone will not help as the only fix. What I mean is change

Re: RFR: 7197187 Currency.isPastCutoverDate should be made more robust

On 19/02/2013 13:05, Seán Coffey wrote: As correctly pointed out by Alan, the 7180362 code fix should be tidied up to not handle RuntimeExceptions. The NullPointerExcepiton and IndexOutOfBoundsException's should not be handled by the Currency.replaceCurrencyData(..) bug report : http://bugs.s

Re: RFR JDK-8013254: Constructor \w need update to add the support of \p{Join_Control}

On 30/04/2013 22:01, Xueming Shen wrote: My apology, the webrev is at http://cr.openjdk.java.net/~sherman/8013254/webrev/ -Sherman On 04/30/2013 10:01 AM, Xueming Shen wrote: Hi, It appears we dropped the ball on u+200c and u+200d when we updated the "simple word boundaries" back to jdk7 I w

8015880: GenerateBreakIteratorData build warning

The new build emits a lot of warnings, the warnings when building the build tools are the most scary. One warning that is starting to stand out (as other issues are addressed) is the GenerateBreakIteratorData tool. In the case the issue is that it overrides equals but not hashCode. This is e

Re: 8015880: GenerateBreakIteratorData build warning

On 05/06/2013 18:47, Naoto Sato wrote: What about the regression risk? With this fix, the equality would differ from the prior releases. Would that be ignorable? Naoto This is the tool used in the build, it's the generated data files are that included in the runtime. I've run the regression te

Re: 8015880: GenerateBreakIteratorData build warning

On 06/06/2013 00:18, Masayoshi Okutsu wrote: When I noticed the warning, actually I tried the exactly same fix (both equals and hashCode). It was supposed to generate the same data after the fix, but the fixed one didn't generate identical data. I haven't had time to look into it further. Yes

Re: [8] Request for review: 8015960: java/util/Locale/LocaleProviders.java failing again on Windows

On 11/06/2013 18:55, Naoto Sato wrote: Hello, Please review an one-liner fix for the following bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015960 The fix is simply to set the time zone in the formatter to "PST": http://cr.openjdk.java.net/~naoto/8015960/webrev.00/ Naoto This loo

Re: [8] Request for review: 8015960: java/util/Locale/LocaleProviders.java failing again on Windows

On 11/06/2013 19:16, Naoto Sato wrote: Thanks for the review. Actually the time zone is set to a SimpleDateFormat instance, not to the system default, so it is ok to not restore anyway. Oh right, I had setDefault(TZ) on the brain from another discussion.

Re: [8] Request for Review: 6863624 : java/util/Currency/PropertiesTest.sh writable check is incorrect

Naoto, As the test might copy a currency.data into the JDK under test then it makes me wonder if this might cause interference for tests that are running concurrently (in other VMs). We might have to adding this directory to the exclusiveAccess.dir list (I don't know if there is an equivalent

Re: [8] Request for Review: 6863624 : java/util/Currency/PropertiesTest.sh writable check is incorrect

On 21/06/2013 21:30, Naoto Sato wrote: Good point. I will fix this later as it is not inherently related to this bug. Sure, it was just something that came to mind as I looked at it. Apparently the bug description claims the situation. That's why I moved the writable check from the top dir

TimeZone.DispayNames - remove it?

While snooping around in java.util.TimeZone I came across DisplayNames which doesn't appear to be be used anymore as the display cache is moved to TimeZoneNameUtility. Any objection if I remove it via the attached patched? The JDK builds without it and I am confident it is not used anywhere.

Re: TimeZone.DispayNames - remove it?

On 24/06/2013 03:49, Masayoshi Okutsu wrote: This appears to be a leftover of the cache cleanup activity. The fix looks good to me. Masayoshi Thanks. I've created 8017477 and will push this to jdk8/tl shortly. -Alan

Re: [8] Request for review: 8017322: java/util/Currency/PropertiesTest.sh should run exclusively

On 24/06/2013 22:20, Naoto Sato wrote: Hello, Please review the following test case fix. This is a follow-up for the issue that Alan pointed out [1]. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017322 http://cr.openjdk.java.net/~naoto/8017322/webrev.00/ Naoto [1]: http://mail.openj

Re: Additional source to guess the local timezone ID on linux

Including i18n-dev on this discussion because that is where this code is maintained. On 23/08/2013 22:09, Omair Majid wrote: Hi, The algorithm that OpenJDK uses to guess the local timezone ID on Linux goes like this: 1. If TZ environment variable is set, use that 2. If /etc/timezone is rea

Re: java.util.Locale changes

On 28/08/2013 14:25, Masayoshi Okutsu wrote: (adding core-libs-dev) Hi Christian, RFC 4647 defines The Language Priority List [1]. The use of java.util.List would be a natural fit, which is the reason why List is used. But use of Iterable does work (as API design). The parameter name `priori

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

On 02/09/2013 19:06, Seán Coffey wrote: This might be a slightly easier one to read. (fast path logic code first) http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ This is nicer (and I see Chris has already pointed out the redundant check). -Alan

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

On 02/09/2013 22:58, Seán Coffey wrote: Some minor modification (and further simplifying of conditions) : http://cr.openjdk.java.net/~coffeys/webrev.8023563.3/webrev/ This looks much better. -Alan.

Re: [8]RFR: 8024332: sun/util/resources/en split between rt.jar and localedata.jar

On 06/09/2013 20:01, Naoto Sato wrote: Hello, Please review the fix for the following bug. At the moment, it's not yet reflected in the bug database, but the symptom is that sun.util.resources.en package is split between rt.jar and localedata.jar, which would make it problematic in Jigsaw env

Re: RFR: 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing

On 24/10/2013 10:05, Aleksej Efimov wrote: Masayoshi, As Michael said, the time zone names changes is not finalized yet and I'll add new regression test as part of 8025051 and will remove this one. So, I suggest to keep this test and later remove it. I prefer not just remove a workable/questio

Re: RFR: 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing

On 24/10/2013 14:32, Aleksej Efimov wrote: Alan, Masayoshi, Michael, If you agree with the proposed changes then we can proceed with closing this bug. Can I ask you to sponsorship this change in such case? The hg patch located here: http://cr.openjdk.java.net/~aefimov/8026772/8026772_jdk8.patc

Re: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes

Adding i18n-dev as this is the mailing list where this area is maintained. On 05/11/2013 17:26, Aleksej Efimov wrote: Hi, Can I have a review for a 8027848 [1] bug fix . There is unimplemented functionality related to the future GMT offset changes. The ZoneInfoFile class doesn't analyses if th

Re: RFR: 8027370: (tz) Support tzdata2013h

On 05/11/2013 16:38, Aleksej Efimov wrote: Hi, Can I have a review for tzdata2013h integration [1]. The webrev link can be located here [2]. The following test sets were executed on build with fix: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/

Re: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script

On 08/11/2013 03:41, Patrick Zhang wrote: Sorry, I have some problems to connect to cr.openjdk.java.net yesterday. Now the webrev and result are attached. Please help to review. After checking the scripts in java.util, most of scripts have been finished in 8003890. So the webrev only change 2 r

Re: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script

On 08/11/2013 10:13, Patrick Zhang wrote: Hi Alan, I have created https://bugs.openjdk.java.net/browse/JDK-8028044 to hold it. Thanks, I'll push this for you with this new bug number. One thing that would be good to do is to go through all the issues in JDK-8019502 as it doesn't appear tha

8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone

We have a number of test failures in agentvm mode that appear to be caused by tests changing the default TimeZone and not restoring it. These failures become very intermittently when running with concurrency as it is unpredictable as to the sequence of tests that a specific agent VM will exec

Re: 8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone

On 21/11/2013 09:33, Masayoshi Okutsu wrote: On 11/21/2013 2:08 AM, Alan Bateman wrote: We have a number of test failures in agentvm mode that appear to be caused by tests changing the default TimeZone and not restoring it. These failures become very intermittently when running with

Re: [8] RFR: 8028771: regression test java/util/Locale/LocaleProviders.sh failed

On 27/11/2013 16:19, Naoto Sato wrote: Ping. I need to push this by 12/04, so your help is needed. Naoto If I understand correctly then it just means the tests silently passes when run on systems that are configured in a manner that requires a calendar that the JDK doesn't support. In that cas

Re: RFR: JDK-8035067: Move jdk/src/share/classes/java/util/CurrencyData.properties to jdk/make/data

On 17/02/2014 14:36, Erik Joelsson wrote: Hello, I found another data file that belongs in make/data. Bug: https://bugs.openjdk.java.net/browse/JDK-8035067 Webrev: http://cr.openjdk.java.net/~erikj/8035067/webrev.jdk.01/ This looks okay to me. Also cc'ing i18n-dev as this is where the currency

Re: Improve timezone mapping for AIX platform

Adding i18n-dev to the thread as i18n-dev is where the TZ code is maintained. On 26/03/2014 06:47, Jonathan Lu wrote: Hi ppc-aix-port-dev, core-libs-dev, Here's a patch for JDK-8034220, http://cr.openjdk.java.net/~luchsh/JDK-8034220/ It is trying to add the a more complete timezone mapping

Re: RFR: JDK-8039751: UTF-8 decoder fails to handle some edge cases correctly

On 09/04/2014 22:51, Xueming Shen wrote: Hi, Please help review the fix for JDK-8039751. Issue: https://bugs.openjdk.java.net/browse/JDK-8039751 webrev: http://cr.openjdk.java.net/~sherman/8039751/webrev/ This is the corner case (in 4 bytes sequence) we missed when fixing 7096080 [1]. T

Re: 8037343 Ready for review

Forwarding to i18n-dev as that it usually the list where changes to the locale and resources are maintained. -Alan On 15/05/2014 04:45, Sandipan Razzaque wrote: Hi all, Please find below the webrev for bug 8037343. http://www.sandipan.net/public/webrevs/8037343/webrev.00 Thanks in advance

Re: RFR [9] 8043613: Update .properties files for serialver tool

On 04/06/2014 13:44, Chris Hegarty wrote: Michael, This is a very trivial request, and follows JDK-8042887 "Remove serialver -show, this tool does not need a GUI". The only changes required are the removal of several values from the two localized property files. No additional translation is

Re: [9] RFR: 8039317: Read currency.data read as a resource

On 26/06/2014 00:16, Naoto Sato wrote: Hello, Please review the proposed fix to the subject issue: https://bugs.openjdk.java.net/browse/JDK-8039317 The fix is to move "currency.data" file from "lib" directory into "resources.jar" file, as this file is merely a data file: http://cr.openjdk.j

Re: [9] RFR: 8038092: Re-examine Bidi reflective dependency on java.awt.font

On 30/06/2014 18:35, Naoto Sato wrote: Hello, Please review the fix for the subject bug: https://bugs.openjdk.java.net/browse/JDK-8038092 The proposed change is located at: http://cr.openjdk.java.net/~naoto/8038092/webrev.0/ Thanks for looking at this issue. One part that doesn't look right

Re: [9] RFR: 8038092: Re-examine Bidi reflective dependency on java.awt.font

On 02/07/2014 01:42, Naoto Sato wrote: I further modified the fix: - Made sure the SharedSecret is lazily evaluated. - Added the missing JavaAWTFontAccessImpl file - Added a test case http://cr.openjdk.java.net/~naoto/8038092/webrev.2/ Please review. This looks much better. I think the only

Re: [9] RFR: 8038092: Re-examine Bidi reflective dependency on java.awt.font

On 02/07/2014 08:20, Alan Bateman wrote: : I think the only case that need detailed examination now is whether it is possible for SharedSecrets.getJavaAWTFontAccess to return null. I'm thinking about the case where 2+ threads use Bidi for the first time, or say something else initia

Re: [9] RFR: 8038092: Re-examine Bidi reflective dependency on java.awt.font

On 02/07/2014 16:43, Naoto Sato wrote: So I think the only question now is the test case and understanding why that needs to be updated. The test case ensures that even BidiBase class was loaded before TextAttribte/NumericShaper classes, it should work correctly. Version 1 of this fix (webr

Re: [9] RFR: 8038092: Re-examine Bidi reflective dependency on java.awt.font

On 03/07/2014 17:16, Naoto Sato wrote: With the original test case, webrev.1 and webrev.2 both succeed. With the modified test case (in webrev.2), webrev.1 fails but webrev.2 succeeds. The reason I changed the test case is to catch possible regression where someone makes changes to the SharedSe

Re: [9] RFR: 8038092: Re-examine Bidi reflective dependency on java.awt.font

On 03/07/2014 17:59, Naoto Sato wrote: Ok, now I think I got what you mean. So it could regress in two ways, one is what you wrote below, and the other I am seeing. So instead of modifying the existing test case, I just add a new one which basically is the same one in the previous webrev as fol

Re: [9] RFR: 8048123: Replace calendars.properties with another mechanism to specify a new Japanese calendar era

On 22/07/2014 08:06, Masayoshi Okutsu wrote: Hello, Please review the change for JDK-8048123. This change removes all the era definitions in ${java.home}/lib/calendars.properties. (The property file will eventually be gone later.) The major change is that any new era of the Japanese calendar

Re: [9] RFR: 8048123: Replace calendars.properties with another mechanism to specify a new Japanese calendar era

On 22/07/2014 14:06, Masayoshi Okutsu wrote: : Other minor comments in passing. The changes to LocalGregorianCalendar.parseEraEntry highlight that it is still using StringTokenizer, there might an opportunity to use String split here instead. But split() uses regex, which I think is too exp

Re: [9] RFR: 8048123: Replace calendars.properties with another mechanism to specify a new Japanese calendar era

On 23/07/2014 09:46, Masayoshi Okutsu wrote: Revised the webrev: http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.01 The changes from the previous one are: - Changed (originally ) to {@code - Replaced StringTokenizer with String.split() - Eliminated RuntimeException The use of {@code ..} and

Re: [9] RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata

On 22/08/2014 19:46, Naoto Sato wrote: Hello, Please review the changes for the following issue: https://bugs.openjdk.java.net/browse/JDK-8038436 The proposed changes are located at: http://cr.openjdk.java.net/~naoto/8038436/webrev.3/ The idea is to introduce an SPI so that supported locales

Re: [9] RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata

On 28/08/2014 19:34, Naoto Sato wrote: Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the changes based on your suggestions as follows: http://cr.openjdk.java.net/~naoto/8038436/webrev.4/ Here are the changes since webrev.3 - CLDRLocaleProviderAdapter.java: modified to thr

Re: [9] RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata

On 29/08/2014 22:07, Naoto Sato wrote: I incorporated the suggestions from Mandy and Alan. Also one change since the last webrev was to revert the hard-coding of the supported locales list back to the one which dynamically generates the lists at the build time. I initially thought static listin

Re: [9] RFR: 8057646: ClassCircularityError running SQE test

On 09/09/2014 00:04, Naoto Sato wrote: Hello, Please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8057646 The proposed changes are located at: http://cr.openjdk.java.net/~naoto/8057646/webrev.0/ It's not clear to me that this is the right place to address th

Re: [9] RFR: 8057646: ClassCircularityError running SQE test

On 09/09/2014 18:14, Naoto Sato wrote: It's an inherent issue where some init code issues locale sensitive services, such as in this case, *Formatter. So this could happen not only in Security class, but could be anywhere. So I think we still need the change proposed here in order for avoidin

Re: [9] RFR: 8061382: Separate CLDR locale data from JRE locale data

On 17/10/2014 23:31, Naoto Sato wrote: Hello, Please review the proposed changes to the following bug: https://bugs.openjdk.java.net/browse/JDK-8061382 The webrev is available at: http://cr.openjdk.java.net/~naoto/8061382/webrev.00/ This is mainly build changes to separate CLDR locale data i

Re: [9] RFR: 8061382: Separate CLDR locale data from JRE locale data

On 21/10/2014 01:25, Naoto Sato wrote: I think we can rename the original jdk.localedata to jdk.localedata.jre solely for the legacy JRE locale data, and create the new jdk.localedata.cldr. Or re-purpose jdk.localedata to represent the legacy JRE locale data, and newly create jdk.cldrlocaleda

Re: [9] RFR: 8061382: Separate CLDR locale data from JRE locale data

On 22/10/2014 20:52, Naoto Sato wrote: Hi Mandy, As I wrote in a separate email, my preference is the following module names: jdk.localedata.jre jdk.localedata.cldr This way, they both come under "localedata" (btw, they don't provide Locale, but the data for locale sensitive services such a

  1   2   >