From amnojeeuw at gmail.com Thu Apr 1 18:23:10 2021 From: amnojeeuw at gmail.com (AmnoJeeuw) Date: Thu, 1 Apr 2021 14:23:10 -0400 Subject: Eclipse and JavaFX - Runnable Jar not running In-Reply-To: <90cc924d-b995-1a65-f4da-5c92b129cbff@oracle.com> References: <4d9c53ef-57d2-36be-1e69-2d21c19258d2@gmail.com> <90cc924d-b995-1a65-f4da-5c92b129cbff@oracle.com> Message-ID: Yes, I agree too. I posted this question in the wrong group. I apologize for the mistake. On 2021-03-30 11:49 a.m., Kevin Rushforth wrote: > I'll second Alan's point about redirecting this to a different mailing > list. > > The only thing I'll add is that the exception suggests that the native > JavaFX libraries cannot be found. > > -- Kevin > > > On 3/30/2021 8:44 AM, Alan Bateman wrote: >> On 30/03/2021 16:33, AmnoJeeuw wrote: >>> I am trying to deploy a runnable jar for my JavaFX project, but >>> after a long research I have not been able to do so. Can anybody >>> suggest a link that shows hot to do create a JavaFX 15.0.1 runnable >>> jar file under Eclipse. >>> This problem did not exist when using JavaFX 8.x, but now the >>> runnable just does not run, what am I doing wrong? >>> >>> I have seen some YouTube videos that show how to successfully do >>> this, but they are using IntelliJ, I would rather not switch to >>> IntelliJ 'cos I am fun of Eclipse. However, if switching to IntelliJ >>> is the only solution, I'd do so. >>> >>> Please see attached file for error report. >> >> If the stack trace is to believed then it looks like the JavaFX >> classes are being loaded from the class path. I think the more recent >> JavaFX release has code to detect that. In any case, it would be >> better to this to the JavaFX or Eclipse mailing lists as I don't >> think this is a JDK issue. >> >> -Alan. > -- Does anyone know why JavaFX-9+ jar files are not runnable nowadays? -- This email has been checked for viruses by AVG. https://www.avg.com From adinn at redhat.com Fri Apr 23 15:29:31 2021 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 23 Apr 2021 16:29:31 +0100 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: <20200611093646.300378510@eggemoggin.niobe.net> References: <20200611093646.300378510@eggemoggin.niobe.net> Message-ID: Hello All, There has been a rather long and quiet interlude since the result of the Leyden vote was reported (see below). Unfortunately, there has not yet been any follow-up announcement of a project repo, mail list(s) or working group. However, that's no indication that the project is not still of great interest to those of us who voted for it, nor that some of us have not been thinking about how we might proceed. I'd like to resume the initial discussion and, I hope, trigger some follow-up actions by offering a few recommendations for how we might wish to progress with Leyden. This is based on lessons learned from working with the GraalVM Native implementation over the last year or two. Please note that I'm not suggesting that GraalVM Native provides a blueprint for how Leyden should proceed. Indeed, I recognise that one of the key reasons for creating the Leyden project is to sharpen up the definition of static Java and, in doing so, critique some of the choices made in implementing GraalVM Native. The path I am proposing we follow here is to: - identify some of the key architectural and design decisions made in implementing GraalVM Native that appear to be relevant to a Hotspot implementation - gauge how far those decisions contribute to improvements in certain aspects of GraalVM Native performance vs degradation in other aspects - at the same time assess how systematically and coherently those same decisions deal, or fail to deal, with some of the problematic semantic issues involved in delivering static Java deployments - consider whether similar decisions might be worth taking in the context of an implementation based on the current Hotspot code base I have posted a document to github [1] that provides a summary of my own thoughts on the above themes. It starts with a critique of GraalVM which, for the benefit of OpenJDK project members who are not familiar with the implementation, also explains (as accurately as my understanding permits) relevant aspects of the design and implementation. It then goes on to discuss how this might be relevant to a Leyden implementation that reuses existing Hotspot components as far as possible. The document has been reviewed informally by a few OpenJDK project colleagues. I'd be very grateful if others who have expressed an interest in the project could take the time to read it and reflect on it, either providing feedback directly on the document or following up with their own opinions and suggestions for how to proceed. [1] https://github.com/adinn/leydendoc n.b. the repo has a Creative Commons 1.0 open source license. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill On 11/06/2020 17:36, mark.reinhold at oracle.com wrote: > Voting on the Leyden Project [1], with me as the initial Lead, > is now closed. > > Yes: 38 > Veto: 0 > Abstain: 0 > > (Two votes, by individuals not in the Members Group [2], did > not count.) > > According to the Bylaws definition of Lazy Consensus, this is > sufficient to approve the new Project and its initial Lead. > > - Mark > > > [1] https://mail.openjdk.java.net/pipermail/announce/2020-May/000289.html > [2] https://openjdk.java.net/census#members > From volker.simonis at gmail.com Sat Apr 24 08:44:00 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 24 Apr 2021 10:44:00 +0200 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: References: <20200611093646.300378510@eggemoggin.niobe.net> Message-ID: Hi Andrew, thank you so much for resurrecting the discussion on project Leyden! I read through your leydendoc [1] which I think is an excellent and technically deep-dive summary of the current workings of the GraalVM Native Image Generator. The analysis and ideas how this functionality could be implemented in the context of OpenJDK and HotSpot is technically sound and very interesting. I'm really a little reluctant to add some non-technical doubts and acting as a killjoy here, but I think there's one real caveat with your approach and that's (unfortunately) licensing. As you know, the whole HotSpot code base (with the exception of very few header files [2]) is licensed under GPLv2 WITHOUT Class Path Exception (CPE). HotSpot code can only be accessed without getting tainted by the GPL through a restricted set of exported, GPLv2+CPE licensed interfaces [2]. This is already a "weak" construct which has never been disputed but I don't want to discuss that here. I'm however afraid that your approach of linking large parts of the HotSpot code together with application classes into a single static image will undoubtedly "infect" all the user code with the GPL license. I think that's unacceptable for the majority of Java applications which are not already GPLv2 licensed. Unfortunately, in my opinion this seems to be a much bigger problem compared to the technical difficulties to implement your approach. Maybe we should have a look at alternative, existing JVM implementations (like OpenJ9, which I'm not all all familiar with) which are more liberally licensed? Having another write-up, similar to yours, which explores the same possibilities with OpenJ9 would be definitely a nice read :) As a side note, it seems like all the Java classes and even the native code parts of the class library are all licensed under GPLv2+CPE. So linking them into a native image together with user/application code seems to be less of a problem. Thanks again for your great analysis, Volker [1] https://github.com/adinn/leydendoc [2] jvm_md.h, jmm.h, jvm_constants.h, jvm.h, jvm_io.h, jvmtiLib.xsl On Fri, Apr 23, 2021 at 5:30 PM Andrew Dinn wrote: > > Hello All, > > There has been a rather long and quiet interlude since the result of the > Leyden vote was reported (see below). Unfortunately, there has not yet > been any follow-up announcement of a project repo, mail list(s) or > working group. However, that's no indication that the project is not > still of great interest to those of us who voted for it, nor that some > of us have not been thinking about how we might proceed. > > I'd like to resume the initial discussion and, I hope, trigger some > follow-up actions by offering a few recommendations for how we might > wish to progress with Leyden. This is based on lessons learned from > working with the GraalVM Native implementation over the last year or two. > > Please note that I'm not suggesting that GraalVM Native provides a > blueprint for how Leyden should proceed. Indeed, I recognise that one of > the key reasons for creating the Leyden project is to sharpen up the > definition of static Java and, in doing so, critique some of the choices > made in implementing GraalVM Native. > > The path I am proposing we follow here is to: > > - identify some of the key architectural and design decisions made in > implementing GraalVM Native that appear to be relevant to a Hotspot > implementation > > - gauge how far those decisions contribute to improvements in certain > aspects of GraalVM Native performance vs degradation in other aspects > > - at the same time assess how systematically and coherently those same > decisions deal, or fail to deal, with some of the problematic semantic > issues involved in delivering static Java deployments > > - consider whether similar decisions might be worth taking in the > context of an implementation based on the current Hotspot code base > > I have posted a document to github [1] that provides a summary of my own > thoughts on the above themes. It starts with a critique of GraalVM > which, for the benefit of OpenJDK project members who are not familiar > with the implementation, also explains (as accurately as my > understanding permits) relevant aspects of the design and > implementation. It then goes on to discuss how this might be relevant to > a Leyden implementation that reuses existing Hotspot components as far > as possible. > > The document has been reviewed informally by a few OpenJDK project > colleagues. I'd be very grateful if others who have expressed an > interest in the project could take the time to read it and reflect on > it, either providing feedback directly on the document or following up > with their own opinions and suggestions for how to proceed. > > [1] https://github.com/adinn/leydendoc > n.b. the repo has a Creative Commons 1.0 open source license. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > > > > On 11/06/2020 17:36, mark.reinhold at oracle.com wrote: > > Voting on the Leyden Project [1], with me as the initial Lead, > > is now closed. > > > > Yes: 38 > > Veto: 0 > > Abstain: 0 > > > > (Two votes, by individuals not in the Members Group [2], did > > not count.) > > > > According to the Bylaws definition of Lazy Consensus, this is > > sufficient to approve the new Project and its initial Lead. > > > > - Mark > > > > > > [1] https://mail.openjdk.java.net/pipermail/announce/2020-May/000289.html > > [2] https://openjdk.java.net/census#members > > > From aph at redhat.com Sat Apr 24 09:35:58 2021 From: aph at redhat.com (Andrew Haley) Date: Sat, 24 Apr 2021 10:35:58 +0100 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: References: <20200611093646.300378510@eggemoggin.niobe.net> Message-ID: <502196e5-d417-5595-2b63-bcac862e78ba@redhat.com> On 4/24/21 9:44 AM, Volker Simonis wrote: > Maybe we should have a look at alternative, existing JVM > implementations (like OpenJ9, which I'm not all all familiar with) > which are more liberally licensed? One of the main purposes of Leyden is to develop a statically-compiled specification for Java; and OpenJDK is the reference implementation of Java. By all means look at something else as an alternative, but it won't solve that problem, and may only be a distraction. I do not intend to discuss legal issues here. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From neugens.limasoftware at gmail.com Sat Apr 24 10:07:31 2021 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 24 Apr 2021 12:07:31 +0200 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: References: <20200611093646.300378510@eggemoggin.niobe.net> Message-ID: <81bf4b15-85fe-4487-a61f-350e73c074b9@Canary> Hi Volker, This is certainly a conversation we need to have, however one of most important reasons for project Leyden is to understand and define a specification that works properly under the closed world-aot assumption. I think there is tremendous value in doing so within the OpenJDK umbrella with hotspot as reference implementation, depending on external or downstream projects would limit the scope considerably and may not work at all. Cheers, Mario ? Mario Torre Java Champion and OpenJDK contributor PGP Key: 0BAB254E Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E Twitter: @neugens Web: https://www.mario-torre.eu/ Music: https://mario-torre.bandcamp.com/ > On Saturday, Apr 24, 2021 at 11:29, Volker Simonis wrote: > Hi Andrew, > > thank you so much for resurrecting the discussion on project Leyden! I > read through your leydendoc [1] which I think is an excellent and > technically deep-dive summary of the current workings of the GraalVM > Native Image Generator. The analysis and ideas how this functionality > could be implemented in the context of OpenJDK and HotSpot is > technically sound and very interesting. > > I'm really a little reluctant to add some non-technical doubts and > acting as a killjoy here, but I think there's one real caveat with > your approach and that's (unfortunately) licensing. As you know, the > whole HotSpot code base (with the exception of very few header files > [2]) is licensed under GPLv2 WITHOUT Class Path Exception (CPE). > HotSpot code can only be accessed without getting tainted by the GPL > through a restricted set of exported, GPLv2+CPE licensed interfaces > [2]. This is already a "weak" construct which has never been disputed > but I don't want to discuss that here. > > I'm however afraid that your approach of linking large parts of the > HotSpot code together with application classes into a single static > image will undoubtedly "infect" all the user code with the GPL > license. I think that's unacceptable for the majority of Java > applications which are not already GPLv2 licensed. Unfortunately, in > my opinion this seems to be a much bigger problem compared to the > technical difficulties to implement your approach. Maybe we should > have a look at alternative, existing JVM implementations (like OpenJ9, > which I'm not all all familiar with) which are more liberally > licensed? Having another write-up, similar to yours, which explores > the same possibilities with OpenJ9 would be definitely a nice read :) > > As a side note, it seems like all the Java classes and even the native > code parts of the class library are all licensed under GPLv2+CPE. So > linking them into a native image together with user/application code > seems to be less of a problem. > > Thanks again for your great analysis, > Volker > > [1] https://github.com/adinn/leydendoc > [2] jvm_md.h, jmm.h, jvm_constants.h, jvm.h, jvm_io.h, jvmtiLib.xsl > > On Fri, Apr 23, 2021 at 5:30 PM Andrew Dinn wrote: > > > > Hello All, > > > > There has been a rather long and quiet interlude since the result of the > > Leyden vote was reported (see below). Unfortunately, there has not yet > > been any follow-up announcement of a project repo, mail list(s) or > > working group. However, that's no indication that the project is not > > still of great interest to those of us who voted for it, nor that some > > of us have not been thinking about how we might proceed. > > > > I'd like to resume the initial discussion and, I hope, trigger some > > follow-up actions by offering a few recommendations for how we might > > wish to progress with Leyden. This is based on lessons learned from > > working with the GraalVM Native implementation over the last year or two. > > > > Please note that I'm not suggesting that GraalVM Native provides a > > blueprint for how Leyden should proceed. Indeed, I recognise that one of > > the key reasons for creating the Leyden project is to sharpen up the > > definition of static Java and, in doing so, critique some of the choices > > made in implementing GraalVM Native. > > > > The path I am proposing we follow here is to: > > > > - identify some of the key architectural and design decisions made in > > implementing GraalVM Native that appear to be relevant to a Hotspot > > implementation > > > > - gauge how far those decisions contribute to improvements in certain > > aspects of GraalVM Native performance vs degradation in other aspects > > > > - at the same time assess how systematically and coherently those same > > decisions deal, or fail to deal, with some of the problematic semantic > > issues involved in delivering static Java deployments > > > > - consider whether similar decisions might be worth taking in the > > context of an implementation based on the current Hotspot code base > > > > I have posted a document to github [1] that provides a summary of my own > > thoughts on the above themes. It starts with a critique of GraalVM > > which, for the benefit of OpenJDK project members who are not familiar > > with the implementation, also explains (as accurately as my > > understanding permits) relevant aspects of the design and > > implementation. It then goes on to discuss how this might be relevant to > > a Leyden implementation that reuses existing Hotspot components as far > > as possible. > > > > The document has been reviewed informally by a few OpenJDK project > > colleagues. I'd be very grateful if others who have expressed an > > interest in the project could take the time to read it and reflect on > > it, either providing feedback directly on the document or following up > > with their own opinions and suggestions for how to proceed. > > > > [1] https://github.com/adinn/leydendoc > > n.b. the repo has a Creative Commons 1.0 open source license. > > > > regards, > > > > > > Andrew Dinn > > ----------- > > Red Hat Distinguished Engineer > > Red Hat UK Ltd > > Registered in England and Wales under Company Registration No. 03798903 > > Directors: Michael Cunningham, Michael ("Mike") O'Neill > > > > > > > > On 11/06/2020 17:36, mark.reinhold at oracle.com wrote: > > > Voting on the Leyden Project [1], with me as the initial Lead, > > > is now closed. > > > > > > Yes: 38 > > > Veto: 0 > > > Abstain: 0 > > > > > > (Two votes, by individuals not in the Members Group [2], did > > > not count.) > > > > > > According to the Bylaws definition of Lazy Consensus, this is > > > sufficient to approve the new Project and its initial Lead. > > > > > > - Mark > > > > > > > > > [1] https://mail.openjdk.java.net/pipermail/announce/2020-May/000289.html > > > [2] https://openjdk.java.net/census#members > > > > > From volker.simonis at gmail.com Sat Apr 24 14:51:28 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 24 Apr 2021 16:51:28 +0200 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: <502196e5-d417-5595-2b63-bcac862e78ba@redhat.com> References: <20200611093646.300378510@eggemoggin.niobe.net> <502196e5-d417-5595-2b63-bcac862e78ba@redhat.com> Message-ID: Andrew Haley schrieb am Sa., 24. Apr. 2021, 11:36: > On 4/24/21 9:44 AM, Volker Simonis wrote: > > > Maybe we should have a look at alternative, existing JVM > > implementations (like OpenJ9, which I'm not all all familiar with) > > which are more liberally licensed? > > One of the main purposes of Leyden is to develop a statically-compiled > specification for Java; and OpenJDK is the reference implementation of > Java. By all means look at something else as an alternative, but it > won't solve that problem, and may only be a distraction. I do not > intend to discuss legal issues here. > Believe me, me neither. But it simply doesn't make sense to implement a reference implementation which will only be usable by/with GPLv2 licensed programs. > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From volker.simonis at gmail.com Sat Apr 24 15:03:59 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 24 Apr 2021 17:03:59 +0200 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: <81bf4b15-85fe-4487-a61f-350e73c074b9@Canary> References: <20200611093646.300378510@eggemoggin.niobe.net> <81bf4b15-85fe-4487-a61f-350e73c074b9@Canary> Message-ID: Mario Torre schrieb am Sa., 24. Apr. 2021, 12:07: > Hi Volker, > > This is certainly a conversation we need to have, however one of most > important reasons for project Leyden is to understand and define a > specification that works properly under the closed world-aot assumption. > > I think there is tremendous value in doing so within the OpenJDK umbrella > with hotspot as reference implementation, depending on external or > downstream projects would limit the scope considerably and may not work at > all. > Sure, I totally agree with everything you say. But implementing a reference implementation which will only usable by/with GPLv2 licensed applications will limit the scope even more. > Cheers, > Mario > > ? > Mario Torre > Java Champion and OpenJDK contributor > > PGP Key: 0BAB254E > Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E > > Twitter: @neugens > Web: https://www.mario-torre.eu/ > Music: https://mario-torre.bandcamp.com/ > > > On Saturday, Apr 24, 2021 at 11:29, Volker Simonis < > volker.simonis at gmail.com> wrote: > Hi Andrew, > > thank you so much for resurrecting the discussion on project Leyden! I > read through your leydendoc [1] which I think is an excellent and > technically deep-dive summary of the current workings of the GraalVM > Native Image Generator. The analysis and ideas how this functionality > could be implemented in the context of OpenJDK and HotSpot is > technically sound and very interesting. > > I'm really a little reluctant to add some non-technical doubts and > acting as a killjoy here, but I think there's one real caveat with > your approach and that's (unfortunately) licensing. As you know, the > whole HotSpot code base (with the exception of very few header files > [2]) is licensed under GPLv2 WITHOUT Class Path Exception (CPE). > HotSpot code can only be accessed without getting tainted by the GPL > through a restricted set of exported, GPLv2+CPE licensed interfaces > [2]. This is already a "weak" construct which has never been disputed > but I don't want to discuss that here. > > I'm however afraid that your approach of linking large parts of the > HotSpot code together with application classes into a single static > image will undoubtedly "infect" all the user code with the GPL > license. I think that's unacceptable for the majority of Java > applications which are not already GPLv2 licensed. Unfortunately, in > my opinion this seems to be a much bigger problem compared to the > technical difficulties to implement your approach. Maybe we should > have a look at alternative, existing JVM implementations (like OpenJ9, > which I'm not all all familiar with) which are more liberally > licensed? Having another write-up, similar to yours, which explores > the same possibilities with OpenJ9 would be definitely a nice read :) > > As a side note, it seems like all the Java classes and even the native > code parts of the class library are all licensed under GPLv2+CPE. So > linking them into a native image together with user/application code > seems to be less of a problem. > > Thanks again for your great analysis, > Volker > > [1] https://github.com/adinn/leydendoc > [2] jvm_md.h, jmm.h, jvm_constants.h, jvm.h, jvm_io.h, jvmtiLib.xsl > > On Fri, Apr 23, 2021 at 5:30 PM Andrew Dinn wrote: > > > Hello All, > > There has been a rather long and quiet interlude since the result of the > Leyden vote was reported (see below). Unfortunately, there has not yet > been any follow-up announcement of a project repo, mail list(s) or > working group. However, that's no indication that the project is not > still of great interest to those of us who voted for it, nor that some > of us have not been thinking about how we might proceed. > > I'd like to resume the initial discussion and, I hope, trigger some > follow-up actions by offering a few recommendations for how we might > wish to progress with Leyden. This is based on lessons learned from > working with the GraalVM Native implementation over the last year or two. > > Please note that I'm not suggesting that GraalVM Native provides a > blueprint for how Leyden should proceed. Indeed, I recognise that one of > the key reasons for creating the Leyden project is to sharpen up the > definition of static Java and, in doing so, critique some of the choices > made in implementing GraalVM Native. > > The path I am proposing we follow here is to: > > - identify some of the key architectural and design decisions made in > implementing GraalVM Native that appear to be relevant to a Hotspot > implementation > > - gauge how far those decisions contribute to improvements in certain > aspects of GraalVM Native performance vs degradation in other aspects > > - at the same time assess how systematically and coherently those same > decisions deal, or fail to deal, with some of the problematic semantic > issues involved in delivering static Java deployments > > - consider whether similar decisions might be worth taking in the > context of an implementation based on the current Hotspot code base > > I have posted a document to github [1] that provides a summary of my own > thoughts on the above themes. It starts with a critique of GraalVM > which, for the benefit of OpenJDK project members who are not familiar > with the implementation, also explains (as accurately as my > understanding permits) relevant aspects of the design and > implementation. It then goes on to discuss how this might be relevant to > a Leyden implementation that reuses existing Hotspot components as far > as possible. > > The document has been reviewed informally by a few OpenJDK project > colleagues. I'd be very grateful if others who have expressed an > interest in the project could take the time to read it and reflect on > it, either providing feedback directly on the document or following up > with their own opinions and suggestions for how to proceed. > > [1] https://github.com/adinn/leydendoc > n.b. the repo has a Creative Commons 1.0 open source license. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > > > > On 11/06/2020 17:36, mark.reinhold at oracle.com wrote: > > Voting on the Leyden Project [1], with me as the initial Lead, > is now closed. > > Yes: 38 > Veto: 0 > Abstain: 0 > > (Two votes, by individuals not in the Members Group [2], did > not count.) > > According to the Bylaws definition of Lazy Consensus, this is > sufficient to approve the new Project and its initial Lead. > > - Mark > > > [1] https://mail.openjdk.java.net/pipermail/announce/2020-May/000289.html > [2] https://openjdk.java.net/census#members > > > From rkennke at redhat.com Sat Apr 24 15:16:09 2021 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 24 Apr 2021 17:16:09 +0200 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: References: <20200611093646.300378510@eggemoggin.niobe.net> <502196e5-d417-5595-2b63-bcac862e78ba@redhat.com> Message-ID: Volker Simonis schrieb am Sa., 24. Apr. 2021, 16:54: > Andrew Haley schrieb am Sa., 24. Apr. 2021, 11:36: > > > On 4/24/21 9:44 AM, Volker Simonis wrote: > > > > > Maybe we should have a look at alternative, existing JVM > > > implementations (like OpenJ9, which I'm not all all familiar with) > > > which are more liberally licensed? > > > > One of the main purposes of Leyden is to develop a statically-compiled > > specification for Java; and OpenJDK is the reference implementation of > > Java. By all means look at something else as an alternative, but it > > won't solve that problem, and may only be a distraction. I do not > > intend to discuss legal issues here. > > > > Believe me, me neither. But it simply doesn't make sense to implement a > reference implementation which will only be usable by/with GPLv2 licensed > programs. > I am not so pessimistic. IANAL, but als long as the resulting binary is not distributed, e.g. it is run on your own premises, it should be ok, right? And that still covers an aweful lot of usecases IMO. Roman > > > -- > > Andrew Haley (he/him) > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > https://keybase.io/andrewhaley > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > > > > From christoph.langer at sap.com Mon Apr 26 08:20:44 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 26 Apr 2021 08:20:44 +0000 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: References: <20200611093646.300378510@eggemoggin.niobe.net> Message-ID: Hi, @Andrew Dinn, thanks for creating this paper. It was an interesting read as well for me and I think it points out some interesting perspectives for evolving a definition of static Java and a reference implementation in the OpenJDK. I would also like to see folks from SAP's JDK team engage in this project, should it take off some day. However, understanding whether licensing is an issue with this approach and finding a solution for that will probably be an important point for us on that path. Best regards Christoph > -----Original Message----- > From: discuss On Behalf Of Volker Simonis > Sent: Samstag, 24. April 2021 10:44 > To: Andrew Dinn > Cc: discuss at openjdk.java.net > Subject: Re: Resumption of Leyden Discusssion (was Re: Result: New Project: > Leyden) > > Hi Andrew, > > thank you so much for resurrecting the discussion on project Leyden! I > read through your leydendoc [1] which I think is an excellent and > technically deep-dive summary of the current workings of the GraalVM > Native Image Generator. The analysis and ideas how this functionality > could be implemented in the context of OpenJDK and HotSpot is > technically sound and very interesting. > > I'm really a little reluctant to add some non-technical doubts and > acting as a killjoy here, but I think there's one real caveat with > your approach and that's (unfortunately) licensing. As you know, the > whole HotSpot code base (with the exception of very few header files > [2]) is licensed under GPLv2 WITHOUT Class Path Exception (CPE). > HotSpot code can only be accessed without getting tainted by the GPL > through a restricted set of exported, GPLv2+CPE licensed interfaces > [2]. This is already a "weak" construct which has never been disputed > but I don't want to discuss that here. > > I'm however afraid that your approach of linking large parts of the > HotSpot code together with application classes into a single static > image will undoubtedly "infect" all the user code with the GPL > license. I think that's unacceptable for the majority of Java > applications which are not already GPLv2 licensed. Unfortunately, in > my opinion this seems to be a much bigger problem compared to the > technical difficulties to implement your approach. Maybe we should > have a look at alternative, existing JVM implementations (like OpenJ9, > which I'm not all all familiar with) which are more liberally > licensed? Having another write-up, similar to yours, which explores > the same possibilities with OpenJ9 would be definitely a nice read :) > > As a side note, it seems like all the Java classes and even the native > code parts of the class library are all licensed under GPLv2+CPE. So > linking them into a native image together with user/application code > seems to be less of a problem. > > Thanks again for your great analysis, > Volker > > [1] https://github.com/adinn/leydendoc > [2] jvm_md.h, jmm.h, jvm_constants.h, jvm.h, jvm_io.h, jvmtiLib.xsl > > On Fri, Apr 23, 2021 at 5:30 PM Andrew Dinn wrote: > > > > Hello All, > > > > There has been a rather long and quiet interlude since the result of the > > Leyden vote was reported (see below). Unfortunately, there has not yet > > been any follow-up announcement of a project repo, mail list(s) or > > working group. However, that's no indication that the project is not > > still of great interest to those of us who voted for it, nor that some > > of us have not been thinking about how we might proceed. > > > > I'd like to resume the initial discussion and, I hope, trigger some > > follow-up actions by offering a few recommendations for how we might > > wish to progress with Leyden. This is based on lessons learned from > > working with the GraalVM Native implementation over the last year or > two. > > > > Please note that I'm not suggesting that GraalVM Native provides a > > blueprint for how Leyden should proceed. Indeed, I recognise that one of > > the key reasons for creating the Leyden project is to sharpen up the > > definition of static Java and, in doing so, critique some of the choices > > made in implementing GraalVM Native. > > > > The path I am proposing we follow here is to: > > > > - identify some of the key architectural and design decisions made in > > implementing GraalVM Native that appear to be relevant to a Hotspot > > implementation > > > > - gauge how far those decisions contribute to improvements in certain > > aspects of GraalVM Native performance vs degradation in other aspects > > > > - at the same time assess how systematically and coherently those same > > decisions deal, or fail to deal, with some of the problematic semantic > > issues involved in delivering static Java deployments > > > > - consider whether similar decisions might be worth taking in the > > context of an implementation based on the current Hotspot code base > > > > I have posted a document to github [1] that provides a summary of my own > > thoughts on the above themes. It starts with a critique of GraalVM > > which, for the benefit of OpenJDK project members who are not familiar > > with the implementation, also explains (as accurately as my > > understanding permits) relevant aspects of the design and > > implementation. It then goes on to discuss how this might be relevant to > > a Leyden implementation that reuses existing Hotspot components as far > > as possible. > > > > The document has been reviewed informally by a few OpenJDK project > > colleagues. I'd be very grateful if others who have expressed an > > interest in the project could take the time to read it and reflect on > > it, either providing feedback directly on the document or following up > > with their own opinions and suggestions for how to proceed. > > > > [1] https://github.com/adinn/leydendoc > > n.b. the repo has a Creative Commons 1.0 open source license. > > > > regards, > > > > > > Andrew Dinn > > ----------- > > Red Hat Distinguished Engineer > > Red Hat UK Ltd > > Registered in England and Wales under Company Registration No. 03798903 > > Directors: Michael Cunningham, Michael ("Mike") O'Neill > > > > > > > > On 11/06/2020 17:36, mark.reinhold at oracle.com wrote: > > > Voting on the Leyden Project [1], with me as the initial Lead, > > > is now closed. > > > > > > Yes: 38 > > > Veto: 0 > > > Abstain: 0 > > > > > > (Two votes, by individuals not in the Members Group [2], did > > > not count.) > > > > > > According to the Bylaws definition of Lazy Consensus, this is > > > sufficient to approve the new Project and its initial Lead. > > > > > > - Mark > > > > > > > > > [1] https://mail.openjdk.java.net/pipermail/announce/2020- > May/000289.html > > > [2] https://openjdk.java.net/census#members > > > > > From andvasp at gmail.com Mon Apr 26 12:18:40 2021 From: andvasp at gmail.com (Anderson Vasconcelos Pires) Date: Mon, 26 Apr 2021 09:18:40 -0300 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: References: <20200611093646.300378510@eggemoggin.niobe.net> Message-ID: Hi Volker, Looks like the graal uses the similar license of openjdk. I understand they would have the same limitation to generate native images, right? If I am not wrong, why do they decide to have native image? We couldn't use at least the same approach? Best regards, Anderson. On Sat, Apr 24, 2021 at 5:44 AM Volker Simonis wrote: > Hi Andrew, > > thank you so much for resurrecting the discussion on project Leyden! I > read through your leydendoc [1] which I think is an excellent and > technically deep-dive summary of the current workings of the GraalVM > Native Image Generator. The analysis and ideas how this functionality > could be implemented in the context of OpenJDK and HotSpot is > technically sound and very interesting. > > I'm really a little reluctant to add some non-technical doubts and > acting as a killjoy here, but I think there's one real caveat with > your approach and that's (unfortunately) licensing. As you know, the > whole HotSpot code base (with the exception of very few header files > [2]) is licensed under GPLv2 WITHOUT Class Path Exception (CPE). > HotSpot code can only be accessed without getting tainted by the GPL > through a restricted set of exported, GPLv2+CPE licensed interfaces > [2]. This is already a "weak" construct which has never been disputed > but I don't want to discuss that here. > > I'm however afraid that your approach of linking large parts of the > HotSpot code together with application classes into a single static > image will undoubtedly "infect" all the user code with the GPL > license. I think that's unacceptable for the majority of Java > applications which are not already GPLv2 licensed. Unfortunately, in > my opinion this seems to be a much bigger problem compared to the > technical difficulties to implement your approach. Maybe we should > have a look at alternative, existing JVM implementations (like OpenJ9, > which I'm not all all familiar with) which are more liberally > licensed? Having another write-up, similar to yours, which explores > the same possibilities with OpenJ9 would be definitely a nice read :) > > As a side note, it seems like all the Java classes and even the native > code parts of the class library are all licensed under GPLv2+CPE. So > linking them into a native image together with user/application code > seems to be less of a problem. > > Thanks again for your great analysis, > Volker > > [1] https://github.com/adinn/leydendoc > [2] jvm_md.h, jmm.h, jvm_constants.h, jvm.h, jvm_io.h, jvmtiLib.xsl > > On Fri, Apr 23, 2021 at 5:30 PM Andrew Dinn wrote: > > > > Hello All, > > > > There has been a rather long and quiet interlude since the result of the > > Leyden vote was reported (see below). Unfortunately, there has not yet > > been any follow-up announcement of a project repo, mail list(s) or > > working group. However, that's no indication that the project is not > > still of great interest to those of us who voted for it, nor that some > > of us have not been thinking about how we might proceed. > > > > I'd like to resume the initial discussion and, I hope, trigger some > > follow-up actions by offering a few recommendations for how we might > > wish to progress with Leyden. This is based on lessons learned from > > working with the GraalVM Native implementation over the last year or two. > > > > Please note that I'm not suggesting that GraalVM Native provides a > > blueprint for how Leyden should proceed. Indeed, I recognise that one of > > the key reasons for creating the Leyden project is to sharpen up the > > definition of static Java and, in doing so, critique some of the choices > > made in implementing GraalVM Native. > > > > The path I am proposing we follow here is to: > > > > - identify some of the key architectural and design decisions made in > > implementing GraalVM Native that appear to be relevant to a Hotspot > > implementation > > > > - gauge how far those decisions contribute to improvements in certain > > aspects of GraalVM Native performance vs degradation in other aspects > > > > - at the same time assess how systematically and coherently those same > > decisions deal, or fail to deal, with some of the problematic semantic > > issues involved in delivering static Java deployments > > > > - consider whether similar decisions might be worth taking in the > > context of an implementation based on the current Hotspot code base > > > > I have posted a document to github [1] that provides a summary of my own > > thoughts on the above themes. It starts with a critique of GraalVM > > which, for the benefit of OpenJDK project members who are not familiar > > with the implementation, also explains (as accurately as my > > understanding permits) relevant aspects of the design and > > implementation. It then goes on to discuss how this might be relevant to > > a Leyden implementation that reuses existing Hotspot components as far > > as possible. > > > > The document has been reviewed informally by a few OpenJDK project > > colleagues. I'd be very grateful if others who have expressed an > > interest in the project could take the time to read it and reflect on > > it, either providing feedback directly on the document or following up > > with their own opinions and suggestions for how to proceed. > > > > [1] https://github.com/adinn/leydendoc > > n.b. the repo has a Creative Commons 1.0 open source license. > > > > regards, > > > > > > Andrew Dinn > > ----------- > > Red Hat Distinguished Engineer > > Red Hat UK Ltd > > Registered in England and Wales under Company Registration No. 03798903 > > Directors: Michael Cunningham, Michael ("Mike") O'Neill > > > > > > > > On 11/06/2020 17:36, mark.reinhold at oracle.com wrote: > > > Voting on the Leyden Project [1], with me as the initial Lead, > > > is now closed. > > > > > > Yes: 38 > > > Veto: 0 > > > Abstain: 0 > > > > > > (Two votes, by individuals not in the Members Group [2], did > > > not count.) > > > > > > According to the Bylaws definition of Lazy Consensus, this is > > > sufficient to approve the new Project and its initial Lead. > > > > > > - Mark > > > > > > > > > [1] > https://mail.openjdk.java.net/pipermail/announce/2020-May/000289.html > > > [2] https://openjdk.java.net/census#members > > > > > > From fweimer at redhat.com Mon Apr 26 16:14:15 2021 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 26 Apr 2021 18:14:15 +0200 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: (Roman Kennke's message of "Sat, 24 Apr 2021 17:16:09 +0200") References: <20200611093646.300378510@eggemoggin.niobe.net> <502196e5-d417-5595-2b63-bcac862e78ba@redhat.com> Message-ID: <87y2d5xbu0.fsf@oldenburg.str.redhat.com> * Roman Kennke: > I am not so pessimistic. IANAL, but als long as the resulting binary is not > distributed, e.g. it is run on your own premises, it should be ok, right? The GPL version 2 is ambiguous whether copying a program to somone else's computer is distribution. This was clarified in GPL version 3. Opinions of actual copyright holders vary, I think. jpackage may have similar issues, given that the potential GPL issue is due to distribution and not due to the binding technology employed. As a last result, Oracle can offer alternative licensing terms. To me, that possibility suggests that if there are potential copyright-related issues with the way the reference implementation is used in combination with a new feature, this is not an absolute blocker for implementing the new feature. There is a way out. Thanks, Florian From neugens at redhat.com Mon Apr 26 16:55:09 2021 From: neugens at redhat.com (Mario Torre) Date: Mon, 26 Apr 2021 18:55:09 +0200 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: References: <20200611093646.300378510@eggemoggin.niobe.net> Message-ID: All, Can we please go back to the merit of this discussion? Licensing terms are a fun and an interesting topic, but not really one that should distract us from the feedback that Andrew requested. Cheers, Mario On Fri, Apr 23, 2021 at 5:30 PM Andrew Dinn wrote: > > Hello All, > > There has been a rather long and quiet interlude since the result of the > Leyden vote was reported (see below). Unfortunately, there has not yet > been any follow-up announcement of a project repo, mail list(s) or > working group. However, that's no indication that the project is not > still of great interest to those of us who voted for it, nor that some > of us have not been thinking about how we might proceed. > > I'd like to resume the initial discussion and, I hope, trigger some > follow-up actions by offering a few recommendations for how we might > wish to progress with Leyden. This is based on lessons learned from > working with the GraalVM Native implementation over the last year or two. > > Please note that I'm not suggesting that GraalVM Native provides a > blueprint for how Leyden should proceed. Indeed, I recognise that one of > the key reasons for creating the Leyden project is to sharpen up the > definition of static Java and, in doing so, critique some of the choices > made in implementing GraalVM Native. > > The path I am proposing we follow here is to: > > - identify some of the key architectural and design decisions made in > implementing GraalVM Native that appear to be relevant to a Hotspot > implementation > > - gauge how far those decisions contribute to improvements in certain > aspects of GraalVM Native performance vs degradation in other aspects > > - at the same time assess how systematically and coherently those same > decisions deal, or fail to deal, with some of the problematic semantic > issues involved in delivering static Java deployments > > - consider whether similar decisions might be worth taking in the > context of an implementation based on the current Hotspot code base > > I have posted a document to github [1] that provides a summary of my own > thoughts on the above themes. It starts with a critique of GraalVM > which, for the benefit of OpenJDK project members who are not familiar > with the implementation, also explains (as accurately as my > understanding permits) relevant aspects of the design and > implementation. It then goes on to discuss how this might be relevant to > a Leyden implementation that reuses existing Hotspot components as far > as possible. > > The document has been reviewed informally by a few OpenJDK project > colleagues. I'd be very grateful if others who have expressed an > interest in the project could take the time to read it and reflect on > it, either providing feedback directly on the document or following up > with their own opinions and suggestions for how to proceed. > > [1] https://github.com/adinn/leydendoc > n.b. the repo has a Creative Commons 1.0 open source license. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > > > > On 11/06/2020 17:36, mark.reinhold at oracle.com wrote: > > Voting on the Leyden Project [1], with me as the initial Lead, > > is now closed. > > > > Yes: 38 > > Veto: 0 > > Abstain: 0 > > > > (Two votes, by individuals not in the Members Group [2], did > > not count.) > > > > According to the Bylaws definition of Lazy Consensus, this is > > sufficient to approve the new Project and its initial Lead. > > > > - Mark > > > > > > [1] https://mail.openjdk.java.net/pipermail/announce/2020-May/000289.html > > [2] https://openjdk.java.net/census#members > > > -- Mario Torre Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From volker.simonis at gmail.com Mon Apr 26 18:29:37 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 26 Apr 2021 20:29:37 +0200 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: References: <20200611093646.300378510@eggemoggin.niobe.net> Message-ID: Anderson Vasconcelos Pires schrieb am Mo., 26. Apr. 2021, 14:20: > Hi Volker, > > Looks like the graal uses the similar license of openjdk. > I understand they would have the same limitation to generate native > images, right? > If I am not wrong, why do they decide to have native image? We couldn't > use at least the same approach? > That's not right. The complete SubstrateVM [1] (which is GraalVM's equivalent of HotSpot in OpenJDK) is fully GPLv2+CPE licensed. That's actually exactly the difference to HotSpot which is mostly GPLv2 only (without CPE) and the thing I wanted to point out if we decide to implement Leyden in top of the current HotSpot. [1] https://github.com/oracle/graal/tree/master/substratevm > Best regards, > Anderson. > > On Sat, Apr 24, 2021 at 5:44 AM Volker Simonis > wrote: > >> Hi Andrew, >> >> thank you so much for resurrecting the discussion on project Leyden! I >> read through your leydendoc [1] which I think is an excellent and >> technically deep-dive summary of the current workings of the GraalVM >> Native Image Generator. The analysis and ideas how this functionality >> could be implemented in the context of OpenJDK and HotSpot is >> technically sound and very interesting. >> >> I'm really a little reluctant to add some non-technical doubts and >> acting as a killjoy here, but I think there's one real caveat with >> your approach and that's (unfortunately) licensing. As you know, the >> whole HotSpot code base (with the exception of very few header files >> [2]) is licensed under GPLv2 WITHOUT Class Path Exception (CPE). >> HotSpot code can only be accessed without getting tainted by the GPL >> through a restricted set of exported, GPLv2+CPE licensed interfaces >> [2]. This is already a "weak" construct which has never been disputed >> but I don't want to discuss that here. >> >> I'm however afraid that your approach of linking large parts of the >> HotSpot code together with application classes into a single static >> image will undoubtedly "infect" all the user code with the GPL >> license. I think that's unacceptable for the majority of Java >> applications which are not already GPLv2 licensed. Unfortunately, in >> my opinion this seems to be a much bigger problem compared to the >> technical difficulties to implement your approach. Maybe we should >> have a look at alternative, existing JVM implementations (like OpenJ9, >> which I'm not all all familiar with) which are more liberally >> licensed? Having another write-up, similar to yours, which explores >> the same possibilities with OpenJ9 would be definitely a nice read :) >> >> As a side note, it seems like all the Java classes and even the native >> code parts of the class library are all licensed under GPLv2+CPE. So >> linking them into a native image together with user/application code >> seems to be less of a problem. >> >> Thanks again for your great analysis, >> Volker >> >> [1] https://github.com/adinn/leydendoc >> [2] jvm_md.h, jmm.h, jvm_constants.h, jvm.h, jvm_io.h, jvmtiLib.xsl >> >> On Fri, Apr 23, 2021 at 5:30 PM Andrew Dinn wrote: >> > >> > Hello All, >> > >> > There has been a rather long and quiet interlude since the result of the >> > Leyden vote was reported (see below). Unfortunately, there has not yet >> > been any follow-up announcement of a project repo, mail list(s) or >> > working group. However, that's no indication that the project is not >> > still of great interest to those of us who voted for it, nor that some >> > of us have not been thinking about how we might proceed. >> > >> > I'd like to resume the initial discussion and, I hope, trigger some >> > follow-up actions by offering a few recommendations for how we might >> > wish to progress with Leyden. This is based on lessons learned from >> > working with the GraalVM Native implementation over the last year or >> two. >> > >> > Please note that I'm not suggesting that GraalVM Native provides a >> > blueprint for how Leyden should proceed. Indeed, I recognise that one of >> > the key reasons for creating the Leyden project is to sharpen up the >> > definition of static Java and, in doing so, critique some of the choices >> > made in implementing GraalVM Native. >> > >> > The path I am proposing we follow here is to: >> > >> > - identify some of the key architectural and design decisions made in >> > implementing GraalVM Native that appear to be relevant to a Hotspot >> > implementation >> > >> > - gauge how far those decisions contribute to improvements in certain >> > aspects of GraalVM Native performance vs degradation in other aspects >> > >> > - at the same time assess how systematically and coherently those same >> > decisions deal, or fail to deal, with some of the problematic semantic >> > issues involved in delivering static Java deployments >> > >> > - consider whether similar decisions might be worth taking in the >> > context of an implementation based on the current Hotspot code base >> > >> > I have posted a document to github [1] that provides a summary of my own >> > thoughts on the above themes. It starts with a critique of GraalVM >> > which, for the benefit of OpenJDK project members who are not familiar >> > with the implementation, also explains (as accurately as my >> > understanding permits) relevant aspects of the design and >> > implementation. It then goes on to discuss how this might be relevant to >> > a Leyden implementation that reuses existing Hotspot components as far >> > as possible. >> > >> > The document has been reviewed informally by a few OpenJDK project >> > colleagues. I'd be very grateful if others who have expressed an >> > interest in the project could take the time to read it and reflect on >> > it, either providing feedback directly on the document or following up >> > with their own opinions and suggestions for how to proceed. >> > >> > [1] https://github.com/adinn/leydendoc >> > n.b. the repo has a Creative Commons 1.0 open source license. >> > >> > regards, >> > >> > >> > Andrew Dinn >> > ----------- >> > Red Hat Distinguished Engineer >> > Red Hat UK Ltd >> > Registered in England and Wales under Company Registration No. 03798903 >> > Directors: Michael Cunningham, Michael ("Mike") O'Neill >> > >> > >> > >> > On 11/06/2020 17:36, mark.reinhold at oracle.com wrote: >> > > Voting on the Leyden Project [1], with me as the initial Lead, >> > > is now closed. >> > > >> > > Yes: 38 >> > > Veto: 0 >> > > Abstain: 0 >> > > >> > > (Two votes, by individuals not in the Members Group [2], did >> > > not count.) >> > > >> > > According to the Bylaws definition of Lazy Consensus, this is >> > > sufficient to approve the new Project and its initial Lead. >> > > >> > > - Mark >> > > >> > > >> > > [1] >> https://mail.openjdk.java.net/pipermail/announce/2020-May/000289.html >> > > [2] https://openjdk.java.net/census#members >> > > >> > >> > From brian.goetz at oracle.com Mon Apr 26 18:40:16 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 26 Apr 2021 14:40:16 -0400 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: References: <20200611093646.300378510@eggemoggin.niobe.net> Message-ID: <87a51a06-0f61-570d-fb9f-f577755e62ab@oracle.com> Volker; AndrewH and Mario have now both asked that we refrain from the licensing discussion here to focus on the technical discussion, and I'll add my own: this is not an appropriate place for licensing or legal discussions.? The charter of this list is: " Technical discussion related to the JDK Project ".? Let's keep it on topic please! On 4/26/2021 2:29 PM, Volker Simonis wrote: > Anderson Vasconcelos Pires schrieb am Mo., 26. Apr. > 2021, 14:20: > >> Hi Volker, >> >> Looks like the graal uses the similar license of openjdk. >> I understand they would have the same limitation to generate native >> images, right? >> If I am not wrong, why do they decide to have native image? We couldn't >> use at least the same approach? >> > > That's not right. The complete SubstrateVM [1] (which is GraalVM's > equivalent of HotSpot in OpenJDK) is fully GPLv2+CPE licensed. > > That's actually exactly the difference to HotSpot which is mostly GPLv2 > only (without CPE) and the thing I wanted to point out if we decide to > implement Leyden in top of the current HotSpot. > > [1] https://github.com/oracle/graal/tree/master/substratevm > > >> Best regards, >> Anderson. >> >> On Sat, Apr 24, 2021 at 5:44 AM Volker Simonis >> wrote: >> >>> Hi Andrew, >>> >>> thank you so much for resurrecting the discussion on project Leyden! I >>> read through your leydendoc [1] which I think is an excellent and >>> technically deep-dive summary of the current workings of the GraalVM >>> Native Image Generator. The analysis and ideas how this functionality >>> could be implemented in the context of OpenJDK and HotSpot is >>> technically sound and very interesting. >>> >>> I'm really a little reluctant to add some non-technical doubts and >>> acting as a killjoy here, but I think there's one real caveat with >>> your approach and that's (unfortunately) licensing. As you know, the >>> whole HotSpot code base (with the exception of very few header files >>> [2]) is licensed under GPLv2 WITHOUT Class Path Exception (CPE). >>> HotSpot code can only be accessed without getting tainted by the GPL >>> through a restricted set of exported, GPLv2+CPE licensed interfaces >>> [2]. This is already a "weak" construct which has never been disputed >>> but I don't want to discuss that here. >>> >>> I'm however afraid that your approach of linking large parts of the >>> HotSpot code together with application classes into a single static >>> image will undoubtedly "infect" all the user code with the GPL >>> license. I think that's unacceptable for the majority of Java >>> applications which are not already GPLv2 licensed. Unfortunately, in >>> my opinion this seems to be a much bigger problem compared to the >>> technical difficulties to implement your approach. Maybe we should >>> have a look at alternative, existing JVM implementations (like OpenJ9, >>> which I'm not all all familiar with) which are more liberally >>> licensed? Having another write-up, similar to yours, which explores >>> the same possibilities with OpenJ9 would be definitely a nice read :) >>> >>> As a side note, it seems like all the Java classes and even the native >>> code parts of the class library are all licensed under GPLv2+CPE. So >>> linking them into a native image together with user/application code >>> seems to be less of a problem. >>> >>> Thanks again for your great analysis, >>> Volker >>> >>> [1] https://github.com/adinn/leydendoc >>> [2] jvm_md.h, jmm.h, jvm_constants.h, jvm.h, jvm_io.h, jvmtiLib.xsl >>> >>> On Fri, Apr 23, 2021 at 5:30 PM Andrew Dinn wrote: >>>> Hello All, >>>> >>>> There has been a rather long and quiet interlude since the result of the >>>> Leyden vote was reported (see below). Unfortunately, there has not yet >>>> been any follow-up announcement of a project repo, mail list(s) or >>>> working group. However, that's no indication that the project is not >>>> still of great interest to those of us who voted for it, nor that some >>>> of us have not been thinking about how we might proceed. >>>> >>>> I'd like to resume the initial discussion and, I hope, trigger some >>>> follow-up actions by offering a few recommendations for how we might >>>> wish to progress with Leyden. This is based on lessons learned from >>>> working with the GraalVM Native implementation over the last year or >>> two. >>>> Please note that I'm not suggesting that GraalVM Native provides a >>>> blueprint for how Leyden should proceed. Indeed, I recognise that one of >>>> the key reasons for creating the Leyden project is to sharpen up the >>>> definition of static Java and, in doing so, critique some of the choices >>>> made in implementing GraalVM Native. >>>> >>>> The path I am proposing we follow here is to: >>>> >>>> - identify some of the key architectural and design decisions made in >>>> implementing GraalVM Native that appear to be relevant to a Hotspot >>>> implementation >>>> >>>> - gauge how far those decisions contribute to improvements in certain >>>> aspects of GraalVM Native performance vs degradation in other aspects >>>> >>>> - at the same time assess how systematically and coherently those same >>>> decisions deal, or fail to deal, with some of the problematic semantic >>>> issues involved in delivering static Java deployments >>>> >>>> - consider whether similar decisions might be worth taking in the >>>> context of an implementation based on the current Hotspot code base >>>> >>>> I have posted a document to github [1] that provides a summary of my own >>>> thoughts on the above themes. It starts with a critique of GraalVM >>>> which, for the benefit of OpenJDK project members who are not familiar >>>> with the implementation, also explains (as accurately as my >>>> understanding permits) relevant aspects of the design and >>>> implementation. It then goes on to discuss how this might be relevant to >>>> a Leyden implementation that reuses existing Hotspot components as far >>>> as possible. >>>> >>>> The document has been reviewed informally by a few OpenJDK project >>>> colleagues. I'd be very grateful if others who have expressed an >>>> interest in the project could take the time to read it and reflect on >>>> it, either providing feedback directly on the document or following up >>>> with their own opinions and suggestions for how to proceed. >>>> >>>> [1] https://github.com/adinn/leydendoc >>>> n.b. the repo has a Creative Commons 1.0 open source license. >>>> >>>> regards, >>>> >>>> >>>> Andrew Dinn >>>> ----------- >>>> Red Hat Distinguished Engineer >>>> Red Hat UK Ltd >>>> Registered in England and Wales under Company Registration No. 03798903 >>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill >>>> >>>> >>>> >>>> On 11/06/2020 17:36, mark.reinhold at oracle.com wrote: >>>>> Voting on the Leyden Project [1], with me as the initial Lead, >>>>> is now closed. >>>>> >>>>> Yes: 38 >>>>> Veto: 0 >>>>> Abstain: 0 >>>>> >>>>> (Two votes, by individuals not in the Members Group [2], did >>>>> not count.) >>>>> >>>>> According to the Bylaws definition of Lazy Consensus, this is >>>>> sufficient to approve the new Project and its initial Lead. >>>>> >>>>> - Mark >>>>> >>>>> >>>>> [1] >>> https://mail.openjdk.java.net/pipermail/announce/2020-May/000289.html >>>>> [2] https://openjdk.java.net/census#members >>>>> From dgriffiths at undo.io Tue Apr 27 15:50:21 2021 From: dgriffiths at undo.io (David Griffiths) Date: Tue, 27 Apr 2021 16:50:21 +0100 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: References: <20200611093646.300378510@eggemoggin.niobe.net> Message-ID: Hi Andrew and all, could I just add a plea if possible to retain ScopeDesc and PCDesc info (or equivalent) in the compiled code image? I work for a company called Undo and we recently released a reversible debugger for OpenJDK that lets you record an entire Java program history at the machine level and then play it back under IntelliJ via an extended JDWP interface. It allows you to set breakpoints on and single step through compiled code, view all local variables and so on. But this depends heavily on ScopeDesc and PCDesc and similar structures. We have a "bridge" program that talks JDWP to IntelliJ and uses a modified version of gdb to set breakpoints and poke around in compiled code in the target (unmodified) JVM. We set breakpoints at nearby safepoints (PCDescs) and then do the same thing the deoptimizer does to transfer the current frame state to our own bytecode interpreter in the bridge from where we can single step, examine local variables etc. For situations like debugging microservices in the cloud, technology like ours could be very useful. Whilst we have an obvious interest in this, it seems like a good idea to try and aim to retain such structures for future similar technologies to be built on. Cheers, David On Fri, 23 Apr 2021 at 16:31, Andrew Dinn wrote: > Hello All, > > There has been a rather long and quiet interlude since the result of the > Leyden vote was reported (see below). Unfortunately, there has not yet > been any follow-up announcement of a project repo, mail list(s) or > working group. However, that's no indication that the project is not > still of great interest to those of us who voted for it, nor that some > of us have not been thinking about how we might proceed. > > I'd like to resume the initial discussion and, I hope, trigger some > follow-up actions by offering a few recommendations for how we might > wish to progress with Leyden. This is based on lessons learned from > working with the GraalVM Native implementation over the last year or two. > > Please note that I'm not suggesting that GraalVM Native provides a > blueprint for how Leyden should proceed. Indeed, I recognise that one of > the key reasons for creating the Leyden project is to sharpen up the > definition of static Java and, in doing so, critique some of the choices > made in implementing GraalVM Native. > > The path I am proposing we follow here is to: > > - identify some of the key architectural and design decisions made in > implementing GraalVM Native that appear to be relevant to a Hotspot > implementation > > - gauge how far those decisions contribute to improvements in certain > aspects of GraalVM Native performance vs degradation in other aspects > > - at the same time assess how systematically and coherently those same > decisions deal, or fail to deal, with some of the problematic semantic > issues involved in delivering static Java deployments > > - consider whether similar decisions might be worth taking in the > context of an implementation based on the current Hotspot code base > > I have posted a document to github [1] that provides a summary of my own > thoughts on the above themes. It starts with a critique of GraalVM > which, for the benefit of OpenJDK project members who are not familiar > with the implementation, also explains (as accurately as my > understanding permits) relevant aspects of the design and > implementation. It then goes on to discuss how this might be relevant to > a Leyden implementation that reuses existing Hotspot components as far > as possible. > > The document has been reviewed informally by a few OpenJDK project > colleagues. I'd be very grateful if others who have expressed an > interest in the project could take the time to read it and reflect on > it, either providing feedback directly on the document or following up > with their own opinions and suggestions for how to proceed. > > [1] https://github.com/adinn/leydendoc > n.b. the repo has a Creative Commons 1.0 open source license. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > > > > On 11/06/2020 17:36, mark.reinhold at oracle.com wrote: > > Voting on the Leyden Project [1], with me as the initial Lead, > > is now closed. > > > > Yes: 38 > > Veto: 0 > > Abstain: 0 > > > > (Two votes, by individuals not in the Members Group [2], did > > not count.) > > > > According to the Bylaws definition of Lazy Consensus, this is > > sufficient to approve the new Project and its initial Lead. > > > > - Mark > > > > > > [1] > https://mail.openjdk.java.net/pipermail/announce/2020-May/000289.html > > [2] https://openjdk.java.net/census#members > > > > -- David Griffiths, Senior Software Engineer Undo | Accelerate software defect resolution by eliminating the guesswork in failure diagnosis From adinn at redhat.com Tue Apr 27 16:26:01 2021 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 27 Apr 2021 17:26:01 +0100 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: References: <20200611093646.300378510@eggemoggin.niobe.net> Message-ID: <8169ecaa-f672-98e3-9596-6fc836d03464@redhat.com> Hi David, On 27/04/2021 16:50, David Griffiths wrote: > Hi Andrew and all, could I just add a plea if possible to retain > ScopeDesc and PCDesc info (or equivalent) in the compiled code image? I > work for a company called Undo and we recently released a reversible > debugger for OpenJDK that lets you record an entire Java program history > at the machine level and then play it back under IntelliJ via an > extended JDWP interface. It allows you to set breakpoints on and single > step through compiled code, view all local variables and so on. But this > depends heavily on ScopeDesc and PCDesc and similar structures. We have > a "bridge" program that talks JDWP to IntelliJ and uses a modified > version of gdb to set breakpoints and poke around in compiled code in > the target (unmodified) JVM. We set breakpoints at nearby safepoints > (PCDescs) and then do the same thing the deoptimizer does to transfer > the current frame state to our own bytecode interpreter in the bridge > from where we can single step, examine local variables etc. > > For situations like debugging microservices in the cloud, technology > like ours could be very useful. Whilst we have an obvious interest in > this, it seems like a good idea to try and aim to retain such structures > for future similar technologies to be built on. I believe a native implementation that reuses the Hotspot JVM will be required to attach ScopeDesc and PCDesc info to the compiled method metadata inserted into the pre-generated code cache. The VM will need to retrieve them in order to populate stack backtraces. We might perhaps choose to rewrite that part of the Hotspot code in a Leyden build to use some other structure or decode logic. However, I think the current model employs a compact and complete representation of what we need so I for th emoment can't think of any any reason why it should be changed. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From dgriffiths at undo.io Tue Apr 27 17:49:54 2021 From: dgriffiths at undo.io (David Griffiths) Date: Tue, 27 Apr 2021 18:49:54 +0100 Subject: Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden) In-Reply-To: <8169ecaa-f672-98e3-9596-6fc836d03464@redhat.com> References: <20200611093646.300378510@eggemoggin.niobe.net> <8169ecaa-f672-98e3-9596-6fc836d03464@redhat.com> Message-ID: On Tue, 27 Apr 2021 at 17:26, Andrew Dinn wrote: > I believe a native implementation that reuses the Hotspot JVM will be > required to attach ScopeDesc and PCDesc info to the compiled method > metadata inserted into the pre-generated code cache. The VM will need to > retrieve them in order to populate stack backtraces. > > We might perhaps choose to rewrite that part of the Hotspot code in a > Leyden build to use some other structure or decode logic. However, I > think the current model employs a compact and complete representation of > what we need so I for th emoment can't think of any any reason why it > should be changed. That's very encouraging, thanks! Cheers, David -- David Griffiths, Senior Software Engineer Undo | Accelerate software defect resolution by eliminating the guesswork in failure diagnosis