www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Java2D III

reply "BLS" <lietz wanadoo.fr> writes:
okay,
the Java Parser, the Java AST Parser and very basic work on the D Emitter
are done.

DEmitter > A class that can take an ANTLR Java AST and produce formatted
 D Java code from it

I guess the string, array and modifiers stuff will be tricky.

anyway, first things first :the following table has to be transformed :
is somebody out there who is kind enough to give me advice regarding the
modifieres stuff : well translationg the table to D is also highly welcome
<g>

  tokenNames[POST_INC]="++";
  tokenNames[POST_DEC]="--";
  tokenNames[UNARY_MINUS]="-";
  tokenNames[UNARY_PLUS]="+";
  tokenNames[STAR]="*";
  tokenNames[ASSIGN]="=";
  tokenNames[PLUS_ASSIGN]="+=";
  tokenNames[MINUS_ASSIGN]="-=";
  tokenNames[STAR_ASSIGN]="*=";
  tokenNames[DIV_ASSIGN]="/=";
  tokenNames[MOD_ASSIGN]="%=";
  tokenNames[SR_ASSIGN]=">>=";
  tokenNames[BSR_ASSIGN]=">>>=";
  tokenNames[SL_ASSIGN]="<<=";
  tokenNames[BAND_ASSIGN]="&=";
  tokenNames[BXOR_ASSIGN]="^=";
  tokenNames[BOR_ASSIGN]="|=";
  tokenNames[QUESTION]="?";
  tokenNames[LOR]="||";
  tokenNames[LAND]="&&";
  tokenNames[BOR]="|";
  tokenNames[BXOR]="^";
  tokenNames[BAND]="&";
  tokenNames[NOT_EQUAL]="!=";
  tokenNames[EQUAL]="==";
  tokenNames[LT]="<";
  tokenNames[GT]=">";
  tokenNames[LE]="<=";
  tokenNames[GE]=">=";
  tokenNames[SL]="<<";
  tokenNames[SR]=">>";
  tokenNames[BSR]=">>>";
  tokenNames[PLUS]="+";
  tokenNames[MINUS]="-";
  tokenNames[DIV]="/";
  tokenNames[MOD]="%";
  tokenNames[INC]="++";
  tokenNames[DEC]="--";
  tokenNames[BNOT]="~";
  tokenNames[LNOT]="!";
  tokenNames[FINAL]="final";
  tokenNames[ABSTRACT]="abstract";
  tokenNames[LITERAL_package]="package";
  tokenNames[LITERAL_import]="import";
  tokenNames[LITERAL_void]="void";
  tokenNames[LITERAL_boolean]="boolean";
  tokenNames[LITERAL_byte]="byte";
  tokenNames[LITERAL_char]="char";
  tokenNames[LITERAL_short]="short";
  tokenNames[LITERAL_int]="int";
  tokenNames[LITERAL_float]="float";
  tokenNames[LITERAL_long]="long";
  tokenNames[LITERAL_double]="double";
  tokenNames[LITERAL_private]="private";
  tokenNames[LITERAL_public]="public";
  tokenNames[LITERAL_protected]="protected";
  tokenNames[LITERAL_static]="static";
  tokenNames[LITERAL_transient]="transient";
  tokenNames[LITERAL_native]="native";
  tokenNames[LITERAL_threadsafe]="threadsafe";
  tokenNames[LITERAL_synchronized]="synchronized";
  tokenNames[LITERAL_volatile]="volatile";
  tokenNames[LITERAL_class]="class";
  tokenNames[LITERAL_extends]="extends";
  tokenNames[LITERAL_interface]="interface";
  tokenNames[LITERAL_implements]="implements";
  tokenNames[LITERAL_throws]="throws";
  tokenNames[LITERAL_if]="if";
  tokenNames[LITERAL_else]="else";
  tokenNames[LITERAL_for]="for";
  tokenNames[LITERAL_while]="while";
  tokenNames[LITERAL_do]="do";
  tokenNames[LITERAL_break]="break";
  tokenNames[LITERAL_continue]="continue";
  tokenNames[LITERAL_return]="return";
  tokenNames[LITERAL_switch]="switch";
  tokenNames[LITERAL_throw]="throw";
  tokenNames[LITERAL_case]="case";
  tokenNames[LITERAL_default]="default";
  tokenNames[LITERAL_try]="try";
  tokenNames[LITERAL_finally]="finally";
  tokenNames[LITERAL_catch]="catch";
  tokenNames[LITERAL_instanceof]="instanceof";
  tokenNames[LITERAL_this]="this";
  tokenNames[LITERAL_super]="super";
  tokenNames[LITERAL_true]="true";
  tokenNames[LITERAL_false]="false";
  tokenNames[LITERAL_null]="null";
  tokenNames[LITERAL_new]="new";

