Re: (Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi, may I have a review of this new iteration for this fix? Thank you! Thomas On Thu, Mar 3, 2016 at 5:26 PM, Thomas Stüfe wrote: > Hi all, > > https://bugs.openjdk.java.net/browse/JDK-8150460 > > thanks to all who took the time to review the first version of this fix! > > This is the new ver

Re: (Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Thomas, Looks good for me. But please wait for someone from core-libs team. PS: Could you also fix a typeo at 79, 51, 53? s/initialized/initialization/ 51 * Heap allocated during initialization - one entry per fd -Dmitry On 2016-03-10 10:59, Thomas Stüfe wrote: > Hi, > > may I have a r

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

Hi all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8030864/webrev.07/ Changes: + @throws DateTimeException if any of the values are out of range in Chronology.epochSecond() and new test cases related to excepted exception in TCKChronology.test_bad_epochSecond() Thanks

RE: [PING] RFR: JDK-8150704 XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees

Hi Joe, I've seen you have already submitted the change so I guess it's of no use going through the Apache License headers now... I would also be willing to improve the tests although you should probably give me some hint on how. Is it about improving the artificial xsl to stress the fix? Then

RFR: JDK-8043329: Wrong variable used in java.util.Collections javadoc code

Hi everyone! Could someone plaese review this tiny javadoc fix and sponsor it? Patch is in attaches. diff --git a/src/java.base/share/classes/java/util/Collections.java b/src/java.base/share/classes/java/util/Collections.java --- a/src/java.base/share/classes/java/util/Collections.java +++ b/sr

Re: RFR: JDK-8043329: Wrong variable used in java.util.Collections javadoc code

Looks ok Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad > On Mar 10, 2016, at 5:51 AM, Sergey Ustimenko wrote: > > Hi everyone! Could someone plaese review this tiny

Re: RFR: JDK-8043329: Wrong variable used in java.util.Collections javadoc code

Thank you, Lance. I would like second review and a sponsor for this one. (bug: https://bugs.openjdk.java.net/browse/JDK-8043329) Regards, Sergey. 2016-03-10 14:35 GMT+03:00 Lance @ Oracle : > Looks ok > > > Lance Andersen| > Principal Mem

Re: (Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Thank you Dmitry! I will fix the typo before comitting. Kind Regards, Thomas On Thu, Mar 10, 2016 at 9:19 AM, Dmitry Samersoff < dmitry.samers...@oracle.com> wrote: > Thomas, > > Looks good for me. But please wait for someone from core-libs team. > > PS: Could you also fix a typeo at 79, 51, 53

Re: RFR: JDK-8043329: Wrong variable used in java.util.Collections javadoc code

Hi Sergey, Small changes don't need multiple reviewers. I reviewed and will sponsor the fix. For more substantive contributions, you may want to become a contributor. [1] Thanks, Roger [1] http://openjdk.java.net/bylaws#contributor On 3/10/2016 6:48 AM, Sergey Ustimenko wrote: Thank you,

Re: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors

> On 8 Mar 2016, at 19:27, Paul Sandoz wrote: > >>> The changes in this webrev take advantage of those for JDK-8149469 >>> and apply the unsafe double addressing scheme so certain byte buffer >>> view implementations can work across heap and direct buffers. This >>> should improve the performanc

Re: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors

On 03/10/2016 08:06 PM, Paul Sandoz wrote: >> On 8 Mar 2016, at 19:27, Paul Sandoz wrote: >> The changes in this webrev take advantage of those for JDK-8149469 and apply the unsafe double addressing scheme so certain byte buffer view implementations can work across heap and direct b

RFR(S): 8150782: findClass / accessClass throw unexpected exceptions

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8150782 Webrev: http://cr.openjdk.java.net/~mhaupt/8150782/webrev.00/ The unexpected exceptions turned out to be non-issues; however it was advisable to add some explanations to the API documentation. Also, the ch

Re: [PING] RFR: JDK-8150704 XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees

Hi Christoph, Yes, an "Oops", sort of multitasking hazard, when I saw an all-test run passed, I was a bit too eager to get it closed. We'll get those headers fixed the next time we touch them. For the result files, I didn't quite like them either, we could have picked up a few keywords to com

Review request for JDK-8151660: Revert NativeBuffer.java to use jdk.internal.ref.Cleaner

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151660/webrev.00/ This is to revert NativeBuffer.java change in JDK-8149925. I can’t reliably reproduce the recursive initialization and this issue seems to be sensitive to the system configuration. JPRT build and tests are fine. I’m inclined to

Re: Review request for JDK-8151660: Revert NativeBuffer.java to use jdk.internal.ref.Cleaner

Hi Mandy, The patch looks fine to revert to the previous use with the old Cleaner. Roger On 3/10/2016 2:47 PM, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151660/webrev.00/ This is to revert NativeBuffer.java change in JDK-8149925. I can’t reliably reproduce the re

Re: Review request for JDK-8151660: Revert NativeBuffer.java to use jdk.internal.ref.Cleaner

Thanks. I’ll push and have the test systems to verify and check the test results. Mandy > On Mar 10, 2016, at 11:52 AM, Roger Riggs wrote: > > Hi Mandy, > > The patch looks fine to revert to the previous use with the old Cleaner. > > Roger > > > > On 3/10/2016 2:47 PM, Mandy Chung wrote:

Re: Review request for JDK-8151660: Revert NativeBuffer.java to use jdk.internal.ref.Cleaner

On 10/03/2016 19:47, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151660/webrev.00/ This is to revert NativeBuffer.java change in JDK-8149925. I can’t reliably reproduce the recursive initialization and this issue seems to be sensitive to the system configuration. JPRT

RE: [PING] RFR: JDK-8150704 XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees

Hi Joe, OK, thanks. I'll prepare the JDK 8 backport then. Best regards Christoph > -Original Message- > From: huizhe wang [mailto:huizhe.w...@oracle.com] > Sent: Donnerstag, 10. März 2016 19:07 > To: Langer, Christoph > Cc: core-libs-dev@openjdk.java.net > Subject: Re: [PING] RFR: JDK-8

Re: RFR(S): 8150782: findClass / accessClass throw unexpected exceptions

+1 On 3/10/2016 11:16 PM, Michael Haupt wrote: > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8150782 > Webrev: http://cr.openjdk.java.net/~mhaupt/8150782/webrev.00/ > > The unexpected exceptions turned out to be non-issues; however it was > advisable t

RFR 8151676/9, Add jdk/internal/jline/console/StripAnsiTest.java into problem list for MacOSX

Hi, please review at your convenience. This test jdk/internal/jline/console/StripAnsiTest.java has been observed hanging on several Mac OSX environments. Suggest to temporarily put into problemlist for Mac OSX. Bug: https://bugs.openjdk.java.net/browse/JDK-8151676 Thanks, Felix Pa

Re: RFR: 8072727 - add variation of Stream.iterate() that's finite

Hello! Just for your information I implemented two alternative stream producers as you suggested: // Produces stream of values returned by producer until the first // empty optional is produced public static IntStream produce(Supplier producer); // Produces stream of values until predicate retur

Re: RFR: 8072727 - add variation of Stream.iterate() that's finite

Here's the source code I wrote for this test: http://cr.openjdk.java.net/~tvaleev/patches/produce/ProduceTest.java I also have somewhat weird idea of emitters (added to this test class as well). Here's example: public static IntEmitter collatzEmitter(int val) { return action -> { act