[jdom-interest] JDOM and Android

Thu Apr 19 02:00:23 PDT 2012

Many thanks for sharing this information. I've done some experiments 
with compiling Saxon for Android, and it's nice that someone has cleared 
a trail through the jungle.

I've so far got as far as compiling the code, by:

* removing a number of packages and classes, essentially those that 
provide interfaces to other libraries such as .NET code, DOM4J, XOM, and 
JDOM, StAX, XQJ

* commenting out a few methods where there's a dependency on one of the 
above.

This isn't an impossible loss of functionality, though it would be nice 
to put some of this back in, e.g. it's a shame to lose some of Saxon's 
diagnostic tracing output just because there's no XMLStreamWriter.

Of course a key aim will be to maintain single source. I suspect that 
will be easier if the build is all done using scripts / Ant, rather than 
in the IDE, which will make it much easier to manage things like 
conditional exclusion of selected methods. If only Java had a decent 
conditional compilation framework. Perhaps something can be done with 
annotations, I don't know.

Actually running the code will no doubt reveal a few more problems, but 
the next challenge is to tackle the test environment, which as with 
JDOM, will probably be a bigger challenge than the code itself. I was 
already thinking in the direction of two projects, one for production 
code and one for test code, before I read this blog post.

Since no one has been clamouring for Saxon on Android it's not my 
highest priority, but there does seem to be a lot of development 
activity on Android and the XML support on the platform seems to be very 
impoverished, so one feels there is an opportunity here.

Michael Kay
Saxonica

