[jsword-devel] Activator classes across the JSword library

Chris Burrell chris at burrell.me.uk
Thu Aug 23 14:33:09 MST 2012

Hi all

Just wondering if this section of the "Activator" code was introduced to
reduce memory as a result of observing an issue, or not? I'm looking at
SwordGenBook in particular, but seeing all kinds of interesting things

   - Activator has a reduceMemoryUsage method. This is based on KILL. Of
   the 3 enum constants, only 1 has a method that actually does something. And
   as far as I can tell, anyone can call reduceMemoryUsage at any time, which
   will then thoroughly break anything in the process of running by nulling
   out a whole load of references.
   - Secondly, there is this Lock object. It's not used to synchronise on,
   nor used in any form. The private javadoc comment is slightly mis-leading,
   unless I'm missing a piece of code somewhere.
   - SwordGenBook.activate gets an empty set from its parent, and thereby
   the loop doesn't do anything.
   - the "global" field is always an empty ReadOnlyList as a result, can we
   remove and simplify this?

In the SwordBook:

   - activate() does nothing (apart from registering it with the activator,
   which seems to defeat the point as there is no clean-up)
   - deactivate() deactivates the backend it is based upon. Should this be
   done preferably by the backend rather than here?

Finally, in order to address JS-109 and contain the refactoring process, I
am thinking of changing the method signature for
AbstractPassageBook.getRawText(). My intended approach is to pass in an
extract parameter, as 1 or 2 anonymous class to post-process what has been
discovered in reading the raw data. By doing so, I believe I might be able
to push both loops from AbstractPassageBook into the backends, so that the
backends themselves deal with iterating through ranges and verses.

The idea being, for performance reasons, we want to keep the random access
files open and re-use the state. However, we don't want to be sharing the
state across threads, and therefore that state needs to be local. Not sure
if it's going to be feasible doing it that way, but I thought I might give
it a go. It obviously might mean re-jigging the vast majority of the
backends. Shout if you want some more details.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20120823/07822536/attachment.html>

More information about the jsword-devel mailing list