Hi Sören,
Thanks for that assessment.
Re: Xerces
Jena uses Xerces for datatypes - java.xml stiff provides Java types to
handle xml values but jena uses Xerces internals for literal parsing and
for the knowledge contained in the derived types hierarchy. It's not an
insignificant amount of work.
This has come up before. Xerces isn't modular so we can't just pick out
the dv bytes - we may be able to extract the source code and incorporate
that way and hence not depend on Xerces for that. That's clearly a bit
uck but I don't see another way to have the datatype support.
I've long had a wish that there was a separate XSD library for
datatypes, separate from XML processing, but the body of knowledge
captured by teh Xerces work is pretty huge so the effort needed to get
it right (and fast) is quite daunting.
Of all the syntax forms supported, TriX is not one I personally worry
about much :-)
Re: httpclient
Trackign back ...
https://issues.apache.org/jira/browse/JENA-576
Solr4j depends on httpclient 4.2 or did at the time someone last looked.
Jena's use of httpclient is fairly contained - having the authenticator
stuff work is quite important though.
Andy
On 31/03/15 21:41, Sören Brunk wrote:
Hi Andy,
thanks for your feedback and sorry for taking so long to reply. It would
be great to get Android support into mainline Jena and I'm willing to
help. It might be necessary to build an extra jar package for Android
though, similar to what jena-osgi does.
Is there are anything the Jena project can do that would make the
conversion? There may be things that Jena does, or the way is it
packaged, that are inconvenient for you but really make no differnce
to the project - sometimes things are just the way they are because it
was done that way but could easily be done another way. If you have
any such points, do email thsilist or raise a JIRA.
The httpclient issue might resolve itself as soon as Jena is able to
switch to httpclient 4.3. I've looked into the javax.xml issues in more
detail and the good news is that all the xsd datatype classes are
actually there. What's missing are the StAX classes (everything in
java.xml.stream) which seem to be used in ARQ and core (for SPARQL XML
result sets, RDF/XML and TriX) and of course in Xerces. That means it's
enough to repackage the StAX classes from xml-apis and to modify
jena-arq, jena-core and xercesImpl. I've changed my build accordingly.
Android uses XmlPullParser for stream parsing. So another solution could
be to replace StAX with a XmlPull based parsing but I guess that would
take some effort.
On Android, how does TDB work well? TDB uses fairly traditional file
handling for 32 bit machines - "direct mode" - and uses memory mapped
I/O for 64 bit machines - "mapped mode" - if it can detect the mode
correctly. Detection is not subtle, it looks in system property
"java.vm.info" and default to 32 bit. In mapped mode, it does try to
use as much memory as possible which is not friendly to co-resident
apps (you can force "direct" mode programmatically).
Since most Android devices nowadays run on a 32 bit ARM architecture I
guess it will run almost always in direct mode.
But I realized that TDB isn't working at all at the moment, because it
depends on JDK classes that aren't available on Android for things like
getting the PID. I think it is possible to replace those calls by using
similar classes provided by the Android SDK. I will try to get it
working. A dependency on Android specific code would probably make
mainline integration more difficult though.
Sören