On 19/04/2012 02:32, Rolf Lear wrote:
> Hi all.
>
> Just reporting some progress on the Android testing.
>
> I have put together a document here:
> https://github.com/hunterhacker/jdom/wiki/JDOM2-and-Android
>
> I believe I have narrowed down the testing issues a lot. Here is the 
> test summary:
>
>      [exec] FAILURES!!!
>      [exec] Tests run: 1629,  Failures: 0,  Errors: 55
>
> The Regular JDOM stream has 1800 tests (of which 33 are ignored). The 
> difference to 1629 tests is a result of skipping the StAX tests and 
> some illegal UniCode tests.
>
> The remaining 55 failing tests fail for one of the following reasons:
> - Android cannot process XMLSchema validation.
> - Android does not give the SAXHandler the 'internal subset' part of a 
> DocType declaration.
> - Some of the JDOM unit tests use the JUnit4 concept of 'assume'. I 
> have not yet coded the JUnit3 wrappers to accommodate these failing 
> assumptions.
> - Android's implementation of java.util.List has slightly different 
> handling for ConcurrentModificationException.
>
> Bottom line is:
> with some pending fixes, JDOM 2.x is functional on Android.
> The only issues I expect to be significant are:
> - XMLSchema validation
>
> I am working on:
>  - testing with the Xerces parser to resolve DTD issues
>  - using Xerces's custom XSDSchema Schema for XSD validation
>  - handling JUnit 'assumptions'
>
> Onc complete this should resolve the issues to close to zero.
>
> Rolf
>
>
> On 17/04/2012 11:58 PM, Rolf Lear wrote:
>> Hi all.
>>
>> So, using the 'Asset' mechanism works, even though it is a fantastic
>> pain in the posterior.
>>
>> No, here are the major issues:
>>
>> Android does not support XML Schema validation
>> ==============================================
>>
>> This i the most significant issue because it causes XMLReaders
>> enumeration to fail:
>>
>> The documentation for ...
>> SchemaFactory.newInstance(XMLConstants.W2C_XML_SCHEMA_NS_URI)
>> ... is ...
>> To be compliant with the spec, the implementation is only required to
>> support W3C XML Schema 1.0
>>
>> But, Android does not..... thus the Enum fails, thus nothing can be
>> parsed... ;-)
>>
>> I have temporarily 'fixed' it by making only the XSD-based test fail,
>> instead of failing *everything* that is parsed....
>>
>>
>> Android does not supply StAX bundles.
>> =====================================
>>
>> Fixed by removing StAX tests.
>>
>>
>>
>>
>> For the moment though, it would seem a preliminary statement is:
>>
>> with some fixes, JDOM 2.0.1 will have full functionality except:
>> DTD - Internal-subset: SAX Parser does not supply it to JDOM
>> XSD Validation is not possible (there are work-arounds...)
>> StAX support not available.
>>
>>
>>
>> Rolf
>>
>>
>> On 17/04/2012 1:15 AM, Joe Bowbeer wrote:
>>> The other approach is to copy the assets to the file system when the 
>>> apk
>>> is first started and then read the resources from the file system at
>>> runtime.
>>>
>>> The file system URLs are of the form /data/data/<package-id>/files/
>>>
>>> See
>>> http://developer.android.com/reference/android/content/Context.html#getFilesDir() 
>>>
>>>
>>>
>>>
>>> --Joe
>>>
>>> On Mon, Apr 16, 2012 at 9:51 PM, Rolf Lear wrote:
>>>
>>> I have been down that road, and it does not work....
>>>
>>> Because the file URL's are still not readable.... here's a test 
>>> trace...
>>> Note how the failure is buried in a 'caused by' where the important
>>> lines are:
>>>
>>> Caused by: java.io.FileNotFoundException:
>>> /android_asset/xsdcomplex/__multi_main.xsd: open failed: ENOENT (No
>>> such file or directory)
>>> at libcore.io.IoBridge.open(__IoBridge.java:406)
>>> at java.io.FileInputStream.<init>__(FileInputStream.java:78)
>>> at
>>> libcore.net.url.__FileURLConnection.connect(__FileURLConnection.java:82) 
>>>
>>> at
>>> libcore.net.url.__FileURLConnection.__getInputStream(__FileURLConnection.java:181) 
>>>
>>>
>>> at java.net.URL.openStream(URL.__java:462)
>>> at
>>> org.jdom2.input.sax.__XMLReaderXSDFactory.__getSchemaFromURL(__XMLReaderXSDFactory.java:195) 
>>>
>>>
>>> ... 15 more
>>>
>>>
>>>
>>> org.jdom2.JDOMException: Unable to read Schema URL
>>> file:///android_asset/__xsdcomplex/multi_main.xsd
>>> at
>>> org.jdom2.input.sax.__XMLReaderXSDFactory.__getSchemaFromURL(__XMLReaderXSDFactory.java:197) 
>>>
>>>
>>> at
>>> org.jdom2.input.sax.__XMLReaderXSDFactory.<init>(__XMLReaderXSDFactory.java:272) 
>>>
>>>
>>> at
>>> org.jdom2.test.cases.input.__sax.TestXMLReaderXSDFactory.__testXMLReaderXSDFactoryFileArr__ay(TestXMLReaderXSDFactory.__java:80) 
>>>
>>>
>>> at
>>> org.jdom2.test.cases.input.__sax.TestXMLReaderXSDFactoryTT.__testXMLReaderXSDFactoryFileArr__ay(TestXMLReaderXSDFactoryTT.__java:28) 
>>>
>>>
>>> at java.lang.reflect.Method.__invokeNative(Native Method)
>>> at
>>> android.test.__AndroidTestRunner.runTest(__AndroidTestRunner.java:169)
>>> at
>>> android.test.__AndroidTestRunner.runTest(__AndroidTestRunner.java:154)
>>> at
>>> android.test.__InstrumentationTestRunner.__onStart(__InstrumentationTestRunner.__java:545) 
>>>
>>>
>>> at
>>> android.app.Instrumentation$__InstrumentationThread.run(__Instrumentation.java:1551) 
>>>
>>>
>>> Caused by: java.io.FileNotFoundException:
>>> /android_asset/xsdcomplex/__multi_main.xsd: open failed: ENOENT (No
>>> such file or directory)
>>> at libcore.io.IoBridge.open(__IoBridge.java:406)
>>> at java.io.FileInputStream.<init>__(FileInputStream.java:78)
>>> at
>>> libcore.net.url.__FileURLConnection.connect(__FileURLConnection.java:82) 
>>>
>>> at
>>> libcore.net.url.__FileURLConnection.__getInputStream(__FileURLConnection.java:181) 
>>>
>>>
>>> at java.net.URL.openStream(URL.__java:462)
>>> at
>>> org.jdom2.input.sax.__XMLReaderXSDFactory.__getSchemaFromURL(__XMLReaderXSDFactory.java:195) 
>>>
>>>
>>> ... 15 more
>>> Caused by: libcore.io.ErrnoException: open failed: ENOENT (No such
>>> file or directory)
>>> at libcore.io.Posix.open(Native Method)
>>> at libcore.io.BlockGuardOs.open(__BlockGuardOs.java:110)
>>> at libcore.io.IoBridge.open(__IoBridge.java:390)
>>> ... 20 more
>>>
>>>
>>>
>>>
>>>
>>> On 17/04/2012 12:00 AM, Joe Bowbeer wrote:
>>>
>>> You'll need to put the data in assets
>>>
>>> http://stackoverflow.com/__questions/4820816/how-to-get-__uri-from-an-asset-file 
>>>
>>>
>>> <http://stackoverflow.com/questions/4820816/how-to-get-uri-from-an-asset-file> 
>>>
>>>
>>>
>>> http://stackoverflow.com/__questions/4789325/android-__path-to-asset-txt-file 
>>>
>>>
>>> <http://stackoverflow.com/questions/4789325/android-path-to-asset-txt-file> 
>>>
>>>
>>>
>>> and use getResources().getAssets().__open()
>>>
>>> Or you could put the data in res/raw and use
>>> getResources().__openRawResource()
>>>
>>> .. but res/raw does not support a nested file structure.
>>>
>>> Or maybe you could do something crazy with a custom class loader:
>>>
>>> http://android-developers.__blogspot.com/2011/07/custom-__class-loading-in-dalvik.html 
>>>
>>>
>>> <http://android-developers.blogspot.com/2011/07/custom-class-loading-in-dalvik.html> 
>>>
>>>
>>>
>>>
>>> --Joe
>>>
>>>
>>> On Mon, Apr 16, 2012 at 8:08 PM, Rolf Lear <jdom at tuis.net
>>> <mailto:jdom at tuis.net>
>>> <mailto:jdom at tuis.net <mailto:jdom at tuis.net>>> wrote:
>>>
>>> Hi all.
>>>
>>> I am having some limited success with the Android testing. I
>>> have
>>> run in to an issue through which could really use some input
>>> from
>>> experienced Android developers.
>>>
>>> Are there any on JDOM-interest with some time to spare?
>>>
>>> My issue right now is that the JUnit tests are mostly
>>> passing, but a
>>> number of them rely on using
>>> ClassLoader.getSystemResource(____"path/to/file.xml") to load
>>>
>>> resources as a URL.
>>>
>>> It is improtant to keep it as a URL because many of these
>>> tests rely
>>> on internal DTD's and XSD's, which, in turn mean that when
>>> they are
>>> processed the input file's URL will be used as a base for a
>>> relative
>>> location of the DTD/XSD.
>>>
>>> In other words, I need to keep access to these files as a
>>> URL....
>>>
>>> But, ClassLoader.getSystemResource(____...) is returning
>>> null on Android.
>>>
>>>
>>> I think it is related to
>>> http://code.google.com/p/____android/issues/detail?id=10076
>>> <http://code.google.com/p/__android/issues/detail?id=10076>
>>>
>>> <http://code.google.com/p/__android/issues/detail?id=10076
>>> <http://code.google.com/p/android/issues/detail?id=10076>__>
>>>
>>> But, I can't find a good way to work around the issue....
>>>
>>> So, If there's some experienced Android developer who can
>>> shed some
>>> light in to this particular dark place, I would appreciate it.
>>>
>>> For the record, I have a full test-suite available for any
>>> Android
>>> developers who happen to use eclipse. It fully compiled,
>>> loads, and
>>> I am running a 'Test' Project on a 4.0.3 emulator.
>>>
>>> I can, in theory, help you bootstrap the environment in your
>>> eclipse
>>> pretty easily... if needed.
>>>
>>> Rolf
>>>
>>>
>>>
>>
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com
>>
>
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com
>