thanks bjoern
Jul 20 2006
next sibling parent reply Frank Benoit <keinfarbton nospam.xyz> writes:
What does this table mean?

tokenNames[POST_INC]="++";
tokenNames[Java symbol] = "D translation"
??

The main problem is, that the operator cannot be mapped 1o1.
The plus in Java can concatenate two strings, in D the '~' is used.
Same for += and ~=.
So if the parser do not know the types of the + operands, a solution can
be to make every + operation to a D function call.

java:
a += b;
c = a + b;
D:
AddAssign( a, b );
c = Add( a, b );

And AddAssign, Add are overloaded with various types:
Add( char[], ... )
Add( int, int )
Add( long, long )
...

Java:
a instanceof ClassA
D:
((cast(ClassA)a) !is null )
Jul 20 2006
parent "BLS" <lietz wanadoo.fr> writes:
Hi Frank,
I am sorry. My previous problem discription was a piece of ...., I was a bit
in a hurry, so give me a second chance.
How to translate the following Java class/method/variable modifieres into D.

public, protected, private
do the D counterparts have the same scope ?.

static, final (or a combination of them)
...especially, when in use for Java classes.

synchronized, volatile (the thread thing).

any hint, tip, etc. is welcome.Thanks bjoern
PS ----------------------------------------
I know about the problems you are talking about in your previous msg.. I
think I should be able to solve them (better > some of them) because walking
the AST back or doing AST lookaheads is possible.  I am also able to
visualize the AST, which is indeed, a great help.

"Frank Benoit" <keinfarbton nospam.xyz> schreef in bericht
news:e9ovom$15sb$1 digitaldaemon.com...
 What does this table mean?

 tokenNames[POST_INC]="++";
 tokenNames[Java symbol] = "D translation"
 ??

 The main problem is, that the operator cannot be mapped 1o1.
 The plus in Java can concatenate two strings, in D the '~' is used.
 Same for += and ~=.
 So if the parser do not know the types of the + operands, a solution can
 be to make every + operation to a D function call.

 java:
 a += b;
 c = a + b;
 D:
 AddAssign( a, b );
 c = Add( a, b );

 And AddAssign, Add are overloaded with various types:
 Add( char[], ... )
 Add( int, int )
 Add( long, long )
 ...

 Java:
 a instanceof ClassA
 D:
 ((cast(ClassA)a) !is null )

Jul 21 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
BLS wrote:
 okay,
 the Java Parser, the Java AST Parser and very basic work on the D Emitter
 are done.
 
 DEmitter > A class that can take an ANTLR Java AST and produce formatted
  D Java code from it
 
 I guess the string, array and modifiers stuff will be tricky.

Arrays will be the trickiest - they're objects in Java, but something completely different in D (better, but totally not-compatible). While it may seem that it can be easily be solved with a template Array object, it can't for the simple reason, that a Derived[] is also a Base[] (but you can't put non-Derived object inside), and that's just not practically doable. You'd have to list all superclasses/interfaces for each array class that appears.. I can't think of a reasonable implementation that would mimic the arrays in Java, so I guess the only choice is to have a single implementation (non-templated) which keeps the element class type at runtime and checks on writes. That's bad, because the information on types of arrays is lost in source..
 anyway, first things first :the following table has to be transformed :
 is somebody out there who is kind enough to give me advice regarding the
 modifieres stuff : well translationg the table to D is also highly welcome
 <g>

   tokenNames[FINAL]="final";

becomes either final (for classes and methods) or const (for variables)
   tokenNames[LITERAL_package]="package";

Ideally, you will take several classes and place them into one module; that way, their FQNs (full names) stay about the same. However, there is a problem there - you can't have both modules "foo.bar" and "foo.bar.baz" in D. But, since the packages do not form a hierarchy in Java (foo, foo.bar and foo.baz are as distinct as kuku, abc.def and qwe.dfg), you can rename them to something like foo.bar and foo_bar.baz for the above case.
   tokenNames[LITERAL_import]="import";

This will be tricky; you can either import a) a normal class (java.util.HashMap), b) an inner class (java.util.Map.Entry), c) all members of a package (java.util.*), For the first two cases, you can also import d) one static member (import static java.lang.Math.PI) or e) all static members of a class (import static java.lang.Math.*) Assuming you do convert packages into modules (so a module contains all classes from a Java package), those become a) static import java.util; alias java.util.HashMap HashMap; b) static import java.util; alias java.util.Map.Entry Entry; c) private import java.util; // private now optional d) static import java.lang; alias java.lang.Math.PI PI; e) static import java.lang; alias java.lang.Math.sin sin; alias java.lang.Math.cos cos; etc. To get the last case just right, some analysis of class contents will have to be made...
   tokenNames[LITERAL_private]="private";

