Naoto, Masayoshi, thanks for looking at this!
On 08/07/2014 07:38 AM, Masayoshi Okutsu wrote:
Sorry, I forgot about Calendar.getDisplayName. Perhaps the JRE semantic
(Locale.ROOT is English) support for all narrow names should be given up.
I will take over this one because it will require some
Hi Karen,
Thanks for the review. Please see my comments in-line.
On 8/6/14, 12:52 PM, Karen Kinnear wrote:
Ioi,
Changes look really good. Just minor comments:
1. jdk: SecureClassLoader.java: getProtectionDomain
please add a comment that this assumes no signers and combine the first and
third
Sorry, I forgot about Calendar.getDisplayName. Perhaps the JRE semantic
(Locale.ROOT is English) support for all narrow names should be given up.
I will take over this one because it will require some changes to the
locale service provider framework.
Thanks,
Masayoshi
On 8/7/2014 11:38 AM, M
A couple of responses inline ...
Cheers,
David
On 7/08/2014 11:25 AM, Ioi Lam wrote:
Hi David,
Thanks for the reviews. I will incorporate your suggestions. See
additional comments below:
On 8/6/14, 3:20 AM, David Holmes wrote:
Hi Ioi,
Continuing ... just a few minor comments
Thanks,
David
The root cause of this "problem" is the semantic difference between the
legacy JRE resources and the CLDR-drived resources. The root CLDR
resources have the narrow month names as numbers to be language-neutral,
while the JRE root resources have them as English. If you specify
Locale.ROOT, you w
Hi David,
Thanks for the reviews. I will incorporate your suggestions. See
additional comments below:
On 8/6/14, 3:20 AM, David Holmes wrote:
Hi Ioi,
Continuing ... just a few minor comments
Thanks,
David
--
hotspot/src/share/vm/memory/filemap.cpp
Nit: printing string literals doesn't
Looks good to me.
Naoto
On 8/5/14, 3:41 AM, dmeetry degrave wrote:
Hello,
Please review a simple fix (jdk 8 and 9) for
8042126: DateTimeFormatter "M" returns English value in Japanese locale
bug: https://bugs.openjdk.java.net/browse/JDK-8042126
fix: http://cr.openjdk.java.net/~dmeetry/80
Please review my fix for:
Bug:
https://bugs.openjdk.java.net/browse/JDK-8034032
Webrev:
http://cr.openjdk.java.net/~bchristi/8034032/webrev.0/
Within jdk/src/macosx/native/java/util/prefs/MacOSXPreferencesFile.m,
there is a pattern of making blocks of toCF() calls, where
later toCF() calls are
Ioi,
Changes look really good. Just minor comments:
1. jdk: SecureClassLoader.java: getProtectionDomain
please add a comment that this assumes no signers and combine the first and
third lines
2. classFileParser.cpp
Would it make sense to move the assertion from skip_over_field_name for
DumpSha
Hello,
I'm withdrawing this review request because the new tzdata2014f release
is available. I will update the 8049343 bug and will use it for later
tzdata2014f integration.
Thank you,
Aleksej
On 08/06/2014 05:30 PM, Aleksej Efimov wrote:
Hello,
Can I ask one more time for a review of this
I agree that assertions like assertThrows belongs in your test framework.
For this change my preference would be to revert to the previous code
without expectedExceptions but author preference wins.
On Wed, Aug 6, 2014 at 9:16 AM, roger riggs wrote:
> Hi,
>
> If a function like assertThrows wa
Hi,
If a function like assertThrows was included in TestNG, it would make
sense to use it.
The TestNG expectedException mechanism is adequate and creating a
one-off extension to TestNG
would raise the maintenance costs without adding much value.
Roger
On 8/6/2014 10:13 AM, Martin Buchholz w
I have more comments, but this is good to go.
69 @Test(expectedExceptions = {NullPointerException.class})
Controversial - many people, including myself, think this is too magical
without adding much value. My own preference is assertThrows e.g. in
http://gee.cs.oswego.edu/cgi-bin/viewcvs.
Hi,
I can't help but ask how this differs from sun.misc.Cleaner?
One concern is about security and robustness of the code that is run on
the system threads.
I don't have the history but these are very sensitive areas of operation.
Roger
On 8/6/2014 6:17 AM, Jaroslav Tulach wrote:
OK,
time to
Hello,
Can I ask one more time for a review of this tzdata fix, please?
-Aleksej
On 07/22/2014 11:21 PM, Aleksej Efimov wrote:
Hi,
Please review the tzdata2014e [1] integration fix to JDK9:
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.00/
Two issues with JSR310 implementation were
Hi Ioi,
Continuing ... just a few minor comments
Thanks,
David
--
hotspot/src/share/vm/memory/filemap.cpp
Nit: printing string literals doesn't need to use %s ie:
+ tty->print("%s", "[");
+ tty->vprint(msg, ap);
+ tty->print_cr("%s", "]");
Should just be:
+ tty->print("[
OK,
time to show the code. I've added an alternative patch to JDK-8051843:
https://bugs.openjdk.java.net/secure/attachment/21640/ActiveQueueFinalizer.diff
I suggest to start reading it from bottom - e.g. the test, the documentation
and then the implementation.
Now there is time for some discussi
On 06.08.2014 10:14, Martin Buchholz wrote:
39 private final static String PREFIXES[] = {"", "{", "@#$%"};
This C style syntax is not good Java style - use String[] instead.
Thanks! fixed
177 if (addLen == 0) {
178 compactElts();
179 return size =
18 matches
Mail list logo
