Re: RFR 8038075 : JNI warnings in jdk/src/share/native/sun/misc/VMSupport.c

Hi Vyom, I will sponsor your change and push the fix for you. best regards, -- daniel On 28/09/15 18:03, Roger Riggs wrote: Hi Vyom, Looks fine. Roger On 9/28/2015 11:46 AM, Vyom Tewari wrote: Hi All, Please review my changes for below bug. Bug: JDK-8038075 : JNI warnings

Re: RFR 8080418 Add Optional.or()

> On 28 Sep 2015, at 19:45, Stefan Zobel wrote: > > Hi Paul, > > is it a good idea to add the "{@inheritDoc}" to the toString() Javadoc of > Optional (and to retain it in OptionalDouble/Int/Long)? > > As Stuart Marks has observed in the Double/Int/LongSummaryStatistics

Re: RFR 8080418 Add Optional.or()

> On 29 Sep 2015, at 11:16, Stefan Zobel wrote: > > Looks good. One more nitpicking. "ifPresent() " in OptionalDouble/Int/Long > still uses the old wording > > > * If a value is present, perform the given action with the value, > * otherwise do nothing. > > > whereas

Re: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs

Updated: a few manual corrections were made (as @linkplain tags displays nested {@code } literally): http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch -checked with specdiff (which of course does not cover documentation for internal packages), no unexpected diffs detected. Regards,

Re: RFR 8135248: Add utility methods to check indexes and ranges

> On 29 Sep 2015, at 06:48, John Rose wrote: > > On Sep 28, 2015, at 5:10 PM, Joseph D. Darcy > wrote: >> >> Joining this thread late, I think the range checking methods would have a >> happier life where they are

Re: RFR 8080418 Add Optional.or()

Looks good. One more nitpicking. "ifPresent() " in OptionalDouble/Int/Long still uses the old wording * If a value is present, perform the given action with the value, * otherwise do nothing. whereas in Optional you have the better * If a value is present, performS the given action with

Re: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math

Good to see this happen. I agree a test would be good to demonstrate edge cases. 1) I think the code for floorMod(long x, int y); cannot actually overflow. As such, the result could just be cast without the if and throw. 2) My preferred algorithm for floorMod is: return ((a % b) + b) % b; as

Re: RFR 8135248: Add utility methods to check indexes and ranges

Just to note that an ideal location for this would be on a new class, one that has been discussed before, an "argument checker class". See Guava Preconditions: https://github.com/google/guava/blob/master/guava/src/com/google/common/base/Preconditions.java See Commons Lang Validate:

Re: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math

On 29 September 2015 at 16:02, Brian Burkhalter wrote: > 2) > My preferred algorithm for floorMod is: > > return ((a % b) + b) % b; > > as it contains no Java-side branches, although tests would be needed > to prove performance. > > This also allows an algorithm for

Re: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math

Hi Joe, Yes, I wanted to clear the conceptual portion first. Thanks, Brian On Sep 28, 2015, at 7:17 PM, Joseph D. Darcy wrote: > Do you think any tests are needed here, at least for a quick sanity check?

Re: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math

On Sep 29, 2015, at 8:05 AM, Stephen Colebourne wrote: >> I tested the code which was in the original issue description and found some >> discrepancies. I’ll need to revisit this to see what happened. > > Yes, the code in the issue for floorDiv() fails when the divisor is

Re: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math

Hi Stephen, On Sep 29, 2015, at 3:49 AM, Stephen Colebourne wrote: > Good to see this happen. Glad to hear it. > I agree a test would be good to demonstrate edge cases. I’ll add something. > 1) > I think the code for floorMod(long x, int y); cannot actually > overflow.

Re: RFR 8135248: Add utility methods to check indexes and ranges

> On 29 Sep 2015, at 12:57, Stephen Colebourne wrote: > > Just to note that an ideal location for this would be on a new class, > one that has been discussed before, an "argument checker class". > > See Guava Preconditions: >

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>> Please review the following webrev that adds support for multi-release jars >> as specified in JEP-238. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 >> >> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 >>

Re: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs

Hi Alexander, your change looks good. It's OK to have manual corrections for automated mega-changes like this, as long as they all revert changes. Random comments: Should you publish your specdiff? I guess not - it would be empty! while((s = br.readLine()) != null) { by matching

Re: RFR: jsr166 openjdk9 integration

