Skip to content

Fix #9115: Make Java-defined fields effectively final #9126

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

Merged
merged 1 commit into from
Jun 8, 2020

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jun 8, 2020

No description provided.

@odersky odersky merged commit f26ff0f into scala:master Jun 8, 2020
@odersky odersky deleted the fx-#9115 branch June 8, 2020 14:52
smarter added a commit to dotty-staging/dotty that referenced this pull request Jul 22, 2020
…d is present

In scala#9126, Java fields were marked effectively finals to prevent false
overrides. This poses a problem when a Java field and method of the same
name are present, because a Scala val or def will match both of these
according to Denotation#matches. We could tweak `matches` further to not
consider the Java field to match any Scala definition, but that might
introduce new problems (we couldn't trust `FullMatch` anymore and would
need to check the info of any Java symbol which might cause cycles, we
would also probably need to tweak overloading resolution to avoid
ambiguity when trying to decide whether to select the Java field or the
Scala override of the Java method).

This commit takes a different approach: we allow a val or def to match a
Java field, but we tweak the logic that checks whether the `override`
modifier is correctly used to disallow definitions that _only_ match a
Java field (thus preventing tests/neg/i9115 from compiling), while
letting through definitions that both match a Java field and something
else (thus making tests/pos/i9392 compile).

This is all a bit messy but I can't think of a better solution which
wouldn't be significantly more complicated.
smarter added a commit to dotty-staging/dotty that referenced this pull request Jul 27, 2020
…d is present

In scala#9126, Java fields were marked effectively finals to prevent false
overrides. This poses a problem when a Java field and method of the same
name are present, because a Scala val or def will match both of these
according to Denotation#matches. This commit changes `matches` to
prevent Java field from matching any Scala method, but we can't prevent
them from matching Scala definitions with NotAMethod signature without
introducing more complexity, so the following still doesn't compile
unlike Scala 2:

```java
package pkg;

public class J {
    int i = 0;
    public int i() { return 1; }
}
```

```scala
class S2 extends pkg.J {
  override def i: Int = 2 // error
}
```

I have an alternative fix at scala#9412 which doesn't have this issue but is
more hacky.
smarter added a commit to smarter/dotty that referenced this pull request Aug 1, 2020
…d is present

In scala#9126, Java fields were marked effectively finals to prevent false
overrides. This poses a problem when a Java field and method of the same
name are present, because a Scala val or def will match both of these
according to Denotation#matches. This commit changes `matches` to
prevent Java field from matching any Scala method, but we can't prevent
them from matching Scala definitions with NotAMethod signature without
introducing more complexity, so the following still doesn't compile
unlike Scala 2:

```java
package pkg;

public class J {
    int i = 0;
    public int i() { return 1; }
}
```

```scala
class S2 extends pkg.J {
  override def i: Int = 2 // error
}
```

I have an alternative fix at scala#9412 which doesn't have this issue but is
more hacky.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants