You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2017/03/02 21:55:11 UTC
ImmutablePair and compareTo()
I was going to replace my custom pair class with ImmutablePair but it looks
like the compareTo() methods in the superclass creates a LOT of objects on
each call. Any thoughts on a custom implementation that would not create to
much garbage to collect?
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: ImmutablePair and compareTo()
Posted by Matt Sicker <bo...@gmail.com>.
Considering the limitations in syntax available for this (compare to Rust
which makes things immutable by default and requires a "mut" modifier to
change things), I think it'd have to be documented that this sort of pair
would only work with objects that were effectively immutable. Let's see how
this definition works:
An effectively immutable object is an object where its fields are:
* final primitives or strings
* primitives or strings without the ability to change their values (so
effectively final like with lambdas)
* a final or effectively final object made up effectively immutable fields
I'm not sure how to fit arrays in there since you can only have an
effectively final array as the components themselves can't be marked final.
Another way to look at it is like this:
Objects are effectively immutable if a.equals(a) for the entire lifetime of
a.
The first definition gives a nice way to look at implementations while the
second definition gives the end result of what guarantee we'd need here.
On 26 March 2017 at 00:27, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Mar 3, 2017 at 8:05 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> > So would a further specialization be useful here for an immutable pair of
> > immutable objects?
>
>
>
> Hi Matt,
>
> But how would you guarantee that aside from using a marker interface to
> denote an object as being immutable? Are you talking about specializing for
> primitives or known JRE immutables like String and Integer? Curious...
>
> Gary
>
> 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
> > underlying objects would be nice.
> >
> > On 3 March 2017 at 09:58, Jörg Schaible <jo...@bpm-inspire.com>
> > wrote:
> >
> > > 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 immutable concerning the referenced objects, it
> > > cannot
> > > make any assumptions about those objects' immutability.
> > >
> > > StringBuilder builder = new StringBuilder();
> > > ImmutablePair<String, StringBuilder> = new ImmutablePair<>("key",
> > builder);
> > > builder.append("a");
> > >
> > > ImmutablePair just guarantees here that you will always have the same
> > > StringBuilder instance.
> > >
> > > Cheers,
> > > Jörg
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: ImmutablePair and compareTo()
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Mar 3, 2017 at 8:05 AM, Matt Sicker <bo...@gmail.com> wrote:
> So would a further specialization be useful here for an immutable pair of
> immutable objects?
Hi Matt,
But how would you guarantee that aside from using a marker interface to
denote an object as being immutable? Are you talking about specializing for
primitives or known JRE immutables like String and Integer? Curious...
Gary
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
> underlying objects would be nice.
>
> On 3 March 2017 at 09:58, Jörg Schaible <jo...@bpm-inspire.com>
> wrote:
>
> > 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 immutable concerning the referenced objects, it
> > cannot
> > make any assumptions about those objects' immutability.
> >
> > StringBuilder builder = new StringBuilder();
> > ImmutablePair<String, StringBuilder> = new ImmutablePair<>("key",
> builder);
> > builder.append("a");
> >
> > ImmutablePair just guarantees here that you will always have the same
> > StringBuilder instance.
> >
> > Cheers,
> > Jörg
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: ImmutablePair and compareTo()
Posted by Matt Sicker <bo...@gmail.com>.
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
underlying objects would be nice.
On 3 March 2017 at 09:58, Jörg Schaible <jo...@bpm-inspire.com>
wrote:
> 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 immutable concerning the referenced objects, it
> cannot
> make any assumptions about those objects' immutability.
>
> StringBuilder builder = new StringBuilder();
> ImmutablePair<String, StringBuilder> = new ImmutablePair<>("key", builder);
> builder.append("a");
>
> ImmutablePair just guarantees here that you will always have the same
> StringBuilder instance.
>
> Cheers,
> Jörg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: ImmutablePair and compareTo()
Posted by Jörg Schaible <jo...@bpm-inspire.com>.
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 immutable concerning the referenced objects, it cannot
make any assumptions about those objects' immutability.
StringBuilder builder = new StringBuilder();
ImmutablePair<String, StringBuilder> = new ImmutablePair<>("key", builder);
builder.append("a");
ImmutablePair just guarantees here that you will always have the same
StringBuilder instance.
Cheers,
J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ImmutablePair and compareTo()
Posted by Matt Sicker <bo...@gmail.com>.
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 <ga...@gmail.com> wrote:
> I was going to replace my custom pair class with ImmutablePair but it looks
> like the compareTo() methods in the superclass creates a LOT of objects on
> each call. Any thoughts on a custom implementation that would not create to
> much garbage to collect?
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>