I added MOAT.java to the integration. We noticed very rare failures testing WeakHashMap if the GC intervened at just the wrong time. (There's also changes to make the test portable to jdk8, since we still test against that)

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 9/29/2015 2:28 PM, Stephen Colebourne wrote: On 29 September 2015 at 21:01, Paul Sandoz wrote: The concern i have is once Preconditions is let loose the scope expands with proposals for “just one more method” (there is even the opportunity to bike shed over the

Re: JEP 264: Platform Logging API and Service

FWIW, I considered using the ServiceLoader to bind the Log4j API to the implementation. However, Log4j also includes the API version and only looks for bindings that implement that version. We also include a “priority” - the binding with the highest priority wins - at the moment. At some future

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 29 September 2015 at 21:01, Paul Sandoz wrote: > The concern i have is once Preconditions is let loose the scope expands with > proposals for “just one more method” (there is even the opportunity to bike > shed over the names checkNotNull or requiresNotNull etc. etc.)

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On Sep 29, 2015, at 1:46 PM, Steve Drach wrote: > >>> Please review the following webrev that adds support for multi-release jars >>> as specified in JEP-238. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 >>>

Re: JEP 269: Convenience Factory Methods for Collections

Hi all, I've been on vacation for a few days. Did anything happen while I was away? :-) I see this JEP was posted as a Candidate, and Kevin and Remi had some comments. I'll reply to Kevin's comments here and to Remi's separately. Kevin, I'm glad you don't think the proposal is bad. :-) I

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Can you describe if there is any effect on signed jars? Including: 1. Will jarsigner be able to sign such a jar? Are all items inside signed? If you sign a jar using jarsigner from different versions of JDK, will there be any difference? 2. Will jarsigner be able to verify such a jar? Will it

Re: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math

I revised floorMod(long x, int y) not to check explicitly check for integer overflow as it does not look as if this is even possible. I also updated the appropriate tests for these versions of the three methods at issue. In testing I still found discrepancies between the existing

Re: RFR: 8137289: java/util/logging/DrainFindDeadlockTest.java hangs

> On Sep 29, 2015, at 11:15 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > 8137289: java/util/logging/DrainFindDeadlockTest.java hangs > https://bugs.openjdk.java.net/browse/JDK-8137289 > > webrev: >

Re: JEP 269: Convenience Factory Methods for Collections

Hi Rémi, Thanks for looking at the proposal. We did consider this style of builder as one of the alternatives to what's in the JEP. The concern I have about builders such as this is that the number of entries isn't available at the time the map is to be built. For HashMap, this means that a

Re: specdiff Re: RFR: jsr166 openjdk9 integration

Thanks for the specdiff - much easier to review for javadoc changes!. I went through it. There were a small number of minor mistakes, which are now corrected. Now would be a good time to regenerate the specdiff. On Thu, Sep 24, 2015 at 1:35 AM, Paul Sandoz wrote: > >

RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi, Please review the following webrev that adds support for multi-release jars as specified in JEP-238. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305

Re: JEP 264: Platform Logging API and Service

On 20/09/15 15:46, Peter Levart wrote: On 09/18/2015 06:17 PM, mark.reinh...@oracle.com wrote: New JEP Candidate:http://openjdk.java.net/jeps/264 - Mark Hi, What is the purpose of exposing a factory for loggers in the generally exported package (java.lang) and making it standard Java API

RFR: 8137289: java/util/logging/DrainFindDeadlockTest.java hangs

Hi, Please find below a fix for: 8137289: java/util/logging/DrainFindDeadlockTest.java hangs https://bugs.openjdk.java.net/browse/JDK-8137289 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8137289/webrev.00/ There are in fact two failures reports under similar configuration: (slow

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 29/09/2015 19:13, Steve Drach wrote: Hi, Please review the following webrev that adds support for multi-release jars as specified in JEP-238. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238:

Re: JEP 264: Platform Logging API and Service

Hi Ralph, On 20/09/15 07:54, Ralph Goers wrote: I do have some questions on this. Would anyone realistically be able to use SLF4J/Logback or Log4j 2 as the implementation? The logging implementation needs to be able to configure itself before logging can realistically be performed. If

Re: RFR: 8137289: java/util/logging/DrainFindDeadlockTest.java hangs

On 29 Sep 2015, at 19:15, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > 8137289: java/util/logging/DrainFindDeadlockTest.java hangs > https://bugs.openjdk.java.net/browse/JDK-8137289 > > webrev: >

Re: RFR 8135248: Add utility methods to check indexes and ranges

It would be nice to introduce a Preconditions class (although I am not opposed to continue maturing Objects). I was waiting for the right time for this to be mentioned again (as it was mentioned in the past). Checking indices aren't the only thing we could add; another thing would be a method that

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 09/29/2015 06:05 PM, Paul Sandoz wrote: On 29 Sep 2015, at 12:57, Stephen Colebourne wrote: Just to note that an ideal location for this would be on a new class, one that has been discussed before, an "argument checker class". See Guava Preconditions:

Re: RFR 8135248: Add utility methods to check indexes and ranges

> On 29 Sep 2015, at 21:24, Peter Levart wrote: >> Just a few *more* bike sheds to paint :-) I am concerned i will never finish >> this nor other un/related tasks. >> >> For now I am ok with Objects being that "argument checker class” simply >> because it already has a