Might it make sense to use a different persistence engine on Android since it probably will not have the huge datasets that TDB is designed for. It might make sense to have a small store available for small devices. Just a thought.
Claude On Tue, Mar 31, 2015 at 9:41 PM, Sören Brunk <[email protected]> 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 > > -- > 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 > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
