This approach means that the same source code is used for both the Java world and the .Net world, making future improvements visible to both from a single source tree.
I tried doing it for .Net on Windows with C# Express and IKVM-0.24.0.1.
SPARQL queries work.
Using Jena from C# works for small scale cases - lots of checking to do but it should be a matter of verifying everything from the dependent libraries works properly.
Some things aren't working but there are a few hotspots of trouble that, when fixed, mean that the majority (may be all) of the Jena test suite will run. As it is at the moment, quite a lot can be done including using the ARQ command line programs.
The IKVM bytecode conversion route is my preferred choice because it means one source
codebase, not two. When I tried this before, I got an early version of ARQ up and running.
But it wasn't complete; the first big block was the lack of
support in GNU Classpath. Jena and ARQ have lots of tests of internationalization and
charsets. That alone was enough to make it not worthwhile exploring further at the time.
The process is simple: run ikvmc on all the jars to get a library. Ignore all the warnings about missing stuff. It's surprising what various libraries actually reference - Log4j has references to a lot of log record transports. At the simplest:
ikvmc *.jar -out:XXX.dll -target:library
I've now broken this in two DLLs: jena-libs.dll (all the jars except the jena ones) and jena.dll (jena.jar, jenatest.jar, arq.,jar, iri.jar) but that is just because I keep building the DDLs while testing.
It takes a minute or so (less time than building jena.jar itself). The result is two DLLs of about totaling 16M - the whole assembly is about 23M including the three IKVM DLLs. Not small - but it works and it is simple to do.
What's been tried: in-memory graphs, reading and writing turtle files (but XML types literals broken) and SPARQL queries.
Jena bugs: (this is relative to CVS and so after Jena 2.3)
- file:///c:/absolute was incorrectly turned into a windows filename. Worked OK with Sun's Java but not IKVM. Fixed.
GNU Classpath bugs:
- InputStreamReader(InputStream, Charset) is broken although the other two constructors that allow the charset conversion to be explicitly controlled do seem to work. This can be worked around in Jena. Bugzilla Entry.
- Zero-width lookbehind regexs aren't implemented. They are used by JJC's new IRI code. Bugzilla Entry.
ARQ Test Suite
As a rough comparision, I ran the ARQ test suite:
BEfore any fixes, with Java 5 JVM:
Tests run: 1119, Failures: 0, Errors: 0
Using ikvm as the JVM:
Tests run: 1119, Failures: 32, Errors: 17
Converting to .Net:
Tests run: 1119, Failures: 32, Errors: 59
[20 Feb: JJC recoded around the lack of lookbehind and now its down to 4 failures of which 3 are because GNUClasspath is just different to Sun's runtime]
Now it's work through the broken tests in the ARQ test suite to determine what's the cause as time permits.
IronPython to Jena?
- Calling Jena from VB.Net works
- The GNU Classpath/InputStreamReader bug has been fixed
- The GNU Classpath/lookbehind bug had already been fixed but very recently so IKVM hasn't picked it up yet.
Now 4 failures, 3 of which are corner case differences of URI resolution in unusual cases.