Java reflection for source code. Have you have heard of it?

[ennio]

Hi.
This is my problem.
I have a proprietary framework with kind-of-java support. It uses
kind-of-java as a of scripting language.
You can write your own java class with a particular syntax, then you
upload this source code into the framework, it slightly modifies it,
compiles it with javac, and TADA you've your own script.
I would like to write a kind of bridge between standard Java source
code and this "particular-framework-script-syntax".
Here is an example of what i need to do.
I have to create Useless.my_java knowing the content of Useless.java.
Here are the files:

-Useless.java---------
class Useless {
Integer i;
public Useless() {
System.out.println("new Useless!");
i = new Integer(0);
AnotherUselessClass.doSomethingUseless();
}
}
-end-of-file----------

-Useless.my_java---------
class ${CLASS:Useless} {
Integer i;
public ${CLASS:Useless} () {
System.out.println("new Useless!");
i = new Integer(0);
${CLASS:AnotherUselessClass}.doSomethingUseless();
}
}
-end-of-file----------

To achieve this, i need a java parser-almost-compiler of java source
code.
I tried with Eclipse jdt libraries, but my problem is the following
one:
It doesn't tell me if, when it reads
AnotherUselessClass.doSomethingUseless()
if AnotherUselessClass is a class or a variable, because it could even
be a variable, and i need to know it.
if it's a class, Eclipse jdt can't tell me its path. (in which package?
or is it in current dir? )
Did anyone understand my terrific explaination?
Can anyone even give me a hint?
thanks

 

[Chris Uppal]

To achieve this, i need a java parser-almost-compiler of java source
code.

Depends on how complex the differences between almost-java and Java are, and on
how much knowledge about the surrounding real Java is needed to interpret the
extensions.

From the look of your examples it seems as if you could probably write a
scanner which recognised your ${CLASS.<name>} constructions without worrying
about the Java they are embedded in (except to recognise string constants and
comments). If so then you can probably translate those constructions directly,
and simply copy the real Java to the output.

However, if you need to understand the surrounding Java to understand the
extensions, or if the extensions are more complicated than they look in your
example, then you'll have to create a full parser for your language.

Personally, I would give up at this point because (a) Java has a ridiculously
complicated syntax (and semantics too, come to that), and it would be a
horribly messy task, and (b) Java's syntax isn't /stable/ -- they change it
around whenever some fuckwit at Sun (or the "community") comes up with another
way to add further complications.

Still, if for some reason I /had/ to do this based on Java, then I'd look into
a parser construction tool like ANTLR. I should imagine that comes with an
example parser for Java (though probably not /current/ Java), which you could
use as the basis for your extended language. The most likely way your program
would look is that it would use ANTRL (or whatever tool you choose) to create a
parse tree for the program written in almost-java, and then you would traverse
that emitting real Java derived from it.

-- chris

 

[Peter Van Weert]

To achieve this, i need a java parser-almost-compiler of java source
code.

http://www.jnome.org/ migth be what you need. The website and the
documentation there is far from complete or up to date though. You could
always contact the author if you are really interested...

Cheers,
Peter