Fix JavaMethodType creation and parameter matching of JavaMethodTypes

[olhotak]

Based on #339.

Fixes java-override test.

The Java method did have a JavaDefined flag.

The bugs were:

• Namer ignored the JavaDefined flag and made a MethodType anyway, instead of a JavaMethodType.
• TypeComparer.matchingParams had the isJava tests for the two methods switched.

[olhotak]

Scalac converts Object to Any in both UnPickler (for .class inputs) and in Namers (for Java source inputs):

       val makeMethodType = (vparams: List[Symbol], restpe: Type) => {
          // TODODEPMET: check that we actually don't need to do anything here
          // new dependent method types: probably OK already, since 'enterValueParams' above
          // enters them in scope, and all have a lazy type. so they may depend on other params. but: need to
          // check that params only depend on ones in earlier sections, not the same. (done by checkDependencies,
          // so re-use / adapt that)
          if (meth.isJavaDefined)
          // TODODEPMET necessary?? new dependent types: replace symbols in restpe with the ones in vparams
            JavaMethodType(vparams map (p => p setInfo objToAny(p.tpe)), restpe)
          else
            MethodType(vparams, restpe)
        }

Dotty does it only in UnPickler, but (currently) not in Namer.

To be consistent with Scalac, we could additionally do it in Namer, and then revert the change that switched things in matchingParams.

Alternatively, we can think about whether in Dotty, we want Java Object to be represented internally as Any or Object. If we decide to keep it as Object, then we would need to remove the conversion from UnPickler for consistency.

[odersky]

Ah I see. I think dotty needs to behave like scalac here. The problem is
that Scala does not have a concept of auto-boxing as Java does. So we
cannot pass an Int to an Object. But people have come to expect that this
works if the Object is the type of a Java parameter.

On Sun, Feb 1, 2015 at 8:52 AM, Ondřej Lhoták [email protected]
wrote:

Scalac converts Object to Any in both UnPickler (for .class inputs) and in
Namers (for Java source inputs):

   val makeMethodType = (vparams: List[Symbol], restpe: Type) => {
      // TODODEPMET: check that we actually don't need to do anything here
      // new dependent method types: probably OK already, since 'enterValueParams' above
      // enters them in scope, and all have a lazy type. so they may depend on other params. but: need to
      // check that params only depend on ones in earlier sections, not the same. (done by checkDependencies,
      // so re-use / adapt that)
      if (meth.isJavaDefined)
      // TODODEPMET necessary?? new dependent types: replace symbols in restpe with the ones in vparams
        JavaMethodType(vparams map (p => p setInfo objToAny(p.tpe)), restpe)
      else
        MethodType(vparams, restpe)
    }

Dotty does it only in UnPickler, but (currently) not in Namer.

To be consistent with Scalac, we could additionally do it in Namer, and
then revert the change that switched things in matchingParams.

Alternatively, we can think about whether in Dotty, we want Java Object to
be represented internally as Any or Object. If we decide to keep it as
Object, then we would need to remove the conversion from UnPickler for
consistency.

—
Reply to this email directly or view it on GitHub
#345 (comment).

Martin Odersky
EPFL

[olhotak]

I have updated the fix to be like scalac: Namer converts Object parameters in Java methods to Any. The switch in TypeComperer.matchingParams has been reverted.

I have some concern over the destructive update of symbol.info, but I did it that way for consistency with scalac. A (probably messy) alternative would be to change Object to Any somewhere inside the completer for the ValDef symbol for the parameter, if it has the JavaDefined and Param flags set.

[olhotak]

Rebased to current master.