commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [all] Commons SCXML 0.9 RC1 available
Date Sat, 22 Nov 2008 18:27:01 GMT
On Sat, Nov 22, 2008 at 12:13 PM, sebb <> wrote:
> On 22/11/2008, Rahul Akolkar <> wrote:
>>  Thanks for going over the Findbugs list. While this is a bit of a déjà
>>  vu for me ...
>>  ... I don't expect others to remember the discussion :-) and should
>>  have commented on it earlier in this thread.
> I've just had a look, and it raises some issues:
> Are all common Log implementations serialisable?
> Does it make sense for Log implementations to have to implement serialisable?
> If not, then it's an easy fix to use private static final instead of private.

Static probably not, container use expected:

> Alternatively, one could document that the code assumes the logging
> implementation is serialisable.

With the exception of AvalonLog perhaps, most provided impls are Serializable:

We could document this better in the FAQ (see last Q, in my mind,
custom log impls come close to user-defined content :-):

> The discussion on threading mentions setting variables once, and
> referring to them later, both without synchronisation. This is not
> guaranteed to work, unless the thread that sets the data then uses a
> lock that is also used by the reading thread(s) at least once after
> the variable was set. [With a shared lock, changes to shared variables
> by thread A "happen before" the lock is released, and lock release
> "happens before" the lock is acquired by thread B.]
> Constructors don't guarantee safe publishing either. Non-final
> instance fields that are set in a constructor and never updated are
> not necessarily accessible to other threads - that is why the
> java.lang.String instance fields had to be made final in Java 1.5. It
> is a good idea to do the same so as far as possible in other code.
> It's unlikely that testing - or even much production use - will ever
> find such problems, but that does not mean they cannot happen.
> It would be nice if the thread-safety guarantees (or otherwise) were
> documented in the Javadoc. Maybe that is something to work towards for
> the next release.

We do FAQ this a bit (see second last Q), but again, it could be more
elaborate and highlighted in various Javadoc bits.

>>  >
>>  > Class org.apache.commons.scxml.model.Data defines non-transient
>>  > non-serializable instance field node
>>  >
> I've had a look at a few of the classes that implement Node, and not
> yet found one that implements serialisable, so I don't know how that's
> going to work.

This one has broad usage in the target JDK for this release (and elsewhere):

The state machine's XML datamodel is user-defined content, but the
implication that the DOM impl needs to be Serializable could be better
stressed in the FAQ.

>>  > ==
>>  >
>>  > org.apache.commons.scxml.env.jexl.JexlEvaluator.evalCond(Context,
>>  > String) has Boolean return type and returns explicit null
>>  >
>>  > org.apache.commons.scxml.env.jsp.ELEvaluator.evalCond(Context, String)
>>  > has Boolean return type and returns explicit null
>>  >
>>  > These will cause problems if used later with autoboxing.
> Are these not problems when using Java 1.5+?

I will have to look (won't be today), but we do have a J6-minimum
branch already:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message