[m-dev.] Java Back-end Report (or What I Did Over Summer)

[Michael Wybrow]

For the benefit of Holger, Andree and anyone else following the progress
of the Java back-end. Here is a short report of my work over summer.

My Commited Changes:
 o While tags shouldn't be generated, they do get generated in some cases 
   and are now handled correctly. 
 o Added code to generate class constructors. 
 o Added code so the Java back-end is now able to simulate the behaviour of
   function pointers, which are used for closures, continuations, as well as
   unify and compare. 
 o Bug fixes and additions to the Java back-end so that it will now
   successfully compile and run mercury programs which contain higher
   order code as well as non-deterministic code. 
 o Disabled current (incomplete) name mangling code. All class, package 
   and method names apart from java.* and mercury.runtime.* will be 
   output as lowercase for the moment.
   The name mangling issue is that to avoid namespace conflicts we should
   use Java's naming conventions for packages, classes and methods. Currently
   we can't easily do this since at the point we output code we have only 
   qualified names without information as to whether they are classes or 
   packages. The long term solution to this is to use the same solution as
   the il back-end. Though this solution is fine for now.
 o Added code to prefix some classes/packages so we don't run into the 
   problem of having a class or package name which is also a Java reserved 
   word. This is the case with the mercury library modules int, char and
   float.
 o Added code to implement commits. 
 o Prevent the Java back-end from generating unreachable code, and re-enabled 
   optimized tailcalls which were previously generating unreachable code. 
 o Hacked up and added to the repository some (partial) Java versions of the
   mercury library. These are required temporarily for testing purposes until
   the mercury library can be compiled in grade java.
   Running mmake in the mercury/java directory (this will get done at build
   time when I fix whatever bootcheck problem this caused last night) and
   setting "CLASSPATH=/whatever/mercury/java:." will allow you to compile 
   and run at least some mercury code in java. Currently all the benchmark
   tests except poly.m will compile and run producing the right output. A
   couple of the hard_coded tests also work but I'm not sure which.
 o Countless small changes and bug fixes. 

Currently in Review:
 o A change that is currently in the review process will allow you to run
   the runtests script in grade java to automate these tests. And allow 
   java testing to be done by nightly tests.

My "If I'd had a little bit more time" list:
   A couple of things I still wanted to address. I might still get round to
   these if I have time during the semester (and someone else doesn't get to
   them first.)
 o Generating RTTI stubs for type_ctor_info_1 type. This would allow us to 
   test some files which reference these types but don't use them.
 o Fixing a small bug I believe is related to no-tag types.
 o Getting mmake to clean up generated nested class files like 
   foo$nested_class.class instead of just the joo.class file.
 

Java Back-end Todo List:
 o Handle static ground terms.
 o RTTI (requires static ground terms)
 o Follow Java naming conventions as mentioned earlier.
 
 o Handle foreign code written in Java  (Andree's Project?)
 o Handle foreign code written in C     (Andree's Project?)


Cheers,
Michael.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------