this is still private, though it doesn't have the same effect - in Java private really means private, while in D it's module-private.
   tokenNames[LITERAL_transient]="transient";

this is used for serialization only, can be dropped (and there is no equivalent in D)
   tokenNames[LITERAL_native]="native";

luckily, no longer needed :) unluckily, you have to get the code for such a function from somewhere else, and it's probably C/C++
   tokenNames[LITERAL_threadsafe]="threadsafe";

never heard of this..
   tokenNames[LITERAL_synchronized]="synchronized";

when used with an expression, it's the same as in D, but can also be a modifier for functions. With non-static methods, synchronized func() { } becomes func() { synchronized(this) { } } With static methods, its synchronized(ClassName.class) in Java, I'm not sure whether something similar can be used in D (is TypeInfo an object or a struct?)
   tokenNames[LITERAL_volatile]="volatile";

There are no volatile variables in D, so this is quite tricky; theoretically, you'd have to wrap each access of such a variable into a volatile statement...
   tokenNames[LITERAL_throws]="throws";

These can be dropped (or even better - converted to DDoc ;)
   tokenNames[LITERAL_case]="case";
   tokenNames[LITERAL_default]="default";

Note that there's an implicit "default: assert(0)" in D, but an implicit "default: break" in Java.
   tokenNames[LITERAL_instanceof]="instanceof";

expr instanceof ClassName becomes (cast(ClassName)expr) No need to compare it to null, as it will be automatically done.
   tokenNames[LITERAL_this]="this";

For inner classes, you can have an expressions OuterClass.this; no such thing in D..
   tokenNames[LITERAL_new]="new";

In Java, you can write "new Foo().method()", in D it must be "(new Foo).method()". Hope that helps :) xs0
Jul 21 2006
next sibling parent "BLS" <lietz wanadoo.fr> writes:
Thanks, a lot of usefull information. I think I should open a dsource
project, to publish the Java parser, the java tree parser, a few helper
classes and the D Emitter (which is not worth its name at the moment, but
using your and Franks info should enable me to make some progress)

The D Emitter(in fact a slightly modified Java Emitter) is beside, quit easy
to understand.
 The very optimistic goal is of course to have a D Emitter which is able to
create perfect translations. A more realistic goal for the near future is to
translate as much as possible, and to extensively comment the untranslated
parts including translation suggestion.

Bjoern

"xs0" <xs0 xs0.com> schreef in bericht
news:e9q7n9$2lu0$1 digitaldaemon.com...
 BLS wrote:
 okay,
 the Java Parser, the Java AST Parser and very basic work on the D


 are done.

 DEmitter > A class that can take an ANTLR Java AST and produce formatted
  D Java code from it

 I guess the string, array and modifiers stuff will be tricky.

Arrays will be the trickiest - they're objects in Java, but something completely different in D (better, but totally not-compatible). While it may seem that it can be easily be solved with a template Array object, it can't for the simple reason, that a Derived[] is also a Base[] (but you can't put non-Derived object inside), and that's just not practically doable. You'd have to list all superclasses/interfaces for each array class that appears.. I can't think of a reasonable implementation that would mimic the arrays in Java, so I guess the only choice is to have a single implementation (non-templated) which keeps the element class type at runtime and checks on writes. That's bad, because the information on types of arrays is lost in source..
 anyway, first things first :the following table has to be transformed :
 is somebody out there who is kind enough to give me advice regarding the
 modifieres stuff : well translationg the table to D is also highly


 <g>

   tokenNames[FINAL]="final";

becomes either final (for classes and methods) or const (for variables)
   tokenNames[LITERAL_package]="package";

Ideally, you will take several classes and place them into one module; that way, their FQNs (full names) stay about the same. However, there is a problem there - you can't have both modules "foo.bar" and "foo.bar.baz" in D. But, since the packages do not form a hierarchy in Java (foo, foo.bar and foo.baz are as distinct as kuku, abc.def and qwe.dfg), you can rename them to something like foo.bar and foo_bar.baz for the above case.
   tokenNames[LITERAL_import]="import";

This will be tricky; you can either import a) a normal class (java.util.HashMap), b) an inner class (java.util.Map.Entry), c) all members of a package (java.util.*), For the first two cases, you can also import d) one static member (import static java.lang.Math.PI) or e) all static members of a class (import static java.lang.Math.*) Assuming you do convert packages into modules (so a module contains all classes from a Java package), those become a) static import java.util; alias java.util.HashMap HashMap; b) static import java.util; alias java.util.Map.Entry Entry; c) private import java.util; // private now optional d) static import java.lang; alias java.lang.Math.PI PI; e) static import java.lang; alias java.lang.Math.sin sin; alias java.lang.Math.cos cos; etc. To get the last case just right, some analysis of class contents will have to be made...
   tokenNames[LITERAL_private]="private";

