commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
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 <sebbaz@gmail.com> wrote:
> On 22/11/2008, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
<snip/>
>>
>>  Thanks for going over the Findbugs list. While this is a bit of a déjà
>>  vu for me ...
>>
>>     http://markmail.org/message/si5kphud52ntxbqi
>>
>>  ... 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.
<snap/>

Static probably not, container use expected:

  http://wiki.apache.org/jakarta-commons/Logging/StaticLog


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

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

  http://markmail.org/message/kqee6ozfrb5ktehh

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

  http://commons.apache.org/scxml/faq.html


> 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.
>
<snap/>

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.
>
<snip/>

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

  http://xerces.apache.org/xerces-j/apiDocs/org/apache/xerces/dom/NodeImpl.html

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+?
>
<snap/>

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

  http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message