Thanks for doing this - wordsmithing is hard.
Maybe
The unsigned
* right shift operator ({@code >>>}) is omitted, as this operation only
makes sense with a fixed word size.
On Mon, May 7, 2018 at 9:47 PM, joe darcy wrote:
> Hello,
>
> Over in BigInteger, 2^Integer.MAX_VALUE just isn't as eff
Thank you Paul!
On 2018/5/8 1:20 AM, Paul Sandoz wrote:
+1 seems reasonable.
I notice that both the linux and windows configuration also collect open files,
is this something that should also be added to the mac configuration? (using
lsof).
Tracked by https://bugs.openjdk.java.net/browse/JDK
Hello,
Over in BigInteger, 2^Integer.MAX_VALUE just isn't as effectively
infinite as it used to be. Please review the spec changes and CSR below
to clarify that the range of BigInteger is "arbitrarily large" but not
"infinite":
JDK-8202563: BigInteger/BigDecimal not immune to overflow, c
Would you please review the following patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8202756
webrev: http://cr.openjdk.java.net/~mli/8202756/webrev.00/
Thank you
-Hamlin
Thanks Vladimir!
Sorry I literally just pushed this before I saw your email.
David
On 8/05/2018 7:31 AM, Vladimir Ivanov wrote:
Looks good!
Best regards,
Vladimir Ivanov
On 5/6/18 15:11, David Holmes wrote:
webrev: http://cr.openjdk.java.net/~dholmes/8202686/webrev/
bug: https://bugs.openjd
On May 7, 2018, at 2:43 PM, David Holmes wrote:
>
> The grammar can be a bit subtle here. IIUC we would say:
>
> "Index %d out of bounds for length %d"
>
> but if we turn it around we'd say:
>
> "out-of-bounds index %d for length %d"
+1 And the hyphens could be dropped altogether,
which I th
Hi Goetz,
The grammar can be a bit subtle here. IIUC we would say:
"Index %d out of bounds for length %d"
but if we turn it around we'd say:
"out-of-bounds index %d for length %d"
Anyway changes seem fine to me. Couple of comments below.
On 8/05/2018 7:26 AM, Lindenmaier, Goetz wrote:
Hi,
Looks good!
Best regards,
Vladimir Ivanov
On 5/6/18 15:11, David Holmes wrote:
webrev: http://cr.openjdk.java.net/~dholmes/8202686/webrev/
bug: https://bugs.openjdk.java.net/browse/JDK-8202686
JDK-8200167 added additional checks to ensure receiver typechecks were
in place where needed for inv
Hi,
as a follow up to "8201593: Print array length in
ArrayIndexOutOfBoundsException." I promised
to check all occurances of out-of-bounds.
This change fixes them wherever the term is not used as an adjective:
http://cr.openjdk.java.net/~goetz/wr18/8202745-out-of-bounds/01/
Please review.
Best
Thanks Paul!
David
On 8/05/2018 3:01 AM, Paul Sandoz wrote:
I am not too familiar with the overall test but i could follow the logic for
the additions, looks good to me.
Paul.
On May 6, 2018, at 3:11 PM, David Holmes wrote:
webrev: http://cr.openjdk.java.net/~dholmes/8202686/webrev/
bug:
Hi,
This looks good, except that comments in method are now obsolete. I
suggest the following rewording:
http://cr.openjdk.java.net/~plevart/jdk-dev/8202548_ClassSpecializer/webrev.02/
Regards, Peter
On 05/07/18 18:57, Paul Sandoz wrote:
+1 this is better.
Paul.
On May 2, 2018, at 6:54
+1 seems reasonable.
I notice that both the linux and windows configuration also collect open files,
is this something that should also be added to the mac configuration? (using
lsof).
Paul.
> On May 3, 2018, at 5:00 AM, Amy Lu wrote:
>
> On macOS systems, the system configured proxy setting
I am not too familiar with the overall test but i could follow the logic for
the additions, looks good to me.
Paul.
> On May 6, 2018, at 3:11 PM, David Holmes wrote:
>
> webrev: http://cr.openjdk.java.net/~dholmes/8202686/webrev/
> bug: https://bugs.openjdk.java.net/browse/JDK-8202686
>
> JDK
+1 this is better.
Paul.
> On May 2, 2018, at 6:54 AM, Claes Redestad wrote:
>
> Hi,
>
> a small follow-up to JDK-8202184 in line with Peter Levart's suggestion,
> where we can avoid
> instantiating two different SpeciesData objects, and should avoid creating an
> instance of
> the Function
On 5/7/18 6:23 AM, Claes Redestad wrote:
Hi,
the --class-for-name jlink plugin was added as an experiment to test
and evolve the jlink plugin infrastructure. The actual effect of
enabling this plugin on standard images is very limited (only a
handful of Class.forName:s are replaced) and tur
+1
Paul.
> On May 7, 2018, at 5:43 AM, Claes Redestad wrote:
>
> Hi,
>
> I'll sponsor this trivial contribution.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202719
>
> Webrev: http://cr.openjdk.java.net/~redestad/8202719/open.00/
>
> Thanks!
>
> /Claes
>
> On 2018-05-07 14:35, Claes
+1
On Mon, May 7, 2018 at 5:43 AM, Claes Redestad
wrote:
> Hi,
>
> I'll sponsor this trivial contribution.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202719
>
> Webrev: http://cr.openjdk.java.net/~redestad/8202719/open.00/
>
> Thanks!
>
> /Claes
>
> On 2018-05-07 14:35, Claes Redestad wr
On 7 May 2018 at 14:19, B. Blaser wrote:
> On 6 May 2018 at 18:35, B. Blaser wrote:
>> On 5 May 2018 at 22:26, Kim Barrett wrote:
On May 5, 2018, at 8:03 AM, B. Blaser wrote:
On 4 May 2018 at 17:42, Alan Bateman wrote:
> On 04/05/2018 16:31, B. Blaser wrote:
>>
>> :
On 07/05/2018 14:23, Claes Redestad wrote:
Hi,
the --class-for-name jlink plugin was added as an experiment to test
and evolve the jlink plugin infrastructure. The actual effect of
enabling this plugin on standard images is very limited (only a
handful of Class.forName:s are replaced) and tur
+1
> On May 7, 2018, at 10:23 AM, Claes Redestad wrote:
>
> Hi,
>
> the --class-for-name jlink plugin was added as an experiment to test and
> evolve the jlink plugin infrastructure. The actual effect of enabling this
> plugin on standard images is very limited (only a handful of Class.forNa
Hi,
the --class-for-name jlink plugin was added as an experiment to test and
evolve the jlink plugin infrastructure. The actual effect of enabling
this plugin on standard images is very limited (only a handful of
Class.forName:s are replaced) and turns out it can be a breaking change
since re
Hi,
I'll sponsor this trivial contribution.
Bug: https://bugs.openjdk.java.net/browse/JDK-8202719
Webrev: http://cr.openjdk.java.net/~redestad/8202719/open.00/
Thanks!
/Claes
On 2018-05-07 14:35, Claes Redestad wrote:
Hi, looks like a reasonable cleanup.
I would expect very few application
Hi, looks like a reasonable cleanup.
I would expect very few applications actually use these, but at the
very least we'd save a few bytes of compiled bytecode.
/Claes
On 2018-05-06 17:19, Christoph Dreis wrote:
Hi,
I just noticed two places - namely in JarFile and JarVerifier - that could
mak
On 6 May 2018 at 18:35, B. Blaser wrote:
> On 5 May 2018 at 22:26, Kim Barrett wrote:
>>> On May 5, 2018, at 8:03 AM, B. Blaser wrote:
>>>
>>> On 4 May 2018 at 17:42, Alan Bateman wrote:
On 04/05/2018 16:31, B. Blaser wrote:
>
> :
>
> I'll create a new JBS issue (unless you
Hello,
I'm currently designing API that I'd like to keep somewhat consistent with
the Stream API and I've stumbled upon Stream.collect(), whose signature is:
R collect(Collector collector);
For most common usages, I would imagine that this signature would have
worked just as well:
R colle
Hi Hamlin,
to me this looks good.
Best regards
Christoph
> -Original Message-
> From: core-libs-dev [mailto:[email protected]] On
> Behalf Of Hamlin Li
> Sent: Montag, 7. Mai 2018 04:08
> To: [email protected]
> Subject: Re: RFR of JDK-8202291,java/rmi/N
Hi Roger,
new webrev:
http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/07/
See my comments inline.
> -Original Message-
> From: Roger Riggs [mailto:[email protected]]
>
> Hi Goetz,
>
> Just comments on the test/message format. (found in the 04 version of
> the webrev)
>
27 matches
Mail list logo
