On 24/03/2009, Rony G. Flatscher <rony.flatsc...@wu-wien.ac.at> wrote: > > > sebb wrote: > > On 24/03/2009, ant elder <ant.el...@gmail.com> wrote: > > > >> Please review and vote on the BSF 3.0 beta3 release. The artifacts are > >> available at: > >> > >> http://people.apache.org/~antelder/bsf/3.0-beta3-RC1/ > >> > >> and the an SVN tag is at: > >> > >> https://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.0-beta3 > >> > > > > There are some duplicate classes in the testing hieararchy - most of > > these look OK, as they are in parallel testing directories. > > > > However testing/e4x/src/test/java/org/mozilla/javascript/ContextHelper > > has the same name - but not quite the same contents - as a class in > > the source directory. It should be renamed or deleted. > > > > There are also a few Javadoc errors. > > > > Neither of these are blockers. > > > > There are quite a few classes which are not thread-safe as they stand. > > I don't know which classes are supposed to be thread-safe, so perhaps > > this is not a problem. > > > > There also seem to be quite a few classes with protected mutable > > variables that are also accessible via public get/set methods. In some > > cases, this is what the Java 6 classes do, so I guess that cannot be > > changed, even though it makes the classes harder to test and make > > thread-safe ;-) > > > > However, there are some mutable protected variables which are not part > > of the Java 6 API, as far as I can tell: > > > > javax.script.SimpleBindings.map > > > > javax.script.ScriptEngineManager.* (all variables except globalscope) > > > > javax.script.ScriptException (all variables) > > > > These could be made private (and final) which would improve thread-safety. > > > > > >> +1 from me. > >> > > > > -1, on the basis that adding protected variables to the API means that > > the API is incompatible with JSR-223. > > > > Assuming that these need to be fixed before release, there are some > > other non-API classes that need fixing too. Let me know if you want me > > to provide patches or just update SVN. > > > > Well, if you can, then patches would be great, of course, and speed up > the updating process!
I can update SVN directly - and have just done so for some Javadoc fixes - but do I need to do so for code fixes? > Regards, > > > ---rony > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: bsf-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: bsf-dev-h...@jakarta.apache.org
