j2d - translating Java to D with the language machine - progress

[Peri Hankey]

Walter Bright wrote:
> Peri Hankey wrote:
> 
>> It looks now as if the 'invalid UTF character' message is a problem 
>> with the gdc/dmd front end in the version (gdc 0.17/dmd140) that I am 
>> using. Is this fixed in later versions of dmd? How else would a java 
>> string
>>
>>    '\uffff'
>>
>> be translated as initialising a D language wchar variable? The following
>>
>>    wchar x = '\uffff';
>>
>> is flagged as invalid.
> 
> 
> That's because \uFFFF is an invalid UTF sequence. You can try instead:
> 
>     wchar x = cast(wchar)0xFFFF;

As I said, we are essentially down to real problems. The j2d translator 
produces syntactically acceptable D-language code for the main elements 
of gnu classpath - the gnu, java, and javax package hierarchies - I 
haven't yet tried to do much with other parts. Here are some of the 
questions/problems that have come up:

invalid UTF sequences:
* the wchar fix is ok for a single character
* but the same problem can arise in a java String literal
* not just \uffff, some other values as well

    however these seem to be accepted by gdc:

    char []c = "abc\xffffxyz";   // must see what this actually does
    wchar[]w = "abc\xffffxyz";   // can be used for java string literal?

name conflicts between java and D-language:
* between identifiers from java and D-language reserved words etc
* in general, can be fixed by adding a suffix to names from java

name conflicts in generated code:
* a class in java can have both 'int x' and 'int x()'
* may be able to use different suffixes to distinguish these cases
* may have to use dictionaries - not yet required otherwise

constants in java interfaces
* Java interfaces can include constants (initialised at runtime)
* quite tricky - useful feature - Walter, what do you think?

java packages, classes, interfaces vs D-language modules
* the unit of import in Java is class/interface or package
* the unit of import in D is the module
* in java class/interface name is effectively module name

* so: (A) produce a modules.d per java package

   (java) package x;  -> (D) module x_.thismodule_;
   (java) import x.*; -> (D) import x_.modules;
   (java) import x.y; -> (D) import x_.y_;

* or: (B) concatenate all D-code for a java package into one file

But in either case there are gotchas, and the ordering of the imports or 
of the separate code chunks needs to relate to dependencies.

dependency ordering:
* circular dependencies in gnu classpath
* java copes (maybe) by selective imports

So, lots of progress, some problems. Any ideas?

Peri

-- 
Peri Hankey                               mpah at thegreen.co.uk
http://languagemachine.sourceforge.net - The language machine