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

[bobef]

xs0 wrote:
> 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



I started to implement such tool an came to the same conclusions. 
Briefly this

 > 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)