activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: “Usage" and other performance improvements by avoiding CopyOnWriteArrayList.
Date Sat, 09 May 2015 03:04:24 GMT
On May 8, 2015 11:33 AM, "Kevin Burton" <> wrote:
> On Thu, May 7, 2015 at 6:05 AM, Tim Bain <> wrote:
> > The other reason a List sometimes gets used is when you want to be able
> > arbitrarily order the elements.  If you're using the natural ordering or
> > can write a comparator, you can use a SortedSet, but if you need them
to be
> > reorderable, I don't know of a Collection that allows arbitrary ordering
> > but enforces the Set semantic of not allowing duplicates.
> Yes.  And strictly speaking, in set theory, the order is irrelevant.  Sets
> are equivalent if they share the same members.  But I’m not sure Java sets
> are supposed to be identical set theoretic sets.

Set uses those semantics, while SortedSet adds guarantees about ordering.
(Set theory doesn't disallow ordering or guarantee non-ordering, it only
avoids making any guarantees at all about ordering, so this is an addition,
not a change, and SortedSets still conform to the semantics of theoretical
sets in addition to conforming to the ordering guarantee.)

> > I don't think that there's a need to arbitrarily reorder any of those
> > Collections you're changing, but you need to make sure none of them had
> > code that relied on inserting elements in sorted order and then having
> > maintaining that order.  I could easily see your changes resulting in
> > jumbled displays in the JMX beans (though maybe there's code that sorts
> > them at display time so maybe it's not a problem), so make sure you test
> > that thoroughly.
> >
> Ah.  I’ll take a look at that but didn’t see this yet.
> I’m also expecting the tests to find any irregularities.. hopefully.

I don't know whether to expect tests that check insertion/alphabetical
ordering of JMX beans given that the code has probably been giving us that
for free since it was written, nor whether that's the responsibility of the
code that exposes the beans or the responsibility of the JMX viewer such as
JConsole.  But I'd be cautious about assuming that all tests passing ==
everything's cool, because I could easily see not validating that
explicitly in a test.  But it would be a good test to have (if that's
actually our responsibility and not handled by the viewer).

> > Also, why are you doing Collections.newSetFromMap( new
> > ConcurrentHashMap<T,Boolean>()) instead of just new Concurrent
> > HashSet<T>()?  That seems super convoluted and ultimately not threadsafe
> > despite appearing to be; am I missing something?
> >
> I don’t think there is a ConcurrentHashSet… There’s a ConcurrentHashMap
> no ConcurrentHashSet.. The work around is to use newSetFromMap …
> I got bit by that too.  I just always assumed there was a
> but the above newSetFromMap works. It’s a lightweight Set implementation.
> In the JDK it’s literally just a 10 line decorator.

I'd always assumed there was one, though reading up on it I can see why it
would be better to be able to make sets from any arbitrary map type that
gets invented rather than having to keep adding set types.  Thanks for
teaching me something new today.  I also discovered that Guava's got a
static method to do those two lines you wrote if you wanted a convenience
It's syntactic sugar, but it makes for cleaner code so I'll probably use it
next time I need one of these.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message