this is still private, though it doesn't have the same effect - in Java private really means private, while in D it's module-private.
   tokenNames[LITERAL_transient]="transient";

this is used for serialization only, can be dropped (and there is no equivalent in D)
   tokenNames[LITERAL_native]="native";

luckily, no longer needed :) unluckily, you have to get the code for such a function from somewhere else, and it's probably C/C++
   tokenNames[LITERAL_threadsafe]="threadsafe";

never heard of this..
   tokenNames[LITERAL_synchronized]="synchronized";

when used with an expression, it's the same as in D, but can also be a modifier for functions. With non-static methods, synchronized func() { } becomes func() { synchronized(this) { } } With static methods, its synchronized(ClassName.class) in Java, I'm not sure whether something similar can be used in D (is TypeInfo an object or a struct?)
   tokenNames[LITERAL_volatile]="volatile";

There are no volatile variables in D, so this is quite tricky; theoretically, you'd have to wrap each access of such a variable into a volatile statement...
   tokenNames[LITERAL_throws]="throws";

These can be dropped (or even better - converted to DDoc ;)
   tokenNames[LITERAL_case]="case";
   tokenNames[LITERAL_default]="default";

Note that there's an implicit "default: assert(0)" in D, but an implicit "default: break" in Java.
   tokenNames[LITERAL_instanceof]="instanceof";

expr instanceof ClassName becomes (cast(ClassName)expr) No need to compare it to null, as it will be automatically done.
   tokenNames[LITERAL_this]="this";

For inner classes, you can have an expressions OuterClass.this; no such thing in D..
   tokenNames[LITERAL_new]="new";

In Java, you can write "new Foo().method()", in D it must be "(new Foo).method()". Hope that helps :) xs0

Jul 21 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
xs0 wrote:
 BLS wrote:
   tokenNames[LITERAL_synchronized]="synchronized";

when used with an expression, it's the same as in D, but can also be a modifier for functions. With non-static methods, synchronized func() { } becomes func() { synchronized(this) { } }

synchronized methos. And yes it's not clearly documented, the only reference to that is in: http://www.digitalmars.com/d/overview.html, Synchronization.
 With static methods, its synchronized(ClassName.class) in Java, I'm not 
 sure whether something similar can be used in D (is TypeInfo an object 
 or a struct?)
 

It also works with static methods in D. It is synchronized on this.classinfo , which is the equivalent of Java's ClassName.class . -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 03 2006
prev sibling next sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
BLS wrote:

Uh, these names are tricky.
When I saw "Java2D" my first thought was that is has something to deal with 2D
graphics in Java <g>.

-- 
Jul 21 2006
parent reply "BLS" <lietz wanadoo.fr> writes:
good point, you are right, I bettter named it Antlr treewalker based Java to
D Translator. ?!
Bjoern

"Andrei Khropov" <andkhropov nospam_mtu-net.ru> schreef in bericht
news:e9qf6c$h5$1 digitaldaemon.com...
 BLS wrote:

 Uh, these names are tricky.
 When I saw "Java2D" my first thought was that is has something to deal

 graphics in Java <g>.

 -- 

Jul 21 2006
parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
BLS wrote:

 good point, you are right, I bettter named it Antlr treewalker based Java to
 D Translator. ?!
 Bjoern
 

Nothing against it, actually. It's the most natural name for this kind of stuff. Just my chatter. --
Jul 21 2006
prev sibling parent reply Frank Benoit <keinfarbton nospam.xyz> writes:
Is this project online accessible?
Jul 23 2006
parent "BLS" <lietz wanadoo.fr> writes:
I need an other  week. The current parser, treeparser ....are based on Java
1.3.  But I want the Java 5 thing on dsolurce.org (allready contacted Brad)

Bjoern

"Frank Benoit" <keinfarbton nospam.xyz> schreef in bericht
news:e9vu3v$1anc$1 digitaldaemon.com...
 Is this project online accessible?

Jul 23 2006