On Sat, Nov 22, 2008 at 12:13 PM, sebb <[EMAIL PROTECTED]> wrote: > On 22/11/2008, Rahul Akolkar <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
