GPT-4 coding assist - was: Re: [VOTE] Apache Daffodil VS Code Extension 1.3.0-rc2

[Mike Beckerle <mb...@apache.org>]

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?

Re: GPT-4 coding assist - was: Re: [VOTE] Apache Daffodil VS Code Extension 1.3.0-rc2

[Davin Shearer <sc...@gmail.com>]

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's GitHub site (see for example
https://github.com/apache/daffodil-vscode/blob/main/.github/workflows/CI.yml#L101)
that builds tests and packages the extension.  The previous release used
Java 11 only because there was a debugger server dependency that wasn't
available on Java 8, but we were able to work around that in version 1.3.0
and now we ship Java 8 bytecode.  Java 8 compatibility is done to maximize
the JREs that can run the software -- I think this is a reasonable
definition of all, but there will be some differences among them with
different settings and tunables.

What are the benefits of bundling a JRE:
- We get to select the precise make and version of the JRE rather than be
at the mercy of whatever is installed on the user's system
- We no longer need to make a JRE a prerequisite, so it eases the install
and maintenance burden on the user (or administrator)
- The build and test environment will now match the user's runtime
environment
- If we control the make and version of the JRE, reproducing and debugging
problems ought to be easier

Is this _required_ to solve Mike's problems?  Maybe (we don't test
in Mike's environment, which is why we need to control the JRE as much as
we can), but it's not sufficient.  I think the most pressing problem is to
make sure we isolate the JRE environment so it's not being influenced by
the parent VS Code environment.  If we do any bundling, I'm hoping we can
do so in a later release and that.we can get 1.3.0 released with some
lighter touches.

As for https://issues.apache.org/jira/browse/LEGAL-488, I'm also not clear
on the resolution, We would be distributing the binaries as provided by
adoptium.net without modification, so I think providing a copy of
the license and a link to the source ought to suffice, but I'm _not_ a
legal expert.

I hope this helps.


On Mon, Jun 5, 2023 at 2:08 PM Steve Lawrence <sl...@apache.org> wrote:

> 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 <sl...@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 <mb...@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?
> >>>>
> >>>
> >>
> >>
> >
>
>

Re: GPT-4 coding assist - was: Re: [VOTE] Apache Daffodil VS Code Extension 1.3.0-rc2

[Steve Lawrence <sl...@apache.org>]

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 <sl...@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 <mb...@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?
>>>>
>>>
>>
>>
> 

Re: GPT-4 coding assist - was: Re: [VOTE] Apache Daffodil VS Code Extension 1.3.0-rc2

[Davin Shearer <sc...@gmail.com>]

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 <sl...@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 <mb...@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?
> >>
> >
>
>

Re: GPT-4 coding assist - was: Re: [VOTE] Apache Daffodil VS Code Extension 1.3.0-rc2

[Steve Lawrence <sl...@apache.org>]

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 <mb...@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?
>>
> 

Re: GPT-4 coding assist - was: Re: [VOTE] Apache Daffodil VS Code Extension 1.3.0-rc2

[Davin Shearer <sc...@gmail.com>]

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 <mb...@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?
>