Brian,
thanks for the diff, I'll take it into account and publish an update.
On 28/10/2010 18:50, Brian Winfrey wrote:
...
The changes I made in this diff were simply to get it to compile.
Subsequently I renamed all files and folders to lowercase, converted
spaces to underscores and added a prefix to eliminate duplicate file
names where needed.
...
Another approach would be to look at (and reverse engineer) the byte code.
If it's not obfuscated, it might even be easier to parse and port than the
native Java.
How would you suggest I proceed in that.
Using the class file format (for example here:
http://en.wikipedia.org/wiki/Class_%28file_format%29),
it would be easy to parse through the tables, identify the class name,
its super class name, the interfaces it's implementing, and even the
public and private methods. The java compiler has done all the work into
translating the java code into nice tables. ;-)
I remember I did the exercise once. I've destroyed the code, but I could
do it again. I remember one of the more difficult parts was
understanding how java coded strings ;-) This was before anonymous
classes and methods, so this could be another difficulty. I don't know
how these are converted to byte code.
Once you have the structure, you can generate the pascal code. I would
recommend against generating one class per unit as Java does: since
pascal dependency rules are strict (no cycles), this would most
certainly result in uncompilable code. What I do when I translate Java
is to pre-declare all classes and interfaces at the top of the unit(s)
and then generate the full class interface further down.
Translating the statements inside the bytecode I haven't tried, since my
efforts were mostly for analyzing java code and measuring it.
I hope this helps,
Thierry
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
