Hi Steve, thanks for this question as it gets to the core of whether the
solution actually matches the problem.
One detail I want to get out of the way first: The debugger and Ωedit
Scala servers require only Java 8 for the VS Code extension, you can verify
this by reviewing the CI on the project
Temurin falls under the same license:
https://adoptium.net/docs/faq/#_is_temurin_free_to_use
What are the JVM environment issues that bundling solves? Mike said that
it requires Java 11, but it's not clear what Java 11 only features the
debugger uses. I image there is an alternative to these f
We wouldn't bundle OpenJDK, we would bundle Temurin (see
https://adoptium.net/). The debugger and the Ωedit Scala servers are both
compiled using Java 8. At issue is control over the JVM environment and
what our options are to control some of the issues that Mike faced in the
RC2 evaluation.
On
Can you detail what in the VS Code extension is specific to a particular
Java version, and why that can't be fixed? It feels like that would be
much less work than trying to bundle and distribute a JVM.
There may even be issues with ASF and distributing OpenJDK. It looks
like the license is GP
Hi Mike,
The answer is useful. It allows the VS Code user to select the version of
Java they wish to use and it will attempt to locate a compatible JVM
through various means. Sounds really useful for Java _development_ but not
so much for other extensions to leverage for their JVM dependencies u
So it seems it went round full circle by telling you yes, you could bundle
the JVM, and this redhat java language thing does so, but then they tell
you it doesn't bundle the JVM anyway, it just uses the system one.
So was this answer useful, or just misleading?
