Hi Kumar,
Changes look good to me!
Thanks,
David
On 10/05/2017 5:45 AM, Kumar Srinivasan wrote:
Hi David,
I have made the following changes:
1. Removed the launcher's check for model flags, allowing the VM to
process
and fail, aligned the test ChangeDataModel to the VM's message.
2. Fix
Another review for HTML 5 fixes, this time in the java.corba module.
As usual, changes are just to the markup, and not to any specification text.
JBS: https://bugs.openjdk.java.net/browse/JDK-8180041
Webrev: http://cr.openjdk.java.net/~jjg/8180041/webrev.00/
-- Jon
Thanks Lance!
Joe
On 5/9/2017 3:54 PM, Lance Andersen wrote:
Hi Joe,
Definitely reads much better
On May 9, 2017, at 6:51 PM, Brian Burkhalter
mailto:brian.burkhal...@oracle.com>> wrote:
Hi Joe,
The verbiage looks good (certainly much better than TODO), but the
new copyright year is now
On 5/9/2017 3:51 PM, Brian Burkhalter wrote:
Hi Joe,
The verbiage looks good (certainly much better than TODO), but the new
copyright year is now 20017. ;-)
wow, predicting copyright 18,000 years ahead of time, am I :-)
Fixed.
Thanks,
Joe
Thanks,
Brian
On May 9, 2017, at 3:15 PM, huiz
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 b
> On May 9, 2017, at 4:23 PM, Brent Christian
>
> I've removed the test case for automatic modules, and added a @run action for
> each policy file + system classloader configuration. I also removed the code
> to compile test sources, using @build instead.
>
> I also made some (hopefully) cla
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 read and understand the cases
it co
Hi Joe,
Definitely reads much better
> On May 9, 2017, at 6:51 PM, Brian Burkhalter
> wrote:
>
> Hi Joe,
>
> The verbiage looks good (certainly much better than TODO), but the new
> copyright year is now 20017. ;-)
>
> Thanks,
>
> Brian
>
> On May 9, 2017, at 3:15 PM, huizhe wang wrote:
Hi Joe,
The verbiage looks good (certainly much better than TODO), but the new
copyright year is now 20017. ;-)
Thanks,
Brian
On May 9, 2017, at 3:15 PM, huizhe wang wrote:
> Hi,
>
> Please review a fix for stax's package description. This is in a format
> similar to its SAX/DOM/Stream cou
Hi,
Please review a fix for stax's package description. This is in a format
similar to its SAX/DOM/Stream counterparts. For JDK 10, we could
consider converting to package-info.java.
JBS: https://bugs.openjdk.java.net/browse/JDK-8179868
webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8179868/
Hi David,
I have made the following changes:
1. Removed the launcher's check for model flags, allowing the VM to process
and fail, aligned the test ChangeDataModel to the VM's message.
2. Fixed up all the pre-existing conditions, pointed out earlier.
Full webrev:
http://cr.openjdk.java.ne
> On May 9, 2017, at 10:08 AM, Alan Bateman wrote:
>
>
>
> On 09/05/2017 17:58, Mandy Chung wrote:
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179950/webrev.00/index.html
>>
>> This is a regression caused by JDK-8020801 that the initialization of a
>> custom system c
On 09/05/2017 17:58, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179950/webrev.00/index.html
This is a regression caused by JDK-8020801 that the initialization of a custom
system class loader hits a code path that checks if a class is loaded by the
platform
looks fine Mandy...
> On May 9, 2017, at 12:58 PM, Mandy Chung wrote:
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179950/webrev.00/index.html
>
> This is a regression caused by JDK-8020801 that the initialization of a
> custom system class loader hits a code path that checks
Looks good to me Mandy!
Nice test :-)
best regards,
-- daniel
On 09/05/2017 17:58, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179950/webrev.00/index.html
This is a regression caused by JDK-8020801 that the initialization of a custom
system class loader hit
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179950/webrev.00/index.html
This is a regression caused by JDK-8020801 that the initialization of a custom
system class loader hits a code path that checks if a class is loaded by the
platform class loader. Such code path should not cal
+1
On 5/8/2017 9:54 PM, Brian Burkhalter wrote:
I agree. I would opt for (A) and be done with it.
On May 8, 2017, at 6:38 PM, Brian Goetz wrote:
Given that this went unnoticed for 18 years, the urgency seems low. Either (a)
or (b) sound fine to me. (c) sounds like a recipe for spending mo
To expand a bit on Martin's point - I think your benchmark should
include a 'baseline' version of bitCountInt/bitCountLong whose
implementation simply delegates to the JDK methods
(Integer.bitCount/Long.bitCount) - I see that bitCount is on the list of
supported intrinsics [1], so, by adding th
On Mon, May 8, 2017 at 10:54 PM Martin Buchholz wrote:
>
> Being able to do better here is very impressive.
>
> I took a quick look and found two things that a paranoid benchmarker like
> myself would not have done:
> - write the benchmark in scala instead of boring java
> - use jdk8 instead of "
This thread has just moved to net-dev mailing list:
http://mail.openjdk.java.net/pipermail/net-dev/2017-May/010785.html
Sorry for the noise, thanks.
> On 20 Apr 2017, at 17:08, Pavel Rappo wrote:
>
> Hello,
>
> Please review the following change:
>
> http://cr.openjdk.java.net/~prappo/81
+1
> On May 8, 2017, at 10:28 PM, Brian Burkhalter
> wrote:
>
> Please review this doc-only change [2] for [1] at your convenience with
> reference to [3].
>
> Thanks,
>
> Brian
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8179662
> [2] diff
>
> --- a/src/java.base/share/classes/java/io
On 08/05/17 22:43, Paul Sandoz wrote:
>> Given any "swap(exp, new)" function can be implemented as
>> "exchange(exp, new) == exp" I'm not sure why we have two complete
>> sets of functions all the way through. But I guess that is a
>> different issue. :)
>
> Yes, it might be possible after some ca
> On 9 May 2017, at 03:28, Brian Burkhalter wrote:
>
> Please review this doc-only change [2] for [1] at your convenience with
> reference to [3].
>
> Thanks,
>
> Brian
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8179662
> [2] diff
>
> --- a/src/java.base/share/classes/java/io/OutputSt
23 matches
Mail list logo