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

+1 for having check methods start with 'require' .. that's a nice and useful naming pattern. On Wed, Sep 30, 2015 at 9:13 AM, Remi Forax wrote: > > > - Mail original - > > De: "Paul Benedict" > > À: "Peter Levart" > >

Re: specdiff Re: RFR: jsr166 openjdk9 integration

I noticed that the Navigable* class descriptions were incompletely @link-ified. Index: src/main/java/util/NavigableMap.java === RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/NavigableMap.java,v retrieving revision

Re: JEP 264: Platform Logging API and Service

You are correct that the discussion on the serviceLoader may be off-topic wrt JEP 264. I believe I mentioned that currently Log4j only supports binding with a single implementation as well. But we don’t take the first, we take the one with the highest priority. Ralph > On Sep 30, 2015, at

Re: JDK 9 RFR of JDK-8136874: Bug in port of fdlibm pow to Java

Hi Joe, On Sep 25, 2015, at 10:33 AM, joe darcy wrote: > Full webrev of the changes up at > >JDK-8136874: Bug in port of fdlibm pow to Java - Java Bug System >http://cr.openjdk.java.net/~darcy/8136874.0/ > > The bulk of the changeset is a new battery of tests

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

On 9/30/15 2:30 PM, Steve Drach wrote: Hi Max, Can you describe if there is any effect on signed jars? Including: 1. Will jarsigner be able to sign such a jar? The jarsigner from 1.8.0_51 can sign the jar. The jarsigner from jdk9/dev can not, giving me the error jarsigner: unable to

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

Hi Max, > Can you describe if there is any effect on signed jars? Including: > > 1. Will jarsigner be able to sign such a jar? The jarsigner from 1.8.0_51 can sign the jar. The jarsigner from jdk9/dev can not, giving me the error jarsigner: unable to sign jar: javax.net.ssl.SSLException:

Re: JEP 269: Convenience Factory Methods for Collections

In my view, the proposal is pretty good. I too use Guava's immutable classes as types, because of the extra value obtained. But that does not mean these methods should not be in the JDK. (Not every project uses Guava). I'd argue for two changes to the JEP. Map.fromEntries() -> Map.ofEntries() In

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

On 09/29/2015 10:01 PM, Paul Sandoz wrote: >I think it's worth introducing Preconditions class. checkNotNull overloads are equally well suited for Objects as they are for Preconditions, so it's not wrong to have them in both, while checkIndex and friends don't really suit any of the

Re: JEP 264: Platform Logging API and Service

On 09/29/2015 11:17 PM, Ralph Goers wrote: 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

Re: RFR: JDK-8073187: Unexpected side effect in Pack200

Reviewed. Thank you, thank you, Joda-Time! — John On Sep 23, 2015, at 10:42 AM, Kumar Srinivasan wrote: > > Hi John, Sherman, > > I noticed a flaw in my fix, ie. in a section of the logic that is present > but unused, and reserved for future use, fixed it

Re: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

> On 25 Sep 2015, at 17:19, Peter Levart wrote: > > Hi Paul, > > Thanks for looking into this. > Apologies for the late reply. > On 09/25/2015 04:07 PM, Paul Sandoz wrote: >> Hi, >> >> This looks like a partial dup of >>

Re: specdiff Re: RFR: jsr166 openjdk9 integration

> On 30 Sep 2015, at 04:16, Martin Buchholz wrote: > > 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

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

On 29/09/15 16:43, Deva Sagar wrote: Hi Miran, Sorry for the delay in responding to this - I was busy with WLS release close down, and now I have moved to a different job in the cloud organization outside of WLS and web services. Regarding your question in #3 - I think Georgiy made a good

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

>>> The jarsigner from jdk9/dev can not, giving me the error >>> >>> jarsigner: unable to sign jar: javax.net.ssl.SSLException: >>> java.lang.RuntimeException: Unexpected error: >>> java.security.InvalidAlgorithmParameterException: the trustAnchors >>> parameter must be non-empty >>> >>> I’m

Re: RFR: JDK-8073187: Unexpected side effect in Pack200

looks good! sherman On 09/23/2015 10:42 AM, Kumar Srinivasan wrote: Hi John, Sherman, I noticed a flaw in my fix, ie. in a section of the logic that is present but unused, and reserved for future use, fixed it here anyway, for correctness. The full webrev:

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

