在运行时确定String中Java表达式的返回类型

Question

At runtime, in my Java program, given a String, I 'd like to know the return type. For example:

• 1 + 1 returns int
• 1L + 1L returns long
• 1L + 1 returns long
• 1 + 1.5 returns double
• 1 + 2 - 3 * 4 / 5 returns int
• 1 / 0 returns int
• 1 + Math.nextInt() returns int
• 1.5 + Math.nextInt() returns double
• Color.RED returns java.awt.Color
• Given that a is an int: a + 1 returns int
• Given that a is an int: a + 1.5 returns double

There is no need to actually evaluate the code: I just need the return type. How can I do this with the JDK runtime compiler, ECJ JDT or any other pure Java dependency?

---

Detailed code: Here's a simplified, pseudo-code unit test for this code:

public static void ExpressionTyper {
    public String determineType(String expression, Map<String, String> variableTypes) {
       ... // How do I implement this?
    }
}
public void ExpressionTyperTest {
    @Test public void determineType() {
        assertEquals("int", ExpressionTyper.determineType("1 + 1", emptyMap());
        assertEquals("long", ExpressionTyper.determineType("1 + 1L", emptyMap());
        assertEquals("double", ExpressionTyper.determineType("1 + 1.5", emptyMap());
        assertEquals("int", ExpressionTyper.determineType("a + 1", mapOf({"a", "int"}));
        assertEquals("int", ExpressionTyper.determineType("a + b", mapOf({"a", "int"}, {"b", "int"}));
        assertEquals("double", ExpressionTyper.determineType("a + b", mapOf({"a", "double"}, {"b", "int"}));
    }
}

Answer 1

I think this depends on the range of input you want to be able to process.

You see, in the end you are asking: how do I evaluate string expressions at runtime.

So, the short answer is: you need some kind of interpreter / REPL implementation; or at least "parts" of that.

Another approach could be to use the javax compiler to simply compile the thing, and then deduce the type, like here .

Other options would go along the lines of certain "compiler construction" topics, like constant folding .

Answer 2

I've not tried this ...

1. Wrap your expression in code like this:

     public class Test { private Test xxx = <<insert expression>>; } 

2. Compile code.

3. Parse the compilation error message to extract the compiler's idea of the RHS type.

The problem is that an expression like Math.nextInt() might require an import to be compilable, and I doubt that there is a bombproof way to infer what the import ought to be. Still, this should work for a useful subset of expressions.

This approach is also fragile and non-portable since it depends on the precise form of the compilation error message which is liable to be compiler / version dependent.

---

A better solution (but more work) would be to implement a parser and type-checker for your Java subset expression language.

Answer 3

To do this for arbitrary expressions, you need a full Java front end that will parse the string and determine its type. In essence, you need what the compiler does.

Eclipse JDT may offer a solution; I'm not very familar with it.

Our DMS Software Reengineering Toolkit with DMS's full Java front end can do this. DMS parses source according to the front end it is using, and then can call on front end services to analyze that code.

The Java front end provides parsing for Java in its various versions and various ways to parse (a file, a stream, a string), and will then build a tree for the parsed text. The Java name resolver built into the front end can be asked to compute the type of an arbitrary expression according to the scoping rules in effect at a specific point in the code.

For OP, this may not be what he wants since he insists on a Java-based answer and DMS is not Java-based (he did ask for "... any other dependency"). The closest one might come here is invoke DMS as a sub-process, and ask DMS to print the type of the expression. If his expressions have an extremely small number of types as shown in his example, this would probably work. If not, he's going to need a complex bit of machinery to read expression types, which in their full glory (eg, package-resolved, templated form) can be pretty complex.

If OP is willing to severely restrict the class of expressions he needs to handle to just simple arithmetic, he might be able to build his own expression parser and work out the type for himself. See my SO answer on how to build a recursive descent parser by hand: https://stackoverflow.com/a/2336769/120163 This same thread of answers also shows how to build a tree and 'evaluate' it; he can evaluate it for the type rather than the computed result.

Otherwise he is going to need the big hammer.