Java to D No2 // Java to XML , XML to D

[xs0]

bobef wrote:
> Seems interesting task to convert this to D, but I suggest before anyone 
> take it we list all the specific cases which looks the same but are 
> handled different in Java. My knowledge of Java is almost non existent, 
> so I ask everyone who know such cases to post them here, because I 
> believe this will be tricky and may cause a lot of trouble.
> 
> One thing I know if is this 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/27876 .

Yup, Java has very specific order of evaluation constraints in the spec, 
while D intentionally doesn't, but there are other problems as well, and 
almost all of them involve some trickiness, in random order:

- in Java, arrays are also Objects; while it would be possible to 
somewhat fake such an array using a templated object, it still wouldn't 
be the same - a SomeClass[] is also implicitly castable to Object[] in 
Java, while I know of no way to make Array!(SomeClass) inherit from 
Array!(Object) (except having a static field in each Java class naming 
the super class; and supporting interfaces in this manner is still 
impossible)

- interfaces are handled totally differently, mostly meaning that in 
Java it's always the case that "cast(Interface)obj" is exactly the same 
reference as "cast(Class)obj". In D, an interface reference points 
somewhere else (though not far :). While implicit casting works for 
single references, casting arrays totally doesn't work, and last time I 
checked, one couldn't even call Object's methods on interface references.

- D's Object.toString() returns char[], not a String object, and you 
can't override it in some other base class :)

- in Java, you can wait(), notify() and notifyAll() on any object, not 
so in D

- Java's RTTI/reflection is waaay stronger than D's, and is commonly 
used. Runtime class loading support is also rather sophisticated..

- Java has Soft, Weak and Phantom references (which are similar to 
normal references, except they don't prevent an object from being GCed), 
and worse - you can also listen for the referred-to objects' destruction

- Java's standard library is huge and highly self-interdependent; even 
something as simple as a String references huge amounts of 
Unicode-related code, if you want a full implementation (and you do, 
because equalsIgnoreCase() is used often)

- operators don't have the same precedence (not all of them, anyway)

- lifetime of classes is different - in D, all static initialization 
occurs at program startup, while in Java, it occurs when a class is 
first needed (you're also allowed cyclic dependences), which means a lot 
of static initializers contain relatively expensive code, as it's not a 
problem. Furthermore, you're allowed cyclic dependences between classes.

- in Java, you can have a package, class, variable and method all share 
the same name, while in D you can't.


Combine all these, and I don't think there's a way to mechanically 
translate Java code into something that is

- 100% equal in meaning
- readable
- maintainable

So I guess the best that could be done is to
1) convert the syntax to what works in simple cases and actually looks 
like D, and
2) prominently mark all the places where it is not certain that the 
resulting code will work properly, for human inspection
3) store the original Java code somewhere handy, for comparison to newer 
versions

I just fear that more time would be spent on a decent tool to do these, 
than would actually be saved by using it (I don't expect a huge number 
of Java code will ever be ported to D in such a manner)


OTOH, no-one would expect readable/maintainable code if it was converted 
from bytecode? It would be really easy, too :)


xs0