www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - Java to D No2 // Java to XML , XML to D

reply "BLS" <lietz wanadoo.fr> writes:
Well, after working  a while with ANTLR, i figured out that is is possible
to create a XML representation of Java 5 code using ANTLR. Unfortunately, we
have have a bad case of programmer-confusion. Is  this really a win. (in
other words, can this be helpfull  in translation Java 2 D) ?? Let me know
what you think. IMO seems to be easier than walking the AST.

I am not able to spend more time on this issue because the Client|/Server
IDE (see announcements) takes most of it. If someone is looking for a sample
translation let me know.
Bjoern Lietz-Spendig
Feb 23 2006
parent reply bobef <bobef lessequal.com> writes:
BLS wrote:
  If someone is looking for a sample
 translation let me know.
 Bjoern Lietz-Spendig
 
 

It would be nice if you could post one here...
Feb 23 2006
next sibling parent "BLS" <lietz wanadoo.fr> writes:
hi bobef.
have to split the message. here attached the xml file
Feb 24 2006
prev sibling parent reply "BLS" <lietz wanadoo.fr> writes:
Hi bobef,
attached a java file and its xml representation. zipped
bjoern
"bobef" <bobef lessequal.com> schreef in bericht
news:dtl38g$13dh$1 digitaldaemon.com...
 BLS wrote:
   If someone is looking for a sample
 translation let me know.
 Bjoern Lietz-Spendig

It would be nice if you could post one here...

Feb 24 2006
parent reply bobef <bobef lessequal.com> writes:
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 
digitalmars.D/27876 .
Feb 24 2006
next sibling parent "BLS" <lietz wanadoo.fr> writes:
thanks for feedback, sorry but i am not able to offer more because the IDE
needs all of my  time.
but i agree, it is nessesary first to collect differences between Java and
D.
Bjoern


bobef" <bobef lessequal.com> schreef in bericht
news:dtmts5$1m1g$1 digitaldaemon.com...
 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
 digitalmars.D/27876 .

Feb 24 2006
prev sibling parent reply xs0 <xs0 xs0.com> writes:
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 
 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
Feb 27 2006
parent bobef <bobef lessequal.com> writes:
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 
 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)

Feb 27 2006