scala language support

[maxandersen]

Feedback welcome - I'm not a scala super user but thought why not try add it :)

scala-cli exists in scala world and is really good and heavily similar (possibly inspired by?) jbang but it doesn't supprot jbang catalog so I thought - why not make it possible in jbang. thus this is not trying to compete with scala-cli nor replace it - definitely use scala-cli where you can :)

For now this just add .scala support just like for .java and .kt, .groovy.

meaning, we dont do like scala-cli does and wrap .sc content in a magical main body nor do we at this time support:
//DEPS com.lihaoyi::os-lib:0.9.1 but require user to be explicit about the package they need, i.e. //DEPS com.lihaoyi:os-lib_3:0.9.1.

I feel we should then rather call scala-cli directly and let it deal with that instead.

Anyhow - feedback welcome :)

[chabala]

When I was looking at what it would take for me to implement this PR, I started by searching for 'kotlin' in the codebase, as an example of another experimentally supported JVM language. I'm not sure that I found all of these files or their Kotlin-specific analogues. Just some thoughts:

• there's a Type enum in Source. Maybe some code could be made simpler by iterating over the types, e.g.

		} else if (ext.equals("groovy")) {
			return new GroovySource(resourceRef, replaceProperties);
		} else if (ext.equals("scala")) {
			return new ScalaSource(resourceRef, replaceProperties);
		} else if (ext.equals("jsh")) {
			return new JshSource(resourceRef, replaceProperties);

if every Type has an associated Type-Source class, then Type.findByExt(ext).getSource(), either passing the parameters, or maybe just letting getSource() return a method reference to the constructor. This may be applicable to the language specific parts of Cache and ProjectBuilder as well.

Then fewer things need to change to support a new language, less chance of missing something or getting out of sync.

• there's a lot of duplicated documentation. Could more of it be generated from a common source? Maybe it already is and it's just being tracked as separate files.

[wfouche]

public static final String DEFAULT_SCALA_VERSION = "3.8.1";

Scala 3 versions from 3.3 LTS through Scala 3.7 support JDK 8 and above.

Scala 3 versions starting with 3.8 have a new minimum JDK version of 17.

The DEFAULT_SCALA_VERSION should be "3.7.4" to allow JBang to use JDK8.

[wfouche]

I feel we should then rather call scala-cli directly and let it deal with that instead.

I agree. Keep is simple for now, and primarily aim to support Scala programs using Java JARs (Maven Central)

[wfouche]

I'm using scala-cli at the moment but looking will change my Scala example app to JBang once this functionality is released.

App.scala using scala-cli

//> using jvm 21
//> using dep io.github.wfouche.tulip:tulip-runtime:2.2.3
//> using javaOpt -Xmx2g -XX:+UseZGC -XX:+ZGenerational
//> using javaOpt -XX:+IgnoreUnrecognizedVMOptions
//> using javaOpt --enable-native-access=ALL-UNNAMED
//> using javaOpt --sun-misc-unsafe-memory-access=allow
//> using repositories m2local

package io.tulip

import io.github.wfouche.tulip.api.TulipApi

object App {
  def main(args: Array[String]): Unit = {
    TulipApi.generateReport(TulipApi.runTulip("benchmark_config.json"))
  }
}