This is a FYGI concerning design decisions about I/O global settings in
Jena.

=====

Back in Jena 1 days, the issue of scope of the I/O subsystems was one
that I thought was questionable; and we decided not to change it in the
Jena 1 to Jena 2 migration.

I think the recent issues with the N3 and Turtle I/O at least gives some
data about the design choices.

In the TopBraid Suite, we are prepared to say that we are the king pin,
and to make global decisions about these; since TDB also makes such an
assumption, I ended up writing the following code snippet:


// force TDB initialization
TDB.init();
// overrule TDB's choice of N3/Turtle reader

String readerTTL =
org.topbraid.n3legacy.n3.N3JenaReader.class.getName() ;
RDFReaderFImpl.setBaseReaderClassName("N3", readerTTL) ;
RDFReaderFImpl.setBaseReaderClassName("TURTLE", readerTTL) ;
RDFReaderFImpl.setBaseReaderClassName("Turtle", readerTTL) ;
RDFReaderFImpl.setBaseReaderClassName("TTL", readerTTL) ;


Obviously as some of the fixes already in Jena SVN work there way
through to the jars, we will review these decisions; which deliberately
make us too lax in our N3 parsing.

Other than the observation that is ugly to have to access an Impl class
to do this, it is not clear that there is a design error here; but it is
also unclear that the design is correct.
This message is not meant to advocate any particular design.

A further observation is that one impact of the globals was that, given
our immediately presenting problem which we decided to fix by using the
Jena 2.5.7 N3JenaReader (renamed as above), the immediate behavior was
unpredictable, and caused us a further build/test cycle. The reason for
this was the initial fix missed out the TDB.init() and worked, accept in
situations in which we were using TDB. This took us a while to detect,
and then a bit longer until the stack trace got passed to the person who
had done the N3 fix (me!).

If at any point you would like to brainstorm this area of the design
further, I would be happy to join in.

Jeremy