[jsword-devel] Activator classes across the JSword library

[DM Smith]

I'm fine with eliminating Activator.

I think the one feature that it does provide is lazy loading of resources. This can be achieved in other ways.

Re-jigging the backends should be transparent to front-ends. I don't see that is a problem.

Holding resources open for long periods of time may not be a good idea for Android phones and tablets.

As you are finding, each client request needs to have a consistent view of the module. You'll note that the backends do caching of lookups on the assumption that the next request is most likely to be adjacent to the last request. This is not true in a multi-client or a multi-threaded front-end.

In Him,
	DM
On Aug 23, 2012, at 5:33 PM, Chris Burrell <chris at burrell.me.uk> wrote:

> 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.
> 
> Cheers
> Chris
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel

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