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

Scalatra existing builds suffer java.lang.AbstractMethodError with Scala 2.11.3 #8899

Closed
scabug opened this Issue Oct 12, 2014 · 10 comments

Comments

Projects
None yet
2 participants
@scabug
Copy link

scabug commented Oct 12, 2014

Scalatra 2.3.0 works fine on Scala 2.11.0 , 2.11.1 and 2.11.2. However, it suffers java.lang.AbstractMethodError with Scala 2.11.3.

2014-10-12 12:30:50,627 ERROR [qtp1562951302-64] controller.Controllers$members$ org.scalatra.ScalatraParams.filterImpl(Lscala/Function1;Z)Ljava/lang/Object;
java.lang.AbstractMethodError: org.scalatra.ScalatraParams.filterImpl(Lscala/Function1;Z)Ljava/lang/Object;
    at scala.collection.TraversableLike$class.filter(TraversableLike.scala:270) ~[scala-library-2.11.3.jar:na]
    at org.scalatra.ScalatraParams.filter(ScalatraContext.scala:9) ~[scalatra_2.11-2.3.0.jar:2.3.0]
    at skinny.StrongParameters.permit(StrongParameters.scala:18) ~[skinny-common_2.11-1.3.3.jar:1.3.3]
    at skinny.controller.Params.permit(Params.scala:46) ~[skinny-framework_2.11-1.3.3.jar:1.3.3]
    at skinny.controller.SkinnyResourceActions$$anonfun$createResource$1.apply(SkinnyResourceActions.scala:139) ~[skinny-framework_2.11-1.3.3.jar:1.3.3]
    at skinny.controller.SkinnyControllerBase$class.withFormat(SkinnyControllerBase.scala:108) ~[skinny-framework_2.11-1.3.3.jar:1.3.3]
    at skinny.controller.SkinnyController.withFormat(SkinnyController.scala:6) [skinny-framework_2.11-1.3.3.jar:1.3.3]
    at skinny.controller.SkinnyResourceActions$class.createResource(SkinnyResourceActions.scala:135) ~[skinny-framework_2.11-1.3.3.jar:1.3.3]
    at controller.MembersController.createResource(MembersController.scala:8) ~[classes/:na]

I just tried Scalatra builds with the 2.11.3 compiler. They works fine.

See also for details:
skinny-framework/skinny-framework#193

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Oct 12, 2014

Imported From: https://issues.scala-lang.org/browse/SI-8899?orig=1
Reporter: Kazuhiro Sera (seratch)
Affected Versions: 2.11.3

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Oct 12, 2014

@retronym said:
Lukas, looks like this stems from 9276a1205f74fdec74206209712831913e93f359. Did we reason incorrectly about the binary compatibilty of that change?

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Oct 12, 2014

kenji yoshida said:
more simple example

https://github.com/xuwei-k/SI-8899

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Oct 12, 2014

Takashi Kawachi (tkawachi) said:
As kenji shown in the sample code, it's not specific to Scalatra. It seems to be caused when it extends standard collection.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Oct 12, 2014

kenji yoshida said (edited on Oct 12, 2014 10:39:30 AM UTC):
another examples

@scabug

This comment has been minimized.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Oct 12, 2014

@gkossakowski said:
The related PR is: scala/scala#3949

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Oct 12, 2014

@lrytz said (edited on Oct 12, 2014 4:58:56 PM UTC):
Making filterImpl non-private in PR #3949 was indeed not binary compatible. The problem is that making a trait method non-private changes its calling convention. Here's an example:

trait Tl {
  private def f1Impl = 0
  def f1 = f1Impl

  private[p] def f2Impl = 0
  def f2 = f2Impl
}

class Mp extends Tl

The point is that the invocation of f1Impl is statically known. So the compiler optimizes it and directly invokes the static method f1Impl in the trait implementation class Tl$class.

Method f2Impl on the other hand may be overwritten in subclasses of Tl, therefore the invocation is compiled as an invoke-interface of the method f2Impl in interface Tl. In the subclass Mp, a mixin is generated for f2Impl.


public abstract interface p/Tl {
  // NOTE: f1Impl is missing - it's private!
  public abstract f1()I
  public abstract f2Impl()I
  public abstract f2()I
}

public abstract class p/Tl$class {
  private static f1Impl(Lp/Tl;)I
  public static f1(Lp/Tl;)I
    ALOAD 0
    INVOKESTATIC p/Tl$class.f1Impl (Lp/Tl;)I  // Directly invokes the static method

  public static f2Impl(Lp/Tl;)I
  public static f2(Lp/Tl;)I
    ALOAD 0
    INVOKEINTERFACE p/Tl.f2Impl ()I  // Interface method
}

public class p/Mp implements p/Tl  {
  // generated mixins (forward to the static functions in Tl$class)
  public f1()I
  public f2Impl()I
  public f2()I
}

The manifestation: subclasses of TraversableLike compiled with 2.11.2 don't have a mixin for filterImpl, but the standard library of 2.11.3 invokes the interface method.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Oct 12, 2014

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Oct 15, 2014

@Blaisorblade said:
If anybody is wondering (like me) why MIMA didn't catch it, don't worry, MIMA is fine:
lrytz/scala@9276a12

The corresponding mima-failures can be whitelisted, as the changes are only to private[scala].

@scabug scabug closed this Nov 4, 2014

@scabug scabug added the blocker label Apr 7, 2017

@scabug scabug added this to the 2.11.4 milestone Apr 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.