[concurrency-interest] RFC -- Java7 java.util.concurrent plans

Chris Kessel/Lou Doherty chriskessel at verizon.net
Sat Dec 13 13:21:09 EST 2008

As an user of the libraries, I'd rather see descriptive names rather than
rely on looking at package imports to understand where it's from. Though,
that does depend a bit on expected usage context as I'll mention later.
When I'm reading through code and see HashMap, I'm going to think it's the
original hash map, not one from a different implementation. I'm not going to
go check what package it's imported from. I'm just going to make that quick
mental assessment of the feature set and keep reading on, which may very
well mean I've created the wrong mental mindset for reading the rest of that
code. If I see ConcurrentHashMap, that's a nice reminder to keep concurrency
in mind as I read the method/class and think about my modifications to that
However, context of usage is an important part of whether or not a generic
or overloaded name is confusing. You'll use a ConcurrentHashMap as a helper
to bring concurrency safety to your work in other domains. You'll typically
only use an Image or Canvas while working on GUI stuff, so it's being used
in a context that makes it's name more obvious. The SQL class Statement is a
horribly generic name, but it's only ever used in the context of a database
call, so there's little confusion. If someone made a 3rd party library that
helped support database work and created a class named Statement, even as
replacement for the original Statement, that'd be terribly confusing because
it corrupts the expected understanding of what "Statement" means in that
I suppose, for me, if the class is a helper to other domains, a more
descriptive name helps clarify what it's bringing to the table. If it's a
class used only within it's own domain (GUI, Socket communications, and DB
usage might be examples) then it's less important to clarify the name.


From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Osvaldo
Pinali Doederlein
Sent: Saturday, December 13, 2008 3:57 AM
To: dholmes at ieee.org
Cc: concurrency-interest
Subject: Re: [concurrency-interest] RFC -- Java7 java.util.concurrent plans

David Holmes wrote: 

I disagree - we prefixed CHM with Concurrent because it supports concurrent
access. The "Concurrent" prefix is descriptive giving an indication of the
kind of concurrency support that is given. It is not there simply because
something is in the java.util.concurrent package.

As it seems to me, the naming standard of the JavaSE APIs (and remarkably
for the Collections API) is that concrete types carry all the main semantics
and implementation meanings that are relevant to users. CRHM is a concurrent
(scalable / thread-happy), hashing (data structure algorithm / big-O
performance / requires keys to provide decent hashCode()), map (collection
kind) that holds references (memory mgmt behavior) to something. All these
meanings fit clearly in the [unwritten] criteria that's been used at least
since Java2, when API naming and design became much more homogeneous than in
JDK 1.0/1.1.

I understand that some people would like to drop "Concurrent" in the basis
of the DRY principle, as that class lives inside a java.util.concurrent
package. But this principle is not strongly observed in the JavaSE APIs -
for example, the java.lang.ref package is full of classes with "Reference"
prefixes (*). My vote is to favor consistency, but having the entire Java
SE/EE APIs as context. (Even the vast majority of third-party frameworks
tend to follow the same style.) I agree, too, that it's important to avoid
clashes with other collections even from different packages. It's very comon
usage to mix different kinds of collections in a single client class, so you
can' rely on packages alone (and in cases like java.util.List X
java.awt.List, clashes are common exactly because the domains are

(*) One could argue that names like "Weak" would look odd, incomplete: weak
what? But after Java5's generics you wouldn't write "Weak buffer", you write
"Weak<Image> buffer" that looks much better. It seems that post-generics,
naming style should often consider the full composition with generic
parameters. Although that's a difficult, case-by-case reasoning... for a
scenario like Weak<Image>, the Weak component looks like a trait, as one
reads "a weak image". Better style for Scala? ;-)


David Holmes

-----Original Message-----
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Bob Lee
Sent: Saturday, 13 December 2008 7:47 AM
To: Joe Bowbeer
Cc: concurrency-interest
Subject: Re: [concurrency-interest] RFC -- Java7 java.util.concurrent plans

On Fri, Dec 12, 2008 at 1:35 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

As for consistency, only 33% of the collection types in the util.concurrent
package start with "Concurrent". As a rule, I think a type should start with
"Concurrent" if it conflicts with a type of the same name in a different
package (like HashMap and ConcurrentHashMap), but that isn't the case here.

ConcurrentHashMap and ConcurrentReferenceMap both implement ConcurrentMap.

We had to prefix CHM with "Concurrent" because of HashMap, not because the
interface name starts with "Concurrent".




Concurrency-interest mailing list

Concurrency-interest at cs.oswego.edu





Osvaldo Pinali Doederlein                        Visionnaire Virtus S/A

osvaldo at visionnaire.com.br                http://www.visionnaire.com.br

Arquiteto de Tecnologia                          +55 (41) 337-1000 #226
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20081213/073d5b6c/attachment.html>

More information about the Concurrency-interest mailing list