[jsword-devel] Applying patch

[DM Smith]

When you get the patch done, I will merge it in and submit another.
I have two bug fixes (Hebrew text display and dictionary lookup of 
inexact matches) and a semantic change to getData(Key).

WRT the semantic change, Joe, you had noted that you wanted getData(Key)
to return null if the verse could not be found. Right now it throws a 
BookException. This would be for OT lookups in the NT, the reverse or 
for input mistakes. Is this still something that you think is a good 
idea. I have implemented the change, but it would be easy to back out.

Joe Walker wrote:
> 
> Hi,
> 
> I'm applying DMS's big patch. Lots has gone in already.
> 
> I'm not sure of the reasoning being splitting up ResourceUtil?
The reason I went after ResourceUtil was that I was trying to fix a bug 
in the finding of resources. The problem was that a dotted name of the 
resource was given. The problem was in ResourceUtil. While the "patient 
was open" I did some refactoring.

Here are my thoughts:
1) Moving stuff to CWClassLoader: In Java the class loader has the 
responsibility for loading resources. We had some resource finding 
behavior in CWClassLoader and some in ResourceUtil. I thought it best to 
have that all in one class. The reason for moving "home" was that it was 
only used by CWClassLoader, but ResourceUtil was managing it. So now, 
CWClassLoader has all the findResource methods.

2) ClassUtils: There was specialized logic for finding implementations 
of a class. In my mind, using resources was an implementation detail. If 
Java provided a way to do it efficiently resources would not be needed, 
except perhaps to limit what is considered (as it is done in the current 
implementation.) ClassUtil's contract seemed better suited to these.

BTW, I had similar reasoning in refactoring Project.java into NetUtil 
and XMLUtil.

> 
> EventListenerList I have not deleted, because it is there for a good 
> reason for it. If you include swing code in non-gui code then you can 
> end up not being able to run your code in a headerless environment 
> because X includes Y which includes Font which tries to lookup font 
> metrics and then everything dies. I appreciate the Headerless changes in 
> 1.4 , but my rule (from before 1.4) was "Don't include swing code from 
> non-swing code", and I enforced that by making sure all my swing code 
> was in a package with swing in the name and by making sure that the word 
> swing was not in any non-swing code (hence I spelled it sw*ng in comments)
> That way some simple greps would tell me if the servlet front end was 
> likely to die. Do you think the Headerless updates make it that the few 
> k lost by this code are not worth the ability to do a grep check?

I like your reasoning. So keeping it as it was is fine. I would 
recommend adding a *standard* to the coding guidelines and to the code 
itself.

The biggest problem I see with borrowed code is that practical ownership 
changes hands. When changes are applied to the original, they are not 
necessarily applied to the borrowed. Perhaps a new TAG (e.g. BORROWED) 
with documentation in tags.txt could be used to indicate that the code 
should be revisited when the original's package is updated. (i.e. JDK 
1.4 -> 1.5 causes a revisit.)

I have run into headerless environment problems in UNIX in C++ and in 
Perl. They are very difficult to find and fix. I have run into a similar 
problem during startup of Java applications (whether headerless or not) 
and it is frustrating. Especially when it is due to race conditions 
between threads.


> 
> I'm sure I wrote some detailed notes of getRaw() did they get lost? The 
> short version is - what about modules with binary sources, or sources 
> that are computed at runtime, etc?

I don't remember seeing the notes other than "implement this". I am 
careful about deleting comments that outline design decisions or to-dos. 
I generally try to maintain them and I include them when refactoring.

If I had deleted them it would have been months ago when I re-wrote 
ModuleType.

> 
> I've created a few 'limbo' directories to hold source that could be 
> useful but that isn't required now.
> 
> Joe.