Class generated for interface-implementing block does not match signature when arg not specified #69

nedgar opened this Issue Mar 27, 2011 · 5 comments


None yet

3 participants

nedgar commented Mar 27, 2011
interface Console do
  def write(s:String):void;end

class Greeter
  def greet(m:String, c:Console)
    c.write m
end"Hi") {
  puts "Yo"

Generates the following class for the block:

  public static class __xform_tmp_2 extends java.lang.Object implements Console {
    public void write() {

At runtime, this results in:

Exception in thread "main" java.lang.reflect.InvocationTargetException
Caused by: java.lang.AbstractMethodError: BlockTest1$__xform_tmp_2.write(Ljava/lang/String;)V
    at Greeter.greet(BlockTest1.mirah:8)
    at BlockTest1.main(BlockTest1.mirah:12)

I've also had it crash the VM on one of the SWT Snippets, if this happens when it's in a callback e.g. due to button press.

The signature should be write(String m) instead, even if m is not used.


Would you expect it to give you an error about the wrong # of arguments on the block or to try to work anyway?


"Comment 1 by rogerpack2005, May 30, 2011
I was able to reproduce this :)"

nedgar commented Sep 6, 2011

I think at the time I expected it to generate a write(String s) method where s is ignored in its body, but maybe it does make more sense for the compiler to flag the mismatch in the # of args.


I've got an idea for fixing this that I'll look into next week. Essentially, when turning the block into a closure class, check the provided args against the args of the fn it's implementing and raise an error if they don't match.

We could probably handle the no args passed to the block case there too.

right now it just blindly uses the arguments for the block when constructing the method definition.


now, Mirah complains when the block's args don't match. 98acfef

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment