The issue lies in our java outline parser, which always produces a dummy constructor:

package <empty> {
  object JavaClass() {}
  class JavaClass private[this](x$1: scala.Unit) extends Object {
    def <init>() = _root_.scala.Predef.???
  }
}

The method is the actual constructor found by the parser (so for this case it's public, if we were to add a private java constructor it would become private etc.), but there is no way to locate it with the quotes.reflect methods.
In scala 2 no such system was used, so after parsing we would get:

package example {
  object JavaClass extends  {
    def <init>()
  };
  class JavaClass extends _root_.java.lang.Object {
    def <init>()
  }
}

and primaryConstructor would return the correct method. In cases where there are more public constructors it would return the first declared one.

Another issue here is the fact that if we split compilations into 2 runs, I believe we read the java class file instead of using our source outline parser, which results in obtaining the correct primaryConstructor.

Perhaps we should leave the JavaParser as is and add a quotes reflect method to return all constructors of a java class?

There was some issue with Scala 2 primaryConstructor and Java as well - https://github.com/scala/scala/blob/d76229ef6f6b2e79422d5990ba2deb4aed340277/src/reflect/scala/reflect/api/Symbols.scala#L960 - so I am not surprised.

Ideally, this behavior would be fixed, but if it cannot, I'd hope that the proper workaround could be documented, ideally in APIs documentation with some code examples. For Scala 2/Scala 3 cross-compilable macros I'd like to be able to align the behavior or at least be able to document the inconsistencies and their sources.

E.g. if it was possible to:

• verify that it's a Java class (Flags.JavaDefined?)
• always get a list of all constructors (sym.declarations.filter(_.isConstructor)?)
• sort them by position and assume that the first one is primary (kinda sketchy but at least deterministic - Ordering.Option(Ordering.fromLessThan[Position] { (a, b) => a.startLine < b.startLine || (a.startLine == b.startLine && a.startColumn < b.startColumn) }))

it would be... something. For classes with a single, default constructors (like most beans) it should be basically deterministic behavior, for classes with multiple-constructors... well, we there could be some best effort.