Cannot transform Scala class to Java class

[frevib]

Checklist

• I read the documentation at https://chimney.readthedocs.io/ and checked that the functionality exists
• I verified that the behavior for my use case doesn't match the documentation
• I checked the https://github.com/scalalandio/chimney/issues and haven't found the issue reported
  • I checked the https://github.com/scala/bug/issues and haven't found the issue reported there - relevant for Scala 2 compiler crashes, since it might be a bug in the compiler
  • I checked the https://github.com/lampepfl/dotty/issues and haven't found the issue reported there - relevant for Scala 3 compiler crashes, since it might be a bug in the compiler
• I confirmed that the bug is not related to functionality that was deprecated: lifted transformers (TransformerFs) or unsafeOption flags
• I believe that this is actual bug, rather than a question how to use existing features

Describe the bug

Cannot transform Scala class to Java class. Java class to Scala class does work.

Reproduction

Transform a Scala class with any number of fields to an identical Java class. E.g.

//> using jvm 17
//> using scala 3.3.3
//> using options -
//> using dep io.scalaland::chimney::0.8.5

personScala.into[PersonJava].transform

Full example:
https://github.com/frevib/chimney-java-enum-bug-example/tree/scala-to-java-object-not-working

Expected behavior

Transformation to succeed.

Actual behavior
Error showing:

Chimney can't derive transformation from com.eventloopsoftware.PersonScala to com.eventlooopsoftware.PersonJava

com.eventlooopsoftware.PersonJava
  derivation from personscala: com.eventloopsoftware.PersonScala to com.eventlooopsoftware.PersonJava is not supported in Chimney!

Which Chimney version do you use

0.8.5

Which platform do you use

• JVM
• Scala.js
• Scala Native

If you checked JVM

openjdk version "17.0.9" 2023-10-17
OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode)

Additional context

Iike this #482 issue before, I've tried to run this on another (Intel) machine, but the same error happens.

[frevib]

Could above issue also be something that works sometimes, and sometimes not? I see it now working in another project:

    private def mapSizeTrace(sizeTrace: ScalaTrace): JavaTrace = {
      sizeTrace
        .into[JavaTrace]
        .withFieldComputed(_.getId, _.id)
        .withFieldComputed(_.getName, _.name)
        .transform
    }

We earlier had some issues with Chimney in a Scala 2.13 not picking up some mappings, while for other classes it did pick up the mappings. We then decided to get rid of it as we didn't understand what was going on. Am I missing something? Is there more known about Chimney acting inconsistent?

[MateuszKubuszok]

We earlier had some issues with Chimney in a Scala 2.13 not picking up some mappings, while for other classes it did pick up the mappings.

Which mappings? Implicits? Automatic matching of fields? Manual overrides? .enableMacrosLogging should tell more about what macro attempted to do and why. Without this information we are only guessing.

Is there more known about Chimney acting inconsistent?

The only inconsistencies that I know of are https://chimney.readthedocs.io/en/stable/troubleshooting/#sealed-traits-fail-to-recompile or https://chimney.readthedocs.io/en/stable/troubleshooting/#javalangunsupportedoperationexception-positionpoint-on-noposition-error . Both are a result of a buggy Scala 2 compiler behavior that Chimney would never be able to fix (here one of them is won't fix, you just have to clean and compile again, and the other is fixed in newest 2.13).

There were also some cases when Scala 2 had a bug which were marked as wontfix but which could be worked around in the code - that is when you learned that there is a workaround to apply when you received a bug report, e.g. https://github.com/scalalandio/chimney/blob/master/chimney-macro-commons/src/main/scala-2/io/scalaland/chimney/internal/compiletime/TypesPlatform.scala#L31 .

Whether this bug is one of these cases might be something I learn when I'll have some time to investigate and reproduce the bug (no ETA on this).

[MateuszKubuszok]

I injected some debug code into our utilities to check the behavior:

    def isPOJO[A](implicit A: Type[A]): Boolean = {
      val sym = TypeRepr.of(using A).typeSymbol
      // extra logic for debugging
      if sym.toString.contains("PersonJava") then {
        println(sym)
        println(sym.primaryConstructor)
        println(sym.primaryConstructor.isPublic) // our extension method based on flags
        println(sym.primaryConstructor.flags.show)
      }
      !A.isPrimitive && !(A <:< Type[String]) && sym.isClassDef && !sym.isAbstract && sym.primaryConstructor.isPublic
    }

for target

public class PersonJava {
    // private doesn't work when Java -> Scala case class
    // use enable bean getters, then it works
    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public PersonJava(String name) {
        this.name = name;
    }
}

it gave me

class PersonJava
method <init>
false
Flags.JavaDefined | Flags.Local | Flags.Method | Flags.Private | Flags.PrivateLocal

As far as I can tell it's a bug in Scala 3 macros - public constructor is flagged as Private so Chimney's behavior is quite correct assuming that compiler is not lying.

@jchyb should I report you a bug?

[MateuszKubuszok]

I'll close this ticket - there is nothing I can do in Chimney to fix it, and once it will get fixed in the compiler then Chimney will receive the correct behavior as well. Optionally, I could add a note in the docs that compiler upgrade is recommended when the fix is released.

[frevib]

Thx @MateuszKubuszok. A note would be helpful for people who experience this issue for the first time.