headers
Ito Kazumitsu | 16 Mar 04:11
Picon

Bug report: void method invocation, Unicode escapes

Thanks for Jel.

And here is my bug report.  My test program is attached below.

Test case 0: evaluate "func(\"Test\\n\")"
Test case 1: evaluate "vfunc(\"Test\\n\")"
Test case 2: evaluate "func(\"\u65e5\u7acb\u96fb\u7dda\\n\")"
Test case 3: evaluate "func(\"\\u65e5\\u7acb\\u96fb\\u7dda\\n\")"

Results:
                         Java VM
Test case     Sun's 1.4.2_04             Kaffe 1.1.4
-----------   ----------------------     ---------------------
       0      PASS                       PASS
       1      VerifyError (*1)           PASS
       2      PASS                       PASS
       3      CompilationException (*2)  CompilationException (*2)

VerifyError (*1)
java.lang.VerifyError: (class: dump, method: evaluate signature:
([Ljava/lang/Object;)Ljava/lang/Object;) Unable to pop operand off an empty stack
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:1610)
        at java.lang.Class.getConstructor0(Class.java:1922)
        at java.lang.Class.newInstance0(Class.java:278)
        at java.lang.Class.newInstance(Class.java:261)
        at gnu.jel.Evaluator.compile(Unknown Source)
        at TestJel.main(TestJel.java:22)

   Seeing this result, I understand that we cannot use a method
(Continue reading)

Permalink | Reply |
headers
Konstantin L. Metlov | 16 Mar 17:27
Picon

Re: Bug report: void method invocation, Unicode escapes

Dear Ito Kazumitsu,

Yes, indeed there was the problem with returning voids from expressions. 
E.g. if the whole expression is merely a call to a function, returning 
void. I suspect this not very typical usage of JEL made the bug unnoticed.

The erroneous code, which JEL generated on returning voids was not really
a complete nonsense and much more forgiving Kaffe JVM was able to 
properly interpret it. Nevertheless, the code was wrong, and did not pass 
Sun's SDK verification, as it should.

Now returning of voids is fixed, the generated code in this situation is
the correct one and should pass any kind of verification. I have added a
new method "evaluate_void" to gnu.jel.CompiledExpression, which is
overridden by void expressions directly. Expressions returning voids can
also be evaluated by the non type-specific evaluate() method, in which
case 'null' is returned. Run time (prior to evaluation) type 
identification of JEL now also fully supports voids.

Unicode escapes were simply not implemented. The reason (probably not
really a good one) was that JEL receives an expression as
java.lang.String, which is already coded in unicode. Nevertheless, I have
implemented the \uXXXX escapes both in 'char' and 'String' literals. Now
all four of your tests successfully pass on Sun's JDK.

These fixes are scheduled for the next version 0.9.12 of JEL, pre-release 
of which I'm sending to you in my next private mail. If anyone else is 
interested in this pre-release, please contact me by E-mail.

Thank you for your report !
(Continue reading)

Permalink | Reply |

Gmane