The JSON-LD support through JSON-LD-Java also uses HTTPClient (to load @contexts), but it can be statically overridden, if needed:
https://github.com/jsonld-java/jsonld-java#customizing-the-apache-httpclient https://github.com/jsonld-java/jsonld-java/blob/master/core/src/main/java/com/github/jsonldjava/core/DocumentLoader.java#L155 On 2 April 2015 at 12:03, Andy Seaborne <[email protected]> wrote: > 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 >> > -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
