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 GPLv2 which ASF considers category X. I found this
ticket where netbeans wanted to distributed it here:
https://issues.apache.org/jira/browse/LEGAL-488
It's not clear what the resolution of that bug is to me
- Steve
On 2023-06-05 12:21 PM, Davin Shearer wrote:
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 unless
they are to be used _in support of Java development_. It's also important
to note that this support is only for Java 17+ (
https://marketplace.visualstudio.com/items?itemName=redhat.java). I don't
think this is a good option for our use case.
GraalVM looks promising though I haven't used it before, so it's hard for
me to predict how successful that integration would be and how long it
would take to get up and running. The idea of having native machine code
applications has a lot of appeal. There is even support for C/C++ code
with the LLVM compiler. The Ωedit Scala server is linking to a C library
using it's foreign function interface (FFI), so I'm sure how that plays out
with GraalVM. GraalVM is GPL with a ClassPath exception. We won't be
distributing GraalVM, just the executables that come out (like gcc/g++), so
I don't foresee licensing problems. Does anyone have any experience with
GraalVM?
I think the most straight-forward path is to bundle Temurin (
https://adoptium.net/), probably using version 17 LTS. We'll be able to
sync the version we build on with the version we test on, distribute and
run on. The downside is increased package size and complexity, but
debugging issues ought to be easier since more variables are controlled
this way.
Either of these options will take a decent chunk of research, development,
and testing. The JVM bundling option is less opaque to me, though
the GraalVM option could _potentially_ provide a superior user experience.
On Mon, Jun 5, 2023 at 9:53 AM Mike Beckerle <mbecke...@apache.org> wrote:
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?