Re: [text] (TEXT-70) Build failure with java 9-ea+159

Also don't this is a blocker. Sent from Yahoo Mail on Android On Sat, Mar 4, 2017 at 15:01, Rob Tompkins wrote: Hello all, I don’t think that the following issue (guessing it’s something with the maven-site-plugin) when running “mvn clean site” with java 9-ea+159 should hold up moving f

[text] (TEXT-70) Build failure with java 9-ea+159

Hello all, I don’t think that the following issue (guessing it’s something with the maven-site-plugin) when running “mvn clean site” with java 9-ea+159 should hold up moving forward with 1.0, but I wanted to see what other folks thought before I dive in to creating RC1. Cheers, -Rob > On Mar

Re: [CONFIGURATION] Changing method parameter to base class type

Hi Oliver, guess clirr is complaining because changing the parameter type of methods is not binary compatible: http://stackoverflow.com/questions/1365409/refactored-methods-and-binary-compatibility-in-java http://wiki.eclipse.org/Evolving_Java-based_APIs_2 -Pascal Am 03.03.2017 um 22:32 sch

[CONFIGURATION] Changing method parameter to base class type

Hi, in CONFIGURATION-653 [1] it is proposed to change the type of some method parameters of utility methods from Configuration to the base type ImmutableConfiguration. This makes those methods broader in scope. I would expect that this is a change which should not affect client code. Nevertheless

Re: [POOL] Use of Exception for caller class info

I remember that :) On 3 March 2017 at 12:15, Gary Gregory wrote: > Hi Matt, > > Feel free to hack on this yourself as all Apache Committers have karma > within Apache Commons. > > Gary > > On Fri, Mar 3, 2017 at 9:58 AM, Mark Thomas wrote: > > > On 03/03/2017 16:13, Matt Sicker wrote: > > > I s

Re: [POOL] Use of Exception for caller class info

Hi Matt, Feel free to hack on this yourself as all Apache Committers have karma within Apache Commons. Gary On Fri, Mar 3, 2017 at 9:58 AM, Mark Thomas wrote: > On 03/03/2017 16:13, Matt Sicker wrote: > > I started using commons-pool 2 yesterday to implement connection pooling > > for Elastics

Re: [POOL] Use of Exception for caller class info

Created . I should be able to implement this over the weekend hopefully. On 3 March 2017 at 12:05, Matt Sicker wrote: > Ok, glad to hear it's nothing specific. I'll make a ticket to track this. > > On 3 March 2017 at 11:58, Mark Thomas wrote: > >>

Re: [POOL] Use of Exception for caller class info

Ok, glad to hear it's nothing specific. I'll make a ticket to track this. On 3 March 2017 at 11:58, Mark Thomas wrote: > On 03/03/2017 16:13, Matt Sicker wrote: > > I started using commons-pool 2 yesterday to implement connection pooling > > for Elasticsearch (mainly for health checking, though

Re: [POOL] Use of Exception for caller class info

On 03/03/2017 16:13, Matt Sicker wrote: > I started using commons-pool 2 yesterday to implement connection pooling > for Elasticsearch (mainly for health checking, though who knows where this > internal project ends up going) and I noticed that Exception is used to > track users of objects from the

[POOL] Use of Exception for caller class info

I started using commons-pool 2 yesterday to implement connection pooling for Elasticsearch (mainly for health checking, though who knows where this internal project ends up going) and I noticed that Exception is used to track users of objects from the pool. In Log4j, we use a myriad of strategies t

Re: ImmutablePair and compareTo()

So would a further specialization be useful here for an immutable pair of immutable objects? In my own applications, I tend to embrace immutability everywhere (except for certain performance-intensive areas involving byte buffers and encoding/decoding), so being able to make assumptions about the u

Re: ImmutablePair and compareTo()

Hi Matt, Matt Sicker wrote: > I took a look at this yesterday and forgot to reply. Anyways, I agree that > ImmutablePair should override compareTo() since it can rely on its own > values not changing, whereas the implementation in Pair isn't as crazy > since it's mutable. ImmutablePair is only i

Re: ImmutablePair and compareTo()

I took a look at this yesterday and forgot to reply. Anyways, I agree that ImmutablePair should override compareTo() since it can rely on its own values not changing, whereas the implementation in Pair isn't as crazy since it's mutable. On 2 March 2017 at 15:55, Gary Gregory wrote: > I was going

JDK 9 EA Build 159 and JDK 8u152 is available on java.net

Hi Benedikt, *JDK 8u152 **Early Access b01 *is available on java.net *JDK 9 Early Access* b159 is available on java.net, summary of changes are listed here .