On 11/5/2014 8:15 AM, Daniel Fuchs wrote:
Here is the new webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.03/index.html
Looks good. Minor nits and no need to generate new webrev.
line 108: {@linkplain #reset} -- # is missing.
line 918-921: nit: formatting looks a little inc
On 11/6/2014 8:57 PM, david.b...@oracle.com wrote:
> Hi Joe,
>
> Thank you for the review!
>
>> Are you checking in the test (the one attached to the bug report)?
> I was not planning on it as I do not believe we should be adding test cases
> to JAXP that only test completely internal implementat
Hi Joe,
Thank you for the review!
> Are you checking in the test (the one attached to the bug report)?
I was not planning on it as I do not believe we should be adding test cases to
JAXP that only test completely internal implementation classes (i.e. white box
testing) for code paths that aren
Looks good.
Are you checking in the test (the one attached to the bug report)?
Cheers,
Joe
On 11/6/2014 7:08 PM, david buck wrote:
Hi!
May I please have a review of this fix:
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8062608
WEBREV: http://cr.openjdk.java.net/~dbuck/8062608/webrev.00/
Hi!
May I please have a review of this fix:
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8062608
WEBREV: http://cr.openjdk.java.net/~dbuck/8062608/webrev.00/
Cheers,
-Buck
Hi Joel,
On Thu, Nov 6, 2014 at 2:48 AM, Joel Borggrén-Franck
wrote:
> Hi,
>
> I’m having a hard time following this thread, which webrev has been updated,
> for which release, fixing which issue?
I am submitting the changeset for JDK-8062771, adding the finals and
the (failed reproduction) tes
Sorry, Paul, I missed your offer on the other thread to take this to
CCC. It's yours.
On Thu, Nov 6, 2014 at 10:50 AM, Martin Buchholz wrote:
> Hi Joe,
>
> I'd like you to do a code review.
>
> https://bugs.openjdk.java.net/browse/JDK-8063147
> Webrev:
> http://cr.openjdk.java.net/~martin/webre
I moved the change to getFields to another changeset, redid some
wording as suggested, harmonized getInterfaces and
getGenericInterfaces some more, and regenerated the
webrev.http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Class-spec/
On Tue, Nov 4, 2014 at 9:26 PM, joe darcy wrote:
> Hi Mart
Hi Joe,
I'd like you to do a code review.
https://bugs.openjdk.java.net/browse/JDK-8063147
Webrev:
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Class-getFields-spec/
getFields was embarrassingly undertested, so I added some.
Please shepherd through CCC.
Igor,
Thanks for your comment!
Here is the updated webrev:
http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/
-Konstantin
On 06.11.2014 17:36, Igor Ignatyev wrote:
Konstantin,
please use 'java.vm.info' instead of iteration over flags.
Igor
On 11/06/2014 01:44 PM, Konstantin Shefov wro
Hi Stanimir,
I believe this makes the code harder to follow as you now have to read
another method to follow the initialization of the arrays: The shifting
of crc and secondHalf is also different so it would still be some
difference between the two if I'm not mistaken.
Cheers,
Staffan
On 11
Hi Andrej,
Thanks for your comments. New webrev,
http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.08
Indeed more common :)
jdk/src/java.base/share$ grep -R "private final static" *|wc -l
282
jdk/src/java.base/share$ grep -R "private static final" *|wc -l
3274
//Staffan
On 11/06/2014
Konstantin,
please use 'java.vm.info' instead of iteration over flags.
Igor
On 11/06/2014 01:44 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8062904
Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.00/
Thanks
-Konsta
Hi Staffan,
I'm not a reviewer but I have small remarks to the code style:
- the instance variable "crc" is declared bevor the class variables. I
would move it closer to the constructor.
- documentation comments should be used for the fields "crc" and
"CRC32C_POLY", e.g. instead of
// Calc
Hi Staffan,
Given the tables in the static class init :
66 private transient final static int[] byteTable0 = byteTables[0];
67 private transient final static int[] byteTable1 = byteTables[1];
68 private transient final static int[] byteTable2 = byteTables[2];
69 private tra
>
>> HashArray.java:
>>82 Integer.highestOneBit(expectedMaxSize +
>> (expectedMaxSize << 1))
>>
>>
>> This effectively multiples expectedMaxSize by 3, I guess you meant >>
>> instead.
>>
>
> The intention of capacity(int expectedMaxSize) is to return the smallest
> power of 2 number
Hi,
I’m having a hard time following this thread, which webrev has been updated,
for which release, fixing which issue?
Martin, as far as I can see you are the only one of us who has replied to this
thread who is a jdk7u committer (or reviewer).
I think the assumption is that generic repositor
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8062904
Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.00/
Thanks
-Konstantin
Anyone have time to be the second reviewer?
http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.07
The CCC request has been approved for the new API.
Regards;
Staffan
On 10/22/2014 12:16 AM, Staffan Friberg wrote:
Thanks for the review. Updated the @implSpec.
Also includes Peter's good c
19 matches
Mail list logo
