Scala Programming Language
  1. Scala Programming Language
  2. SI-6387

AbstractMethodError with vars implementing trait member

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Duplicate
    • Affects Version/s: Scala 2.8.1, Scala 2.9.2, Scala 2.10.0-M7
    • Fix Version/s: Scala 2.11.0-RC1
    • Component/s: Misc Compiler
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          Johannes Rudolph added a comment -

          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.

          Show
          Johannes Rudolph added a comment - 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.
          Hide
          Jason Zaugg added a comment -

          I believe that the proposal in SI-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.

          Show
          Jason Zaugg added a comment - I believe that the proposal in SI-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.
          Hide
          Eugene Vigdorchik added a comment -

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

          Show
          Eugene Vigdorchik added a comment - Yes, I like it better. Leaving source symbols as-as and generating delegates looks like the right thing.
          Hide
          James Iry added a comment -

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

          Show
          James Iry added a comment - 2.10.2 is about to be cut. Kicking down the road and un-assigning to foster work stealing.
          Hide
          Adriaan Moors added a comment -

          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.

          Show
          Adriaan Moors added a comment - 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.
          Hide
          Adriaan Moors added a comment -

          see SI-7085

          Show
          Adriaan Moors added a comment - see SI-7085
          Hide
          Jason Zaugg added a comment -

          I have noted this test case in description of SI-6387. We shouldn't have closed this ticket as a duplicate without carrying the test across and linking the tickets.

          Show
          Jason Zaugg added a comment - I have noted this test case in description of SI-6387 . We shouldn't have closed this ticket as a duplicate without carrying the test across and linking the tickets.

            People

            • Assignee:
              Adriaan Moors
              Reporter:
              Johannes Rudolph
            • Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development