[concurrency-interest] concurrency errors in java.lang.Throwable

Dhanji R. Prasanna dhanji at gmail.com
Wed Aug 2 20:25:11 EDT 2006


This is purely hypothetical (and probably not feasible), but if the
cause is effectively immutable (after being set) and getCause()'s
contract is to only ever return the cause, is there a problem with
making it synchronized and final?

Obviously it would break backwards compat but maybe something like a
SafeThrowable?

On 8/3/06, Gregg Wonderly <gergg at cox.net> wrote:
> Joe Bowbeer wrote:
> > On 8/2/06, Gregg Wonderly <gregg at cytetech.com> wrote:
> >
> >>Maybe I missed something.  Is it felt that there's no real value in
> >>synchronizing getCause() because subclasses might override it and not
> >>synchronize?  Is there a feeling that synchronizing getCause() would
> >>place some undue burden on JVM performance?
> >
> > It would be desirable to:
> >
> > 1. Declare detailMessage final
> > 2. Make getCause synchronized
> > 3. Most of all: document intent so we don't need to have these discussions
>
> Okay, that sounds like a good plan to me :-)
>
> Gregg Wonderly
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>


More information about the Concurrency-interest mailing list