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
--
Dipl. Inf. Sören Brunk
Research Associate
Technische Universität Dresden
Faculty of Computer Science
Institute for Software- and Multimedia-Technology
Junior Professorship in Software Engineering of Ubiquitous Systems
01062 Dresden
