[Biojava-dev] bjv2 alpha 3

Michael Heuer heuermh at acm.org
Mon May 24 15:16:55 EDT 2004


On Mon, 24 May 2004, Matthew Pocock wrote:

> Queue brain-dump... Utility methods are primarily intended for dumb
> users - dumb coder users. A different mechanism may be more appropreate
> for dumb drag-n-droppers. I am assuming from what you have said that
> bean editors let you do quasi-illegal things like invoking static
> methods relative to instances. I've no problem with 'skinning' bjv2 for
> a different user group. What if we had some magic like this:
>
> Object tool = new ToolFactory().makeTool(Utility.class)
>
> This returns a 1st class object with non-static methods that alias to
> the static tools methods on Utility.class and is serializable - would
> this help?

That is nifty but doesn't help with the public default constructor
problem.  Most reflective code won't be able to figure out factory
construction methods automatically.

There was a long debate on the commons-dev mailing list in 2002 and a
long second round of debate in 2003 that maybe isn't worth rehashing
here.  In the end the community decided to go with public constructors
documented against normal use, so that is what I was suggesting.

   michael


> What's the standard pattern for exposing processes through beans? I'd
> feel much happier if this level of logic was handled in a workflow
> language e.g. Taverna could be adapted so that all utility classes
> become processors. That way dumb d-n-d users realy don't have to look at
> any of the code.
>
> >It would be nice if more of BioJava could be made into valid beans.
> >Unfortunately this does render all of the elegant singletons invalid. If
> >only java had a keyword for a constructor that could be called only by the
> >VM to create a bean. I suspect such a thing would cause all kinds of
> >security problems though.
> >
> >- Mark
>



More information about the biojava-dev mailing list