Jena debugging most of the day.

Equality methods all seemed to be in order, with the exception that BlankNodeImpl did not have one. It turned out that it is only used in one place (unrelated to Jena) so implementing this didn't really help, though I did it anyway for completeness.

Did find one error in JenaFactory where convertSubjectToValue was not using the cache when building anonymous nodes. Unfortunately, this did not seem to improve anything. Also, the Jena unit tests insert anonymous nodes into the graph as predicates. This is something that is not allowed by OWL, so convertPredicateToValue did not handle anonymous nodes. Again this did not seem to fix anything. Logging showed that these methods don't get called with the Jena tests, which showed me (with confirmation from AN) that all of these tests us JRDFFactory rather than JenaFactory. The JRDFFactory code all seems OK, but I'm starting to get suspicious that this may be the source of the problem. There are also other classes in these Kowari/Jena packages, and I need to check them as well.

Looking at the unit test errors I found there are two types. The first is the set of Jena graph tests. These tests insert a number of triples with simple structures into the graph, and then test for their presence. In each case they fail when looking for the existence of new anonymous nodes. Jena anonymous nodes are differentiated by an underscore character prefix. Tried to log the anonymous nodes which are created (which is how I found out that this happens in JRDFFactory, as mentioned above), and found that some nodes have a negative node number. According to AN this means that they are global nodes, but it somehow seems suspicious.

The second failing unit test was simply due to different representations of anonymous nodes having toString methods which returned URIs in differing formats. This was trivial to fix.

Also helped AM with an RMI problem. It turns out that the next() method on the Answer interface cannot be called after it returns false for the first time. This was a problem for AnswerPageImpl which would fill itself from an Answer object using the next method, and stop when next() returned false. The next AnswerPageImpl expected to be able to call next() again, and get false again, telling it that it had zero size.

I fixed this by adding an isLastPage method to AnswerPage, and changing the client (RemoteAnswerWrapperAnswer) to not ask for the next page if a page returned true for this method. This could be a little fragile, in case the code ever changes, so AM is changing Answer to be more robust. This means that he has made next() continue to return false after it gets to the end, and to not throw any exceptions.