> 在 2015年10月1日，上午2:51，Sean Mullan 写道： > >> The jarsigner from jdk9/dev can not, giving me the error >> >> jarsigner: unable to sign jar: javax.net.ssl.SSLException: >> java.lang.RuntimeException: Unexpected error: >> java.security.InvalidAlgorithmParameterException:

RFR (jaxp) 8136778: SAXParser: support stopping a parsing process

Hi, This is an enhancement to allow a SAX parsing process to be stopped and resumed. A SAX process scans through an entire document while making callbacks to its handler when defined events are met. The stop and resume methods make it easy to stop and subsequently resume the process as

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

Hi Max, Here are updated answers to your questions, after I received some help (thank you Sean Mullan). > Can you describe if there is any effect on signed jars? Including: > > 1. Will jarsigner be able to sign such a jar? The jarsigner from 1.8.0_51 can sign the jar. The jarsigner from

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

Hi Alexander, Martin, The challenge of Perl file slurping and Emacs one-liners was too much to bear. This is Java, so one-liners are hardly possible. Still, there are a bunch of improvements that can be made to the Java version. (OK, and I'm showing off a bit.) Take a look at this:

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

> 在 2015年10月1日，上午8:21，Steve Drach 写道： > >> Can you add a -debug option to show the full exception stack info? I even >> could not see how SSL is involved here. > > Would you still like me to do this? Yes, please. I cannot reproduce the problem in my jdk9 repo using a

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

- Mail original - > De: "Paul Benedict" > À: "Peter Levart" > Cc: "core-libs-dev" > Envoyé: Mercredi 30 Septembre 2015 16:06:18 > Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges > >

Re: JEP 264: Platform Logging API and Service

On 30/09/2015 14:59, Ralph Goers wrote: If I understand you correctly, then no that isn’t what I would want. The version and priority are captured in the same properties file where the class name is specified. If the class implements the wrong version or isn’t chosen due to its priority then

RFR 9: 8137313 : TreeTest.java intermittently fails with a timeout

Please review an enhancement to the test to help diagnose this failure in the ProcessHandle TreeTest. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-treetest-8137313/ Issue: https://bugs.openjdk.java.net/browse/JDK-8137313 Thanks, Roger

Re: RFR 9: 8137313 : TreeTest.java intermittently fails with a timeout

Adding additional diagnostic information to help find the root cause of the intermittent failures seems like the right thing to do. Reviewed. -Chris. On 30/09/15 15:21, Roger Riggs wrote: Please review an enhancement to the test to help diagnose this failure in the ProcessHandle TreeTest.

Re: specdiff Re: RFR: jsr166 openjdk9 integration

Note that the patches are not all independent - each patch was tested with previous patches applied. My original intent was to push all the patches at once, but of course there are testing advantages to pushing them individually. On Wed, Sep 30, 2015 at 5:59 AM, Paul Sandoz

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

Ah, I was going to write about "values" ... glad this was mentioned. With Valhalla working on value classes, it does raise the question if range-checking is particular to Objects. Clearly it won't be once values are introduced. PS: I am still in favor of using Objects at the time being though

Re: RFR 9: 8137313 : TreeTest.java intermittently fails with a timeout

+1 -Joe On 9/30/2015 7:49 AM, Chris Hegarty wrote: Adding additional diagnostic information to help find the root cause of the intermittent failures seems like the right thing to do. Reviewed. -Chris. On 30/09/15 15:21, Roger Riggs wrote: Please review an enhancement to the test to help

Re: JEP 264: Platform Logging API and Service

Alan, Your suggestion is literally the same thing that Peter suggested which is what my reply below was to. So you can take that reply as the reply to your message as well. What would be preferable is to have the serviceLoader accept “criteria” (which are callbacks) that can evaluate each of

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

On 30/09/15 16:20, Deva Sagar wrote: Hi Georgiy, I think both Miran and I are referring to the mention of SAAJMetaFactory in the bullet list about the public newInstance() method. The Javadoc of the SAAJMetaFactory class still describes it as an SPI and it is accessible from package-info.

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

On 30/09/15 16:50, Georgiy Rakov wrote: Hello Miroslav, could you please see some more comments below: 1. I believe it's better to say that exactly "fully qualified name" of the provider factory implementation class is assumed to be the value of the property: * {@code

Re: JEP 264: Platform Logging API and Service

Hi Ralph, On 30/09/15 18:30, Ralph Goers wrote: What would be preferable is to have the serviceLoader accept “criteria” (which are callbacks) that can evaluate each of the located services based on any additional properties that are included in the properties file and either eliminate them or