JVM stabilization ticket

[chrisjrn]

Currently, JVM features have been released for a year, but are still marked experimental. It would be good to release these as "stable" in the short-term.

This ticket will accumulate a list of other tickets that block stabilization, and will remain open for a week unless stability-blocking bugs are added here.

[chrisjrn]

cc @tdyas @stuhood

[tdyas]

cc @somdoron as well since I recall their organization uses the Scala backend and they may have some thoughts on stability blockers.

[tdyas]

Also product question: should "stability" be interpreted "accept the current feature set as the stable feature set and stablize that" or are there additional features which should be part of a "stable" release of the JVM support?

[chrisjrn]

@tdyas At the moment, we don't have a good definition of "stability" other than by reference to the experimental category or to the deprecation policy.

In my view, it means that "the interface can be relied upon to not change without a deprecation cycle". That actually describes the state of the JVM backends, since they haven't significantly changed in several releases now.

Note that stability does not mean that new features cannot be grown, just that the interface for existing features must not break unexpectedly in order to add those new features.

[somdoron]

For us it is pretty stable, I have two concerts at the moment, one is around JVM and one specific for Scala:

1. JVM - the cache is not very stable, sometimes our builds take a long time even after building the same code twice.
2. Scala - scala is very slow when building without a cache (or when the cache invalidates), up to 3-4 times SBT. One improvement that I didn't get time to do is not to compress intermediate JARs (or maybe even not create JARs to begin with and just use the class files).

[chrisjrn]

@somdoron

One improvement that I didn't get time to do is not to compress intermediate JARs (or maybe even not create JARs to begin with and just use the class files).

Not compressing the intermediate JARs seems like something we should be able to do short term with minimal impact 🤔 .

Re. using plain class files: that should be possible, but the design of Classpath in Pants is simplified somewhat by having every ClasspathEntry generator producing JAR files. The initial implementations of deploy_jar in particular benefited from it. I'm not certain that's the case any more, but it would definitely take some design work.