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 Roger! On Fri, Mar 11, 2016 at 4:26 PM, Roger Riggs wrote: > Hi Thomas, > > When returning the address of the fdentry, the style using [fd] is > preferred over > the implicit pointer arithmetic (as it was in the previous version). > > Occurs in all 3 deltas: >

JDK 9 RFR of JDK-8151763; Use more informative format for problem list

Hello, As Jon Gibbons has noted off-list, the problem list entries can directly include the bug number associated with the test in question, enabling better reporting. This format should be used rather than the current convention of putting the bug number in a comment. Please review the

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 03/12/2016 02:49 AM, Coleen Phillimore wrote: > On 3/11/16 6:36 PM, Aleksey Shipilev wrote: >> On 03/08/2016 01:55 AM, Coleen Phillimore wrote: Aside: see the last experiment, avoiding StringTable::intern (shows in profiles a lot!) trims down construction costs down even further. I'd

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 3/11/16 6:36 PM, Aleksey Shipilev wrote: On 03/08/2016 01:55 AM, Coleen Phillimore wrote: Aside: see the last experiment, avoiding StringTable::intern (shows in profiles a lot!) trims down construction costs down even further. I'd think that is a worthwhile improvement to consider. Hm,

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 03/08/2016 01:55 AM, Coleen Phillimore wrote: >> Aside: see the last experiment, avoiding StringTable::intern (shows in >> profiles a lot!) trims down construction costs down even further. I'd >> think that is a worthwhile improvement to consider. > > Hm, this is an interesting experiment.

Re: JDK 9 RFR of JDK-8151750: Mark ChangingInterests.java as intermittently failing

+1 On Mar 11, 2016, at 5:54 PM, joe darcy wrote: > Hello, > > With bugs JDK-8151749 and JDK-8149082 outstanding, the test > > java/nio/channels/Selector/ChangingInterests.java > > should be marked as intermittently failing. Please review the corresponding > patch below.

JDK 9 RFR of JDK-8151750: Mark ChangingInterests.java as intermittently failing

Hello, With bugs JDK-8151749 and JDK-8149082 outstanding, the test java/nio/channels/Selector/ChangingInterests.java should be marked as intermittently failing. Please review the corresponding patch below. Thanks, -Joe diff -r 0a1b582d18b3

RFR 9: 8085887 : java.time.format.FormatStyle.LONG or FULL causes unchecked exception

Please review java.time javadoc improvements to highlight a common misunderstanding about formatting elements that require a timezone in addition to the time. When using locale specific formatting, it may work if the locale formatting does not require a timezone or fail if the locale formatting

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

If there's no better way, then OK. Jan On 11.3.2016 09:59, Felix Yang wrote: Hi Jan, we have seen test runs hanging 15+ hours on several environments, which blocks other testing. So is it OK to exclude it before the fix ready? Thanks, Felix On 2016/3/11 16:12, Jan Lahoda wrote: Hi, I

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

Hi Nadeesh, Thanks for filling in the missing DateTimeException cases. - src/java.base/share/classes/java/time/chrono/IsoChronology.java: " * @throws DateTimeException if the value of any field is out of range, + * or if the day-of-month is invalid for the month-of-year" refers to

RE: Review request for JDK-8151063 : Typo in java.lang.invoke.StringConcatFactory

Hi Roger, I have attached the required changeset for JDK-8151063. Can you please sponsor for me to get it pushed? Thanks Abhijit -Original Message- From: Roger Riggs Sent: Friday, March 11, 2016 7:46 PM To: core-libs-dev@openjdk.java.net Subject: Re: Review request for JDK-8151063 :

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

