Problem extending java.lang.Enum

[ekrich]

minimized code

import java.{lang => jl}

final class ConfigSyntax private (name: String, ordinal: Int)
    extends jl.Enum[ConfigSyntax](name, ordinal)

object ConfigSyntax {

  final val JSON = new ConfigSyntax("JSON", 0)
  final val CONF = new ConfigSyntax("CONF", 1)
  final val PROPERTIES = new ConfigSyntax("PROPERTIES", 2)

  private[this] final val _values: Array[ConfigSyntax] =
    Array(JSON, CONF, PROPERTIES)

  def values: Array[ConfigSyntax] = _values.clone()

  def valueOf(name: String): ConfigSyntax =
    _values.find(_.name == name).getOrElse {
      throw new IllegalArgumentException("No enum const ConfigSyntax." + name)
    }
}

problem

Currently the compiler requires an alias or fully specified class name for java.lang.Enum and errors when compiling.

too many arguments for constructor Enum: (): Enum[ConfigSyntax]

expectation

Should compile and not require a fully specified class name.

[ekrich]

Edit: this was removed as it is not applicable to the problem.

[ekrich]

I also confirmed that the following code works fine just in Dotty, not Scala 2.

import java.{lang => jl}

enum FromMapMode extends jl.Enum[FromMapMode]{
  case KEYS_ARE_PATHS, KEYS_ARE_KEYS
}

[bishabosha]

I’m sceptical if the name + ordinal constructor should be exposed in Scala as it’s not visible in Java either

[ekrich]

@bishabosha But this is code existing in the Scala wild as there are no such restrictions from Scala.
Also, this is needed to be compatible with Java enum for interoperability.

[ekrich]

A longer term solution is to provide duplicate enums for Scala 3 but this means editing in 2 places if needed. This is the approach I took here. ekrich/sconfig@4aecf41

[bishabosha]

@bishabosha But this is code existing in the Scala wild as there are no such restrictions from Scala.
Also, this is needed to be compatible with Java enum for interoperability.

Well I would just say for migration you would be required to use the built-in enum which would synthesise a super call to jl.Enum with the identifier of the constant, and later should be have semantically correct valueOf, values etc. without needing the scala library.

[bishabosha]

So the current plan is to prevent user-written classes that extend java.lang.Enum like the example, and migrate to the enum construct, once java compatible enums are complete - So I believe that this is out of scope to fix this in the meantime.