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 features that
works on all versions of Java (for a reasonable definition of all).
On 2023-06-05 01:47 PM, Davin Shearer wrote:
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 Mon, Jun 5, 2023 at 12:39 PM Steve Lawrence <slawre...@apache.org> wrote:
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?
