Port all Scala code to Java

[Scott-Guest]

While Scala is a nice language, the consensus of the frontend team is that maintaining a mixture of Scala and Java causes more friction than it is worth:

• IntelliJ struggles to reason about the Scala code and reports false errors (Address all errors reported by IntelliJ #3867)
• We have to frequently convert between Java and Scala types (see the usages of collections.scala) and write boilerplate code to offer two versions of the same methods (e.g. getOption and getOptional in Att.scala).
• As a company, my impression is that more of us are familiar with the intricacies of Java than of Scala.

As a result, we have decided that

• All new code should be written in Java
• In the longterm, all existing Scala code should be ported to Java as well

The largest blocker will be the matching library in the LLVM backend, which makes heavy usage of pattern matching and likely can't be ported until we update to Java 21 (#3499).

However, searching the frontend, there are only 47 Scala files, and many of them can be straightforwardly ported even without pattern matching support in Java.

A high level roadmap:

• Port Scala case classes not involved in pattern matching to Java record classes inheriting from a sealed interface
  • Rich.scala, LabelInfoFromModule.scala, Location.scala, etc.
  • The main KORE data structures likely can't be ported due to their use in matching
• Port Scala classes/algorithms not making use of pattern matching
  • POSet.scala, Att.scala, etc.
• Make remaining Scala classes as Java-esque as possible
  • Port any trait to an interface
  • Use Java types for all members that are not pattern matched on
    • We already have pcollections as a dependency, which provides immutable functional data structures
• Update to Java 21
• Port remaining Scala code

[Scott-Guest]

Another option might be to extend @Baltoli's pattern matching library then port matching to C++.

This would be more work in the short term, but would also make the LLVM backend more cohesive and get rid of the reverse dependency on K.

[ehildenb]

Love the idea of removing the reverse dependency! LLVM backend being self-contained seems worth the effort. That matching code is just used for LLVM codegen right?

[Baltoli]

Yep, that's the only place it's used. I think we'd want to first build a C++ implementation that generates the same YAML as the scala code does, test equivalence of the outputs, then eliminate the intermediate YAML. It would be a reasonably big rewrite but Dwight's documentation is really good, and we have a strong way of testing any new implementation!