On 10/15/14, 4:44 AM, Kumar Srinivasan wrote:
Amy,
The modifications you have made will not test pack200 compression
and normalization correctly, as the test needs ".class" files.
Sorry, I missed that.
Please review the updated version, test works on ".class" files
(Utils.TEST_CLS_DIR)
http:
On 10/13/2014 2:04 AM, Peter Levart wrote:
On 10/13/2014 04:18 AM, David Holmes wrote:
Looking at definePackage it seems both old and new code have serious
race conditions due to a lack of atomicity when checking the
parent/system packages. A package of the same name could be defined
in the
Claes, Peter,
Thanks for the revised webrev and Peter's thorough review. webrev.05
looks much better. My comment is mostly minor.
On 10/13/2014 8:41 AM, Claes Redestad wrote:
http://cr.openjdk.java.net/~redestad/8060130/webrev.05
ClassLoader.java
line 1582-1586 - I suggest to get rid of
On 10/13/2014 5:50 AM, David M. Lloyd wrote:
On 10/10/2014 07:31 PM, Mandy Chung wrote:
On 10/10/2014 8:10 AM, Claes Redestad wrote:
Hi all,
please review this patch which attempts to clean up synchronization
and improve scalability when
defining and getting java.lang.Package objects.
I ag
Hi Joe
Could you be my sponsor to push this if you’re okay with the code.
Thank you
Tristan
> On Aug 27, 2014, at 4:38 PM, huizhe wang wrote:
>
>
> On 8/27/2014 4:03 PM, Tristan Yan wrote:
>> Hi Joe and others
>>
>> I updated the tests with putting them in jaxp repo. I also run these tests
>>
Hi Joe
If you’re okay with the code; would you be my sponsor for this. We need move
forward and push these tests into openjdk repo.
Thank you so much
Tristan
> On Aug 29, 2014, at 11:21 AM, huizhe wang wrote:
>
> Hi Tristan,
>
> Looks good. I left notes in the bug's comment section as a record
Amy,
The modifications you have made will not test pack200 compression
and normalization correctly, as the test needs ".class" files. Do you know
why the test fails on windows ?
Kumar
On 10/14/2014 7:19 AM, Amy Lu wrote:
Please review the test fix.
bug: https://bugs.openjdk.java.net/browse/J
a
On Tue, Oct 14, 2014 at 10:55 PM, Alan Bateman
wrote:
> On 14/10/2014 18:38, Aleksey Shipilev wrote:
>
>> Thanks guys!
>>
>> And of course, I managed to do two minor mistakes in a two-line change:
>> the indentation is a bit wrong, and cast to String is redundant. Here is
>> the updated webrev
On 14/10/2014 18:38, Aleksey Shipilev wrote:
Thanks guys!
And of course, I managed to do two minor mistakes in a two-line change:
the indentation is a bit wrong, and cast to String is redundant. Here is
the updated webrev and the changeset (need a Sponsor!):
http://cr.openjdk.java.net/~shade/
Paul,
Thanks for the feedback!
Updated version:
http://cr.openjdk.java.net/~vlivanov/8059877/webrev.01/
http://cr.openjdk.java.net/~vlivanov/8059877/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8059877
Generally looks ok.
- MethodHandleImpl
786 if (wrapper.unblock(
On 14.10.2014 19:32, Stanimir Simeonoff wrote:
> Hi,
>
> This is an unrelated issue, yet is there any reason for the inner loop
> of equals to be written in such a (confusing) way?
>
> if (n == anotherString.value.length) {
> char v1[] = value;
> char v
Thanks guys!
And of course, I managed to do two minor mistakes in a two-line change:
the indentation is a bit wrong, and cast to String is redundant. Here is
the updated webrev and the changeset (need a Sponsor!):
http://cr.openjdk.java.net/~shade/8060485/webrev.01/
http://cr.openjdk.java.net/
Hi,
This is an unrelated issue, yet is there any reason for the inner loop of
equals to be written in such a (confusing) way?
if (n == anotherString.value.length) {
char v1[] = value;
char v2[] = anotherString.value;
int i = 0;
On 14 Oct 2014, at 17:33, Martin Buchholz wrote:
> Looks good to me!
+1 'noreg-hard'
-Chris.
> On Tue, Oct 14, 2014 at 9:05 AM, Aleksey Shipilev <
> aleksey.shipi...@oracle.com> wrote:
>
>> Hi,
>>
>> Please review a trivial change in String.contentEquals:
>> https://bugs.openjdk.java.net/
Looks good to me!
On Tue, Oct 14, 2014 at 9:05 AM, Aleksey Shipilev <
aleksey.shipi...@oracle.com> wrote:
> Hi,
>
> Please review a trivial change in String.contentEquals:
> https://bugs.openjdk.java.net/browse/JDK-8060485
> http://cr.openjdk.java.net/~shade/8060485/webrev.00/
>
> It improves
Hi,
Please review a trivial change in String.contentEquals:
https://bugs.openjdk.java.net/browse/JDK-8060485
http://cr.openjdk.java.net/~shade/8060485/webrev.00/
It improves the performance drastically:
http://cr.openjdk.java.net/~shade/8060485/perf.txt
...not to mention it improves the co
Thanks a lot!
-Pavel
On 14 Oct 2014, at 15:33, Chris Hegarty wrote:
> META-INF files in the webrev, two of which are in the wrong location. They
> are directly under 'META-INF’, where they should all be under
> ‘META-INF/services’. This is just a note for Pavel, when he follows up later
> wi
On 14 Oct 2014, at 15:15, Daniel Fuchs wrote:
> On 14/10/14 16:09, Chris Hegarty wrote:
>> On 14 Oct 2014, at 15:03, Pavel Rappo wrote:
>>
>>> OK, so what I will do for now is I exclude these 4 files and push without
>>> them. I'll create a new issue to add them later.
>>
>> That sounds like
Please review the test fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8060432
webrev: http://cr.openjdk.java.net/~weijun/8060432/webrev.00/
This test is to test
compareJars(new JarFile("normalized.jar"), new JarFile("repacked.jar"));
where the jar files (normalized.jar repacked.jar and origi
On 14/10/14 16:09, Chris Hegarty wrote:
On 14 Oct 2014, at 15:03, Pavel Rappo wrote:
OK, so what I will do for now is I exclude these 4 files and push without them.
I'll create a new issue to add them later.
That sounds like a fine plan. This issue has already gone on for long enough,
and
On 14 Oct 2014, at 15:03, Pavel Rappo wrote:
> OK, so what I will do for now is I exclude these 4 files and push without
> them. I'll create a new issue to add them later.
That sounds like a fine plan. This issue has already gone on for long enough,
and I don’t think that the crooks of the cha
OK, so what I will do for now is I exclude these 4 files and push without them.
I'll create a new issue to add them later.
-Pavel
On 14 Oct 2014, at 14:44, Alan Bateman wrote:
> On 14/10/2014 14:34, Daniel Fuchs wrote:
>> Hi Pavel,
>>
>> I saw your mail on build-dev.
>> I guess the issue will
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8059070
Webrev is http://cr.openjdk.java.net/~kshefov/8059070/webrev.00/
Thanks
-Konstantin
Here's the updated webrev: http://cr.openjdk.java.net/~prappo/8044627/webrev.01/
-Pavel
On 22 Sep 2014, at 09:55, Alan Bateman wrote:
> On 16/09/2014 12:12, Pavel Rappo wrote:
>> Hi everyone,
>>
>> Could you please review my change for JDK-8044627?
>>
> Pavel - are you planning to send an upd
On Oct 14, 2014, at 11:44 AM, Konstantin Shefov
wrote:
> Gently reminder
> Please, review this test bug fix backport
>
Looks ok to me, but i did not detect any difference between:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d37a314f2f64
and:
http://cr.openjdk.java.net/~kshefov/8058695/8u-
Hi,
Following a feedback from Alan - I dropped 'SecurityException'
from the throws clause of the new constructor - keeping
only the @throws in the API documentation.
Here is the new webrev (the above is the only change compared
to the previous webrev.01).
http://cr.openjdk.java.net/~dfuchs/webr
On Oct 14, 2014, at 10:26 AM, Konstantin Shefov
wrote:
> Gently reminder
> Please, review
>
+1
Paul.
> -Konstantin
>
> On 13.10.2014 19:04, Vladimir Ivanov wrote:
>> Looks good (not a Reviewer).
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 10/13/14, 6:22 PM, Konstantin Shefov wrote:
>
Gently reminder
Please, review this test bug fix backport
-Konstantin
On 13.10.2014 18:24, Konstantin Shefov wrote:
On 10.10.2014 13:06, Konstantin Shefov wrote:
Hello,
Please review and approve the backport of the test bug fix to 8u40
The bug: https://bugs.openjdk.java.net/browse/JDK-80586
Gently reminder
Please, review
-Konstantin
On 13.10.2014 19:04, Vladimir Ivanov wrote:
Looks good (not a Reviewer).
Best regards,
Vladimir Ivanov
On 10/13/14, 6:22 PM, Konstantin Shefov wrote:
Hello,
Please review and approve the backport of the test bug fix to 8u40
The webrev is slightly
Hi XML experts,
Can I humbly ask to review this simple fix.
Thank you,
Aleksej
On 08.10.2014 13:09, Aleksej Efimov wrote:
Hello,
Please, review the fix [1] for the 8046817 [2].
Problem: schemagen tool doesn't generate schema file for the enum
types [3].
SchemaGenerator class gets a list of a
30 matches
Mail list logo
