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? > >> > > > >
