My hobbyist coding updates and releases as the mysterious "Mr. Tines"

Sunday, 3 February 2008

No love for client-side Java

It seemed a nice idea, having a deeper stack than just Python on Java that could build cross-VM apps from one code-base. But alas…

  • The only Java-on-.Net runtime I've found that has even half-way decent support for client-side apps (enough of AWT to support the GWT, or any flavour of Swing) is MSFT's J#, especially at 2.0
  • The obvious cross-compilers (scala-net, if I could get it to work; IKVM) want to use anything else they can except the J# runtime, and don't offer the facility to choose the one you want
  • Meanwhile scala's bytecode is just plain beyond decompilation to Java by obvious decompilers

So, I'd have to write the tools myself if I want to do this. It wouldn't even be a simple fork of IKVM to re-point references, and there are also its own special attributes decorating the classes. It might be simpler to tweak the scala compiler, since the .Net-bit islooked smaller in that (and it would improve my hands-on with the language).

 

Later:

Building a replacement scalaruntime.dll based on the .Java files from the scala-library source jar (one tweak for the older Java dialect with doesn't have the JDK 1.4 Character.toString()), plus a J# version of scala.runtime.SymtabAttribute based on the C# one in SVN, easy. Finding that the scala compiler source jar omits all the MSIL compiler files (from https://lampsvn.epfl.ch/trac/scala/browser/msil/trunk), more of a pain.

With a mscorlib 2.0 and my new runtime, and the predef.dll moved out of the way, I have to figure out why System.String is causing a wobbly:


java.lang.RuntimeException: PEModule.getTypeDefOrRef(): TypeSpec
        at ch.epfl.lamp.compiler.msil.PEModule.getTypeDefOrRef(PEModule.java:206)
        at ch.epfl.lamp.compiler.msil.PEType.loadInterfaces(PEType.java:309)
        at ch.epfl.lamp.compiler.msil.Type.initInterfaces(Type.java:944)
        at ch.epfl.lamp.compiler.msil.Type.getInterfaces(Type.java:907)
        at scala.tools.nsc.symtab.clr.TypeParser.parseClass(TypeParser.scala:88)
        at scala.tools.nsc.symtab.clr.TypeParser.parse(TypeParser.scala:58)
...
java.io.IOException: type 'System.String' is broken

I'd probably have to rework a whole lot of stuff that shims a virtual Java library layer. Which would have to start with identifying and encapsulating the shimming.

No comments: