Java additions can silently break overloading extension methods

[soronpo]

I used Java 11 for a long time and I had an extension method indent on String that indents a string.
Java 12 and above introduced its own indent method. As a result, my existing code broke, like demonstrated in the following code.

Compiler version

v3.2.2-RC2

Minimized code

extension (text: String)
  def indent: String = text

println("hello".indent)

Output

Under Java 12 and above:

Playground$$$Lambda$7955/0x00000008010fc800@4e7d4166

Expectation

Print hello or at least give a warning/error that overloading existing class methods via extension methods is not possible.

[sjrd]

That's the way it is, I'm afraid. Backward source compatibility can never be promised in the presence of extension methods.

There could potentially be a warning at the definition of indent, but it would only happen when that extension method gets compiled with Java 12. The code that uses indent would never see the difference.

[odersky]

I also think we should warn when compiling an extension method for a value that already has a member with the same name; that's the only thing that can reasonably be done.

[nicolasstucki]

A case that needs to be taken into account is the following

trait Foo:
  type X
  extension (text: X) def indent: String
trait Bar extends Foo:
  type X = String
  extension (text: X) def indent: String = text

In this case, we should not warn. This kind of cases can be found in scala.quoted.Quotes and QuotesImpl.

[dwijnand]

indent isn't a "member" there anyways.

[som-snytt]

There was one case exposed by the PR where extension (s: String) def isAbsolute was inadvertently refactored to Path.

Probably this happens more often than one might assume.

The converse use case is that the spurious extension is a backup for cross-compiling against old API that lacks the method.