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

Java and Scala compilers treat records differently, Scala compiler not exposing accessor methods #19386

Closed
ek-gh opened this issue Jan 5, 2024 · 10 comments · Fixed by #19583
Closed

Comments

@ek-gh
Copy link

ek-gh commented Jan 5, 2024

Compiler version

3.3.1

Minimized code

MyRecord.java:

public record MyJavaRecord(String name, Integer age) {}

MyTest.scala

object MyScalaObject {
  @main def test(): Unit = {
    val javaRecord = new MyJavaRecord("Name", 50)
    println(javaRecord.name())
    println(javaRecord.age)
  }
}

If MyJavaRecord is compiled with java compiler, and MyScalaObject is compiled with scala compiler using class file generated by Java compiler for the record, you'd get no syntax errors from scala compiler.

If MyJavaRecord & MyScalaObject are both compiled with scala compiler, first println would give you syntax error.

Expectation

When record is compiled via Scala compiler, it exposes accessor methods to the fields just like Java compiler. We should get no errors compiling both with scala compiler. Scala compiler should not enforce a syntax for java data type that is illegal by java compiler.

@ek-gh ek-gh added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Jan 5, 2024
@som-snytt
Copy link
Contributor

Same in Scala 2. Except more carets in Scala 3.

➜  i19386 scalac -d /tmp/sandbox *a
MyScalaObject.scala:5: error: not enough arguments for method apply: (i: Int): Char in class StringOps.
Unspecified value parameter i.
    println(javaRecord.name())
                           ^
1 error
➜  i19386 ~/projects/dotty/bin/scalac -d /tmp/sandbox *a
-- [E171] Type Error: MyScalaObject.scala:5:27 -------------------------------------------------------------------------
5 |    println(javaRecord.name())
  |            ^^^^^^^^^^^^^^^^^
  |            missing argument for parameter i of method apply in class StringOps: (i: Int): Char
1 error found

@jchyb jchyb added compat:java and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Jan 9, 2024
yilinwei added a commit to yilinwei/dotty that referenced this issue Feb 1, 2024
We change the proxy method to take in a single argument. This also
exposed a second issue where the overriden methods were not
invalidated correctly in the `Namer`.
bishabosha added a commit that referenced this issue Feb 9, 2024
This is a dependency of #19577 and should be reviewed and merged first.

fixes #18639
fixes #19386
fixes #19578
@Kordyjan Kordyjan added this to the 3.4.1 milestone Feb 14, 2024
@ek-gh
Copy link
Author

ek-gh commented Mar 14, 2024

Folks, is there a plan to incorporate the fix to this issue into the 3.3 LTS?

@He-Pin
Copy link

He-Pin commented Mar 14, 2024

I think this should be backported, and I'm using Java 21 LTS at work too.

@som-snytt
Copy link
Contributor

No one asked, but scala/scala#10715

@ek-gh
Copy link
Author

ek-gh commented Mar 14, 2024

IMHO incompatibility with Java is a significant bug to remain in LTS version of Scala.

@ek-gh
Copy link
Author

ek-gh commented Mar 14, 2024

Moreover, it represents a real challenge to developers who work on mix Java-Scala projects.

@som-snytt
Copy link
Contributor

The workaround is compileOrder := CompileOrder.JavaThenScala per https://www.scala-sbt.org/1.x/docs/Java-Sources.html

Someone always mentions that setting eventually. I've never actually used it but it's an easy internet search.

@ek-gh
Copy link
Author

ek-gh commented Mar 14, 2024

Would this be required for tools such as Scala plugin for IntelliJ? Or would this setting be integral to Scala 3.3 LTS compiler settings so no other client code / tool has to think about this?

@ek-gh
Copy link
Author

ek-gh commented Apr 4, 2024

Folks, 3.4.1 seems to have resolved this issue. But since 3.3 is supposed to be Long Term Support, I will please request the fixes to be brought in to 3.3 as well. As of 3.3.3, I am still seeing the same problem. I am not sure who to reach for this request, so just adding it to this ticket.

@som-snytt
Copy link
Contributor

@ek-gh I don't what the process is, but the PR is labelled backport:nominated.

WojciechMazur pushed a commit that referenced this issue Jun 28, 2024
We change the proxy method to take in a single argument. This also
exposed a second issue where the overriden methods were not
invalidated correctly in the `Namer`.

[Cherry-picked 47511ae]
WojciechMazur pushed a commit that referenced this issue Jun 30, 2024
We change the proxy method to take in a single argument. This also
exposed a second issue where the overriden methods were not
invalidated correctly in the `Namer`.

[Cherry-picked 47511ae]
WojciechMazur pushed a commit that referenced this issue Jun 30, 2024
We change the proxy method to take in a single argument. This also
exposed a second issue where the overriden methods were not
invalidated correctly in the `Namer`.

[Cherry-picked 47511ae]
WojciechMazur pushed a commit that referenced this issue Jun 30, 2024
We change the proxy method to take in a single argument. This also
exposed a second issue where the overriden methods were not
invalidated correctly in the `Namer`.

[Cherry-picked 47511ae]
WojciechMazur added a commit that referenced this issue Jul 1, 2024
)

Backports #19583 to the LTS branch.

PR submitted by the release tooling.
[skip ci]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants