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

override Unit returning method in a parameterized class doesn't override

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Scala 2.8.1, Scala 2.9.0
    • Fix Version/s: Scala 2.10.0
    • Component/s: Misc Compiler
    • Labels:
      None

      Description

      I have an entry point wrapper that looks something like the trait listed below that is intended to expose a main for a java entry point if type T = Unit or an arbitrary return type T if the module is embedded:

      trait RunWrapper[T] {
        def run(args : Array[String]) : T;
        def main(args : Array[String]) : T = {
          try { run(args) } finally { }
        }
      }
      
      // Entry point for java
      object A extends RunWrapper[Unit] {
        def run(args : Array[String]) { println("the end") }
      }
      

      Unfortunately, I get this bytecode from the compiler (the same for both 2.8.1 and 2.9.0.1):

      $ javap A
      Compiled from "test.scala"
      public final class A extends java.lang.Object

      { public static final java.lang.Object main(java.lang.String[]); public static final void run(java.lang.String[]); }

      Why do I get a return type of java.lang.Object, in this case, for main()? How do I get void in this scenario so that java will allow my to use A as an entry point?

      However, if I define the following:

      object B extends RunWrapper[Unit] {
      def run(args : Array[String])

      { println("the end") }

      override def main(args : Array[String]) { try

      { run(args) }

      finally { } }
      }

      I get this:

      $ javap B
      Compiled from "test.scala"
      public final class B extends java.lang.Object{
          public static final void main(java.lang.String[]);
          public static final void run(java.lang.String[]);
          public static final java.lang.Object main(java.lang.String[]);
      }
      

      So it seems override didn't override anything and the compiler doesn't complain or warn about this. Is this a boxing issue?

        Activity

        Hide
        Paul Phillips added a comment -

        OK, let's see here:

        The return type of Object in RunWrapper is correct. This is how generics work.

        Unless we special case main, you will have to write a method which is specifically Unit, you can't use a generic implementation because the jvm requires the exact signature.

        When I first saw the example I thought there was a bug, but now if there is one I don't know what it is, other than that we should spot a method which looks like it's trying to be an entry point and warn that it is not in fact an entry point.

        Show
        Paul Phillips added a comment - OK, let's see here: The return type of Object in RunWrapper is correct. This is how generics work. Unless we special case main, you will have to write a method which is specifically Unit, you can't use a generic implementation because the jvm requires the exact signature. When I first saw the example I thought there was a bug, but now if there is one I don't know what it is, other than that we should spot a method which looks like it's trying to be an entry point and warn that it is not in fact an entry point.
        Hide
        s wade added a comment -

        I'm guessing that object B is the bug. Shouldn't the override yield a warning or an error instead of quietly creating a main method with a void return type in addition to the base class's main?

        Show
        s wade added a comment - I'm guessing that object B is the bug. Shouldn't the override yield a warning or an error instead of quietly creating a main method with a void return type in addition to the base class's main?
        Hide
        Paul Phillips added a comment -

        No, that is also how generics work.

        Show
        Paul Phillips added a comment - No, that is also how generics work.
        Hide
        s wade added a comment -

        got it. Thanks for the explanation.

        Show
        s wade added a comment - got it. Thanks for the explanation.
        Hide
        Paul Phillips added a comment -

        Better error messages in 2064372659 .

        Show
        Paul Phillips added a comment - Better error messages in 2064372659 .

          People

          • Assignee:
            Paul Phillips
            Reporter:
            s wade
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development