Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AbstractMethodError with vars implementing trait member #6387

Closed
scabug opened this issue Sep 18, 2012 · 8 comments
Closed

AbstractMethodError with vars implementing trait member #6387

scabug opened this issue Sep 18, 2012 · 8 comments
Assignees
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Sep 18, 2012

We recently had this problem with spray:

trait A {
  def foo: Long
}

object Main {
  def a(): A = new A {
    var foo: Long = 1000L

    val test = () => {
      foo = 28
    }
  }
  def main(args: Array[String]) {
    println(a().foo)
  }
}

will throw

java.lang.AbstractMethodError: Main$$anon$1.foo()J
	at Main$.main(Main.scala:14)
	at Main.main(Main.scala)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)

Important things here:

  • implementing foo with a var
  • accessing the setter of foo in an inner anonymous class
  • function a() having an explicit return-type

The same behavior can be observed in 2.8.2, 2.9.2, and 2.10.0-M7.

A workaround is not to implement A.foo directly with a var but use an auxiliary var and implement foo separately.

@scabug
Copy link
Author

@scabug scabug commented Sep 18, 2012

Imported From: https://issues.scala-lang.org/browse/SI-6387?orig=1
Reporter: @jrudolph
Affected Versions: 2.8.1, 2.9.2, 2.10.0-M7
Duplicates #7085

@scabug
Copy link
Author

@scabug scabug commented Sep 18, 2012

@jrudolph said:
Another piece of information. What happens is this:

public final class Main$$anon$1 implements A {
  public long Main$$anon$$foo();
  public final void Main$$anon$$foo_$eq(long);
  public Main$$anon$1();
}

Under the circumstances from above foo's name gets mangled.

@scabug
Copy link
Author

@scabug scabug commented Apr 8, 2013

@retronym said:
I believe that the proposal in #7085 offers a cleaner solution to this problem: we should leave the original method in place and create a public forwarder to it, rather than renaming and publicising it.

@scabug
Copy link
Author

@scabug scabug commented Apr 9, 2013

@vigdorchik said:
Yes, I like it better. Leaving source symbols as-as and generating delegates looks like the right thing.

@scabug
Copy link
Author

@scabug scabug commented May 20, 2013

@JamesIry said:
2.10.2 is about to be cut. Kicking down the road and un-assigning to foster work stealing.

@scabug
Copy link
Author

@scabug scabug commented Dec 6, 2013

@adriaanm said:
We're going to focus on fixing this in 2.11. If there's enough interest and time, this can be backported to 2.10.

@scabug
Copy link
Author

@scabug scabug commented Jan 28, 2014

@adriaanm said:
see #7085

@scabug scabug closed this Jan 28, 2014
@scabug
Copy link
Author

@scabug scabug commented Feb 18, 2014

@retronym said:
I have noted this test case in description of #6387. We shouldn't have closed this ticket as a duplicate without carrying the test across and linking the tickets.

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

Successfully merging a pull request may close this issue.

None yet
2 participants