👍
📱
> On Jul 15, 2020, at 4:32 PM, Joe Wang wrote:
>
> Jim: I was referring to the rest of the process (the calls to
> toCodePoint/toUpperCase/toLowerCase), not isHighSurrogate itself. But Roger
> has a more comprehensive review on performance, and Naoto is planning on
> preparing a JMH tes
I fully understand. I’ll set up a separate bug.
Cheers,
— Jim
📱
> On Jun 5, 2020, at 8:57 PM, Magnus Ihse Bursie
> wrote:
>
> On 2020-06-05 13:59, Jim Laskey wrote:
>> I know there was a discussion about this elsewhere but I would like to take
>> the opportunity to correct this now
>>
>>
I’m fixing the two in java.base. The other two are in different modules and
would require changes to export. So you can file on those.
📱
> On Jun 5, 2020, at 5:36 PM, Stuart Marks wrote:
>
>
>
>> On 6/3/20 10:36 AM, Stuart Marks wrote:
>> 3) Integer wraparound/overflow during size computat
Understood. Just trying to balance correctness with providing meaningful
exceptions.
I suppose another approach is to let it all go deep and catch the error on the
way back and provide the detail then. Not likely win any fans.
📱
> On May 30, 2020, at 12:30 PM, Martin Buchholz wrote:
>
> I
Missed that it was a backout.
📱
> On May 29, 2020, at 11:18 PM, James Laskey wrote:
>
> You may not have intended this comment. s/offset/scale/
> 49
> 50 // Cached array base offset
> 51 private static final long ARRAY_INDEX_SCALE =
> UNSAFE.arrayInde
You may not have intended this comment. s/offset/scale/
49
50 // Cached array base offset
51 private static final long ARRAY_INDEX_SCALE =
UNSAFE.arrayIndexScale($type$[].class);
📱
> On May 29, 2020, at 11:05 PM, Mikael Vidstedt
> wrote:
>
>
> Looks good, thanks for fixing!
+1
📱
> On May 29, 2020, at 6:05 AM, Conor Cleary wrote:
>
> Hi,
>
> The method-level documentation of Intstream::reduce(int, IntBinaryOperator)
> mentions the average function as a case of reduction even though the function
> cannot be used with the reduce method. This might cause confusion
+1
📱
> On May 29, 2020, at 6:37 AM, Conor Cleary wrote:
>
> Hi,
>
> Could someone please review my webrev for JDK-8245658 'Arrays.java has two
> occurrences of bad unicode constants in Javadoc.'?
>
> In Arrays.java Javadoc, there were two instances of bad Unicode formatting
> where the nul
+1
📱
> On May 28, 2020, at 3:16 AM, sundararajan.athijegannat...@oracle.com wrote:
>
> Please review.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246034
>
> Webrev: http://cr.openjdk.java.net/~sundar/8246034/webrev.00/
>
> Thanks
>
> -Sundar
>
Thank you Paul.
📱
> On May 19, 2020, at 5:41 PM, Paul Sandoz wrote:
>
> +1
> Paul.
>
>> On May 19, 2020, at 1:00 PM, Jim Laskey wrote:
>>
>> Please review this change to remove the preview heading from the javadoc of
>> String::formatted. This also updates the @since to 15.
>>
>> Thank y
+1
On the road.
> On Jan 13, 2020, at 10:25 AM, sundararajan.athijegannat...@oracle.com wrote:
>
> Bumping the default timeout (other tests in the same dir have similar
> timeout settings).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8222100
>
> Webrev: http://cr.openjdk.java.net/~sund
Thank you Roger.
Sent from my iPhone
> On May 28, 2019, at 5:36 PM, Roger Riggs wrote:
>
> +1, Roger
>
>
>> On 05/28/2019 03:46 PM, Kim Barrett wrote:
>>> On May 28, 2019, at 3:39 PM, Jim Laskey wrote:
>>> Please review. Need to revert a change Sundar did earlier today that is
>>> causing
+1
> On Dec 7, 2018, at 8:11 PM, Claes Redestad wrote:
>
> Hi,
>
> following up from discussions during review of JDK-8214971[1], I
> examined the startup and peak performance of a few different variant of
> writing String::equals.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8215017/jdk.
It’s there. AlignIndent.java.
Sent from my iPhone
> On Dec 20, 2018, at 12:10 PM, Roger Riggs wrote:
>
> Hi Jim,
>
> Is there a missing test? I'd expect to see a corresponding test change also.
>
> otherwise, looks fine.
>
> Regards, Roger
>
>
>> On 12/19/2018 03:13 PM, Jim Laskey wrote
Or simply;
if (anObject instanceof String) {
String aString = (String)anObject;
if (coder() == aString.coder())
return Arrays.equals(value, aString.value);
}
}
Sent from my iPhone
> On Dec 6, 2018, at 10:56 PM, Stuart Marks wrote:
>
>> On
I wasn’t as fussy about the original comment but this one is also fine.
Sent from my iPhone
> On Dec 4, 2018, at 12:58 PM, Roger Riggs wrote:
>
> Hi Brian, Jim,
>
> Thanks for the reviews.
>
> I simplify the description, the full details are in the bug report
> and are more complete.
>
> Up
We went through the same exercise with jjs. Tough coming up with shebang tests
that worked on all platforms. Shebang args vs command line args was a
nightmare.
Sent from my iPhone
> On Jun 27, 2018, at 6:02 PM, mandy chung wrote:
>
> Looks good. It's amazing to find out 3 different behavior
Replicator (as in DNA)
Sent from my iPhone
> On Jun 18, 2018, at 6:49 PM, James Laskey wrote:
>
> Bifurcate
>
> Sent from my iPhone
>
>> On Jun 18, 2018, at 6:29 PM, Brian Goetz wrote:
>>
>> "bisecting" sounds like it sends half the eleme
Bifurcate
Sent from my iPhone
> On Jun 18, 2018, at 6:29 PM, Brian Goetz wrote:
>
> "bisecting" sounds like it sends half the elements to one collector and half
> to the other ...
>
> "tee" might be a candidate, though it doesn't follow the `ing convention.
> "teeing" sounds dumb.
>
>
>
+1
Sent from my iPhone
> On May 22, 2018, at 9:43 PM, Xueming Shen wrote:
>
> Thanks!
>
> webrev has been updated as suggested.
>
> http://cr.openjdk.java.net/~sherman/8200172/webrev/
>
> -Sherman
>
>> On 5/22/18, 4:30 PM, joe darcy wrote:
>> Hello,
>>
>> I think some larger re-wording is
+1
Thinking still needs CSR to track the change.
Sent from my iPhone
> On May 22, 2018, at 8:07 PM, Xueming Shen wrote:
>
> Hi,
>
> Please help review a api doc clarification for String.split()/Pattern.split().
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8200172
> webrev: http://cr
Will do.
Sent from my iPhone
> On May 9, 2018, at 10:38 PM, Stuart Marks wrote:
>
> A typical way to refer to a particular Unicode character by code point hex
> value is U+ (with more x's if necessary). For example,
>
> 2602 * Returns a string whose value is this string, with all le
Thanks Stuart. RE apinote, I was trying to follow the pattern of other older
method comments (Roman-style.) Comments/Javadoc in most of these older classes
are a mix of styles. Question: if you update/clean-up a method in an older
class, should you bring the comment/Javadoc up-to-date as well?
Thanks Paul.
Sent from my iPhone
> On Feb 28, 2018, at 10:13 PM, Paul Sandoz wrote:
>
> Hi Jim,
>
> Looks good. I like the power of 2 copying.
>
>
> 2978 * @throws IllegalArgumentException if the {@code count} is
> 2979 * negative.
> 2980 */
> 2981 public String
Didn’t I hear someone mentioning “\U1D11A” at some point?
Sent from my iPhone
> On Feb 18, 2018, at 1:10 AM, Stuart Marks wrote:
>
> Fair enough. I'll be less unhappy if there is a way to convert from a code
> point to a String, as requested by JDK-4993841. This will reduce
>
>new String(
Good to have the data. Thank you Louis.
Sent from my iPhone
> On Feb 15, 2018, at 4:52 PM, Louis Wasserman wrote:
>
> I don't think there's a case for demand to merit having a
> repeat(CharSequence, int) at all.
>
> I did an analysis of usages of Guava's Strings.repeat on Google's codebase
Sent from my iPhone
> On Jul 11, 2016, at 11:09 AM, Paul Sandoz wrote:
>
>
>> On 11 Jul 2016, at 14:17, Jim Laskey (Oracle)
>> wrote:
>>
>> I’m not sure if we can determine supplied classes vs others unless we
>> provide a flag or the set of supplied modules. At any rate, the rules for
stand the test
> JImageReadTest.java is not being run in any of the official test runs since
> it is currently on the exclude list.
>
> -Joe
>
>> On 1/9/2016 11:35 AM, James Laskey wrote:
>> Alan questioned why this is showing up after the sjavac changes. There was
>> concern t
Alan questioned why this is showing up after the sjavac changes. There was
concern there was some lurking issue.
Sent from my iPhone
> On Jan 9, 2016, at 3:19 PM, joe darcy wrote:
>
> Hello,
>
> The recent push of the fix for
>
>8146712: jdk/internal/jimage/JImageReadTest.java fails on
Changeset: a8bbd962f34a
Author:jlaskey
Date: 2013-01-28 16:29 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8bbd962f34a
8006676: Integrate Nashorn into new build system
Reviewed-by: jlaskey
Contributed-by: james.las...@oracle.com
! THIRD_PARTY_README
! make/launchers/Makef
Changeset: 3dc55f0c1b6f
Author:jlaskey
Date: 2013-01-28 16:29 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/rev/3dc55f0c1b6f
8006676: Integrate Nashorn into new build system
Reviewed-by: jlaskey
Contributed-by: james.las...@oracle.com
! common/autoconf/generated-configure.sh
! comm
Changeset: 7985ec3782b5
Author:hannesw
Date: 2013-10-25 10:20 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7985ec3782b5
8027042: Evaluation order for binary operators can be improved
Reviewed-by: lagergren, jlaskey, attila
! src/jdk/nashorn/internal/codegen/CodeGenerat
Changeset: 0feca8a93cb3
Author:attila
Date: 2013-06-05 10:44 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0feca8a93cb3
8015955: ObjectNode.elements should be stronger typed
Reviewed-by: lagergren, sundar
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/n
Changeset: 0bf451c0678d
Author:hannesw
Date: 2013-05-27 12:26 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0bf451c0678d
8015348: RegExp("[") results in StackOverflowError
Reviewed-by: sundar, attila
! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/sc
Changeset: 833a9a584b64
Author:attila
Date: 2013-05-21 13:40 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/833a9a584b64
8014953: Have NativeJavaPackage throw a ClassNotFoundException when invoked
Reviewed-by: jlaskey, sundar
! src/jdk/nashorn/internal/runtime/NativeJava
Changeset: b754fb89367d
Author:jlaskey
Date: 2013-04-30 10:05 -0300
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b754fb89367d
8006220: Simplify PropertyMaps
Reviewed-by: hannesw, lagergren
Contributed-by: james.las...@oracle.com
! src/jdk/nashorn/internal/codegen/MapCreator.
36 matches
Mail list logo
