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

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

hi bobef.
have to split the message. here attached the xml file

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

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 .

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 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/27876 .

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

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)