Hi Thomas, When returning the address of the fdentry, the style using [fd] is preferred over the implicit pointer arithmetic (as it was in the previous version). Occurs in all 3 deltas: src/java.base/*/native/libnet/*_close.c: +result = fdTable + fd; and +result =

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

Hello! In general IntGenerator looks good, though I still like my Emitter idea :-) I will probably add it to my library regardless of this discussion. The problem with spliterator is that you should be very careful to fulfill the contract: - You must call the action at most once - If you called

Re: Review request for JDK-8151063 : Typo in java.lang.invoke.StringConcatFactory

Hi Abhijit, Reviewed (and I can sponsor to get it pushed if needed.) Roger On 3/11/2016 4:29 AM, Pavel Rappo wrote: Hi Abhijit, Looks good. (I'm not a Reviewer though.) I recommend you to create bugs on issues like this one (and [1]) trying to put as many typos per issue as possible. Also

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

Hi Tagir, I wonder if lambdas are the right tool in Java to express such generators. They have something in common - each generator uses a very specific internal state. So maybe an abstract Splitterator class that just needs one method to be implemented is perhaps concise enough and easier

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

Hi Michael, The comments are mostly about separating "access" and "loading". In publicLookup(): > which means it cannot find or access user classes publicLookup() still can access user classes (i.e. accessClass() can succeed), it only can't find them. In in(): > Access capabilities are

RE: Review request for JDK-8151065 : Typo in javax.naming.CompoundName

Hi Vincent, It'll be great if Pavel can do this for me. Thanks Abhijit -Original Message- From: Vincent Ryan Sent: Friday, March 11, 2016 5:14 PM To: Abhijit Roy Cc: Pavel Rappo; core-libs-dev Subject: Re: Review request for JDK-8151065 : Typo in javax.naming.CompoundName Your fix

Re: Review request for JDK-8151065 : Typo in javax.naming.CompoundName

Given the level of severity I assume process overhead would be way too big. So it's totally up to you. > On 11 Mar 2016, at 11:33, Abhijit Roy wrote: > > Hi Pavel, > > As of now I'm going to update in 9ea. But if you are suggesting me to update > in 8 as well, I can

RE: Review request for JDK-8151065 : Typo in javax.naming.CompoundName

Hi Pavel, As of now I'm going to update in 9ea. But if you are suggesting me to update in 8 as well, I can do that definitely. So, please let me know your suggestion. Thank you. Kind regards, Abhijit -Original Message- From: Pavel Rappo Sent: Friday, March 11, 2016 2:40 PM To:

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

> On 10 Mar 2016, at 18:14, Aleksey Shipilev > wrote: > > 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

Re: Review request for JDK-8151063 : Typo in java.lang.invoke.StringConcatFactory

Hi Abhijit, Looks good. (I'm not a Reviewer though.) I recommend you to create bugs on issues like this one (and [1]) trying to put as many typos per issue as possible. Also grouping typos by components. The reason is simple: separate bugs with current level of granularity and importance may

Re: Review request for JDK-8151065 : Typo in javax.naming.CompoundName

Hi Abhijit, Looks good. (Disclaimer: I'm not a "Reviewer".) Are you going to update this in JDK 8 or in JDK 9, or both? The reason I'm asking is that the bug states "Affects Version/s: 8u74" and the patch is prepared against JDK 9 as far as I can see. > On 11 Mar 2016, at 08:16, Abhijit Roy

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

Hi Jan, we have seen test runs hanging 15+ hours on several environments, which blocks other testing. So is it OK to exclude it before the fix ready? Thanks, Felix On 2016/3/11 16:12, Jan Lahoda wrote: Hi, I think I'd prefer to try to fix that. I think there's a good chance this fix:

Review request for JDK-8151063 : Typo in java.lang.invoke.StringConcatFactory

Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8151063 Bug - Typo in java.lang.invoke.StringConcatFactory Webrev - http://cr.openjdk.java.net/~rpatil/abhi/8151063/webrev.00/ I have rectified error and updated that one. And moving forward it for

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

Using the IntEmitter the Craps round could also be implemented easily and without additional classes: public static IntEmitter crapsEmitter(IntSupplier dice, int point) { return action -> { int roll = dice.getAsInt(); action.accept(roll); return roll == 7 || (point == 0 && (roll >

Review request for JDK-8151062 : Unclosed parenthesis in java.util.EnumMap.clone() Javadoc

Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8151062 Bug - Unclosed parenthesis in java.util.EnumMap.clone() Javadoc Webrev - http://cr.openjdk.java.net/~rpatil/abhi/8151062/webrev.00/ I have just rectified and closed the corresponding

Review request for JDK-8151065 : Typo in javax.naming.CompoundName

Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8151065 Bug - Typo in javax.naming.CompoundName Webrev - http://cr.openjdk.java.net/~rpatil/abhi/8151065/webrev.00/ I have just rectified and modified those error. And moving forward it for review.

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

Hi, I think I'd prefer to try to fix that. I think there's a good chance this fix: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039165.html will fix also the Mac OSX problem. Sadly, I didn't hear any feedback on that yet. Thanks, Jan On 11.3.2016 08:15, Felix Yang