[concurrency-interest] Concurrency-interest Digest, Vol 27, Issue 33

Martin Buchholz Martin.Buchholz at Sun.COM
Wed Apr 18 16:57:42 EDT 2007

> From: "David Holmes" <dcholmes at optusnet.com.au>
> Subject: Re: [concurrency-interest] LinkedBlockingQueue does not
> 	throwClassCastException
> To: "Szabolcs Ferenczi" <szabolcs.ferenczi at gmail.com>
> Cc: Concurrency-interest at cs.oswego.edu
> Message-ID: <NFBBKALFDCPFIDBNKAPCEEFIHGAA.dcholmes at optusnet.com.au>
> Content-Type: text/plain;	charset="iso-8859-1"
> My apologies, seems someone has (perhaps unintentionally) changed the
> specification, as I was looking at the Java 5 documentation:
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractQueue.html#add(E)
> where ClassCastException (and IllegalArgumentException) are not redeclared
> to be thrown.

There was a significant effort in jdk6 to have more correct exception
specifications in java.util.

6269713: (coll) Unchecked exception specifications of collection classes
are missing or inaccurate
6269739: BlockingQueue.drainTo needs to throw all unchecked exceptions
that Collection.add does
6458306: Executor classes missing unchecked exception specs

A key idea is that all of the AbstractFoo classes are for use only
by Collection Framework class implementers (that is, they provide only
code), and do not participate in the specification of use by clients.

Whether a concrete class
is a subclass of AbstractFoo should play no part in its specification.
Unfortunately, the Java language does not separate subtyping and
implementation inheritance, javadoc provides no way to mark a class or a
method as pure implementation, and javadoc always prefers superclasses
to superinterfaces for the purpose of javadoc inheritance, with the
result that creators of public concrete subclasses of AbstractFoo
need to do a lot of unnecessary specification cut-n-paste from Foo
instead of AbstractFoo.
At least we save some repetition with "@throws @{inheritDoc}"

This is unlikely to improve soon.

Inheritance has always been the most problematic feature of
Object Orientation.

> Given the use of generics, it is not unreasonable to infer that trying to
> add anything other than an E will indeed cause ClassCastException to be
> thrown.

In practice, many generified classes provide only compile-time type
safety, which can be circumvented using raw types and casting,
so programmers can and do add Integers to a List<String>.

> Arguably the Java 6 documentation is more correct,

I've always argued that the most recent spec (i.e. now jdk7) is the
best documentation available for previous releases (like jdk5).

 as until offer() et al
> are defined you don't know whether or not the exceptions will be thrown. But
> overall I have to say this is a bit of a mess. The base class is trying to
> allow for a range of conditions that a subclass might impose and so
> documenting the possible/potential exceptions, but the subclasses are
> leaving open the possibility for their own subclasses to strengthen the
> conditions, and so still declare exceptions that they themselves will never
> throw.
> There's really no way to fix this - the existing specifications will never
> be changed - even though is a documentation issue more than anything, as
> none of the exceptions involved are (or could be) checked exceptions.

Completely agreed.


> David Holmes

More information about the Concurrency-interest mailing list