For providing something informational, option #3 is a good choice.
It's simple (no need for new StackWalker access options), yet sufficient.
The changes look good to me.
Thanks,
-Brent
On 08/28/2017 07:37 PM, mandy chung wrote:
On 8/28/17 4:23 PM, Paul Sandoz wrote:
Hi Mandy,
Thanks! -B
On 08/25/2017 10:29 AM, Brian Burkhalter wrote:
+2
On Aug 25, 2017, at 10:28 AM, Naoto Sato <naoto.s...@oracle.com
<mailto:naoto.s...@oracle.com>> wrote:
+1
Naoto
On 8/25/17 10:03 AM, Brent Christian wrote:
Hi,
Please review this simple doc fi
Hi,
Please review this simple doc fix for:
https://bugs.openjdk.java.net/browse/JDK-8186217
When working on JDK-8029891, solutions were sought to avoid cluttering
up the Properties JavaDoc with new overridden methods. The @hidden tag
was considered, then later rejected.
Here[1] is the
Hi, Claes
Fix looks good, test looks good.
Thanks,
-Brent
On 08/21/2017 02:53 AM, Claes Redestad wrote:
Hi,
this patch addresses an unfortunate regression where backtick characters
in a manifest can cause an AIOOBE.
Webrev: http://cr.openjdk.java.net/~redestad/8186334/jdk.00/
Bug:
FYI, I plan to fix this by way of:
https://bugs.openjdk.java.net/browse/JDK-8186217
Remove erroneous @hidden JavaDoc tag from
java.util.Properties.replace(Object, Object, Object)
-Brent
On 8/14/17 10:02 AM, Brent Christian wrote:
Hi, Max
This tag snuck in by mistake. Before pushing
Hi, Max
This tag snuck in by mistake. Before pushing the fix for JDK-8029891,
we looked into ways to avoid addition of JavaDoc for all the
trivial method overrides. I tried adding @hidden tags,
but they didn't do what we wanted, so they were taken out. Except one -
sorry about that.
The fix looks good, Naoto.
Thanks,
-Brent
On 7/18/17 3:23 PM, Naoto Sato wrote:
Hello,
Please review this small fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8183902
The proposed fix is located at:
http://cr.openjdk.java.net/~naoto/8183902/webrev.00/
This is a
The fix looks good, Naoto.
Thanks,
-Brent
On 7/18/17 3:23 PM, Naoto Sato wrote:
Hello,
Please review this small fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8183902
The proposed fix is located at:
http://cr.openjdk.java.net/~naoto/8183902/webrev.00/
This is a
Thanks a lot for fixing that, Amy. Looks good.
-Brent
On 07/05/2017 07:16 PM, Felix Yang wrote:
Hi Amy,
looks fine. Just one comment on sentence below. "LOCALE" looks to be
a local variable, though used several times. Switch to usual naming?
50 final String LOCALE = args[2];
Thanks, Naoto. The updated changes look good.
-Brent
On 06/28/2017 03:13 PM, Naoto Sato wrote:
Thanks, Brent! Here is the updated webrev:
http://cr.openjdk.java.net/~naoto/8160199/webrev.04/
And my comments embedded below:
On 6/28/17 2:16 PM, Brent Christian wrote:
Hi, Naoto
This looks
Thanks, Naoto. The updated changes look good.
-Brent
On 06/28/2017 03:13 PM, Naoto Sato wrote:
Thanks, Brent! Here is the updated webrev:
http://cr.openjdk.java.net/~naoto/8160199/webrev.04/
And my comments embedded below:
On 6/28/17 2:16 PM, Brent Christian wrote:
Hi, Naoto
This looks
Hi, Naoto
This looks quite good.
I will test a bit with some of the trickier locales. BTW, the script
will now also be reflected in Locale.getScript() and
Locale.getDisplayScript().
Just a few comments:
---
src/java.base/macosx/native/libjava/java_props_macosx.h
Update copyright year
Hi, Naoto
This looks quite good.
I will test a bit with some of the trickier locales. BTW, the script
will now also be reflected in Locale.getScript() and
Locale.getDisplayScript().
Just a few comments:
---
src/java.base/macosx/native/libjava/java_props_macosx.h
Update copyright year
On 06/20/2017 06:14 AM, Claes Redestad wrote:
it felt reasonable to simplify the code to
consistently throw InternalError and remove a number of distracting
try-catch blocks.
With the try-catches gone, it looks like quite a few static fields could
now be initialized inline, and the static
That all looks fine to me, Amy.
(You'll also need a JDK 10 Reviewer).
Thanks,
-Brent
On 5/25/17 7:42 PM, Amy Lu wrote:
java/nio/Buffer/LimitDirectMemory.sh
Please review this patch to refactor the shell test to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8181126
webrev:
Hi, Mandy
Should "@key intermittent" be added, or is this pretty likely to resolve
the problem ?
Thanks,
-Brent
On 5/26/17 11:17 AM, Mandy Chung wrote:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180574/webrev.00/
The test fails intermittently that the hash of new_m1.jar might be the
Hi, Hamlin
That looks pretty good. A couple comments:
* If I'm not mistaken, main/othervm/policy=... is sufficient to enable
the default security manager, and specifying "-Djava.security.manager"
is unnecessary.
* Please add 8180732 to the @bug tag
You will also need approval from a JDK
Hi,
The test:
java/lang/ClassLoader/Assert.java
has been passing consistently on our automated test systems for quite a
while. The last recorded failure I found happened ~18 months ago.
I propose that the 'intermittent' jtreg key be removed from this test:
--
diff -r ee3280639210
Hi, Brian
This looks fine to me.
This will get some good bake time in 10, a chance for incompatibilities
(if any) to be revealed.
-Brent
On 5/17/17 1:54 PM, Brian Burkhalter wrote:
Please review at your convenience:
Issue: https://bugs.openjdk.java.net/browse/JDK-8177809 Patch:
Brent Christian wrote:
> Mandy Chung wrote:
>>
>> I think we could take out the automatic module case as named module
>> would verify it. One refactor you can consider by separating them
>> in several @run actions.
...
I think it would make the test easier to re
On 5/9/17 4:27 PM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/
Thanks for the clean up. Does each @run action need 4 mins timeout? Can it
restore to the default timeout?
Yes. Between the additional @runs and no longer testing automated
modules, I
On 5/12/17 9:11 AM, Mandy Chung wrote:
Minor comment:
95 private final List COMMON_ARGS;
This is an instance field and you can use lower case as the convention.
238 return !s.equals("");
You can consider using String::isEmpty.
Thanks, Mandy. I will make these
for Xcomp run,
the test would probably now be able to run for over an hour before
timing out.
I suggest making the test run faster, or seeing if there has been a
regressions in Xcomp to make test perform more poorly there.
Thanks,
-Joe
On 4/27/2017 12:08 PM, Brent Christian wrote:
Hi,
This test times
On 5/9/17 4:39 PM, Brent Christian wrote:
On 5/9/17 4:27 PM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/
Can it restore to the default timeout?
Yes. Between the additional @runs and no longer testing automated
modules, I believe that should be fine
not affect test execution.)
http://cr.openjdk.java.net/~bchristi/8177328/webrev.02/
Thanks,
-Brent
On 5/10/17 9:42 AM, Brent Christian wrote:
On 5/9/17 4:39 PM, Brent Christian wrote:
On 5/9/17 4:27 PM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/
Can
Hi,
This test times out under our automated testing configurations that
include -Xcomp.
Please review my change to increase the timeout for this test. It is
sufficient for the test configurations in question to pass on two
different local machines (Mac & Linux).
diff -r 7c04ab31b4d6
On 5/1/17 12:50 PM, Mandy Chung wrote:
On May 1, 2017, at 12:47 PM, Brent Christian <brent.christ...@oracle.com> wrote:
>>>
One refactor you can consider by separating
them in several @run actions. The timeout will apply to each action
but that does not help shorten the test
On 5/12/17 9:11 AM, Mandy Chung wrote:
Minor comment:
95 private final List COMMON_ARGS;
This is an instance field and you can use lower case as the convention.
238 return !s.equals("");
You can consider using String::isEmpty.
Thanks, Mandy. I will make these
not affect test execution.)
http://cr.openjdk.java.net/~bchristi/8177328/webrev.02/
Thanks,
-Brent
On 5/10/17 9:42 AM, Brent Christian wrote:
On 5/9/17 4:39 PM, Brent Christian wrote:
On 5/9/17 4:27 PM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/
Can
On 5/9/17 4:39 PM, Brent Christian wrote:
On 5/9/17 4:27 PM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/
Can it restore to the default timeout?
Yes. Between the additional @runs and no longer testing automated
modules, I believe that should be fine
On 5/9/17 4:27 PM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/
Thanks for the clean up. Does each @run action need 4 mins timeout? Can it
restore to the default timeout?
Yes. Between the additional @runs and no longer testing automated
modules, I
Brent Christian wrote:
> Mandy Chung wrote:
>>
>> I think we could take out the automatic module case as named module
>> would verify it. One refactor you can consider by separating them
>> in several @run actions.
...
I think it would make the test easier to re
On 5/1/17 12:50 PM, Mandy Chung wrote:
On May 1, 2017, at 12:47 PM, Brent Christian <brent.christ...@oracle.com> wrote:
>>>
One refactor you can consider by separating
them in several @run actions. The timeout will apply to each action
but that does not help shorten the test
to avoid such issues? I'm not sure how that can be assured though.
Roger
On 5/1/2017 3:47 PM, Brent Christian wrote:
On 5/1/17 12:41 PM, Mandy Chung wrote:
Looks like this test execs a new VM for 66 times to exhaust the
combination of with and without security manager, with a valid or
malformed
On 5/1/17 12:41 PM, Mandy Chung wrote:
Looks like this test execs a new VM for 66 times to exhaust the
combination of with and without security manager, with a valid or
malformed policy, client & custom loader in unnamed, named, automatic
module.
Right.
I think we could take out the
for Xcomp run,
the test would probably now be able to run for over an hour before
timing out.
I suggest making the test run faster, or seeing if there has been a
regressions in Xcomp to make test perform more poorly there.
Thanks,
-Joe
On 4/27/2017 12:08 PM, Brent Christian wrote:
Hi,
This test times
On 4/15/17 10:34 AM, Martin Buchholz wrote:
@index is new to me; I couldn't find any documentation
for it.
@index is part of JEP 225, Javadoc Search (right?)
https://bugs.openjdk.java.net/browse/JDK-8044243
-Brent
Hi, Stuart
The changes look fine. You found and changed all the references I could
find. Having the @index I think will be nice.
-Brent
On 4/14/17 3:36 PM, Stuart Marks wrote:
Hi all,
Please review this changeset that fixes up links around the JDK that
point to the old Collections
Hi, Naoto
On 4/5/17 2:14 PM, Naoto Sato wrote:
I revised the test case not to rely on shell script.
Yay! Hopefully this can also happen sometime for JDK 9+.
http://cr.openjdk.java.net/~naoto/816/webrev.01/
Looks fine to me, Naoto. A few comments:
* I presume additional @bug values
Hi, Naoto
On 4/5/17 2:14 PM, Naoto Sato wrote:
I revised the test case not to rely on shell script.
Yay! Hopefully this can also happen sometime for JDK 9+.
http://cr.openjdk.java.net/~naoto/816/webrev.01/
Looks fine to me, Naoto. A few comments:
* I presume additional @bug values
On 3/22/17 11:29 AM, Daniel Fuchs wrote:
I updated the webrev in place. I will now proceed with all
the paperwork to get that fix in 9 ;-)
http://cr.openjdk.java.net/~dfuchs/webrev_8177136/webrev.04
Looks good.
-Brent
Hi, Daniel
I think the new @throws tag gives a good explanation of the situation,
with instructions for someone wanting to get a System.Logger from JNI.
To nitpick on style, it's maybe on the long side for an @throws -
perhaps consider a slightly more concise version:
* @throws
Hi, Mandy
I agree that the new permission type is overkill.
The changes look good to me.
-Brent
On 3/15/17 12:42 PM, Mandy Chung wrote:
StackWalker::getInstance is currently specified to check for
StackFramePermission("retainClassReference“) due to an early review
feedback . Given it has
Hi, Naoto
That fix looks fine.
The "Portuguese (Brazil)" fix now happens before the Language ID fix,
but that shouldn't matter, as the "pt_BR" ID won't trigger that code
anyway (doesn't contain '-').
One very mall nit I noticed: one more space on line 97 will realign it
with line 96, which
Looks good to me, Naoto.
-Brent
On 02/14/2017 11:05 AM, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8174779
The proposed fix is located at:
http://cr.openjdk.java.net/~naoto/8174779/webrev.01/
The root cause of the problem
Looks good to me, Naoto.
-Brent
On 02/14/2017 11:05 AM, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8174779
The proposed fix is located at:
http://cr.openjdk.java.net/~naoto/8174779/webrev.01/
The root cause of the problem
This looks fine to me, Daniel.
Fun test case. :)
Thanks,
-Brent
On 02/03/2017 11:51 AM, Daniel Fuchs wrote:
Hi,
Please find below a simple fix for:
8173898: StackWalker.walk throws InternalError if called
from a constructor invoked through reflection.
dn't
need any changes.
Please make sure JPRT -testset hotspot works with this (or check it in
that way).
Yes, that runs cleanly, and I do plan to push through hs.
Thanks for having a look, Coleen.
-Brent
On 1/26/17 8:07 PM, Brent Christian wrote:
Hi,
Please review my updated approach for f
On 01/26/2017 05:07 PM, Brent Christian wrote:
I also removed the more simplistic CountLocalSlots.java test, given that
the updated LocalsAndOperands.java will now better cover testing -Xcomp.
I also noticed that we no longer need the LocalsCrash.java test. Removed.
-Brent
On 01/27/2017 08:26 AM, Mandy Chung wrote:
On Jan 26, 2017, at 5:07 PM, Brent Christian <brent.christ...@oracle.com> wrote:
Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
I agree with Remi to make the MODE_* constants in LiveStackFrameInfo final and
PrimitiveSlot
Hi,
Please review my updated approach for fixing 8156073 ("2-slot
LiveStackFrame locals (long and double) are incorrect") in the
experimental portion of the StackWalker API, added in JDK 9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
Webrev:
really good now!
best regards,
-- daniel
On 10/12/16 01:16, Brent Christian wrote:
On 12/07/2016 04:05 PM, Mandy Chung wrote:
I suggest to add two utility methods rather than the has method:
boolean dropClassLoaderName()
boolean dropModuleVersion()
Done.
430if (m != null
Hi,
Please review my fix for 8169389.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8169389
Webrev:
http://cr.openjdk.java.net/~bchristi/8169389/webrev.03/
The addition of classloader names (JDK-6749237) updated the format of
StackTraceElement.toString(). A field was added to store the
On 11/11/16 2:16 AM, Alan Bateman wrote:
>>>
Since there is already a @CallerSensitive protected static method
called "registerAsParallelCapable" for subclasses to call from their
blocks, the query could be called:
isRegisteredAsParallelCapable() ?
I doubt this name is already taken by any
On 11/17/16 11:09 AM, Alan Bateman wrote:
On 17/11/2016 18:25, Paul Sandoz wrote:
>>
Looks ok, but has indicated by Alan i would leave Class alone and
untested until Jake gets integrated, then follow up with another issue.
Actually no follow-up needed because it's updated in jake to specify
/~bchristi/8136831/webrev.01/
You will need to file a CCC for the change in behaviour of the Enumeration
returning getResources.
And for the new @throws, I should think.
Thanks, Paul
-Brent
On 16 Nov 2016, at 15:22, Brent Christian <brent.christ...@oracle.com> wrote:
Hi,
Please review
Hi,
Please review my fix for 8136831 - Undefined null behavior in
Class[Loader].getResource().
Bug:
https://bugs.openjdk.java.net/browse/JDK-8136831
Webrev:
http://cr.openjdk.java.net/~bchristi/8136831/webrev.00/
Class and ClassLoader have the following public methods for locating
Hi,
It seems that the method name used in 8165793[1], "isParallelCapable",
was a little *too* intuitive. An existing use of that method name has
been uncovered (via NetBeans, in Eclipse Equinox).
Because the newly added method was marked final, the pre-existing method
results in a
On 10/28/16 1:44 PM, Mandy Chung wrote:
On Oct 28, 2016, at 11:11 AM, Brent Christian <brent.christ...@oracle.com>
wrote:
Should something be done for STEs returned from
StackFrameInfo.toStackTraceElement() ?
Good catch - I missed it. I added package-private static m
Hi, Mandy
It looks pretty good to me. Just a couple small things:
* StackTraceElement.java
379 ClassLoader loader = cls.getClassLoader0();
It looks as if 'loader' isn't used...?
* Throwable.java
832 // VM to fill in StackTraceElement
833
On 10/11/16 8:25 AM, Alan Bateman wrote:
>
One thing that would be good is to beef up
the test to cover more scenarios, esp. loader L1 extends loader L2 where
you've got 4 combination of capable/non-capable to test.
I updated the test case to provide better coverage:
On 10/10/16 3:51 PM, Mandy Chung wrote:
Do you mind fixing @return in the registerAsParallelCapable method
with {@code true} amd {@code false} since you are in this method. No
need for a new webrev.
Sure, no problem.
Thanks,
-Brent
On 10/10/16 2:30 PM, Mandy Chung wrote:
The patch looks fine. It would be good to add @see
#registerAsParallelCapable in this new method. Also the first
“parallel capable” occurrance in the class spec and the
registerAsParallelCapable method spec to @linkplain
#isParallelCapable.
Thanks for
On 9/9/16 12:05 PM, Mandy Chung wrote:
I file a RFE and Brent Christian has agreed to work on it and will go through
JDK 9 FC approval request.
https://bugs.openjdk.java.net/browse/JDK-8165793
FYI, the review thread is here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016
Hi,
Please review my fix for 8165793. This follows the discussion here:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009328.html
The proposal is to add a new public method on ClassLoader:
/**
* Returns {@code true} if this class loader is
* {@linkplain
On 10/5/16 4:43 PM, David Holmes wrote:
Okay but this will still affect the lifecycle of the PDs because
without the strong reference in L, those weak references in the VM
will quickly be cleared.
There's also a strong reference held by the Class object itself (on the
VM side [1]).
Thanks
Yes! Good catch, thanks.
-Brent
On 10/5/16 2:08 PM, Naoto Sato wrote:
Typo in ClassForNameLeak.java? At line 103, "change" -> "chance"?
Naoto
On 10/5/16 12:38 PM, Brent Christian wrote:
Hi,
Please review my fix for 8151486, "Class.forName caus
Hi,
Please review my fix for 8151486, "Class.forName causes memory leak".
Bug:
https://bugs.openjdk.java.net/browse/JDK-8151486
Webrev:
http://cr.openjdk.java.net/~bchristi/8151486/webrev.00/
The test case reproduces the bug as such:
With a SecurityManager enabled, a class ("ClassForName") is
Thanks for making some improvements to these intermittent RMI tests.
I agree with Roger that I don't think we want to add the id to the @bug
of every test.
Also, it looks like there's an indentation change in JavaVM.java:
53 public static final long POLLTIME_MS = 100L;
(I believe
Thanks for the good suggestions. Webrev updated in place:
http://cr.openjdk.java.net/~bchristi/8165372/webrev.00/
-Brent
Hi,
Please review my fix for 8165372 : "StackWalker performance regression
following JDK-8147039"
Bug: https://bugs.openjdk.java.net/browse/JDK-8165372
Webrev: http://cr.openjdk.java.net/~bchristi/8165372/webrev.00/
8147039 reimplemented stack walking using javaVFrames in place of
v.03/
Mandy
On Sep 13, 2016, at 4:09 PM, Brent Christian <brent.christ...@oracle.com> wrote:
Hi, Mandy
Is a new JVM_STACKWALK_GET_CALLER_CLASS bit needed in jvm.h? AFAICT,
JVM_STACKWALK_FILL_CLASS_REFS_ONLY is already only set for the getCallerClass()
case.
Hi, Mandy
Is a new JVM_STACKWALK_GET_CALLER_CLASS bit needed in jvm.h? AFAICT,
JVM_STACKWALK_FILL_CLASS_REFS_ONLY is already only set for the
getCallerClass() case.
Could the new get_caller_class() instead check if
JVM_STACKWALK_FILL_CLASS_REFS_ONLY is set? (Yes, this would be a third
appened to have high-order bits set, it would be
interpreted as a 64-bit long value, and the preceding slot could have
its (legitimate) value overwritten:
slot 0: slot for real local int
slot 1: unused slot containing garbage w/ upper bits set
slot 2: 2nd slot of a long, containing the lo
Hi,
Please review this StackWalker fix in hotspot for 8156073, "2-slot
LiveStackFrame locals (long and double) are incorrect"
Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.01/
The experimental LiveStackFrame[1] interface for
On 8/16/16 8:33 PM, Mandy Chung wrote:
On Aug 16, 2016, at 1:54 PM, Brent Christian <brent.christ...@oracle.com> wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-7180225
Webrev: http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/webrev/
Specdiff:
http://cr.openjdk.ja
Hi,
Please review this change which does some cleanup around documenting
conditions for throwing SecurityExceptions.
It adds a missing @throws tag to Class.forName(String, boolean,
ClassLoader), and consolidates specifics in the @throws tags of
ClassLoader & Thread.
Bug:
Hi,
This idea has been brought up before [1].
I concur with Pavel's assessment. I would add that now that latin-1
Strings are stored in a more compact form in JDK 9 ("Compact Strings"
[2]), the performance profile of string data is further complicated.
Thanks,
-Brent
1.
Hi,
The fix for 7131356 introduced a minor behavior change in the value of
the "os.version" system property on MacOS.
On systems running an OS with a patch version of 0, we've started
including this in the value of os.version (e.g. "10.11.0"), whereas
before the trailing ".0" was omitted.
Thank you, Brian and Naoto!
-Brent
On 7/19/16 4:46 PM, Naoto Sato wrote:
+1
Naoto
On 7/19/16 4:45 PM, Brian Burkhalter wrote:
Hi Brent,
Looks OK to me.
Brian
On Jul 19, 2016, at 4:26 PM, Brent Christian
<brent.christ...@oracle.com> wrote:
Hi,
Please review some spacing and punct
On 6/30/16 9:53 AM, Brent Christian wrote:
When the minimum Mac build platform is SDK 10.10, we'll be able to call
operatingSystemVersion directly without using msgSend. We can also
consider removing this then.
FYI:
https://bugs.openjdk.java.net/browse/JDK-8160676
-Brent
On 6/30/16 9:53 AM, Brent Christian wrote:
When the minimum Mac build platform is SDK 10.10, we'll be able to call
operatingSystemVersion directly without using msgSend. We can also
consider removing this then.
FYI:
https://bugs.openjdk.java.net/browse/JDK-8160676
-Brent
On 6/29/16 4:47 PM, Mandy Chung wrote:
On Jun 29, 2016, at 12:36 PM, Brent Christian <brent.christ...@oracle.com>
wrote:
The code to restore behavior on older Mac systems is only a few
lines, so that seems like a good way to get testing going again.
I think we should move away from t
On 6/29/16 4:47 PM, Mandy Chung wrote:
On Jun 29, 2016, at 12:36 PM, Brent Christian <brent.christ...@oracle.com>
wrote:
The code to restore behavior on older Mac systems is only a few
lines, so that seems like a good way to get testing going again.
I think we should move away from t
Thanks, Brian
On 6/29/16 4:35 PM, Brian Burkhalter wrote:
Approved.
Brian
On Jun 29, 2016, at 4:33 PM, Brent Christian <brent.christ...@oracle.com
<mailto:brent.christ...@oracle.com>> wrote:
Thank you, Dave and Gerard.
I believe I still need to hear from a JDK9 Reviewer.
Thanks, Brian
On 6/29/16 4:35 PM, Brian Burkhalter wrote:
Approved.
Brian
On Jun 29, 2016, at 4:33 PM, Brent Christian <brent.christ...@oracle.com
<mailto:brent.christ...@oracle.com>> wrote:
Thank you, Dave and Gerard.
I believe I still need to hear from a JDK9 Reviewer.
Will do - thanks, Roger.
-Brent
On 6/30/16 6:46 AM, Roger Riggs wrote:
+1
Can you wrap a couple of very long lines to make the diff easier to read.
- 187
- 202
Thanks, Roger
On 6/29/2016 7:47 PM, Mandy Chung wrote:
On Jun 29, 2016, at 12:36 PM, Brent Christian
<brent.christ...@oracle.
fixing the original issue and for putting in this follow-up fix!
Looks good! (for full disclosure I proposed the workaround)
cheers
On Jun 29, 2016, at 2:36 PM, Brent Christian <brent.christ...@oracle.com> wrote:
Hi,
Please review the following change for JDK 9:
Bug:
https://bugs.openjdk.jav
fixing the original issue and for putting in this follow-up fix!
Looks good! (for full disclosure I proposed the workaround)
cheers
On Jun 29, 2016, at 2:36 PM, Brent Christian <brent.christ...@oracle.com> wrote:
Hi,
Please review the following change for JDK 9:
Bug:
https://bugs.openjdk.jav
Hi,
Please review the following change for JDK 9:
Bug:
https://bugs.openjdk.java.net/browse/JDK-8160370
Webrev:
http://cr.openjdk.java.net/~bchristi/8160370/webrev.00/
The fix for 7131356 fills in the "os.version" system property on Mac
using [NSProcessInfo operatingSystemVersion], available
Hi,
Please review the following change for JDK 9:
Bug:
https://bugs.openjdk.java.net/browse/JDK-8160370
Webrev:
http://cr.openjdk.java.net/~bchristi/8160370/webrev.00/
The fix for 7131356 fills in the "os.version" system property on Mac
using [NSProcessInfo operatingSystemVersion], available
I'm not familiar with this area. The changes looks reasonable enough to me.
-Brent
On 06/27/2016 01:19 PM, Kumar Srinivasan wrote:
I am not an expert in this area, if Sergey is ok with it.
I am fine with it.
Brent ?
Kumar
Thanks, Sergey.
Can someone from the core-libs launcher group
I'm not familiar with this area. The changes looks reasonable enough to me.
-Brent
On 06/27/2016 01:19 PM, Kumar Srinivasan wrote:
I am not an expert in this area, if Sergey is ok with it.
I am fine with it.
Brent ?
Kumar
Thanks, Sergey.
Can someone from the core-libs launcher group
h
case when we call CFLocaleGetIdentifier(), which I guess was the source
of my confusion.
I've removed that comment line, and reworked the comment a little bit.
http://cr.openjdk.java.net/~bchristi/7131356/webrev.05/
Thanks,
-Brent
On 6/23/16 8:24 AM, Naoto Sato wrote:
On 6/22/16 9:48 PM, Brent Chris
h
case when we call CFLocaleGetIdentifier(), which I guess was the source
of my confusion.
I've removed that comment line, and reworked the comment a little bit.
http://cr.openjdk.java.net/~bchristi/7131356/webrev.05/
Thanks,
-Brent
On 6/23/16 8:24 AM, Naoto Sato wrote:
On 6/22/16 9:48 PM, Brent Chris
On 6/23/16 8:24 AM, Naoto Sato wrote:
On 6/22/16 9:48 PM, Brent Christian wrote:
On 6/22/16 3:58 PM, Naoto Sato wrote:
2. I think mapping language/script combination to a typical locale is ok
to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS,
right?
In the meantime, I would like to have "user.script" set to
"Latn" in such a case.
Is this something that I could file a follow-on issue for? The existing
code doesn't set "user.script" in these cases, either, and it looks like
that would take some digging into java_
In the meantime, I would like to have "user.script" set to
"Latn" in such a case.
Is this something that I could file a follow-on issue for? The existing
code doesn't set "user.script" in these cases, either, and it looks like
that would take some digging into java_
In the meantime, I would like to have "user.script" set to
"Latn" in such a case.
Is this something that I could file a follow-on issue for? The existing
code doesn't set "user.script" in these cases, either, and it looks like
that would take some digging into java_
On 22/06/16 15:10, Alex Strange wrote:
On Jun 20, 2016, at 3:44 PM, Brent Christian <brent.christ...@oracle.com> wrote:
I'd prefer something that can build on SDK 10.9 and 10.10, etc.
There might be a way to #ifdef it out (not sure), but it's not worth it.
I came to the same conc
601 - 700 of 849 matches
Mail list logo
