From hjohn at xs4all.nl Sat Sep 1 06:43:46 2018 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 1 Sep 2018 08:43:46 +0200 Subject: Review Request for JDK-8209968: Fix rounding error in image scale calculation Message-ID: <2d331c2f-167f-18bf-c7c0-bc48796c7438@xs4all.nl> Hi, This is a review request for: https://bugs.openjdk.java.net/browse/JDK-8209968 The PR is on Github: https://github.com/javafxports/openjdk-jfx/pull/170 --John From pedro.duquevieira at gmail.com Sat Sep 1 12:00:48 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sat, 1 Sep 2018 13:00:48 +0100 Subject: Is JavaFX going to truly be a community project? Message-ID: Hi, For JavaFX to start being, truly, a community project it is important that it is perceived as a real community effort. Right now it's starting to look more like it's changing hands, from being an Oracle project to being a Gluon project. I don't have anything against Gluon, I'd say the same if for instance, instead of Gluon it was JPro or Karakun, or whatever... Hosting the JavaFX docs, builds, installations, etc on a company owned site or a company endorsed site sounds like a really bad idea. Which is what's happening right now. If it's to be a community project it should be owned by the community as a whole. As well as being perceived to be owned by the community as a whole. Being a one company project will deter the contributions of other players in the JavaFX space. Other players that also offer consultancy services, and JavaFX products will have a big disadvantage towards the company hosting the JavaFX assets and downloads. At the very minimum think about the huge advantage this company will have in publicity when compared to the others. A community project is a project where various players join efforts to mutually benefit each other. As soon as this starts being a project that's benefiting one particular company more than the others it ceases to be a community project. I don't think that anyone would like to join in on the efforts in this scenario. Thanks, -- Pedro Duque Vieira - https://www.pixelduke.com From johnvalrose at gmail.com Sat Sep 1 12:38:00 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 1 Sep 2018 22:38:00 +1000 Subject: Is JavaFX going to truly be a community project? In-Reply-To: References: Message-ID: Hi Pedro, I just happen to agree with you in this issue. But, out of all the possible new custodians of JavaFX, I have to say that I am always in awe of what Johan and Gluon have already contributed and accomplished. So how do we ensue that OpenJFX is truly ?open?? I agree that even though Gluon are doing a fantastic job, JavaFX should not be a ?Gluon product?. I think it?s a great move for Oracle to basically relinquish control of JavaFX - but to whom? I?m not familiar enough with FOSS projects to offer any sage advice but I totally agree that a ?community? project has to be as open to everyone as possible and no person or entity should have a commercial advantage over others. So, basically I like your question, I don?t believe the current scenario is satisfactory but unfortunately I confess I can?t offer any suggestions of better scenarios. Graciously, John-Val Rose > On 1 Sep 2018, at 22:00, Pedro Duque Vieira wrote: > > Hi, > > For JavaFX to start being, truly, a community project it is important that > it is perceived as a real community effort. Right now it's starting to look > more like it's changing hands, from being an Oracle project to being a > Gluon project. > > I don't have anything against Gluon, I'd say the same if for instance, > instead of Gluon it was JPro or Karakun, or whatever... > > Hosting the JavaFX docs, builds, installations, etc on a company owned site > or a company endorsed site sounds like a really bad idea. Which is what's > happening right now. If it's to be a community project it should be owned > by the community as a whole. As well as being perceived to be owned by the > community as a whole. > > Being a one company project will deter the contributions of other players > in the JavaFX space. Other players that also offer consultancy services, > and JavaFX products will have a big disadvantage towards the company > hosting the JavaFX assets and downloads. At the very minimum think about > the huge advantage this company will have in publicity when compared to the > others. > > A community project is a project where various players join efforts to > mutually benefit each other. As soon as this starts being a project that's > benefiting one particular company more than the others it ceases to be a > community project. > > I don't think that anyone would like to join in on the efforts in this > scenario. > > Thanks, > > > > -- > Pedro Duque Vieira - https://www.pixelduke.com From werner at yellowcouch.org Sat Sep 1 13:05:23 2018 From: werner at yellowcouch.org (Werner Van Belle) Date: Sat, 01 Sep 2018 15:05:23 +0200 Subject: Is JavaFX going to truly be a community project? In-Reply-To: References: Message-ID: <1535807123.1909.22.camel@yellowcouch.org> Hello, Just put it on github and let people fork it however they want.? That would be "open". Werner,- PS: I _am_ seriously pissed at Oracle about this shit. I spend the last years specializing in their newest technology 'which they would never ever drop' and now they just drop it. On Sat, 2018-09-01 at 22:38 +1000, John-Val Rose wrote: > Hi Pedro, > > I just happen to agree with you in this issue. > > But, out of all the possible new custodians of JavaFX, I have to say > that I am always in awe of what Johan and Gluon have already > contributed and accomplished. > > So how do we ensue that OpenJFX is truly ?open?? > > I agree that even though Gluon are doing a fantastic job, JavaFX > should not be a ?Gluon product?. > > I think it?s a great move for Oracle to basically relinquish control > of JavaFX - but to whom? > > I?m not familiar enough with FOSS projects to offer any sage advice > but I totally agree that a ?community? project has to be as open to > everyone as possible and no person or entity should have a commercial > advantage over others. > > So, basically I like your question, I don?t believe the current > scenario is satisfactory but unfortunately I confess I can?t offer > any suggestions of better scenarios. > > Graciously, > > John-Val Rose > > > > > On 1 Sep 2018, at 22:00, Pedro Duque Vieira > l.com> wrote: > > > > Hi, > > > > For JavaFX to start being, truly, a community project it is > > important that > > it is perceived as a real community effort. Right now it's starting > > to look > > more like it's changing hands, from being an Oracle project to > > being a > > Gluon project. > > > > I don't have anything against Gluon, I'd say the same if for > > instance, > > instead of Gluon it was JPro or Karakun, or whatever... > > > > Hosting the JavaFX docs, builds, installations, etc on a company > > owned site > > or a company endorsed site sounds like a really bad idea. Which is > > what's > > happening right now. If it's to be a community project it should be > > owned > > by the community as a whole. As well as being perceived to be owned > > by the > > community as a whole. > > > > Being a one company project will deter the contributions of other > > players > > in the JavaFX space. Other players that also offer consultancy > > services, > > and JavaFX products will have a big disadvantage towards the > > company > > hosting the JavaFX assets and downloads. At the very minimum think > > about > > the huge advantage this company will have in publicity when > > compared to the > > others. > > > > A community project is a project where various players join efforts > > to > > mutually benefit each other. As soon as this starts being a project > > that's > > benefiting one particular company more than the others it ceases to > > be a > > community project. > > > > I don't think that anyone would like to join in on the efforts in > > this > > scenario. > > > > Thanks, > > > > > > From julianjupiter.io at gmail.com Sat Sep 1 13:29:39 2018 From: julianjupiter.io at gmail.com (Julian Jupiter) Date: Sat, 1 Sep 2018 21:29:39 +0800 Subject: Is JavaFX going to truly be a community project? In-Reply-To: References: Message-ID: Hi Pedro, I also agree. JavaFX should be developed outside of any profit organization. I'm not sure, maybe I'm quick to suggest this: perhaps, a foundation should be created to foster the development of JavaFX. And anyone (same people now, amd more) should be encouraged to participate. I'm not against Apache & Eclipse (they are so fantastic orgs) but I think a foundation whose sole purpose is to further the development of JavaFX would be better. And I think this org should be in contant touch with OpenJDK team as well as other initiatives the could help advance JavaFX (e.g. JSR 377). Thank you. Julian Jupiter On Sat, Sep 1, 2018, 8:38 PM John-Val Rose, wrote: > Hi Pedro, > > I just happen to agree with you in this issue. > > But, out of all the possible new custodians of JavaFX, I have to say that > I am always in awe of what Johan and Gluon have already contributed and > accomplished. > > So how do we ensue that OpenJFX is truly ?open?? > > I agree that even though Gluon are doing a fantastic job, JavaFX should > not be a ?Gluon product?. > > I think it?s a great move for Oracle to basically relinquish control of > JavaFX - but to whom? > > I?m not familiar enough with FOSS projects to offer any sage advice but I > totally agree that a ?community? project has to be as open to everyone as > possible and no person or entity should have a commercial advantage over > others. > > So, basically I like your question, I don?t believe the current scenario > is satisfactory but unfortunately I confess I can?t offer any suggestions > of better scenarios. > > Graciously, > > John-Val Rose > > > On 1 Sep 2018, at 22:00, Pedro Duque Vieira > wrote: > > > > Hi, > > > > For JavaFX to start being, truly, a community project it is important > that > > it is perceived as a real community effort. Right now it's starting to > look > > more like it's changing hands, from being an Oracle project to being a > > Gluon project. > > > > I don't have anything against Gluon, I'd say the same if for instance, > > instead of Gluon it was JPro or Karakun, or whatever... > > > > Hosting the JavaFX docs, builds, installations, etc on a company owned > site > > or a company endorsed site sounds like a really bad idea. Which is what's > > happening right now. If it's to be a community project it should be owned > > by the community as a whole. As well as being perceived to be owned by > the > > community as a whole. > > > > Being a one company project will deter the contributions of other players > > in the JavaFX space. Other players that also offer consultancy services, > > and JavaFX products will have a big disadvantage towards the company > > hosting the JavaFX assets and downloads. At the very minimum think about > > the huge advantage this company will have in publicity when compared to > the > > others. > > > > A community project is a project where various players join efforts to > > mutually benefit each other. As soon as this starts being a project > that's > > benefiting one particular company more than the others it ceases to be a > > community project. > > > > I don't think that anyone would like to join in on the efforts in this > > scenario. > > > > Thanks, > > > > > > > > -- > > Pedro Duque Vieira - https://www.pixelduke.com > From pedro.duquevieira at gmail.com Sat Sep 1 13:54:54 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sat, 1 Sep 2018 14:54:54 +0100 Subject: Is JavaFX going to truly be a community project? In-Reply-To: <1535807123.1909.22.camel@yellowcouch.org> References: <1535807123.1909.22.camel@yellowcouch.org> Message-ID: Yes, just a site with code on github would be enough, for example. Without any publicity or endorsement to any particular company. Jfxtras does this: http://jfxtras.org/ and the code of the site is on github repository: https://github.com/JFXtras/jfxtras.github.com Outside of this, Gluon can still offer consultancy, payed support for javafx, javafx based products, etc. I think this is the type of decisions that should be discussed among the community before any action is taken. Cheers, On Sat, Sep 1, 2018 at 2:05 PM Werner Van Belle wrote: > Hello, > > Just put it on github and let people fork it however they want. > That would be "open". > > Werner,- > > PS: I _am_ seriously pissed at Oracle about this shit. I spend the last > years specializing in their newest technology 'which they would never > ever drop' and now they just drop it. > > On Sat, 2018-09-01 at 22:38 +1000, John-Val Rose wrote: > > Hi Pedro, > > > > I just happen to agree with you in this issue. > > > > But, out of all the possible new custodians of JavaFX, I have to say > > that I am always in awe of what Johan and Gluon have already > > contributed and accomplished. > > > > So how do we ensue that OpenJFX is truly ?open?? > > > > I agree that even though Gluon are doing a fantastic job, JavaFX > > should not be a ?Gluon product?. > > > > I think it?s a great move for Oracle to basically relinquish control > > of JavaFX - but to whom? > > > > I?m not familiar enough with FOSS projects to offer any sage advice > > but I totally agree that a ?community? project has to be as open to > > everyone as possible and no person or entity should have a commercial > > advantage over others. > > > > So, basically I like your question, I don?t believe the current > > scenario is satisfactory but unfortunately I confess I can?t offer > > any suggestions of better scenarios. > > > > Graciously, > > > > John-Val Rose > > > > > > > > On 1 Sep 2018, at 22:00, Pedro Duque Vieira > > l.com> wrote: > > > > > > Hi, > > > > > > For JavaFX to start being, truly, a community project it is > > > important that > > > it is perceived as a real community effort. Right now it's starting > > > to look > > > more like it's changing hands, from being an Oracle project to > > > being a > > > Gluon project. > > > > > > I don't have anything against Gluon, I'd say the same if for > > > instance, > > > instead of Gluon it was JPro or Karakun, or whatever... > > > > > > Hosting the JavaFX docs, builds, installations, etc on a company > > > owned site > > > or a company endorsed site sounds like a really bad idea. Which is > > > what's > > > happening right now. If it's to be a community project it should be > > > owned > > > by the community as a whole. As well as being perceived to be owned > > > by the > > > community as a whole. > > > > > > Being a one company project will deter the contributions of other > > > players > > > in the JavaFX space. Other players that also offer consultancy > > > services, > > > and JavaFX products will have a big disadvantage towards the > > > company > > > hosting the JavaFX assets and downloads. At the very minimum think > > > about > > > the huge advantage this company will have in publicity when > > > compared to the > > > others. > > > > > > A community project is a project where various players join efforts > > > to > > > mutually benefit each other. As soon as this starts being a project > > > that's > > > benefiting one particular company more than the others it ceases to > > > be a > > > community project. > > > > > > I don't think that anyone would like to join in on the efforts in > > > this > > > scenario. > > > > > > Thanks, > > > > > > > > > > -- Pedro Duque Vieira - https://www.pixelduke.com From julianjupiter.io at gmail.com Sat Sep 1 14:01:41 2018 From: julianjupiter.io at gmail.com (Julian Jupiter) Date: Sat, 1 Sep 2018 22:01:41 +0800 Subject: Is JavaFX going to truly be a community project? In-Reply-To: References: <1535807123.1909.22.camel@yellowcouch.org> Message-ID: Not sure if the term "drop" is correct. But, with what Oracle did, it would be more beneficial for JavaFX. The development has been more open; encouraging more contributors. Julez On Sat, Sep 1, 2018, 9:55 PM Pedro Duque Vieira, < pedro.duquevieira at gmail.com> wrote: > Yes, just a site with code on github would be enough, for example. Without > any publicity or endorsement to any particular company. > > Jfxtras does this: http://jfxtras.org/ and the code of the site is on > github repository: https://github.com/JFXtras/jfxtras.github.com > > Outside of this, Gluon can still offer consultancy, payed support for > javafx, javafx based products, etc. > > I think this is the type of decisions that should be discussed among the > community before any action is taken. > > Cheers, > > > > > > On Sat, Sep 1, 2018 at 2:05 PM Werner Van Belle > wrote: > > > Hello, > > > > Just put it on github and let people fork it however they want. > > That would be "open". > > > > Werner,- > > > > PS: I _am_ seriously pissed at Oracle about this shit. I spend the last > > years specializing in their newest technology 'which they would never > > ever drop' and now they just drop it. > > > > On Sat, 2018-09-01 at 22:38 +1000, John-Val Rose wrote: > > > Hi Pedro, > > > > > > I just happen to agree with you in this issue. > > > > > > But, out of all the possible new custodians of JavaFX, I have to say > > > that I am always in awe of what Johan and Gluon have already > > > contributed and accomplished. > > > > > > So how do we ensue that OpenJFX is truly ?open?? > > > > > > I agree that even though Gluon are doing a fantastic job, JavaFX > > > should not be a ?Gluon product?. > > > > > > I think it?s a great move for Oracle to basically relinquish control > > > of JavaFX - but to whom? > > > > > > I?m not familiar enough with FOSS projects to offer any sage advice > > > but I totally agree that a ?community? project has to be as open to > > > everyone as possible and no person or entity should have a commercial > > > advantage over others. > > > > > > So, basically I like your question, I don?t believe the current > > > scenario is satisfactory but unfortunately I confess I can?t offer > > > any suggestions of better scenarios. > > > > > > Graciously, > > > > > > John-Val Rose > > > > > > > > > > > On 1 Sep 2018, at 22:00, Pedro Duque Vieira > > > l.com> wrote: > > > > > > > > Hi, > > > > > > > > For JavaFX to start being, truly, a community project it is > > > > important that > > > > it is perceived as a real community effort. Right now it's starting > > > > to look > > > > more like it's changing hands, from being an Oracle project to > > > > being a > > > > Gluon project. > > > > > > > > I don't have anything against Gluon, I'd say the same if for > > > > instance, > > > > instead of Gluon it was JPro or Karakun, or whatever... > > > > > > > > Hosting the JavaFX docs, builds, installations, etc on a company > > > > owned site > > > > or a company endorsed site sounds like a really bad idea. Which is > > > > what's > > > > happening right now. If it's to be a community project it should be > > > > owned > > > > by the community as a whole. As well as being perceived to be owned > > > > by the > > > > community as a whole. > > > > > > > > Being a one company project will deter the contributions of other > > > > players > > > > in the JavaFX space. Other players that also offer consultancy > > > > services, > > > > and JavaFX products will have a big disadvantage towards the > > > > company > > > > hosting the JavaFX assets and downloads. At the very minimum think > > > > about > > > > the huge advantage this company will have in publicity when > > > > compared to the > > > > others. > > > > > > > > A community project is a project where various players join efforts > > > > to > > > > mutually benefit each other. As soon as this starts being a project > > > > that's > > > > benefiting one particular company more than the others it ceases to > > > > be a > > > > community project. > > > > > > > > I don't think that anyone would like to join in on the efforts in > > > > this > > > > scenario. > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > -- > Pedro Duque Vieira - https://www.pixelduke.com > From kevin.rushforth at oracle.com Sat Sep 1 14:35:15 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 1 Sep 2018 07:35:15 -0700 Subject: Is JavaFX going to truly be a community project? In-Reply-To: References: <1535807123.1909.22.camel@yellowcouch.org> Message-ID: <42f07dc1-90d0-f99f-87d4-730e376c81ad@oracle.com> There is nothing stopping you or anyone else from producing builds of OpenJFX. Software doesn't build itself, though, so you'll need to find the resources to build / test / host JavaFX somewhere. I for one am very happy that Gluon has stepped up to do this. There has been some discussion with the AdoptOpenJDK folks about builds, so maybe something could happen there eventually. As for a GitHub repo, there already is a GitHub mirror / sandbox here: https://github.com/javafxports/openjdk-jfx You can fork it, play around with it, even submit pull requests against it; as with any open source project, you will need to sign the contributor agreement, as well as have your code reviewed, in order to get your change merged in. -- Kevin On 9/1/2018 6:54 AM, Pedro Duque Vieira wrote: > Yes, just a site with code on github would be enough, for example. Without > any publicity or endorsement to any particular company. > > Jfxtras does this: http://jfxtras.org/ and the code of the site is on > github repository: https://github.com/JFXtras/jfxtras.github.com > > Outside of this, Gluon can still offer consultancy, payed support for > javafx, javafx based products, etc. > > I think this is the type of decisions that should be discussed among the > community before any action is taken. > > Cheers, > > > > > > On Sat, Sep 1, 2018 at 2:05 PM Werner Van Belle > wrote: > >> Hello, >> >> Just put it on github and let people fork it however they want. >> That would be "open". >> >> Werner,- >> >> PS: I _am_ seriously pissed at Oracle about this shit. I spend the last >> years specializing in their newest technology 'which they would never >> ever drop' and now they just drop it. >> >> On Sat, 2018-09-01 at 22:38 +1000, John-Val Rose wrote: >>> Hi Pedro, >>> >>> I just happen to agree with you in this issue. >>> >>> But, out of all the possible new custodians of JavaFX, I have to say >>> that I am always in awe of what Johan and Gluon have already >>> contributed and accomplished. >>> >>> So how do we ensue that OpenJFX is truly ?open?? >>> >>> I agree that even though Gluon are doing a fantastic job, JavaFX >>> should not be a ?Gluon product?. >>> >>> I think it?s a great move for Oracle to basically relinquish control >>> of JavaFX - but to whom? >>> >>> I?m not familiar enough with FOSS projects to offer any sage advice >>> but I totally agree that a ?community? project has to be as open to >>> everyone as possible and no person or entity should have a commercial >>> advantage over others. >>> >>> So, basically I like your question, I don?t believe the current >>> scenario is satisfactory but unfortunately I confess I can?t offer >>> any suggestions of better scenarios. >>> >>> Graciously, >>> >>> John-Val Rose >>> >>>> On 1 Sep 2018, at 22:00, Pedro Duque Vieira >>> l.com> wrote: >>>> >>>> Hi, >>>> >>>> For JavaFX to start being, truly, a community project it is >>>> important that >>>> it is perceived as a real community effort. Right now it's starting >>>> to look >>>> more like it's changing hands, from being an Oracle project to >>>> being a >>>> Gluon project. >>>> >>>> I don't have anything against Gluon, I'd say the same if for >>>> instance, >>>> instead of Gluon it was JPro or Karakun, or whatever... >>>> >>>> Hosting the JavaFX docs, builds, installations, etc on a company >>>> owned site >>>> or a company endorsed site sounds like a really bad idea. Which is >>>> what's >>>> happening right now. If it's to be a community project it should be >>>> owned >>>> by the community as a whole. As well as being perceived to be owned >>>> by the >>>> community as a whole. >>>> >>>> Being a one company project will deter the contributions of other >>>> players >>>> in the JavaFX space. Other players that also offer consultancy >>>> services, >>>> and JavaFX products will have a big disadvantage towards the >>>> company >>>> hosting the JavaFX assets and downloads. At the very minimum think >>>> about >>>> the huge advantage this company will have in publicity when >>>> compared to the >>>> others. >>>> >>>> A community project is a project where various players join efforts >>>> to >>>> mutually benefit each other. As soon as this starts being a project >>>> that's >>>> benefiting one particular company more than the others it ceases to >>>> be a >>>> community project. >>>> >>>> I don't think that anyone would like to join in on the efforts in >>>> this >>>> scenario. >>>> >>>> Thanks, >>>> >>>> >>>> > From john.childress at gmail.com Sat Sep 1 15:22:00 2018 From: john.childress at gmail.com (John Childress) Date: Sat, 1 Sep 2018 10:22:00 -0500 Subject: Is JavaFX going to truly be a community project? In-Reply-To: <42f07dc1-90d0-f99f-87d4-730e376c81ad@oracle.com> References: <1535807123.1909.22.camel@yellowcouch.org> <42f07dc1-90d0-f99f-87d4-730e376c81ad@oracle.com> Message-ID: I have to say I am very happy with what Gluon has done and continues to do. It takes a tremendous amount of time and money to manage and grow a project like JavaFX. I can't thank them enough. I agree with Kevin that nothing is stopping anyone from contributing. On Sat, Sep 1, 2018 at 9:35 AM Kevin Rushforth wrote: > There is nothing stopping you or anyone else from producing builds of > OpenJFX. Software doesn't build itself, though, so you'll need to find > the resources to build / test / host JavaFX somewhere. I for one am very > happy that Gluon has stepped up to do this. There has been some > discussion with the AdoptOpenJDK folks about builds, so maybe something > could happen there eventually. > > As for a GitHub repo, there already is a GitHub mirror / sandbox here: > > https://github.com/javafxports/openjdk-jfx > > You can fork it, play around with it, even submit pull requests against > it; as with any open source project, you will need to sign the > contributor agreement, as well as have your code reviewed, in order to > get your change merged in. > > -- Kevin > > > On 9/1/2018 6:54 AM, Pedro Duque Vieira wrote: > > Yes, just a site with code on github would be enough, for example. > Without > > any publicity or endorsement to any particular company. > > > > Jfxtras does this: http://jfxtras.org/ and the code of the site is on > > github repository: https://github.com/JFXtras/jfxtras.github.com > > > > Outside of this, Gluon can still offer consultancy, payed support for > > javafx, javafx based products, etc. > > > > I think this is the type of decisions that should be discussed among the > > community before any action is taken. > > > > Cheers, > > > > > > > > > > > > On Sat, Sep 1, 2018 at 2:05 PM Werner Van Belle > > wrote: > > > >> Hello, > >> > >> Just put it on github and let people fork it however they want. > >> That would be "open". > >> > >> Werner,- > >> > >> PS: I _am_ seriously pissed at Oracle about this shit. I spend the last > >> years specializing in their newest technology 'which they would never > >> ever drop' and now they just drop it. > >> > >> On Sat, 2018-09-01 at 22:38 +1000, John-Val Rose wrote: > >>> Hi Pedro, > >>> > >>> I just happen to agree with you in this issue. > >>> > >>> But, out of all the possible new custodians of JavaFX, I have to say > >>> that I am always in awe of what Johan and Gluon have already > >>> contributed and accomplished. > >>> > >>> So how do we ensue that OpenJFX is truly ?open?? > >>> > >>> I agree that even though Gluon are doing a fantastic job, JavaFX > >>> should not be a ?Gluon product?. > >>> > >>> I think it?s a great move for Oracle to basically relinquish control > >>> of JavaFX - but to whom? > >>> > >>> I?m not familiar enough with FOSS projects to offer any sage advice > >>> but I totally agree that a ?community? project has to be as open to > >>> everyone as possible and no person or entity should have a commercial > >>> advantage over others. > >>> > >>> So, basically I like your question, I don?t believe the current > >>> scenario is satisfactory but unfortunately I confess I can?t offer > >>> any suggestions of better scenarios. > >>> > >>> Graciously, > >>> > >>> John-Val Rose > >>> > >>>> On 1 Sep 2018, at 22:00, Pedro Duque Vieira >>>> l.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> For JavaFX to start being, truly, a community project it is > >>>> important that > >>>> it is perceived as a real community effort. Right now it's starting > >>>> to look > >>>> more like it's changing hands, from being an Oracle project to > >>>> being a > >>>> Gluon project. > >>>> > >>>> I don't have anything against Gluon, I'd say the same if for > >>>> instance, > >>>> instead of Gluon it was JPro or Karakun, or whatever... > >>>> > >>>> Hosting the JavaFX docs, builds, installations, etc on a company > >>>> owned site > >>>> or a company endorsed site sounds like a really bad idea. Which is > >>>> what's > >>>> happening right now. If it's to be a community project it should be > >>>> owned > >>>> by the community as a whole. As well as being perceived to be owned > >>>> by the > >>>> community as a whole. > >>>> > >>>> Being a one company project will deter the contributions of other > >>>> players > >>>> in the JavaFX space. Other players that also offer consultancy > >>>> services, > >>>> and JavaFX products will have a big disadvantage towards the > >>>> company > >>>> hosting the JavaFX assets and downloads. At the very minimum think > >>>> about > >>>> the huge advantage this company will have in publicity when > >>>> compared to the > >>>> others. > >>>> > >>>> A community project is a project where various players join efforts > >>>> to > >>>> mutually benefit each other. As soon as this starts being a project > >>>> that's > >>>> benefiting one particular company more than the others it ceases to > >>>> be a > >>>> community project. > >>>> > >>>> I don't think that anyone would like to join in on the efforts in > >>>> this > >>>> scenario. > >>>> > >>>> Thanks, > >>>> > >>>> > >>>> > > > > -- John Childress 713-234-0427 john.childress at gmail.com From mike.ennen at gmail.com Sat Sep 1 18:59:45 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Sat, 1 Sep 2018 11:59:45 -0700 Subject: Is JavaFX going to truly be a community project? In-Reply-To: References: Message-ID: This is one of the reasons I pushed (along with other's) to open a Github repository. Making it so that the work we do there transfers over to master easier is something that is on-going. I implemented the support for Travis CI and Appveyor so that if you open a pull-request on the openjdk-jfx Github repository you can see test results for Mac, Windows, and Linux. You can even run a temporary "FULL_TEST" by adding a temporary commit (that would be removed when the PR is merged) that adds `-PFULL_TEST=true`, `-PUSE_ROBOT=true`, to "tools\scripts\build.ps1" for Windows and ".ci\script.sh" for Linux and macOS. There were some questions about checking if the JavaFX tutorials could be re-licensed under a FOSS license. If that becomes a reality we could either add them to the openjdk-jfx repository, create an orphan branch for them, or add them to an additional repository that is linked to in the README. JavaFX has technically been open for quite some time. Making it so others can join in and add their contributions has been part of my focus for a bit now, and things are getting better incrementally in that regard. I opened a pull-request to move the JavaFX Robot API from private API to public API, and with the help of Kevin Rushforth that was stewarded into the latest JavaFX releases. That's one example from me, personally. I hope we can continue to add/improve features to JavaFX, even if there was a different or simply more stewards. Thanks, Michael Ennen On Sat, Sep 1, 2018 at 5:01 AM Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > Hi, > > For JavaFX to start being, truly, a community project it is important that > it is perceived as a real community effort. Right now it's starting to look > more like it's changing hands, from being an Oracle project to being a > Gluon project. > > I don't have anything against Gluon, I'd say the same if for instance, > instead of Gluon it was JPro or Karakun, or whatever... > > Hosting the JavaFX docs, builds, installations, etc on a company owned site > or a company endorsed site sounds like a really bad idea. Which is what's > happening right now. If it's to be a community project it should be owned > by the community as a whole. As well as being perceived to be owned by the > community as a whole. > > Being a one company project will deter the contributions of other players > in the JavaFX space. Other players that also offer consultancy services, > and JavaFX products will have a big disadvantage towards the company > hosting the JavaFX assets and downloads. At the very minimum think about > the huge advantage this company will have in publicity when compared to the > others. > > A community project is a project where various players join efforts to > mutually benefit each other. As soon as this starts being a project that's > benefiting one particular company more than the others it ceases to be a > community project. > > I don't think that anyone would like to join in on the efforts in this > scenario. > > Thanks, > > > > -- > Pedro Duque Vieira - https://www.pixelduke.com > From pedro.duquevieira at gmail.com Sat Sep 1 19:49:20 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sat, 1 Sep 2018 20:49:20 +0100 Subject: Is JavaFX going to truly be a community project? Message-ID: I'm just an individual, freelancer/consultant, I don't have the resources to build / test / host JavaFX myself. I've done what I can to contribute with free open source projects for JavaFX (see: https://pixelduke.com/projects/ for a list of some, not all of my free open source JavaFX projects). I try to contribute with what I think I can do best. I only do this because of my passion for the technology. I'm not gaining anything with it, in fact I haven't had any javafx client projects in about an year. I've recently only done web development. But enough about myself. I was kinda skeptical when Oracle "dropped" JavaFX. Anyway, I thought it was going to become a community effort. My vision was various players companies or individuals contributing towards the common goal of evolving JavaFX, No individual company would stand out has the owner of JavaFX. It would be community owned and the various players could support themselves by selling their own JavaFX products or consultancy services. This would only work if no one company or individual stands out has the JavaFX owner, ripping all the benefits out of the contributions of the other players. I'm in a hurry right now. Don't have time to write something more pondered. I don't want to offend anyone, and I'm sorry if this sounds too harsh but that's how I'm perceiving things to be right now and in the future. If some non profit would take up the task of building and providing JavaFX that would be the best solution. Or some entity that could be funded by all the other players. I'm not perfectly acquainted with AdoptOpenJDK. Not sure if this is how they work. As things stand out right now, it's not appealing. It's not something that would motivate me into contributing my free time. I think probably others might think like this. Will maybe just fork javafx and make their own distributions. Or just go and try out a different technology. Or maybe I'm just wrong. Thanks, -- Pedro Duque Vieira - https://www.pixelduke.com From mike at plan99.net Sun Sep 2 16:59:59 2018 From: mike at plan99.net (Mike Hearn) Date: Sun, 2 Sep 2018 18:59:59 +0200 Subject: Is JavaFX going to truly be a community project? In-Reply-To: References: Message-ID: I believe you're over-thinking this Pedro. A quote from Margaret Thatcher springs to mind: "They are casting their problems on society and who is society? There is no > such thing! There are individual men and women and there are families and > no government can do anything except through people and people look to > themselves first." Her point was that when someone says "the community should do this", that's an abstraction - the community is nothing more than people, sometimes individuals and sometimes organised into companies. Gluon and Oracle are both clearly critical parts of the JavaFX community and that's a good thing. I'm not sure why it would be off-putting. After all, JavaFX is based on Java and the Java community is mostly made of companies too (Oracle, Red Hat, Intel, Azul etc). Perhaps the JavaFX community will get more organised with time - I believe the "community-ness" feeling would be significantly enhanced with simple things like a JavaFX website. Perhaps you can contribute such a thing, as it would not involve core JavaFX hacking? From johnvalrose at gmail.com Sun Sep 2 23:26:07 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Mon, 3 Sep 2018 09:26:07 +1000 Subject: Is JavaFX going to truly be a community project? In-Reply-To: References: Message-ID: <17D927CC-4C81-449A-B4C7-986F61CA205A@gmail.com> Mike, can you explain what you mean by a ?JavaFX website?? > On 3 Sep 2018, at 02:59, Mike Hearn wrote: > > I believe you're over-thinking this Pedro. A quote from Margaret Thatcher > springs to mind: > > "They are casting their problems on society and who is society? There is no >> such thing! There are individual men and women and there are families and >> no government can do anything except through people and people look to >> themselves first." > > > Her point was that when someone says "the community should do this", that's > an abstraction - the community is nothing more than people, sometimes > individuals and sometimes organised into companies. Gluon and Oracle are > both clearly critical parts of the JavaFX community and that's a good > thing. I'm not sure why it would be off-putting. After all, JavaFX is based > on Java and the Java community is mostly made of companies too (Oracle, Red > Hat, Intel, Azul etc). > > Perhaps the JavaFX community will get more organised with time - I believe > the "community-ness" feeling would be significantly enhanced with simple > things like a JavaFX website. Perhaps you can contribute such a thing, as > it would not involve core JavaFX hacking? From johan.vos at gluonhq.com Mon Sep 3 14:17:29 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 3 Sep 2018 16:17:29 +0200 Subject: Review request for 8209969 Message-ID: Please review the trivial fix for https://bugs.openjdk.java.net/browse/JDK-8209969 at http://cr.openjdk.java.net/~jvos/8209969/webrev.00/ (approved and merged in github via https://github.com/javafxports/openjdk-jfx/commit/3fbd1165a31cf07a4dcb6c854597adeccc4af7c7 ) Thanks, - Johan From kevin.rushforth at oracle.com Mon Sep 3 14:23:24 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 3 Sep 2018 07:23:24 -0700 Subject: Review request for 8209969 In-Reply-To: References: Message-ID: <8d0c5fcf-9073-c87c-0d6e-b78631cb64c9@oracle.com> +1 On 9/3/2018 7:17 AM, Johan Vos wrote: > Please review the trivial fix for > https://bugs.openjdk.java.net/browse/JDK-8209969 at > http://cr.openjdk.java.net/~jvos/8209969/webrev.00/ (approved and merged in > github via > https://github.com/javafxports/openjdk-jfx/commit/3fbd1165a31cf07a4dcb6c854597adeccc4af7c7 > ) > > Thanks, > > - Johan From pedro.duquevieira at gmail.com Tue Sep 4 00:07:33 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 4 Sep 2018 01:07:33 +0100 Subject: Is JavaFX going to truly be a community project? In-Reply-To: <17D927CC-4C81-449A-B4C7-986F61CA205A@gmail.com> References: <17D927CC-4C81-449A-B4C7-986F61CA205A@gmail.com> Message-ID: .. my point is such a project backed by only one company is possibly not enough. Unless that company is Microsoft, Google, Facebook or even Oracle. Xamarin and React Native, both cross platform frameworks, are more popular than JavaFX and are each owned by Microsoft and Facebook, respectively. My thinking is that we need more developers working on JavaFX (JavaFX framework, JavaFX third party libraries) than are currently available. And that the way JavaFX is currently setup doesn't probably invite other companies to join in on the effort. It does not increase the feeling of "community-ness" either. I think it's not the right message to the outside. I agree with Mike that a website is needed but I think that's another discussion not related to the one in this thread. My 2 cents, On Mon, Sep 3, 2018 at 12:26 AM John-Val Rose wrote: > Mike, can you explain what you mean by a ?JavaFX website?? > > > On 3 Sep 2018, at 02:59, Mike Hearn wrote: > > > > I believe you're over-thinking this Pedro. A quote from Margaret Thatcher > > springs to mind: > > > > "They are casting their problems on society and who is society? There is > no > >> such thing! There are individual men and women and there are families > and > >> no government can do anything except through people and people look to > >> themselves first." > > > > > > Her point was that when someone says "the community should do this", > that's > > an abstraction - the community is nothing more than people, sometimes > > individuals and sometimes organised into companies. Gluon and Oracle are > > both clearly critical parts of the JavaFX community and that's a good > > thing. I'm not sure why it would be off-putting. After all, JavaFX is > based > > on Java and the Java community is mostly made of companies too (Oracle, > Red > > Hat, Intel, Azul etc). > > > > Perhaps the JavaFX community will get more organised with time - I > believe > > the "community-ness" feeling would be significantly enhanced with simple > > things like a JavaFX website. Perhaps you can contribute such a thing, as > > it would not involve core JavaFX hacking? > -- Pedro Duque Vieira - https://www.pixelduke.com From johan.vos at gluonhq.com Tue Sep 4 07:01:59 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 4 Sep 2018 09:01:59 +0200 Subject: JavaFX website Message-ID: It has been mentioned a number of times that JavaFX would benefit from a JavaFX website. I see a number of options that fall in the category website: 1. A set of pages with details on what OpenJFX is, how to build, where to download and get release notes, how to contribute, roadmap,... That is what I believe can perfectly be done in the OpenJFX wiki. It can be the reference manual 2. A set of pages targeting new and existing JavaFX developers, with a focus on where to download, how to get started (maven/gradle/IDE's), where to get docs/tutorials and probably with some links to third party libraries (free/commercial). This is sort of the user manual. 3. A highly interactive community site, gathering tweets/blog posts etc, more or less similar to what James Weaver and Gerrit Grunwald did years ago. For 1: I think this is up to us (OpenJFX committers) to maintain and improve. It will also benefit the people here. For 2: This is the most important thing, I believe. It would be great if a number of people from this list step up to organize this. It can be a static website, a github page, or anything else. I don't think this strictly belongs under OpenJFX (which I consider to be the technical development umbrella) but it's extremely important to have. I think this is a perfect opportunity for people and companies who want to get more active in JavaFX to get involved in. For 3: That would be nice, but I think it's too ambitious for now. I would be happy with a static, simple, clear website. - Johan From mnachev.nscenter.eu at gmail.com Tue Sep 4 07:13:35 2018 From: mnachev.nscenter.eu at gmail.com (Miroslav Nachev) Date: Tue, 4 Sep 2018 10:13:35 +0300 Subject: JavaFX website In-Reply-To: References: Message-ID: 4. Online demonstration of graphical controls and other capabilities - basic and extra from the community. On Tue, Sep 4, 2018 at 10:02 AM Johan Vos wrote: > It has been mentioned a number of times that JavaFX would benefit from a > JavaFX website. > I see a number of options that fall in the category website: > > 1. A set of pages with details on what OpenJFX is, how to build, where to > download and get release notes, how to contribute, roadmap,... That is what > I believe can perfectly be done in the OpenJFX wiki. It can be the > reference manual > > 2. A set of pages targeting new and existing JavaFX developers, with a > focus on where to download, how to get started (maven/gradle/IDE's), where > to get docs/tutorials and probably with some links to third party libraries > (free/commercial). This is sort of the user manual. > > 3. A highly interactive community site, gathering tweets/blog posts etc, > more or less similar to what James Weaver and Gerrit Grunwald did years > ago. > > For 1: I think this is up to us (OpenJFX committers) to maintain and > improve. It will also benefit the people here. > > For 2: This is the most important thing, I believe. It would be great if a > number of people from this list step up to organize this. It can be a > static website, a github page, or anything else. I don't think this > strictly belongs under OpenJFX (which I consider to be the technical > development umbrella) but it's extremely important to have. > I think this is a perfect opportunity for people and companies who want to > get more active in JavaFX to get involved in. > > For 3: That would be nice, but I think it's too ambitious for now. I would > be happy with a static, simple, clear website. > > - Johan > From mike.ennen at gmail.com Tue Sep 4 07:16:52 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Tue, 4 Sep 2018 00:16:52 -0700 Subject: JavaFX website In-Reply-To: References: Message-ID: Johan, I just wanted to remind you (and everyone) that Github offers a Wiki feature so we have a nice way to house at least some documentation (probably mostly related to actually working on OpenJFX itself) already. I think 3.) is somewhat pie-in-the-sky and it is my humble opinion that time would be better spent documenting for other prospective developer's how we (the contributors) actually work on JavaFX. How do we set up IDEs, configure build systems, debug native code, etc. etc. I am trying to make setting up a local dev environment as painless as possible on Windows for working on JavaFX and there is a tie-in to that effort with having Appveyor scripts that share the same build/setup logic. I have made some progress thereof, I want to make more. Cheers, Michael Ennen On Tue, Sep 4, 2018 at 12:02 AM Johan Vos wrote: > It has been mentioned a number of times that JavaFX would benefit from a > JavaFX website. > I see a number of options that fall in the category website: > > 1. A set of pages with details on what OpenJFX is, how to build, where to > download and get release notes, how to contribute, roadmap,... That is what > I believe can perfectly be done in the OpenJFX wiki. It can be the > reference manual > > 2. A set of pages targeting new and existing JavaFX developers, with a > focus on where to download, how to get started (maven/gradle/IDE's), where > to get docs/tutorials and probably with some links to third party libraries > (free/commercial). This is sort of the user manual. > > 3. A highly interactive community site, gathering tweets/blog posts etc, > more or less similar to what James Weaver and Gerrit Grunwald did years > ago. > > For 1: I think this is up to us (OpenJFX committers) to maintain and > improve. It will also benefit the people here. > > For 2: This is the most important thing, I believe. It would be great if a > number of people from this list step up to organize this. It can be a > static website, a github page, or anything else. I don't think this > strictly belongs under OpenJFX (which I consider to be the technical > development umbrella) but it's extremely important to have. > I think this is a perfect opportunity for people and companies who want to > get more active in JavaFX to get involved in. > > For 3: That would be nice, but I think it's too ambitious for now. I would > be happy with a static, simple, clear website. > > - Johan > From guy.abossolo.foh at scientificware.com Tue Sep 4 07:23:54 2018 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Tue, 04 Sep 2018 09:23:54 +0200 Subject: JavaFX website In-Reply-To: References: Message-ID: <660b6c7baaaf3ff36e4d9f696a4d5966@scientificware.com> Hi Michael, Could everybody access to the Wiki and modify it ? Guy. -------------------------------- Le 2018-09-04 9:16, Michael Ennen a ?crit?: > Johan, > > I just wanted to remind you (and everyone) that Github offers a Wiki > feature > so we have a nice way to house at least some documentation (probably > mostly > related to actually working on OpenJFX itself) already. > > I think 3.) is somewhat pie-in-the-sky and it is my humble opinion that > time > would be better spent documenting for other prospective developer's how > we (the contributors) actually work on JavaFX. How do we set up IDEs, > configure build systems, debug native code, etc. etc. > > I am trying to make setting up a local dev environment as painless > as possible on Windows for working on JavaFX and there is a tie-in > to that effort with having Appveyor scripts that share the same > build/setup > logic. I have made some progress thereof, I want to make more. > > Cheers, > Michael Ennen > > On Tue, Sep 4, 2018 at 12:02 AM Johan Vos > wrote: > >> It has been mentioned a number of times that JavaFX would benefit from >> a >> JavaFX website. >> I see a number of options that fall in the category website: >> >> 1. A set of pages with details on what OpenJFX is, how to build, where >> to >> download and get release notes, how to contribute, roadmap,... That is >> what >> I believe can perfectly be done in the OpenJFX wiki. It can be the >> reference manual >> >> 2. A set of pages targeting new and existing JavaFX developers, with a >> focus on where to download, how to get started (maven/gradle/IDE's), >> where >> to get docs/tutorials and probably with some links to third party >> libraries >> (free/commercial). This is sort of the user manual. >> >> 3. A highly interactive community site, gathering tweets/blog posts >> etc, >> more or less similar to what James Weaver and Gerrit Grunwald did >> years >> ago. >> >> For 1: I think this is up to us (OpenJFX committers) to maintain and >> improve. It will also benefit the people here. >> >> For 2: This is the most important thing, I believe. It would be great >> if a >> number of people from this list step up to organize this. It can be a >> static website, a github page, or anything else. I don't think this >> strictly belongs under OpenJFX (which I consider to be the technical >> development umbrella) but it's extremely important to have. >> I think this is a perfect opportunity for people and companies who >> want to >> get more active in JavaFX to get involved in. >> >> For 3: That would be nice, but I think it's too ambitious for now. I >> would >> be happy with a static, simple, clear website. >> >> - Johan >> -- Abossolo Foh Guy 71 rue Guy de Maupassant 69500 Bron 06 87 01 82 27 04 72 81 89 46 From nlisker at gmail.com Tue Sep 4 08:18:01 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 4 Sep 2018 11:18:01 +0300 Subject: JavaFX website In-Reply-To: References: Message-ID: 1. Yes. The OpenJFX wiki is editable only by specific people (or only Kevin) and it requires a lot of updating. We need either to be able to submit changes to it, or to use the GitHub wiki which is collaborative by design, in which case we need to hide the OpenJFX wiki to avoid confusion. 2. Yes. The tutorials [1] are slightly outdated (and SceneBuilder should disappear from there ASAP and point to Gluon). I don't know who controls those pages. 3. No. There's not enough traction. Jonathan Giles collects some "links of the week" and the semi-zombified /r/JavaFX subreddit is enough to indicate that we shouldn't invest yet in this direction. [1] https://docs.oracle.com/javase/8/javase-clienttechnologies.htm - Nir On Tue, Sep 4, 2018 at 10:02 AM Johan Vos wrote: > It has been mentioned a number of times that JavaFX would benefit from a > JavaFX website. > I see a number of options that fall in the category website: > > 1. A set of pages with details on what OpenJFX is, how to build, where to > download and get release notes, how to contribute, roadmap,... That is what > I believe can perfectly be done in the OpenJFX wiki. It can be the > reference manual > > 2. A set of pages targeting new and existing JavaFX developers, with a > focus on where to download, how to get started (maven/gradle/IDE's), where > to get docs/tutorials and probably with some links to third party libraries > (free/commercial). This is sort of the user manual. > > 3. A highly interactive community site, gathering tweets/blog posts etc, > more or less similar to what James Weaver and Gerrit Grunwald did years > ago. > > For 1: I think this is up to us (OpenJFX committers) to maintain and > improve. It will also benefit the people here. > > For 2: This is the most important thing, I believe. It would be great if a > number of people from this list step up to organize this. It can be a > static website, a github page, or anything else. I don't think this > strictly belongs under OpenJFX (which I consider to be the technical > development umbrella) but it's extremely important to have. > I think this is a perfect opportunity for people and companies who want to > get more active in JavaFX to get involved in. > > For 3: That would be nice, but I think it's too ambitious for now. I would > be happy with a static, simple, clear website. > > - Johan > From pedro.duquevieira at gmail.com Tue Sep 4 12:27:03 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 4 Sep 2018 13:27:03 +0100 Subject: JavaFX website Message-ID: I can volunteer to build or help build such a site. I think such a site should have examples of apps built with JavaFX or/and big well known companies using JavaFX to build apps. For example we can say that NASA uses JavaFX or at least that NASA uses software built with JavaFX (just an example). Electron, React Native, Xamarin have this on their website. I think it acts a bit like the movie scores on sites like IMDB that you check out before actually seeing the movie to know if the movie is any good. It shows proof that you can build real, well working apps with JavaFX. If reputable companies use it or reputable software has been built with it then it should be good. Another point: If the site is to have a highly interactive component with list of third party libraries, tweets, blog posts, etc. Then it needs to be actively maintained or we risk passing down the message that the technology is dead. If all those links are old, obsolete or broken or the user sees that no new content has been added in a while, he may assume the technology isn't being maintained. So if we add this we need to make sure it can in fact be actively maintained. One other question I'd like to raise is the domain. What domain should we use? Cheers, -- Pedro Duque Vieira - https://www.pixelduke.com From kevin.rushforth at oracle.com Tue Sep 4 12:48:50 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 4 Sep 2018 05:48:50 -0700 Subject: JavaFX website In-Reply-To: References: Message-ID: <01e78bff-2599-9588-0572-8ed2a73702ba@oracle.com> 1. The OpenJFX Wiki on openjdk.java.net is ideal for maintaining pages related to the Project itself. This can be supplemented by other Wikis. As for access, any OpenJFX Project Author (or Committer) can have write access to the Wiki. Just let me know if you want access, but it isn't activated yet. 2. This is where the community could really help as noted by Johan and others. The tutorials are indeed out of date. If you want to file a JBS bug and assign it to me, I can see what needs to be done to either correct (if simple) or archive pages that are so out of date as to be useless (or worse, misleading). -- Kevin On 9/4/2018 1:18 AM, Nir Lisker wrote: > 1. Yes. The OpenJFX wiki is editable only by specific people (or only > Kevin) and it requires a lot of updating. We need either to be able to > submit changes to it, or to use the GitHub wiki which is collaborative by > design, in which case we need to hide the OpenJFX wiki to avoid confusion. > > 2. Yes. The tutorials [1] are slightly outdated (and SceneBuilder should > disappear from there ASAP and point to Gluon). I don't know who controls > those pages. > > 3. No. There's not enough traction. Jonathan Giles collects some "links of > the week" and the semi-zombified /r/JavaFX subreddit is enough to indicate > that we shouldn't invest yet in this direction. > > [1] https://docs.oracle.com/javase/8/javase-clienttechnologies.htm > > - Nir > > On Tue, Sep 4, 2018 at 10:02 AM Johan Vos wrote: > >> It has been mentioned a number of times that JavaFX would benefit from a >> JavaFX website. >> I see a number of options that fall in the category website: >> >> 1. A set of pages with details on what OpenJFX is, how to build, where to >> download and get release notes, how to contribute, roadmap,... That is what >> I believe can perfectly be done in the OpenJFX wiki. It can be the >> reference manual >> >> 2. A set of pages targeting new and existing JavaFX developers, with a >> focus on where to download, how to get started (maven/gradle/IDE's), where >> to get docs/tutorials and probably with some links to third party libraries >> (free/commercial). This is sort of the user manual. >> >> 3. A highly interactive community site, gathering tweets/blog posts etc, >> more or less similar to what James Weaver and Gerrit Grunwald did years >> ago. >> >> For 1: I think this is up to us (OpenJFX committers) to maintain and >> improve. It will also benefit the people here. >> >> For 2: This is the most important thing, I believe. It would be great if a >> number of people from this list step up to organize this. It can be a >> static website, a github page, or anything else. I don't think this >> strictly belongs under OpenJFX (which I consider to be the technical >> development umbrella) but it's extremely important to have. >> I think this is a perfect opportunity for people and companies who want to >> get more active in JavaFX to get involved in. >> >> For 3: That would be nice, but I think it's too ambitious for now. I would >> be happy with a static, simple, clear website. >> >> - Johan >> From johan.vos at gluonhq.com Tue Sep 4 13:31:15 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 4 Sep 2018 15:31:15 +0200 Subject: webkit feedback calls on failure Message-ID: The WebEngine already allows to get information about the progress of the underlying webkit via the onError() handler and the getLoadWorker() status updates. However, there are a number of cases where things go wrong in webkit, yet the status of the loadWorker is SUCCEEDED and no WebErrorEvent is generated. A simple case is where a small html page loads a large image. In this case, URLLoader will call twkDidFinishLoading() which is a native call, which in turn will invoke ImageDecoderJava.cpp::setData This call will invoke WCImageDecoderImpl.addImageData (back in the java layer), but when that throws a throwable (which it does, an OOME in resizeDataArray), it will ignore it by calling CheckAndClearException (in ImageDecoderJava.cpp) and the information about the exception is lost (that is, env->ExceptionDescribe() is called which will print thread + exception, but that's it). Hence, at this moment it seems impossible to detect a failure when large images are loaded. While the status of the loadWorker will move to SUCCEEDED, the image won't be shown. There are a number of ways to improve this, so if it is agreed that this can be an enhancement, I'll file an issue for it. - Johan From johan.vos at gluonhq.com Tue Sep 4 13:52:39 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 4 Sep 2018 15:52:39 +0200 Subject: Review request for 8210359 Message-ID: Please review webrev http://cr.openjdk.java.net/~jvos/8210359/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8210359 (this allows to build OpenJFX SDK on platforms that don't include Swing, e.g. armv6hf) From nlisker at gmail.com Tue Sep 4 13:54:27 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 4 Sep 2018 16:54:27 +0300 Subject: JavaFX website In-Reply-To: <01e78bff-2599-9588-0572-8ed2a73702ba@oracle.com> References: <01e78bff-2599-9588-0572-8ed2a73702ba@oracle.com> Message-ID: 1. I would like access, thanks. I'll be able to update the Eclipse instructions and some of the Windows build instructions. 2. I submitted https://bugs.openjdk.java.net/browse/JDK-8210360. It's going to take a large effort to go over every page there and see what needs changing. If enough people join the task we could (and should) have it updated for openjfx12. On Tue, Sep 4, 2018 at 3:49 PM Kevin Rushforth wrote: > 1. The OpenJFX Wiki on openjdk.java.net is ideal for maintaining pages > related to the Project itself. This can be supplemented by other Wikis. > As for access, any OpenJFX Project Author (or Committer) can have write > access to the Wiki. Just let me know if you want access, but it isn't > activated yet. > > 2. This is where the community could really help as noted by Johan and > others. The tutorials are indeed out of date. If you want to file a JBS > bug and assign it to me, I can see what needs to be done to either > correct (if simple) or archive pages that are so out of date as to be > useless (or worse, misleading). > > -- Kevin > > > > On 9/4/2018 1:18 AM, Nir Lisker wrote: > > 1. Yes. The OpenJFX wiki is editable only by specific people (or only > > Kevin) and it requires a lot of updating. We need either to be able to > > submit changes to it, or to use the GitHub wiki which is collaborative by > > design, in which case we need to hide the OpenJFX wiki to avoid > confusion. > > > > 2. Yes. The tutorials [1] are slightly outdated (and SceneBuilder should > > disappear from there ASAP and point to Gluon). I don't know who controls > > those pages. > > > > 3. No. There's not enough traction. Jonathan Giles collects some "links > of > > the week" and the semi-zombified /r/JavaFX subreddit is enough to > indicate > > that we shouldn't invest yet in this direction. > > > > [1] https://docs.oracle.com/javase/8/javase-clienttechnologies.htm > > > > - Nir > > > > On Tue, Sep 4, 2018 at 10:02 AM Johan Vos wrote: > > > >> It has been mentioned a number of times that JavaFX would benefit from a > >> JavaFX website. > >> I see a number of options that fall in the category website: > >> > >> 1. A set of pages with details on what OpenJFX is, how to build, where > to > >> download and get release notes, how to contribute, roadmap,... That is > what > >> I believe can perfectly be done in the OpenJFX wiki. It can be the > >> reference manual > >> > >> 2. A set of pages targeting new and existing JavaFX developers, with a > >> focus on where to download, how to get started (maven/gradle/IDE's), > where > >> to get docs/tutorials and probably with some links to third party > libraries > >> (free/commercial). This is sort of the user manual. > >> > >> 3. A highly interactive community site, gathering tweets/blog posts etc, > >> more or less similar to what James Weaver and Gerrit Grunwald did years > >> ago. > >> > >> For 1: I think this is up to us (OpenJFX committers) to maintain and > >> improve. It will also benefit the people here. > >> > >> For 2: This is the most important thing, I believe. It would be great > if a > >> number of people from this list step up to organize this. It can be a > >> static website, a github page, or anything else. I don't think this > >> strictly belongs under OpenJFX (which I consider to be the technical > >> development umbrella) but it's extremely important to have. > >> I think this is a perfect opportunity for people and companies who want > to > >> get more active in JavaFX to get involved in. > >> > >> For 3: That would be nice, but I think it's too ambitious for now. I > would > >> be happy with a static, simple, clear website. > >> > >> - Johan > >> > > From kevin.rushforth at oracle.com Tue Sep 4 14:07:58 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 4 Sep 2018 07:07:58 -0700 Subject: Review request for 8210359 In-Reply-To: References: Message-ID: <95fa91f0-0877-676e-42c3-96499b58b442@oracle.com> I reviewed/approved on GitHub. -- Kevin On 9/4/2018 6:52 AM, Johan Vos wrote: > Please review webrev http://cr.openjdk.java.net/~jvos/8210359/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8210359 > > (this allows to build OpenJFX SDK on platforms that don't include Swing, > e.g. armv6hf) From julianjupiter.io at gmail.com Tue Sep 4 14:56:20 2018 From: julianjupiter.io at gmail.com (Julian Jupiter) Date: Tue, 4 Sep 2018 22:56:20 +0800 Subject: JavaFX website In-Reply-To: References: <01e78bff-2599-9588-0572-8ed2a73702ba@oracle.com> Message-ID: Hi all, I wish JavaFX could have a site that is similar to those of PrimeFaces or Bootstrap and other similar sites. They have a comprehensive pages for different components that even a new user or student can easily follow and try out. Thank you. Julez On Tue, Sep 4, 2018, 9:55 PM Nir Lisker, wrote: > 1. I would like access, thanks. I'll be able to update the Eclipse > instructions and some of the Windows build instructions. > > 2. I submitted https://bugs.openjdk.java.net/browse/JDK-8210360. It's > going > to take a large effort to go over every page there and see what needs > changing. If enough people join the task we could (and should) have it > updated for openjfx12. > > On Tue, Sep 4, 2018 at 3:49 PM Kevin Rushforth > > wrote: > > > 1. The OpenJFX Wiki on openjdk.java.net is ideal for maintaining pages > > related to the Project itself. This can be supplemented by other Wikis. > > As for access, any OpenJFX Project Author (or Committer) can have write > > access to the Wiki. Just let me know if you want access, but it isn't > > activated yet. > > > > 2. This is where the community could really help as noted by Johan and > > others. The tutorials are indeed out of date. If you want to file a JBS > > bug and assign it to me, I can see what needs to be done to either > > correct (if simple) or archive pages that are so out of date as to be > > useless (or worse, misleading). > > > > -- Kevin > > > > > > > > On 9/4/2018 1:18 AM, Nir Lisker wrote: > > > 1. Yes. The OpenJFX wiki is editable only by specific people (or only > > > Kevin) and it requires a lot of updating. We need either to be able to > > > submit changes to it, or to use the GitHub wiki which is collaborative > by > > > design, in which case we need to hide the OpenJFX wiki to avoid > > confusion. > > > > > > 2. Yes. The tutorials [1] are slightly outdated (and SceneBuilder > should > > > disappear from there ASAP and point to Gluon). I don't know who > controls > > > those pages. > > > > > > 3. No. There's not enough traction. Jonathan Giles collects some "links > > of > > > the week" and the semi-zombified /r/JavaFX subreddit is enough to > > indicate > > > that we shouldn't invest yet in this direction. > > > > > > [1] https://docs.oracle.com/javase/8/javase-clienttechnologies.htm > > > > > > - Nir > > > > > > On Tue, Sep 4, 2018 at 10:02 AM Johan Vos > wrote: > > > > > >> It has been mentioned a number of times that JavaFX would benefit > from a > > >> JavaFX website. > > >> I see a number of options that fall in the category website: > > >> > > >> 1. A set of pages with details on what OpenJFX is, how to build, where > > to > > >> download and get release notes, how to contribute, roadmap,... That is > > what > > >> I believe can perfectly be done in the OpenJFX wiki. It can be the > > >> reference manual > > >> > > >> 2. A set of pages targeting new and existing JavaFX developers, with a > > >> focus on where to download, how to get started (maven/gradle/IDE's), > > where > > >> to get docs/tutorials and probably with some links to third party > > libraries > > >> (free/commercial). This is sort of the user manual. > > >> > > >> 3. A highly interactive community site, gathering tweets/blog posts > etc, > > >> more or less similar to what James Weaver and Gerrit Grunwald did > years > > >> ago. > > >> > > >> For 1: I think this is up to us (OpenJFX committers) to maintain and > > >> improve. It will also benefit the people here. > > >> > > >> For 2: This is the most important thing, I believe. It would be great > > if a > > >> number of people from this list step up to organize this. It can be a > > >> static website, a github page, or anything else. I don't think this > > >> strictly belongs under OpenJFX (which I consider to be the technical > > >> development umbrella) but it's extremely important to have. > > >> I think this is a perfect opportunity for people and companies who > want > > to > > >> get more active in JavaFX to get involved in. > > >> > > >> For 3: That would be nice, but I think it's too ambitious for now. I > > would > > >> be happy with a static, simple, clear website. > > >> > > >> - Johan > > >> > > > > > From kevin.rushforth at oracle.com Tue Sep 4 16:27:06 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 4 Sep 2018 09:27:06 -0700 Subject: JavaFX website In-Reply-To: References: <01e78bff-2599-9588-0572-8ed2a73702ba@oracle.com> Message-ID: <71094b1f-f064-f8d5-b426-d19246521806@oracle.com> On 9/4/2018 6:54 AM, Nir Lisker wrote: > 1. I would like access, thanks. I'll be able to update the Eclipse > instructions and some of the Windows build instructions. You should have access now. > 2. I submitted https://bugs.openjdk.java.net/browse/JDK-8210360. Thanks. > It's going to take a large effort to go over every page there and see > what needs changing. If enough people join the task we could (and > should) have it updated for openjfx12. I'm not sure that going over every page and suggesting updates would work well. At least not unless we are able to open-source them (I have started that conversation internally) and host them somewhere else (maybe on the Wiki or maybe checked into the openjfx repo or some other repo). For the pages on the OTN site, the best we can hope for as far as updating these tutorial pages is to fix or remove anything that is egregiously wrong (e.g., the SceneBuilder docs), and also have a pointer to the OpenJFX Project page / Wiki for newer docs -- at least that way someone who visits that page could find more up-to-date docs. Btw, since we still support JDK 8u, we can't for example, remove the Deployment section, so some old / out-of-date docs need to remain. -- Kevin > On Tue, Sep 4, 2018 at 3:49 PM Kevin Rushforth > > wrote: > > 1. The OpenJFX Wiki on openjdk.java.net > is ideal for maintaining pages > related to the Project itself. This can be supplemented by other > Wikis. > As for access, any OpenJFX Project Author (or Committer) can have > write > access to the Wiki. Just let me know if you want access, but it isn't > activated yet. > > 2. This is where the community could really help as noted by Johan > and > others. The tutorials are indeed out of date. If you want to file > a JBS > bug and assign it to me, I can see what needs to be done to either > correct (if simple) or archive pages that are so out of date as to be > useless (or worse, misleading). > > -- Kevin > > > > On 9/4/2018 1:18 AM, Nir Lisker wrote: > > 1.? Yes. The OpenJFX wiki is editable only by specific people > (or only > > Kevin) and it requires a lot of updating. We need either to be > able to > > submit changes to it, or to use the GitHub wiki which is > collaborative by > > design, in which case we need to hide the OpenJFX wiki to avoid > confusion. > > > > 2. Yes. The tutorials [1] are slightly outdated (and > SceneBuilder should > > disappear from there ASAP and point to Gluon). I don't know who > controls > > those pages. > > > > 3. No. There's not enough traction. Jonathan Giles collects some > "links of > > the week" and the semi-zombified /r/JavaFX subreddit is enough > to indicate > > that we shouldn't invest yet in this direction. > > > > [1] https://docs.oracle.com/javase/8/javase-clienttechnologies.htm > > > > - Nir > > > > On Tue, Sep 4, 2018 at 10:02 AM Johan Vos > wrote: > > > >> It has been mentioned a number of times that JavaFX would > benefit from a > >> JavaFX website. > >> I see a number of options that fall in the category website: > >> > >> 1. A set of pages with details on what OpenJFX is, how to > build, where to > >> download and get release notes, how to contribute, roadmap,... > That is what > >> I believe can perfectly be done in the OpenJFX wiki. It can be the > >> reference manual > >> > >> 2. A set of pages targeting new and existing JavaFX developers, > with a > >> focus on where to download, how to get started > (maven/gradle/IDE's), where > >> to get docs/tutorials and probably with some links to third > party libraries > >> (free/commercial). This is sort of the user manual. > >> > >> 3. A highly interactive community site, gathering tweets/blog > posts etc, > >> more or less similar to what James Weaver and Gerrit Grunwald > did years > >> ago. > >> > >> For 1: I think this is up to us (OpenJFX committers) to > maintain and > >> improve. It will also benefit the people here. > >> > >> For 2: This is the most important thing, I believe. It would be > great if a > >> number of people from this list step up to organize this. It > can be a > >> static website, a github page, or anything else. I don't think this > >> strictly belongs under OpenJFX (which I consider to be the > technical > >> development umbrella) but it's extremely important to have. > >> I think this is a perfect opportunity for people and companies > who want to > >> get more active in JavaFX to get involved in. > >> > >> For 3: That would be nice, but I think it's too ambitious for > now. I would > >> be happy with a static, simple, clear website. > >> > >> - Johan > >> > From arunprasad.rajkumar at oracle.com Wed Sep 5 05:37:15 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 5 Sep 2018 11:07:15 +0530 Subject: [RFR] [openjfx12] 8148129: Implement Accelerated composition for WebView In-Reply-To: References: Message-ID: <54D53345-3ADC-44A4-89A1-4EBB9FDE8257@oracle.com> It is been merged with develop branch[1]. I?m planning to merge the patch to jfx-dev[2] mercurial branch as well. [1] https://github.com/javafxports/openjdk-jfx/commit/9d16a90f2a3b79622ea834d9b5a0e1ed9f2779dc [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt Thanks, Arun > On 25-Aug-2018, at 12:25 PM, Arunprasad Rajkumar wrote: > > Hi, > > Please review the patch for following enhancement, it is targeted for openjfx12. > > https://bugs.openjdk.java.net/browse/JDK-8148129 > > Changes are available as gihub PR, refer the following link, > > https://github.com/javafxports/openjdk-jfx/pull/51 > > Unified diff is available in the following link, > > https://github.com/javafxports/openjdk-jfx/pull/51.diff > > Thanks, > Arun From arunprasad.rajkumar at oracle.com Wed Sep 5 10:12:13 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 5 Sep 2018 15:42:13 +0530 Subject: webkit feedback calls on failure In-Reply-To: References: Message-ID: <95C1CEE7-AE76-4DFA-A892-04678B8F6407@oracle.com> Hi Johan, Thanks for reporting this. I agree, there are few areas which needs improvement in WebView component, error handling is one among them. Please file a bug. Regards, Arun > On 04-Sep-2018, at 7:01 PM, Johan Vos wrote: > > The WebEngine already allows to get information about the progress of the > underlying webkit via the onError() handler and the getLoadWorker() status > updates. > > However, there are a number of cases where things go wrong in webkit, yet > the status of the loadWorker is SUCCEEDED and no WebErrorEvent is generated. > > A simple case is where a small html page loads a large image. In this case, > URLLoader will call twkDidFinishLoading() which is a native call, which in > turn will invoke ImageDecoderJava.cpp::setData > > This call will invoke > WCImageDecoderImpl.addImageData (back in the java layer), but when that > throws a throwable (which it does, an OOME in resizeDataArray), it will > ignore it by calling CheckAndClearException (in ImageDecoderJava.cpp) and > the information about the exception is lost (that > is, env->ExceptionDescribe() is called which will print thread + exception, > but that's it). > > Hence, at this moment it seems impossible to detect a failure when large > images are loaded. While the status of the loadWorker will move to > SUCCEEDED, the image won't be shown. > > There are a number of ways to improve this, so if it is agreed that this > can be an enhancement, I'll file an issue for it. > > - Johan From arunprasad.rajkumar at oracle.com Wed Sep 5 12:29:59 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 5 Sep 2018 17:59:59 +0530 Subject: [RFR] 8210218: WebKit build fails with newer versions of VS 2017 Message-ID: <03234AFB-41A8-4C1F-81AA-2399882E15D5@oracle.com> Hi Kevin, Johan, Please review the following PR. https://github.com/javafxports/openjdk-jfx/pull/200 Thanks, Arun From kevin.rushforth at oracle.com Wed Sep 5 13:00:40 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 5 Sep 2018 06:00:40 -0700 Subject: [RFR] [openjfx12] 8148129: Implement Accelerated composition for WebView In-Reply-To: <54D53345-3ADC-44A4-89A1-4EBB9FDE8257@oracle.com> References: <54D53345-3ADC-44A4-89A1-4EBB9FDE8257@oracle.com> Message-ID: <8e10501d-ed90-be02-220c-7c8392465816@oracle.com> Thanks for the heads-up. -- Kevin On 9/4/2018 10:37 PM, Arunprasad Rajkumar wrote: > It is been merged with develop branch[1]. I?m planning to merge the patch to jfx-dev[2] mercurial branch as well. > > [1] https://github.com/javafxports/openjdk-jfx/commit/9d16a90f2a3b79622ea834d9b5a0e1ed9f2779dc > [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt > > Thanks, > Arun > > >> On 25-Aug-2018, at 12:25 PM, Arunprasad Rajkumar wrote: >> >> Hi, >> >> Please review the patch for following enhancement, it is targeted for openjfx12. >> >> https://bugs.openjdk.java.net/browse/JDK-8148129 >> >> Changes are available as gihub PR, refer the following link, >> >> https://github.com/javafxports/openjdk-jfx/pull/51 >> >> Unified diff is available in the following link, >> >> https://github.com/javafxports/openjdk-jfx/pull/51.diff >> >> Thanks, >> Arun From kevin.rushforth at oracle.com Thu Sep 6 12:26:26 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 6 Sep 2018 05:26:26 -0700 Subject: HEADS-UP: Updating minimum boot JDK to 11 for OpenJFX 12 Message-ID: <75c29911-f9d7-a349-a7ec-a5c560dfabc7@oracle.com> As a heads-up, the following issue is in progress for OpenJFX 12: https://bugs.openjdk.java.net/browse/JDK-8209966 https://github.com/javafxports/openjdk-jfx/pull/174 This will bump the minimum boot JDK version to JDK 11 for building and testing OpenJFX 12. Note that this will *not* affect OpenJFX 11 in any way. This will enable a few follow-on issues to be done: 1. Stop redistributing Microsoft DLLs :: JDK-8210089 [1] 2. Remove old javafx.swing implementation :: JDK-8210092 [2] 3. Build with --source 11 and --target 11 :: JDK-8210093 [3] as well making some additional cleanup of the build possible. Before sending it out for formal review, I wanted to give everyone a heads-up that this is coming, so you can prepare for it. For the timing of this, my plan was to wait until the final version of JDK 11 is released. We probably could do it a week or two ahead of the final release to unblock work on the follow-on issues, depending on what the rest of the people who build OpenJFX from source think. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8210089 [2] https://bugs.openjdk.java.net/browse/JDK-8210092 [3] https://bugs.openjdk.java.net/browse/JDK-8210093 From amnojeeuw at gmail.com Thu Sep 6 22:21:33 2018 From: amnojeeuw at gmail.com (AmnoJeeuw) Date: Thu, 6 Sep 2018 18:21:33 -0400 Subject: SQLiteJava Message-ID: <72904f60-3530-1eeb-4de2-89ccdef52906@gmail.com> I have a database table named company that looks like this: snapshot2 When the application is asked to change the value of ArbolOne to ArbolOn, db_snapshot1 the application generates the following schema represented on this message box: db_snapshot3 which produces this Exception error: db_snapshot4 I am attaching a snip of the code, in case you'd like to know it. Having said that, I'd like to know if this is a bug or if I have not understand the information found in here . Any help would be much appreciated. -- ArbolOne Using Fire Fox and Thunderbird. Developing using Java, C/C++, HTM/CSS and JS as our platform has been exciting and most rewarding. [ S? ] -------------- next part -------------- public class ToDataBase extends CenizaDatabaseManager { /** * Update a record from the database * ...... */ public void updateRecord(ArrayList relation) throws SQLException { @SuppressWarnings("unused") MessageBox mb = new MessageBox(); try { this.schema.delete(0, schema.length()); this.schema.append("UPDATE "); this.schema.append(relation.get(2).toString()); // Table name this.schema.append(" SET "); this.schema.append(relation.get(3).toString()); // Column name this.schema.append("="); this.schema.append(relation.get(4)); // new data this.schema.append(", "); this.schema.append("WHERE id "); this.schema.append(relation.get(1).toString()); // Primary Key mb.Show("Debugging", "ToDataBase.updateRecord(...)", schema.toString()); System.out.println("and the \'schema\' is " + schema); this.stmt.executeUpdate(this.schema.toString()); //<-- Exception ?? } catch (final /*SQL*/Exception e) { mb.Show("Debugging", "Error message: " + e.getMessage()); } } }// End of Class From kevin.rushforth at oracle.com Thu Sep 6 22:52:20 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 6 Sep 2018 15:52:20 -0700 Subject: SQLiteJava In-Reply-To: <72904f60-3530-1eeb-4de2-89ccdef52906@gmail.com> References: <72904f60-3530-1eeb-4de2-89ccdef52906@gmail.com> Message-ID: [Bcc'ing the openjfx-dev list] I see no indication that there is anything relating to JavaFX in your question, so there seems to be no need to include the openjfx-dev list. -- Kevin On 9/6/2018 3:21 PM, AmnoJeeuw wrote: > I have a database table named company that looks like this: > > snapshot2 > > > When the application is asked to change the value of ArbolOne to ArbolOn, > > db_snapshot1 > > > the application generates the following schema represented on this > message box: > db_snapshot3 > > > which produces this Exception error: > db_snapshot4 > > > I am attaching a snip of the code, in case you'd like to know it. > Having said that, I'd like to know if this is a bug or if I have not > understand the information found in here > . > > Any help would be much appreciated. > From amnojeeuw at gmail.com Thu Sep 6 23:47:41 2018 From: amnojeeuw at gmail.com (AmnoJeeuw) Date: Thu, 6 Sep 2018 19:47:41 -0400 Subject: which technology should give preference Message-ID: <68b63bbb-e3ef-84a3-ca76-72875fdbedc0@gmail.com> I am learning hands-on how to program using JavaFX and in the process doing so I?ve come across FXML; which I find most interesting. Since the principal is ?Think hand held device first? -TH2DF, my intention is to port the my future application to Android device, but I am concerned that there will be too many issues when doing that. So, my question is, which technology should give preference to, JavaFX or FXML? Please, keep in mind that I am using a Windows 8.1 machine and Eclipse-Photon. Thanks in advance -- ArbolOne Using Fire Fox and Thunderbird. Developing using Java, C/C++, HTM/CSS and JS as our platform has been exciting and most rewarding. [ S? ] From johnvalrose at gmail.com Fri Sep 7 00:18:30 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Fri, 7 Sep 2018 10:18:30 +1000 Subject: which technology should give preference In-Reply-To: <68b63bbb-e3ef-84a3-ca76-72875fdbedc0@gmail.com> References: <68b63bbb-e3ef-84a3-ca76-72875fdbedc0@gmail.com> Message-ID: FXML is ?part? of JavaFX. It?s the format used to specify the UI of a JavaFX application. Plus I don?t think this is the appropriate list to post such questions as it is intended as a forum to discuss the development of JavaFX itself. > On 7 Sep 2018, at 09:47, AmnoJeeuw wrote: > > I am learning hands-on how to program using JavaFX and in the process doing so I?ve come across FXML; which I find most interesting. Since the principal is ?Think hand held device first? -TH2DF, my intention is to port the my future application to Android device, but I am concerned that there will be too many issues when doing that. So, my question is, which technology should give preference to, JavaFX or FXML? > > Please, keep in mind that I am using a Windows 8.1 machine and Eclipse-Photon. > > > Thanks in advance > > -- > ArbolOne > Using Fire Fox and Thunderbird. > Developing using Java, C/C++, HTM/CSS and JS as our platform has been exciting and most rewarding. > [ S? ] > From mike.ennen at gmail.com Fri Sep 7 00:19:20 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Thu, 6 Sep 2018 17:19:20 -0700 Subject: which technology should give preference In-Reply-To: <68b63bbb-e3ef-84a3-ca76-72875fdbedc0@gmail.com> References: <68b63bbb-e3ef-84a3-ca76-72875fdbedc0@gmail.com> Message-ID: Amno, It is not a zero-sum choice. FXML is a part of JavaFX. FXML does not add anything, per se (in terms of nodes, controls, etc.) FXML allows for decoupling the specific UI configuration (in terms of what nodes contain which and their positions, etc.). Basically it is the most sustainable (in terms of increasing application size/scope) practice to use FXML for setting up the initial scenes (and perhaps also wiring event listeners) In the Android world it is equivalent to using the Layout Editor (similar to FXML) versus making the scene programmatically by calling constructors, setting ownership, positions, constraints, etc. There is nothing that can be done using FXML that can't be done using pure Java. Cheers, Michael Ennen On Thu, Sep 6, 2018 at 4:48 PM AmnoJeeuw wrote: > I am learning hands-on how to program using JavaFX and in the process > doing so I?ve come across FXML; which I find most interesting. Since the > principal is ?Think hand held device first? -TH2DF, my intention is to > port the my future application to Android device, but I am concerned > that there will be too many issues when doing that. So, my question is, > which technology should give preference to, JavaFX or FXML? > > Please, keep in mind that I am using a Windows 8.1 machine and > Eclipse-Photon. > > > Thanks in advance > > -- > ArbolOne > Using Fire Fox and Thunderbird. > Developing using Java, C/C++, HTM/CSS and JS as our platform has been > exciting and most rewarding. > [ S? ] > > From johnvalrose at gmail.com Fri Sep 7 00:22:07 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Fri, 7 Sep 2018 10:22:07 +1000 Subject: which technology should give preference In-Reply-To: References: <68b63bbb-e3ef-84a3-ca76-72875fdbedc0@gmail.com> Message-ID: <2C93C7A8-4E53-499D-A4D2-627D816B995D@gmail.com> Thanks Michael - your answer was way better than mine! > On 7 Sep 2018, at 10:19, Michael Ennen wrote: > > Amno, > > It is not a zero-sum choice. FXML is a part of JavaFX. FXML does not add > anything, per se (in terms of nodes, controls, etc.) FXML allows for > decoupling > the specific UI configuration (in terms of what nodes contain which and > their > positions, etc.). Basically it is the most sustainable (in terms of > increasing > application size/scope) practice to use FXML for setting up the initial > scenes > (and perhaps also wiring event listeners) > > In the Android world it is equivalent to using the Layout Editor (similar > to FXML) > versus making the scene programmatically by calling constructors, setting > ownership, > positions, constraints, etc. There is nothing that can be done using FXML > that can't > be done using pure Java. > > Cheers, > Michael Ennen > >> On Thu, Sep 6, 2018 at 4:48 PM AmnoJeeuw wrote: >> >> I am learning hands-on how to program using JavaFX and in the process >> doing so I?ve come across FXML; which I find most interesting. Since the >> principal is ?Think hand held device first? -TH2DF, my intention is to >> port the my future application to Android device, but I am concerned >> that there will be too many issues when doing that. So, my question is, >> which technology should give preference to, JavaFX or FXML? >> >> Please, keep in mind that I am using a Windows 8.1 machine and >> Eclipse-Photon. >> >> >> Thanks in advance >> >> -- >> ArbolOne >> Using Fire Fox and Thunderbird. >> Developing using Java, C/C++, HTM/CSS and JS as our platform has been >> exciting and most rewarding. >> [ S? ] >> >> From mike.ennen at gmail.com Fri Sep 7 00:23:57 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Thu, 6 Sep 2018 17:23:57 -0700 Subject: which technology should give preference In-Reply-To: <2C93C7A8-4E53-499D-A4D2-627D816B995D@gmail.com> References: <68b63bbb-e3ef-84a3-ca76-72875fdbedc0@gmail.com> <2C93C7A8-4E53-499D-A4D2-627D816B995D@gmail.com> Message-ID: No worries. Also I agree with Johan that it would be more appropriate to ask questions like this on, say, Stack Overflow. As Johan mentioned this list is for discussing the development of JavaFX itself (not the use of it). Cheers, Michael Ennen On Thu, Sep 6, 2018 at 5:22 PM John-Val Rose wrote: > Thanks Michael - your answer was way better than mine! > > > On 7 Sep 2018, at 10:19, Michael Ennen wrote: > > > > Amno, > > > > It is not a zero-sum choice. FXML is a part of JavaFX. FXML does not add > > anything, per se (in terms of nodes, controls, etc.) FXML allows for > > decoupling > > the specific UI configuration (in terms of what nodes contain which and > > their > > positions, etc.). Basically it is the most sustainable (in terms of > > increasing > > application size/scope) practice to use FXML for setting up the initial > > scenes > > (and perhaps also wiring event listeners) > > > > In the Android world it is equivalent to using the Layout Editor (similar > > to FXML) > > versus making the scene programmatically by calling constructors, setting > > ownership, > > positions, constraints, etc. There is nothing that can be done using FXML > > that can't > > be done using pure Java. > > > > Cheers, > > Michael Ennen > > > >> On Thu, Sep 6, 2018 at 4:48 PM AmnoJeeuw wrote: > >> > >> I am learning hands-on how to program using JavaFX and in the process > >> doing so I?ve come across FXML; which I find most interesting. Since the > >> principal is ?Think hand held device first? -TH2DF, my intention is to > >> port the my future application to Android device, but I am concerned > >> that there will be too many issues when doing that. So, my question is, > >> which technology should give preference to, JavaFX or FXML? > >> > >> Please, keep in mind that I am using a Windows 8.1 machine and > >> Eclipse-Photon. > >> > >> > >> Thanks in advance > >> > >> -- > >> ArbolOne > >> Using Fire Fox and Thunderbird. > >> Developing using Java, C/C++, HTM/CSS and JS as our platform has been > >> exciting and most rewarding. > >> [ S? ] > >> > >> > From johnvalrose at gmail.com Fri Sep 7 00:40:37 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Fri, 7 Sep 2018 10:40:37 +1000 Subject: which technology should give preference In-Reply-To: <2C93C7A8-4E53-499D-A4D2-627D816B995D@gmail.com> References: <68b63bbb-e3ef-84a3-ca76-72875fdbedc0@gmail.com> <2C93C7A8-4E53-499D-A4D2-627D816B995D@gmail.com> Message-ID: <0286A583-0211-497D-8337-29724E3C13D3@gmail.com> Yes, as I suggested too, this is probably not the appropriate forum to post such questions. I tried to say this in an inoffensive way as possible because we are all human and make simple mistakes. I wish Amno all the best with their JavaFX app and I would suggest they check-out the products of Gluon when it comes to porting the app to mobile. Their URL is http://gluonhq.com Graciously, John-Val > On 7 Sep 2018, at 10:22, John-Val Rose wrote: > > Thanks Michael - your answer was way better than mine! > >> On 7 Sep 2018, at 10:19, Michael Ennen wrote: >> >> Amno, >> >> It is not a zero-sum choice. FXML is a part of JavaFX. FXML does not add >> anything, per se (in terms of nodes, controls, etc.) FXML allows for >> decoupling >> the specific UI configuration (in terms of what nodes contain which and >> their >> positions, etc.). Basically it is the most sustainable (in terms of >> increasing >> application size/scope) practice to use FXML for setting up the initial >> scenes >> (and perhaps also wiring event listeners) >> >> In the Android world it is equivalent to using the Layout Editor (similar >> to FXML) >> versus making the scene programmatically by calling constructors, setting >> ownership, >> positions, constraints, etc. There is nothing that can be done using FXML >> that can't >> be done using pure Java. >> >> Cheers, >> Michael Ennen >> >>> On Thu, Sep 6, 2018 at 4:48 PM AmnoJeeuw wrote: >>> >>> I am learning hands-on how to program using JavaFX and in the process >>> doing so I?ve come across FXML; which I find most interesting. Since the >>> principal is ?Think hand held device first? -TH2DF, my intention is to >>> port the my future application to Android device, but I am concerned >>> that there will be too many issues when doing that. So, my question is, >>> which technology should give preference to, JavaFX or FXML? >>> >>> Please, keep in mind that I am using a Windows 8.1 machine and >>> Eclipse-Photon. >>> >>> >>> Thanks in advance >>> >>> -- >>> ArbolOne >>> Using Fire Fox and Thunderbird. >>> Developing using Java, C/C++, HTM/CSS and JS as our platform has been >>> exciting and most rewarding. >>> [ S? ] >>> >>> From javafx at use.startmail.com Sat Sep 8 00:37:59 2018 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Fri, 7 Sep 2018 20:37:59 -0400 Subject: JavaFX Application Thread is recursively re-entrant into Eventhandler handle() method under some circumstances Message-ID: <11143b3d4920860f005d4243e5b9a9c1.startmail@startmail.com> Hi,? I have a couple of very small apps (3 small classes in one case and 5 in another)? which demonstrate that, under some circumstances, the JavaFX Application Thread will recursively re-enter EventHandler#handle(). So this means that it is already in handle (and calls therefrom) and will, in some situations not complete that? processing (thus exiting handle) before it reappears in the same instance of EventHandler's handle method again. So this is true recursion. I actually don't know if this is expected behavior or not. No one I've talked to expected it; the general understanding is the JavaFX Application Thread (processing) is specifically single-threaded and also that it will defintily complete one invocation of handle() before beginning another one. I have to say that there is NO other Thread? in play here, at least no other Thread my applications create (what's going on QuantumToolKit may be a different story.) The material upshot of this is it can lead to apparent? program incorrectness if the dev believes that it's not the case, and 100% of devs I've talked to think it's not possible.? I am happy to post or attach the classes or modules as requested but first I wanted to check to see if in fact this is already known to be true and is in fact? expected behavior, in which case it's a non-issue and just a subtlety people are not aware of. Thank you so much ! From kevin.rushforth at oracle.com Sat Sep 8 12:02:42 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 8 Sep 2018 05:02:42 -0700 Subject: JavaFX Application Thread is recursively re-entrant into Eventhandler handle() method under some circumstances In-Reply-To: <11143b3d4920860f005d4243e5b9a9c1.startmail@startmail.com> References: <11143b3d4920860f005d4243e5b9a9c1.startmail@startmail.com> Message-ID: <55dd39dc-27e7-ce2b-62ae-247dc2808269@oracle.com> I am not aware of such a bug. If you have a test program, then you can file a bug here: https://bugreport.java.com/ -- Kevin On 9/7/2018 5:37 PM, javafx at use.startmail.com wrote: > Hi, > > I have a couple of very small apps (3 small classes in one case and 5 > in another)? which demonstrate that, under some circumstances, the > JavaFX Application Thread will recursively re-enter > EventHandler#handle(). > > So this means that it is already in handle (and calls therefrom) and > will, in some situations not complete that? processing (thus exiting > handle) before it reappears in the same instance of EventHandler's > handle method again. So this is true recursion. > > I actually don't know if this is expected behavior or not. No one I've > talked to expected it; the general understanding is the JavaFX > Application Thread (processing) is specifically single-threaded and > also that it will defintily complete one invocation of handle() before > beginning another one. > > I have to say that there is NO other Thread? in play here, at least no > other Thread my applications create (what's going on QuantumToolKit > may be a different story.) > > The material upshot of this is it can lead to apparent? program > incorrectness if the dev believes that it's not the case, and 100% of > devs I've talked to think it's not possible. > > I am happy to post or attach the classes or modules as requested but > first I wanted to check to see if in fact this is already known to be > true and is in fact? expected behavior, in which case it's a non-issue > and just a subtlety people are not aware of. > > Thank you so much ! From javafx at use.startmail.com Sat Sep 8 15:32:40 2018 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Sat, 8 Sep 2018 11:32:40 -0400 Subject: JavaFX Application Thread is recursively re-entrant into Eventhandler handle() method under some circumstances In-Reply-To: <11143b3d4920860f005d4243e5b9a9c1.startmail@startmail.com> References: <11143b3d4920860f005d4243e5b9a9c1.startmail@startmail.com> Message-ID: <23d5e54cf7a6f1bdf077b27d10e44434.startmail@startmail.com> Here is the link to the demonstration applications for this issue. I noticed one small javadoc error which references a class whose name was changed in a refactoring, but it should not really confuse anyone.? You have to read the readme.txt . https://uploadfiles.io/ejt5h HTH ? On Friday, September 7, 2018 at 8:37 PM, javafx at use.startmail.com wrote: ? > Hi,? > > I have a couple of very small apps (3 small classes in one case and 5 > in another)? which demonstrate that, under some circumstances, the > JavaFX Application Thread will recursively re-enter > EventHandler#handle(). > > So this means that it is already in handle (and calls therefrom) and > will, in some situations not complete that? processing (thus exiting > handle) before it reappears in the same instance of EventHandler's > handle method again. So this is true recursion. > > I actually don't know if this is expected behavior or not. No one > I've > talked to expected it; the general understanding is the JavaFX > Application Thread (processing) is specifically single-threaded and > also that it will defintily complete one invocation of handle() > before > beginning another one. > > I have to say that there is NO other Thread? in play here, at least > no > other Thread my applications create (what's going on QuantumToolKit > may > be a different story.) > > The material upshot of this is it can lead to apparent? program > incorrectness if the dev believes that it's not the case, and 100% of > devs I've talked to think it's not possible.? > > I am happy to post or attach the classes or modules as requested but > first I wanted to check to see if in fact this is already known to be > true and is in fact? expected behavior, in which case it's a > non-issue > and just a subtlety people are not aware of. > > Thank you so much ! From javafx at use.startmail.com Sun Sep 9 17:05:15 2018 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Sun, 9 Sep 2018 13:05:15 -0400 Subject: JavaFX Application Thread is recursively re-entrant into Eventhandler handle() method under some circumstances In-Reply-To: <55dd39dc-27e7-ce2b-62ae-247dc2808269@oracle.com> References: <11143b3d4920860f005d4243e5b9a9c1.startmail@startmail.com> <55dd39dc-27e7-ce2b-62ae-247dc2808269@oracle.com> Message-ID: <3105330a76395e24195b1b544a07f337.startmail@startmail.com> Hi All, I spent some time refactoring the program which displays this bug. It's now small enough to share the source in an email, but it is very very dense and the proof of bug, one? specific line to standard I/O, requires the source code to be read and understood in order to see the bug. As I said previously, more comprehensible and user-friendly versions of this program are? available at . The javadoc is more copious, the bug is manifested as an exception and the side effect of the bug are more consequential. This brief version cnosists of just two classes. Here is the JavaFX Application class: *************************************************************************** package bareBonesJavaFXBugExample; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Label; import javafx.scene.input.MouseEvent; import javafx.scene.layout.Pane; import javafx.stage.Stage; /** ?* An {@link Application} with one {@link Pane} containing one {@link Label}. The {@link Label} has a single {@link javafx.event.EventHandler}, {@link LabelEventHandler} which processes all {@link MouseEvent}s the {@link Label} receives. ?*

?* To trigger the bug, run the application, then spend a second mouse over the little label in the upper left hand corner of the scrren. You will see output to standard I/O. Then, click the label, which will then disppear. Check the I/O for Strings ending in debugCounter is 1.

?* What that String means and how it proves that the JavaFX Application Thread has become reentrant is explained in the javadoc of {@link LabelEventHandler}. ?*/ public class JavaFXAnomalyBareBonesApplication extends Application { ? ? public void start(Stage primaryStage) ? ? { ? ? ? Pane mainPane = new Pane(); ? ? ? mainPane.setMinHeight(800); ? ? ? mainPane.setMinWidth(800); ? ? ? Label label = new Label(" this is quite a bug !!!!"); ? ? ? LabelEventHandler labelEventHandler = new LabelEventHandler(mainPane, label); ? ? ? label.addEventHandler(MouseEvent.ANY, labelEventHandler); ? ? ? mainPane.getChildren().add(label); ? ? ? Scene scene = new Scene(mainPane); ? ? ? primaryStage.setScene(scene); ? ? ? primaryStage.show(); ? ? } ? ? /** ? ? ?* The entry point of application. ? ? ?* ? ? ?* @param args ? ? ?*? ? ? ? ?the input arguments ? ? ?*/ ? ? public static void main(String[] args) ? ? { ? ? ? ? launch(args); ? ? } } *************************************************************************** and here is its only dependency, the EventListener class. I included enough javadoc to have the program makes sense. : *************************************************************************** package bareBonesJavaFXBugExample; import javafx.event.Event; import javafx.event.EventHandler; import javafx.scene.control.Label; import javafx.scene.input.MouseEvent; import javafx.scene.layout.Pane; import java.util.Collection; import java.util.ConcurrentModificationException; /** ?* An {@link EventHandler} implementation for {@link MouseEvent}s.

This implementation's {@link EventHandler#handle(Event)} shows the relevant debug information to standard output before and after removing the member {@link #label} from the {@link #pane}. ?*

?* discussion

?*

?* Users should first satisfy themselves that the value of {@link LabelEventHandler#debugCounter} can only be non-zero, in fact 1 (one) in the method {@link LabelEventHandler#showDebugInformation(String)} if the method {@link LabelEventHandler#handle(MouseEvent)}? has been re-entered recursively, that is, before a previous invocation of {@link LabelEventHandler#handle(MouseEvent)} has returned. ?*

?* Proof:

1) debugCounter starts at value 0 (zero).

2) debugCounter is only incremented once, by 1 (one), and that is after the first call to {@link LabelEventHandler#showDebugInformation(String)} has returned.

3) debugCounter is only decremented once, by 1 (one) and that is before the last call to {@link LabelEventHandler#showDebugInformation(String)}.

4) however, because ?* debugCounter is a class variable ( it's static), if handle() is recurvsively re-entered then it's value can be 1 (one) when the re-entrant Thread executes {@link LabelEventHandler#showDebugInformation(String)} ?*

?* End proof. ?*

?*

?*

?* The output of this method to standard I/O is volumnious but searching the output for the exact String "debugCounter is 1" will immediately show the {@link LabelEventHandler#handle(MouseEvent)} method to have been recursively entered.

?* Some other possibilities other than the JavaFX Application Thread recursing into {@code handle()} need to be addressed.

One is the fact that the compiler is free to reorder statements if it can ?* prove that such a reordering would have no effect on the program's correctness. ?*

?* So somehow the compiler is reordering the increment/decrement of {@code? debugCounter} and the calls to {@code? ?showDebugInformation}.

But this would alter the correctness of the program, so this cannot be the case, or the compiler is making an error.

?*

?*

?* Another is the fact that I/O is not instantaneous and can appear to standard output later than it actually was executed.

This is something often seen in debug stack traces, where the output is broken up? or interleaved by the output of the stack trace even though the two sets of statments, i/o and stack trace i/o, were strictly ordered in execution.

But this can't account for the value of {@code? ?debugCounter}, so it can't ?* be the reason "debugCounter is 1" appears in output.

In fact we can make this recursive behaviour more obviously consequential to the correctness of the program.

If {@code? ?handle() } is being recursively re-entered, then we can force a {@link ConcurrentModificationException} on a {@link Collection}.?

If we try to invoke {@link Collection#add(Object)} to a {@link Collection} while it is being iterated through, then a ?* {@link ConcurrentModificationException} will be thrown.

If we re-write this program slightly to first add or remove to or from a {@link Collection} then iterate through that {@link Collection} within the scope of? execution of {@code? ?handle()}, and {@code? ?handle()} is being recursively invoked, then we may see a {@link ConcurrentModificationException}. ?*

?* Two other instances of this same basic program exist at the link provided. They are named {@link JavaFXAnomalySimpleVersionApplication} and {@link JavaFXAnomalyComplexVersionApplication} which is written to throw a {@link ConcurrentModificationException} when the JavaFX Application Thread becomes reentrant. ?*

?* I also have a screen grab (not included here) of the stack trace at a specific moment handle()/code> is being invoked, and it can clearly be seen that the previous executing line was within the scope of execution of the previous invocation of handle(). ?*

?* In the .zip file at the link there is a readme.txt. In that file. I present the two lines of code which need to be added, and where they need to be added,? so as to generate the same stack trace showing the same thing. ?* ?* ?*

?*/ public class LabelEventHandler implements EventHandler { ? /** ? ?* a counter which acts as a recursion detector. If {@link #handle(MouseEvent)} is never recursively invoked by the JavaFX Application Thread, then it's value will never be other than 0 (zero) in {@link #showDebugInformation(String)}. ? ?*/ ? private static int debugCounter; ? /** ? ?* The {@link Label} which will disappear when clicked. This causes a MOUSE_EXITED_TARGET event top be fired and that in turn causes the JavaFX Event Dispatch Thread to recurse into this class's {@link #handle(MouseEvent)} ? ?*/ ? private Label label; ? /** ? ?* The {@link Pane} which contains the {@link Label}. The {@link Label} is removed from this {@link Pane}. ? ?*/ ? private final Pane pane; ? /** ? ?* Assign the values to the members {@link Pane} and {@link Label} ? ?*/ ? public LabelEventHandler(Pane pane, Label label) ? { ? ? this.pane = pane; ? ? this.label = label; ? } ? /** ? ?* Causes the member {@link #label} to be removed as a child of the member {@link #pane}. ? ?* ? ?* ? ?* @param mouseEvent ? ?*? ? ? ? ?the {@link MouseEvent} received from the JavaFX Application Thread from the {@link Label} which this {@link EventHandler} is listening to. ? ?*/ ? @Override ? public void handle(MouseEvent mouseEvent) ? { ? ? showDebugInformation("ENTERING");// debug can only every be 0 (zero) at this point ? ? debugCounter++; ? ? if (mouseEvent.getEventType().equals(MouseEvent.MOUSE_PRESSED) && mouseEvent.isPrimaryButtonDown()) ? ? { ? ? ? pane.getChildren().remove(label); ? ? } ? ? debugCounter--; ? ? showDebugInformation("EXITING");// debug can only every be 0 (zero) at this point ? } ? /** ? ?* Displays two values to standard output. The first is a {@link String}? indicating whether the {@link LabelEventHandler#handle(MouseEvent)} method is being entered or exited and the second is the value of {@link LabelEventHandler#debugCounter} at the time this method is executed. ? ?* ? ?* @param enterOrExit ? ?*? ? ? ? ?the string ENTERING or EXITING reflecting the point? at which this method was invoked by {@link LabelEventHandler#handle(MouseEvent)}. ? ?*/ ? private void showDebugInformation(String enterOrExit) ? { ? ? System.out.println(); ? ? System.out.print(enterOrExit + " method handle"); ? ? System.out.print(" and debugCounter is " + debugCounter); ? ? System.out.println(); ? } } ******************************************************************* Just cut and pasting these two into files named by? their? respective Java class names, then? placing those? files into a folder named?bareBonesJavaFXBugExample is all it should? take to make this work. Unless I get contrary? feedback, I will file this as a bug after I run it against the most recent releases of the JavaFX.? Either way I am interested in feedback from the community.?? Cheers ! ? On Saturday, September 8, 2018 at 8:02 AM, Kevin Rushforth wrote: ? > I am not aware of such a bug. If you have a test program, then you > can > file a bug here: > > https://bugreport.java.com/ > > -- Kevin > > > On 9/7/2018 5:37 PM, javafx at use.startmail.com wrote: >> Hi, >> >> I have a couple of very small apps (3 small classes in one case and >> 5 >> in another)? which demonstrate that, under some circumstances, the >> JavaFX Application Thread will recursively re-enter >> EventHandler#handle(). >> >> So this means that it is already in handle (and calls therefrom) and >> will, in some situations not complete that? processing (thus exiting >> handle) before it reappears in the same instance of EventHandler's >> handle method again. So this is true recursion. >> >> I actually don't know if this is expected behavior or not. No one >> I've >> talked to expected it; the general understanding is the JavaFX >> Application Thread (processing) is specifically single-threaded and >> also that it will defintily complete one invocation of handle() >> before >> beginning another one. >> >> I have to say that there is NO other Thread? in play here, at least >> no >> other Thread my applications create (what's going on QuantumToolKit >> may be a different story.) >> >> The material upshot of this is it can lead to apparent? program >> incorrectness if the dev believes that it's not the case, and 100% >> of >> devs I've talked to think it's not possible. >> >> I am happy to post or attach the classes or modules as requested but >> first I wanted to check to see if in fact this is already known to >> be >> true and is in fact? expected behavior, in which case it's a >> non-issue >> and just a subtlety people are not aware of. >> >> Thank you so much ! From hjohn at xs4all.nl Sun Sep 9 20:04:40 2018 From: hjohn at xs4all.nl (John Hendrikx) Date: Sun, 9 Sep 2018 22:04:40 +0200 Subject: JavaFX Application Thread is recursively re-entrant into Eventhandler handle() method under some circumstances In-Reply-To: <3105330a76395e24195b1b544a07f337.startmail@startmail.com> References: <11143b3d4920860f005d4243e5b9a9c1.startmail@startmail.com> <55dd39dc-27e7-ce2b-62ae-247dc2808269@oracle.com> <3105330a76395e24195b1b544a07f337.startmail@startmail.com> Message-ID: <11944a2d-d48d-4f0d-4587-47879921953d@xs4all.nl> I see nothing special in the stack trace. When you remove the component, a new MouseEvent *must* trigger (MouseEvent.EXITED) as it always needs to match with MouseEvent.ENTERED. So, the call to 'remove' triggers a new event, which gets handled by the same handler. It is indeed entered recursively, but in a normal fashion. This has nothing to do with another thread or compiler bugs. Don't be confused by the double "handle" lines in the stacktrace. This happens when methods are overriden (the line number is 1). There are two relevant lines in this trace: LabelEventHandler.handle(LabelEventHandler.java:95) ...where Remove is called, which triggers the recursive call later on: LabelEventHandler.handle(LabelEventHandler.java:88) ... for the MouseEvent.EXITED event. The full stack trace is this: at bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:88) at bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:1) at javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218) at javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) at javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) at javafx.base/javafx.event.Event.fireEvent(Event.java:198) at javafx.base/com.sun.javafx.event.EventQueue.fire(EventQueue.java:48) at javafx.graphics/javafx.scene.Scene$MouseHandler.handleNodeRemoval(Scene.java:3717) at javafx.graphics/javafx.scene.Scene$MouseHandler.access$7800(Scene.java:3604) at javafx.graphics/javafx.scene.Scene.generateMouseExited(Scene.java:3601) at javafx.graphics/javafx.scene.Parent$3.onProposedChange(Parent.java:613) at javafx.base/com.sun.javafx.collections.VetoableListDecorator.remove(VetoableListDecorator.java:329) at javafx.base/com.sun.javafx.collections.VetoableListDecorator.remove(VetoableListDecorator.java:221) at bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:95) at bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:1) at javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218) (... rest cut off as it is not needed ... ) --John On 09/09/2018 19:05, javafx at use.startmail.com wrote: > Hi All, > I spent some time refactoring the program which displays this bug. It's > now small enough to share the source in an email, but it is very very > dense and the proof of bug, one specific line to standard I/O, requires > the source code to be read and understood in order to see the bug. As I > said previously, more comprehensible and user-friendly versions of this > program are available at . The javadoc is more copious, the bug is > manifested as an exception and the side effect of the bug are more > consequential. > > This brief version cnosists of just two classes. Here is the JavaFX > Application class: > > *************************************************************************** > > package bareBonesJavaFXBugExample; > > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Label; > import javafx.scene.input.MouseEvent; > import javafx.scene.layout.Pane; > import javafx.stage.Stage; > > > > /** > * An {@link Application} with one {@link Pane} containing one {@link > Label}. The {@link Label} has a single {@link > javafx.event.EventHandler}, {@link LabelEventHandler} which processes > all {@link MouseEvent}s the {@link Label} receives. > *

> * To trigger the bug, run the application, then spend a second mouse > over the little label in the upper left hand corner of the scrren. You > will see output to standard I/O. Then, click the label, which will then > disppear. Check the I/O for Strings ending in debugCounter is 1.

> * What that String means and how it proves that the JavaFX Application > Thread has become reentrant is explained in the javadoc of {@link > LabelEventHandler}. > */ > public class JavaFXAnomalyBareBonesApplication extends Application > { > public void start(Stage primaryStage) > { > > Pane mainPane = new Pane(); > mainPane.setMinHeight(800); > mainPane.setMinWidth(800); > > Label label = new Label(" this is quite a bug !!!!"); > > LabelEventHandler labelEventHandler = new > LabelEventHandler(mainPane, label); > label.addEventHandler(MouseEvent.ANY, labelEventHandler); > > mainPane.getChildren().add(label); > > > Scene scene = new Scene(mainPane); > primaryStage.setScene(scene); > primaryStage.show(); > > } > > > > /** > * The entry point of application. > * > * @param args > * the input arguments > */ > public static void main(String[] args) > { > > launch(args); > } > > > > } > > > *************************************************************************** > > and here is its only dependency, the EventListener class. I included > enough javadoc to have the program makes sense. : > > *************************************************************************** > > package bareBonesJavaFXBugExample; > > > > import javafx.event.Event; > import javafx.event.EventHandler; > import javafx.scene.control.Label; > import javafx.scene.input.MouseEvent; > import javafx.scene.layout.Pane; > > import java.util.Collection; > import java.util.ConcurrentModificationException; > > /** > * An {@link EventHandler} implementation for {@link MouseEvent}s. >

This implementation's {@link EventHandler#handle(Event)} shows > the relevant debug information to standard output before and after > removing the member {@link #label} from the {@link #pane}. > *

> * discussion

> *

> * Users should first satisfy themselves that the value of {@link > LabelEventHandler#debugCounter} can only be non-zero, in fact 1 (one) in > the method {@link LabelEventHandler#showDebugInformation(String)} if the > method {@link LabelEventHandler#handle(MouseEvent)} has been re-entered > recursively, that is, before a previous invocation of {@link > LabelEventHandler#handle(MouseEvent)} has returned. > *

> * Proof:

1) debugCounter starts at value 0 (zero). >

2) debugCounter is only incremented once, by 1 > (one), and that is after the first call to {@link > LabelEventHandler#showDebugInformation(String)} has returned.

3) > debugCounter is only decremented once, by 1 (one) and that > is before the last call to {@link > LabelEventHandler#showDebugInformation(String)}.

4) however, because > * debugCounter is a class variable ( it's static), if > handle() is recurvsively re-entered then it's value can be 1 (one) when > the re-entrant Thread executes {@link > LabelEventHandler#showDebugInformation(String)} > *

> * End proof. > *

> *

> *

> * The output of this method to standard I/O is volumnious but searching > the output for the exact String "debugCounter is 1" will immediately > show the {@link LabelEventHandler#handle(MouseEvent)} method to have > been recursively entered.

> * Some other possibilities other than the JavaFX Application Thread > recursing into {@code handle()} need to be addressed.

One is the > fact that the compiler is free to reorder statements if it can > * prove that such a reordering would have no effect on the program's > correctness. > *

> * So somehow the compiler is reordering the increment/decrement of > {@code debugCounter} and the calls to {@code showDebugInformation}. >

But this would alter the correctness of the program, so this > cannot be the case, or the compiler is making an error.

> *

> *

> * Another is the fact that I/O is not instantaneous and can appear to > standard output later than it actually was executed.

This is > something often seen in debug stack traces, where the output is broken > up or interleaved by the output of the stack trace even though the two > sets of statments, i/o and stack trace i/o, were strictly ordered in > execution.

But this can't account for the value of {@code > debugCounter}, so it can't > * be the reason "debugCounter is 1" appears in output.

In fact > we can make this recursive behaviour more obviously consequential to the > correctness of the program.

If {@code handle() } is being > recursively re-entered, then we can force a {@link > ConcurrentModificationException} on a {@link Collection}.

If > we try to invoke {@link Collection#add(Object)} to a {@link Collection} > while it is being iterated through, then a > * {@link ConcurrentModificationException} will be thrown.

If we > re-write this program slightly to first add or remove to or from a > {@link Collection} then iterate through that {@link Collection} within > the scope of execution of {@code handle()}, and {@code > handle()} is being recursively invoked, then we may see a {@link > ConcurrentModificationException}. > *

> * Two other instances of this same basic program exist at the link > provided. They are named {@link JavaFXAnomalySimpleVersionApplication} > and {@link JavaFXAnomalyComplexVersionApplication} which is written to > throw a {@link ConcurrentModificationException} when the JavaFX > Application Thread becomes reentrant. > *

> * I also have a screen grab (not included here) of the stack trace at a > specific moment handle()/code> is being invoked, and it can > clearly be seen that the previous executing line was within the scope of > execution of the previous invocation of handle(). > *

> * In the .zip file at the link there is a readme.txt. In that file. I > present the two lines of code which need to be added, and where they > need to be added, so as to generate the same stack trace showing the > same thing. > * > * > *

> */ > public class LabelEventHandler implements EventHandler > { > /** > * a counter which acts as a recursion detector. If {@link > #handle(MouseEvent)} is never recursively invoked by the JavaFX > Application Thread, then it's value will never be other than 0 (zero) in > {@link #showDebugInformation(String)}. > */ > private static int debugCounter; > > /** > * The {@link Label} which will disappear when clicked. This causes a > MOUSE_EXITED_TARGET event top be fired and that in turn causes the > JavaFX Event Dispatch Thread to recurse into this class's {@link > #handle(MouseEvent)} > */ > private Label label; > /** > * The {@link Pane} which contains the {@link Label}. The {@link > Label} is removed from this {@link Pane}. > */ > private final Pane pane; > > > > /** > * Assign the values to the members {@link Pane} and {@link Label} > */ > public LabelEventHandler(Pane pane, Label label) > { > > this.pane = pane; > this.label = label; > } > > > > /** > * Causes the member {@link #label} to be removed as a child of the > member {@link #pane}. > * > * > * @param mouseEvent > * the {@link MouseEvent} received from the JavaFX Application > Thread from the {@link Label} which this {@link EventHandler} is > listening to. > */ > @Override > public void handle(MouseEvent mouseEvent) > { > > showDebugInformation("ENTERING");// debug can only every be 0 (zero) > at this point > debugCounter++; > > > if (mouseEvent.getEventType().equals(MouseEvent.MOUSE_PRESSED) && > mouseEvent.isPrimaryButtonDown()) > { > pane.getChildren().remove(label); > } > > debugCounter--; > showDebugInformation("EXITING");// debug can only every be 0 (zero) > at this point > } > > > > /** > * Displays two values to standard output. The first is a {@link > String} indicating whether the {@link > LabelEventHandler#handle(MouseEvent)} method is being entered or exited > and the second is the value of {@link LabelEventHandler#debugCounter} at > the time this method is executed. > * > * @param enterOrExit > * the string ENTERING or EXITING reflecting the point at > which this method was invoked by {@link > LabelEventHandler#handle(MouseEvent)}. > */ > private void showDebugInformation(String enterOrExit) > { > > System.out.println(); > System.out.print(enterOrExit + " method handle"); > System.out.print(" and debugCounter is " + debugCounter); > System.out.println(); > } > > > > > > } > > > > ******************************************************************* > > Just cut and pasting these two into files named by their respective > Java class names, then placing those files into a folder > named bareBonesJavaFXBugExample is all it should take to make this work. > > Unless I get contrary feedback, I will file this as a bug after I run > it against the most recent releases of the JavaFX. > > Either way I am interested in feedback from the community. > > Cheers ! > > > > > On Saturday, September 8, 2018 at 8:02 AM, Kevin Rushforth > wrote: > >> I am not aware of such a bug. If you have a test program, then you can >> file a bug here: >> >> https://bugreport.java.com/ >> >> -- Kevin >> >> >> On 9/7/2018 5:37 PM, javafx at use.startmail.com wrote: >>> Hi, >>> >>> I have a couple of very small apps (3 small classes in one case and 5 >>> in another) which demonstrate that, under some circumstances, the >>> JavaFX Application Thread will recursively re-enter >>> EventHandler#handle(). >>> >>> So this means that it is already in handle (and calls therefrom) and >>> will, in some situations not complete that processing (thus exiting >>> handle) before it reappears in the same instance of EventHandler's >>> handle method again. So this is true recursion. >>> >>> I actually don't know if this is expected behavior or not. No one I've >>> talked to expected it; the general understanding is the JavaFX >>> Application Thread (processing) is specifically single-threaded and >>> also that it will defintily complete one invocation of handle() before >>> beginning another one. >>> >>> I have to say that there is NO other Thread in play here, at least no >>> other Thread my applications create (what's going on QuantumToolKit >>> may be a different story.) >>> >>> The material upshot of this is it can lead to apparent program >>> incorrectness if the dev believes that it's not the case, and 100% of >>> devs I've talked to think it's not possible. >>> >>> I am happy to post or attach the classes or modules as requested but >>> first I wanted to check to see if in fact this is already known to be >>> true and is in fact expected behavior, in which case it's a non-issue >>> and just a subtlety people are not aware of. >>> >>> Thank you so much ! > From javafx at use.startmail.com Sun Sep 9 21:38:53 2018 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Sun, 9 Sep 2018 17:38:53 -0400 Subject: JavaFX Application Thread is recursively re-entrant into Eventhandler handle() method under some circumstances In-Reply-To: <11944a2d-d48d-4f0d-4587-47879921953d@xs4all.nl> References: <11143b3d4920860f005d4243e5b9a9c1.startmail@startmail.com> <55dd39dc-27e7-ce2b-62ae-247dc2808269@oracle.com> <3105330a76395e24195b1b544a07f337.startmail@startmail.com> <11944a2d-d48d-4f0d-4587-47879921953d@xs4all.nl> Message-ID: <7409fb960d86a0b42db91804ccb32692.startmail@startmail.com> I did not say it was another Thread. In fact, I said it was the Java Application Thread itself- being recursively re-entrant. Specifically, at the time the MOUSE_EXITED_TARGET event is generated, the Java Application Thread has a choice- continue proocessing the EventHandler#handle method which it is in, or respond to the?MOUSE_EXITED_TARGET event which was just generated. Suprisingly, it does the second , completes that call to handle, then the stack pops and it nfinishes the previous invocation of handle. It's not about another Thread. I don't? ?refer to the stack trace as proof? ?that the thread is reentrant. I do say the contrapositve of that, which is, if the thread trace didn't show the bug? then the bug? wouldn't? exist. But I don't assert the stack trace as a proof. The proof is? the proof? I gave in the javadoc, and that is the value of one the static int debugCounter acheives in the debug statements can only be explained if? recursive re-entrancy has cocurred, which? is true. You need to address this.? Also, this is merely the most barebones implementation which reveals this bug. This is why I didn't want to post it, because you have to work out what cannot be the case before evaluating the argument. What cannot be the case is? debugCounter cannot have value 1 in the debug output method.? The link provides a more consequential /? more easily understood bug / less dismissable bug- a ConcurrentModificationException? against a Set which the EventHandler is iterating through. That CME happens not because two threads are operating on the Set but because one thread , the JAva Application Thread is modifying the Set while it is also iterating through it.? ? ? On Sunday, September 9, 2018 at 4:04 PM, John Hendrikx wrote: ? > I see nothing special in the stack trace. > > When you remove the component, a new MouseEvent *must* trigger > (MouseEvent.EXITED) as it always needs to match with > MouseEvent.ENTERED. > > So, the call to 'remove' triggers a new event, which gets handled by > the > same handler. ?It is indeed entered recursively, but in a normal > fashion. ?This has nothing to do with another thread or compiler > bugs. > > Don't be confused by the double "handle" lines in the stacktrace. > ?This > happens when methods are overriden (the line number is 1). > > There are two relevant lines in this trace: > > ? ?LabelEventHandler.handle(LabelEventHandler.java:95) > > ...where Remove is called, which triggers the recursive call later > on: > > ? ?LabelEventHandler.handle(LabelEventHandler.java:88) > > ... for the MouseEvent.EXITED event. > > The full stack trace is this: > > at > bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:88) > at > bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:1) > at > javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218) > at > javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) > at > javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238) > at > javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > at > javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > at > javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > at > javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) > at javafx.base/javafx.event.Event.fireEvent(Event.java:198) > at > javafx.base/com.sun.javafx.event.EventQueue.fire(EventQueue.java:48) > at > javafx.graphics/javafx.scene.Scene$MouseHandler.handleNodeRemoval(Scene.java:3717) > at > javafx.graphics/javafx.scene.Scene$MouseHandler.access$7800(Scene.java:3604) > at > javafx.graphics/javafx.scene.Scene.generateMouseExited(Scene.java:3601) > at > javafx.graphics/javafx.scene.Parent$3.onProposedChange(Parent.java:613) > at > javafx.base/com.sun.javafx.collections.VetoableListDecorator.remove(VetoableListDecorator.java:329) > at > javafx.base/com.sun.javafx.collections.VetoableListDecorator.remove(VetoableListDecorator.java:221) > at > bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:95) > at > bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:1) > at > javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218) > > (... rest cut off as it is not needed ... ) > > --John > > On 09/09/2018 19:05, javafx at use.startmail.com wrote: >> Hi All, >> I spent some time refactoring the program which displays this bug. >> It's >> now small enough to share the source in an email, but it is very >> very >> dense and the proof of bug, one ?specific line to standard I/O, >> requires >> the source code to be read and understood in order to see the bug. >> As I >> said previously, more comprehensible and user-friendly versions of >> this >> program are ?available at . The javadoc is more copious, the bug is >> manifested as an exception and the side effect of the bug are more >> consequential. >> >> This brief version cnosists of just two classes. Here is the JavaFX >> Application class: >> >> *************************************************************************** >> >> package bareBonesJavaFXBugExample; >> >> >> import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.control.Label; >> import javafx.scene.input.MouseEvent; >> import javafx.scene.layout.Pane; >> import javafx.stage.Stage; >> >> >> >> /** >> ?* An {@link Application} with one {@link Pane} containing one >> {@link >> Label}. The {@link Label} has a single {@link >> javafx.event.EventHandler}, {@link LabelEventHandler} which >> processes >> all {@link MouseEvent}s the {@link Label} receives. >> ?*

>> ?* To trigger the bug, run the application, then spend a second >> mouse >> over the little label in the upper left hand corner of the scrren. >> You >> will see output to standard I/O. Then, click the label, which will >> then >> disppear. Check the I/O for Strings ending in debugCounter is 1. >>

>> ?* What that String means and how it proves that the JavaFX >> Application >> Thread has become reentrant is explained in the javadoc of {@link >> LabelEventHandler}. >> ?*/ >> public class JavaFXAnomalyBareBonesApplication extends Application >> { >> ? ? public void start(Stage primaryStage) >> ? ? { >> >> ? ? ? Pane mainPane = new Pane(); >> ? ? ? mainPane.setMinHeight(800); >> ? ? ? mainPane.setMinWidth(800); >> >> ? ? ? Label label = new Label(" this is quite a bug !!!!"); >> >> ? ? ? LabelEventHandler labelEventHandler = new >> LabelEventHandler(mainPane, label); >> ? ? ? label.addEventHandler(MouseEvent.ANY, labelEventHandler); >> >> ? ? ? mainPane.getChildren().add(label); >> >> >> ? ? ? Scene scene = new Scene(mainPane); >> ? ? ? primaryStage.setScene(scene); >> ? ? ? primaryStage.show(); >> >> ? ? } >> >> >> >> ? ? /** >> ? ? ?* The entry point of application. >> ? ? ?* >> ? ? ?* @param args >> ? ? ?* ? ? ? ? the input arguments >> ? ? ?*/ >> ? ? public static void main(String[] args) >> ? ? { >> >> ? ? ? ? launch(args); >> ? ? } >> >> >> >> } >> >> >> *************************************************************************** >> >> and here is its only dependency, the EventListener class. I included >> enough javadoc to have the program makes sense. : >> >> *************************************************************************** >> >> package bareBonesJavaFXBugExample; >> >> >> >> import javafx.event.Event; >> import javafx.event.EventHandler; >> import javafx.scene.control.Label; >> import javafx.scene.input.MouseEvent; >> import javafx.scene.layout.Pane; >> >> import java.util.Collection; >> import java.util.ConcurrentModificationException; >> >> /** >> ?* An {@link EventHandler} implementation for {@link MouseEvent}s. >>

This implementation's {@link EventHandler#handle(Event)} >> shows >> the relevant debug information to standard output before and after >> removing the member {@link #label} from the {@link #pane}. >> ?*

>> ?* discussion

>> ?*

>> ?* Users should first satisfy themselves that the value of {@link >> LabelEventHandler#debugCounter} can only be non-zero, in fact 1 >> (one) in >> the method {@link LabelEventHandler#showDebugInformation(String)} if >> the >> method {@link LabelEventHandler#handle(MouseEvent)} ?has been >> re-entered >> recursively, that is, before a previous invocation of {@link >> LabelEventHandler#handle(MouseEvent)} has returned. >> ?*

>> ?* Proof:

1) debugCounter starts at value 0 >> (zero). >>

2) debugCounter is only incremented once, by 1 >> (one), and that is after the first call to {@link >> LabelEventHandler#showDebugInformation(String)} has returned.

>> 3) >> debugCounter is only decremented once, by 1 (one) and >> that >> is before the last call to {@link >> LabelEventHandler#showDebugInformation(String)}.

4) however, >> because >> ?* debugCounter is a class variable ( it's static), if >> handle() is recurvsively re-entered then it's value can be 1 (one) >> when >> the re-entrant Thread executes {@link >> LabelEventHandler#showDebugInformation(String)} >> ?*

>> ?* End proof. >> ?*

>> ?*

>> ?*

>> ?* The output of this method to standard I/O is volumnious but >> searching >> the output for the exact String "debugCounter is 1" will immediately >> show the {@link LabelEventHandler#handle(MouseEvent)} method to have >> been recursively entered.

>> ?* Some other possibilities other than the JavaFX Application Thread >> recursing into {@code handle()} need to be addressed.

One is >> the >> fact that the compiler is free to reorder statements if it can >> ?* prove that such a reordering would have no effect on the >> program's >> correctness. >> ?*

>> ?* So somehow the compiler is reordering the increment/decrement of >> {@code ?debugCounter} and the calls to {@code ? >> showDebugInformation}. >>

But this would alter the correctness of the program, so >> this >> cannot be the case, or the compiler is making an error.

>> ?*

>> ?*

>> ?* Another is the fact that I/O is not instantaneous and can appear >> to >> standard output later than it actually was executed.

This >> is >> something often seen in debug stack traces, where the output is >> broken >> up ?or interleaved by the output of the stack trace even though the >> two >> sets of statments, i/o and stack trace i/o, were strictly ordered in >> execution.

But this can't account for the value of {@code >> ?debugCounter}, so it can't >> ?* be the reason "debugCounter is 1" appears in output.

In >> fact >> we can make this recursive behaviour more obviously consequential to >> the >> correctness of the program.

If {@code ? handle() } is being >> recursively re-entered, then we can force a {@link >> ConcurrentModificationException} on a {@link Collection}. ?

>> If >> we try to invoke {@link Collection#add(Object)} to a {@link >> Collection} >> while it is being iterated through, then a >> ?* {@link ConcurrentModificationException} will be thrown.

If >> we >> re-write this program slightly to first add or remove to or from a >> {@link Collection} then iterate through that {@link Collection} >> within >> the scope of ?execution of {@code ? handle()}, and {@code >> ?handle()} is being recursively invoked, then we may see a {@link >> ConcurrentModificationException}. >> ?*

>> ?* Two other instances of this same basic program exist at the link >> provided. They are named {@link >> JavaFXAnomalySimpleVersionApplication} >> and {@link JavaFXAnomalyComplexVersionApplication} which is written >> to >> throw a {@link ConcurrentModificationException} when the JavaFX >> Application Thread becomes reentrant. >> ?*

>> ?* I also have a screen grab (not included here) of the stack trace >> at a >> specific moment handle()/code> is being invoked, and it can >> clearly be seen that the previous executing line was within the >> scope of >> execution of the previous invocation of handle(). >> ?*

>> ?* In the .zip file at the link there is a readme.txt. In that file. >> I >> present the two lines of code which need to be added, and where they >> need to be added, ?so as to generate the same stack trace showing >> the >> same thing. >> ?* >> ?* >> ?*

>> ?*/ >> public class LabelEventHandler implements EventHandler >> { >> ? /** >> ? ?* a counter which acts as a recursion detector. If {@link >> #handle(MouseEvent)} is never recursively invoked by the JavaFX >> Application Thread, then it's value will never be other than 0 >> (zero) in >> {@link #showDebugInformation(String)}. >> ? ?*/ >> ? private static int debugCounter; >> >> ? /** >> ? ?* The {@link Label} which will disappear when clicked. This >> causes a >> MOUSE_EXITED_TARGET event top be fired and that in turn causes the >> JavaFX Event Dispatch Thread to recurse into this class's {@link >> #handle(MouseEvent)} >> ? ?*/ >> ? private Label label; >> ? /** >> ? ?* The {@link Pane} which contains the {@link Label}. The {@link >> Label} is removed from this {@link Pane}. >> ? ?*/ >> ? private final Pane pane; >> >> >> >> ? /** >> ? ?* Assign the values to the members {@link Pane} and {@link Label} >> ? ?*/ >> ? public LabelEventHandler(Pane pane, Label label) >> ? { >> >> ? ? this.pane = pane; >> ? ? this.label = label; >> ? } >> >> >> >> ? /** >> ? ?* Causes the member {@link #label} to be removed as a child of >> the >> member {@link #pane}. >> ? ?* >> ? ?* >> ? ?* @param mouseEvent >> ? ?* ? ? ? ? the {@link MouseEvent} received from the JavaFX >> Application >> Thread from the {@link Label} which this {@link EventHandler} is >> listening to. >> ? ?*/ >> ? @Override >> ? public void handle(MouseEvent mouseEvent) >> ? { >> >> ? ? showDebugInformation("ENTERING");// debug can only every be 0 >> (zero) >> at this point >> ? ? debugCounter++; >> >> >> ? ? if (mouseEvent.getEventType().equals(MouseEvent.MOUSE_PRESSED) >> && >> mouseEvent.isPrimaryButtonDown()) >> ? ? { >> ? ? ? pane.getChildren().remove(label); >> ? ? } >> >> ? ? debugCounter--; >> ? ? showDebugInformation("EXITING");// debug can only every be 0 >> (zero) >> at this point >> ? } >> >> >> >> ? /** >> ? ?* Displays two values to standard output. The first is a {@link >> String} ?indicating whether the {@link >> LabelEventHandler#handle(MouseEvent)} method is being entered or >> exited >> and the second is the value of {@link >> LabelEventHandler#debugCounter} at >> the time this method is executed. >> ? ?* >> ? ?* @param enterOrExit >> ? ?* ? ? ? ? the string ENTERING or EXITING reflecting the point ?at >> which this method was invoked by {@link >> LabelEventHandler#handle(MouseEvent)}. >> ? ?*/ >> ? private void showDebugInformation(String enterOrExit) >> ? { >> >> ? ? System.out.println(); >> ? ? System.out.print(enterOrExit + " method handle"); >> ? ? System.out.print(" and debugCounter is " + debugCounter); >> ? ? System.out.println(); >> ? } >> >> >> >> >> >> } >> >> >> >> ******************************************************************* >> >> Just cut and pasting these two into files named by ?their >> ?respective >> Java class names, then ?placing those ?files into a folder >> named bareBonesJavaFXBugExample is all it should ?take to make this >> work. >> >> Unless I get contrary ?feedback, I will file this as a bug after I >> run >> it against the most recent releases of the JavaFX. >> >> Either way I am interested in feedback from the community. >> >> Cheers ! >> >> >> >> >> On Saturday, September 8, 2018 at 8:02 AM, Kevin Rushforth >> wrote: >> ? >>> I am not aware of such a bug. If you have a test program, then you >>> can >>> file a bug here: >>> >>> https://bugreport.java.com/ >>> >>> -- Kevin >>> >>> >>> On 9/7/2018 5:37 PM, javafx at use.startmail.com wrote: >>>> Hi, >>>> >>>> I have a couple of very small apps (3 small classes in one case >>>> and 5 >>>> in another) ?which demonstrate that, under some circumstances, the >>>> JavaFX Application Thread will recursively re-enter >>>> EventHandler#handle(). >>>> >>>> So this means that it is already in handle (and calls therefrom) >>>> and >>>> will, in some situations not complete that ?processing (thus >>>> exiting >>>> handle) before it reappears in the same instance of EventHandler's >>>> handle method again. So this is true recursion. >>>> >>>> I actually don't know if this is expected behavior or not. No one >>>> I've >>>> talked to expected it; the general understanding is the JavaFX >>>> Application Thread (processing) is specifically single-threaded >>>> and >>>> also that it will defintily complete one invocation of handle() >>>> before >>>> beginning another one. >>>> >>>> I have to say that there is NO other Thread ?in play here, at >>>> least no >>>> other Thread my applications create (what's going on >>>> QuantumToolKit >>>> may be a different story.) >>>> >>>> The material upshot of this is it can lead to apparent ?program >>>> incorrectness if the dev believes that it's not the case, and 100% >>>> of >>>> devs I've talked to think it's not possible. >>>> >>>> I am happy to post or attach the classes or modules as requested >>>> but >>>> first I wanted to check to see if in fact this is already known to >>>> be >>>> true and is in fact ?expected behavior, in which case it's a >>>> non-issue >>>> and just a subtlety people are not aware of. >>>> >>>> Thank you so much ! From javafx at use.startmail.com Sun Sep 9 21:58:16 2018 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Sun, 9 Sep 2018 17:58:16 -0400 Subject: JavaFX Application Thread is recursively re-entrant into Eventhandler handle() method under some circumstances In-Reply-To: <11944a2d-d48d-4f0d-4587-47879921953d@xs4all.nl> References: <11143b3d4920860f005d4243e5b9a9c1.startmail@startmail.com> <55dd39dc-27e7-ce2b-62ae-247dc2808269@oracle.com> <3105330a76395e24195b1b544a07f337.startmail@startmail.com> <11944a2d-d48d-4f0d-4587-47879921953d@xs4all.nl> Message-ID: I am reading your stack trace but I defintely never mentioned the double invocation to handle that I see there are evidencing anything. The issue is the value of debugCounter at a two certain moments in the application - in the two calls to showDebugInformation.? Although the proof that I am right is contained in the value debugCounter in the method showDebugInformation in the current program, if you go to the link in my previous post and download? and run the Complex version of this, you can more easily see the departure of the JavaApplicationThread from the instance of handle which is on the stack - and at a method which is not handle (as it is in this one) followed by? it's recursive re-entry to handle , completion of that recursive-handle's execution and re-entry and then completion into the previous invocation of handle. It's is completely obvious in the output of that Applcation.? That application also throws the ConcurrentModificationException which is no way an artifact or misreading of a stacktrace.? However, what is at issue in this program is the value of debugCounter in?showDebugInformation. Cheers.? ? On Sunday, September 9, 2018 at 4:04 PM, John Hendrikx wrote: ? > I see nothing special in the stack trace. > > When you remove the component, a new MouseEvent *must* trigger > (MouseEvent.EXITED) as it always needs to match with > MouseEvent.ENTERED. > > So, the call to 'remove' triggers a new event, which gets handled by > the > same handler. ?It is indeed entered recursively, but in a normal > fashion. ?This has nothing to do with another thread or compiler > bugs. > > Don't be confused by the double "handle" lines in the stacktrace. > ?This > happens when methods are overriden (the line number is 1). > > There are two relevant lines in this trace: > > ? ?LabelEventHandler.handle(LabelEventHandler.java:95) > > ...where Remove is called, which triggers the recursive call later > on: > > ? ?LabelEventHandler.handle(LabelEventHandler.java:88) > > ... for the MouseEvent.EXITED event. > > The full stack trace is this: > > at > bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:88) > at > bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:1) > at > javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218) > at > javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) > at > javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238) > at > javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > at > javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > at > javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > at > javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > at > javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > at > javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) > at javafx.base/javafx.event.Event.fireEvent(Event.java:198) > at > javafx.base/com.sun.javafx.event.EventQueue.fire(EventQueue.java:48) > at > javafx.graphics/javafx.scene.Scene$MouseHandler.handleNodeRemoval(Scene.java:3717) > at > javafx.graphics/javafx.scene.Scene$MouseHandler.access$7800(Scene.java:3604) > at > javafx.graphics/javafx.scene.Scene.generateMouseExited(Scene.java:3601) > at > javafx.graphics/javafx.scene.Parent$3.onProposedChange(Parent.java:613) > at > javafx.base/com.sun.javafx.collections.VetoableListDecorator.remove(VetoableListDecorator.java:329) > at > javafx.base/com.sun.javafx.collections.VetoableListDecorator.remove(VetoableListDecorator.java:221) > at > bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:95) > at > bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:1) > at > javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218) > > (... rest cut off as it is not needed ... ) > > --John > > On 09/09/2018 19:05, javafx at use.startmail.com wrote: >> Hi All, >> I spent some time refactoring the program which displays this bug. >> It's >> now small enough to share the source in an email, but it is very >> very >> dense and the proof of bug, one ?specific line to standard I/O, >> requires >> the source code to be read and understood in order to see the bug. >> As I >> said previously, more comprehensible and user-friendly versions of >> this >> program are ?available at . The javadoc is more copious, the bug is >> manifested as an exception and the side effect of the bug are more >> consequential. >> >> This brief version cnosists of just two classes. Here is the JavaFX >> Application class: >> >> *************************************************************************** >> >> package bareBonesJavaFXBugExample; >> >> >> import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.control.Label; >> import javafx.scene.input.MouseEvent; >> import javafx.scene.layout.Pane; >> import javafx.stage.Stage; >> >> >> >> /** >> ?* An {@link Application} with one {@link Pane} containing one >> {@link >> Label}. The {@link Label} has a single {@link >> javafx.event.EventHandler}, {@link LabelEventHandler} which >> processes >> all {@link MouseEvent}s the {@link Label} receives. >> ?*

>> ?* To trigger the bug, run the application, then spend a second >> mouse >> over the little label in the upper left hand corner of the scrren. >> You >> will see output to standard I/O. Then, click the label, which will >> then >> disppear. Check the I/O for Strings ending in debugCounter is 1. >>

>> ?* What that String means and how it proves that the JavaFX >> Application >> Thread has become reentrant is explained in the javadoc of {@link >> LabelEventHandler}. >> ?*/ >> public class JavaFXAnomalyBareBonesApplication extends Application >> { >> ? ? public void start(Stage primaryStage) >> ? ? { >> >> ? ? ? Pane mainPane = new Pane(); >> ? ? ? mainPane.setMinHeight(800); >> ? ? ? mainPane.setMinWidth(800); >> >> ? ? ? Label label = new Label(" this is quite a bug !!!!"); >> >> ? ? ? LabelEventHandler labelEventHandler = new >> LabelEventHandler(mainPane, label); >> ? ? ? label.addEventHandler(MouseEvent.ANY, labelEventHandler); >> >> ? ? ? mainPane.getChildren().add(label); >> >> >> ? ? ? Scene scene = new Scene(mainPane); >> ? ? ? primaryStage.setScene(scene); >> ? ? ? primaryStage.show(); >> >> ? ? } >> >> >> >> ? ? /** >> ? ? ?* The entry point of application. >> ? ? ?* >> ? ? ?* @param args >> ? ? ?* ? ? ? ? the input arguments >> ? ? ?*/ >> ? ? public static void main(String[] args) >> ? ? { >> >> ? ? ? ? launch(args); >> ? ? } >> >> >> >> } >> >> >> *************************************************************************** >> >> and here is its only dependency, the EventListener class. I included >> enough javadoc to have the program makes sense. : >> >> *************************************************************************** >> >> package bareBonesJavaFXBugExample; >> >> >> >> import javafx.event.Event; >> import javafx.event.EventHandler; >> import javafx.scene.control.Label; >> import javafx.scene.input.MouseEvent; >> import javafx.scene.layout.Pane; >> >> import java.util.Collection; >> import java.util.ConcurrentModificationException; >> >> /** >> ?* An {@link EventHandler} implementation for {@link MouseEvent}s. >>

This implementation's {@link EventHandler#handle(Event)} >> shows >> the relevant debug information to standard output before and after >> removing the member {@link #label} from the {@link #pane}. >> ?*

>> ?* discussion

>> ?*

>> ?* Users should first satisfy themselves that the value of {@link >> LabelEventHandler#debugCounter} can only be non-zero, in fact 1 >> (one) in >> the method {@link LabelEventHandler#showDebugInformation(String)} if >> the >> method {@link LabelEventHandler#handle(MouseEvent)} ?has been >> re-entered >> recursively, that is, before a previous invocation of {@link >> LabelEventHandler#handle(MouseEvent)} has returned. >> ?*

>> ?* Proof:

1) debugCounter starts at value 0 >> (zero). >>

2) debugCounter is only incremented once, by 1 >> (one), and that is after the first call to {@link >> LabelEventHandler#showDebugInformation(String)} has returned.

>> 3) >> debugCounter is only decremented once, by 1 (one) and >> that >> is before the last call to {@link >> LabelEventHandler#showDebugInformation(String)}.

4) however, >> because >> ?* debugCounter is a class variable ( it's static), if >> handle() is recurvsively re-entered then it's value can be 1 (one) >> when >> the re-entrant Thread executes {@link >> LabelEventHandler#showDebugInformation(String)} >> ?*

>> ?* End proof. >> ?*

>> ?*

>> ?*

>> ?* The output of this method to standard I/O is volumnious but >> searching >> the output for the exact String "debugCounter is 1" will immediately >> show the {@link LabelEventHandler#handle(MouseEvent)} method to have >> been recursively entered.

>> ?* Some other possibilities other than the JavaFX Application Thread >> recursing into {@code handle()} need to be addressed.

One is >> the >> fact that the compiler is free to reorder statements if it can >> ?* prove that such a reordering would have no effect on the >> program's >> correctness. >> ?*

>> ?* So somehow the compiler is reordering the increment/decrement of >> {@code ?debugCounter} and the calls to {@code ? >> showDebugInformation}. >>

But this would alter the correctness of the program, so >> this >> cannot be the case, or the compiler is making an error.

>> ?*

>> ?*

>> ?* Another is the fact that I/O is not instantaneous and can appear >> to >> standard output later than it actually was executed.

This >> is >> something often seen in debug stack traces, where the output is >> broken >> up ?or interleaved by the output of the stack trace even though the >> two >> sets of statments, i/o and stack trace i/o, were strictly ordered in >> execution.

But this can't account for the value of {@code >> ?debugCounter}, so it can't >> ?* be the reason "debugCounter is 1" appears in output.

In >> fact >> we can make this recursive behaviour more obviously consequential to >> the >> correctness of the program.

If {@code ? handle() } is being >> recursively re-entered, then we can force a {@link >> ConcurrentModificationException} on a {@link Collection}. ?

>> If >> we try to invoke {@link Collection#add(Object)} to a {@link >> Collection} >> while it is being iterated through, then a >> ?* {@link ConcurrentModificationException} will be thrown.

If >> we >> re-write this program slightly to first add or remove to or from a >> {@link Collection} then iterate through that {@link Collection} >> within >> the scope of ?execution of {@code ? handle()}, and {@code >> ?handle()} is being recursively invoked, then we may see a {@link >> ConcurrentModificationException}. >> ?*

>> ?* Two other instances of this same basic program exist at the link >> provided. They are named {@link >> JavaFXAnomalySimpleVersionApplication} >> and {@link JavaFXAnomalyComplexVersionApplication} which is written >> to >> throw a {@link ConcurrentModificationException} when the JavaFX >> Application Thread becomes reentrant. >> ?*

>> ?* I also have a screen grab (not included here) of the stack trace >> at a >> specific moment handle()/code> is being invoked, and it can >> clearly be seen that the previous executing line was within the >> scope of >> execution of the previous invocation of handle(). >> ?*

>> ?* In the .zip file at the link there is a readme.txt. In that file. >> I >> present the two lines of code which need to be added, and where they >> need to be added, ?so as to generate the same stack trace showing >> the >> same thing. >> ?* >> ?* >> ?*

>> ?*/ >> public class LabelEventHandler implements EventHandler >> { >> ? /** >> ? ?* a counter which acts as a recursion detector. If {@link >> #handle(MouseEvent)} is never recursively invoked by the JavaFX >> Application Thread, then it's value will never be other than 0 >> (zero) in >> {@link #showDebugInformation(String)}. >> ? ?*/ >> ? private static int debugCounter; >> >> ? /** >> ? ?* The {@link Label} which will disappear when clicked. This >> causes a >> MOUSE_EXITED_TARGET event top be fired and that in turn causes the >> JavaFX Event Dispatch Thread to recurse into this class's {@link >> #handle(MouseEvent)} >> ? ?*/ >> ? private Label label; >> ? /** >> ? ?* The {@link Pane} which contains the {@link Label}. The {@link >> Label} is removed from this {@link Pane}. >> ? ?*/ >> ? private final Pane pane; >> >> >> >> ? /** >> ? ?* Assign the values to the members {@link Pane} and {@link Label} >> ? ?*/ >> ? public LabelEventHandler(Pane pane, Label label) >> ? { >> >> ? ? this.pane = pane; >> ? ? this.label = label; >> ? } >> >> >> >> ? /** >> ? ?* Causes the member {@link #label} to be removed as a child of >> the >> member {@link #pane}. >> ? ?* >> ? ?* >> ? ?* @param mouseEvent >> ? ?* ? ? ? ? the {@link MouseEvent} received from the JavaFX >> Application >> Thread from the {@link Label} which this {@link EventHandler} is >> listening to. >> ? ?*/ >> ? @Override >> ? public void handle(MouseEvent mouseEvent) >> ? { >> >> ? ? showDebugInformation("ENTERING");// debug can only every be 0 >> (zero) >> at this point >> ? ? debugCounter++; >> >> >> ? ? if (mouseEvent.getEventType().equals(MouseEvent.MOUSE_PRESSED) >> && >> mouseEvent.isPrimaryButtonDown()) >> ? ? { >> ? ? ? pane.getChildren().remove(label); >> ? ? } >> >> ? ? debugCounter--; >> ? ? showDebugInformation("EXITING");// debug can only every be 0 >> (zero) >> at this point >> ? } >> >> >> >> ? /** >> ? ?* Displays two values to standard output. The first is a {@link >> String} ?indicating whether the {@link >> LabelEventHandler#handle(MouseEvent)} method is being entered or >> exited >> and the second is the value of {@link >> LabelEventHandler#debugCounter} at >> the time this method is executed. >> ? ?* >> ? ?* @param enterOrExit >> ? ?* ? ? ? ? the string ENTERING or EXITING reflecting the point ?at >> which this method was invoked by {@link >> LabelEventHandler#handle(MouseEvent)}. >> ? ?*/ >> ? private void showDebugInformation(String enterOrExit) >> ? { >> >> ? ? System.out.println(); >> ? ? System.out.print(enterOrExit + " method handle"); >> ? ? System.out.print(" and debugCounter is " + debugCounter); >> ? ? System.out.println(); >> ? } >> >> >> >> >> >> } >> >> >> >> ******************************************************************* >> >> Just cut and pasting these two into files named by ?their >> ?respective >> Java class names, then ?placing those ?files into a folder >> named bareBonesJavaFXBugExample is all it should ?take to make this >> work. >> >> Unless I get contrary ?feedback, I will file this as a bug after I >> run >> it against the most recent releases of the JavaFX. >> >> Either way I am interested in feedback from the community. >> >> Cheers ! >> >> >> >> >> On Saturday, September 8, 2018 at 8:02 AM, Kevin Rushforth >> wrote: >> ? >>> I am not aware of such a bug. If you have a test program, then you >>> can >>> file a bug here: >>> >>> https://bugreport.java.com/ >>> >>> -- Kevin >>> >>> >>> On 9/7/2018 5:37 PM, javafx at use.startmail.com wrote: >>>> Hi, >>>> >>>> I have a couple of very small apps (3 small classes in one case >>>> and 5 >>>> in another) ?which demonstrate that, under some circumstances, the >>>> JavaFX Application Thread will recursively re-enter >>>> EventHandler#handle(). >>>> >>>> So this means that it is already in handle (and calls therefrom) >>>> and >>>> will, in some situations not complete that ?processing (thus >>>> exiting >>>> handle) before it reappears in the same instance of EventHandler's >>>> handle method again. So this is true recursion. >>>> >>>> I actually don't know if this is expected behavior or not. No one >>>> I've >>>> talked to expected it; the general understanding is the JavaFX >>>> Application Thread (processing) is specifically single-threaded >>>> and >>>> also that it will defintily complete one invocation of handle() >>>> before >>>> beginning another one. >>>> >>>> I have to say that there is NO other Thread ?in play here, at >>>> least no >>>> other Thread my applications create (what's going on >>>> QuantumToolKit >>>> may be a different story.) >>>> >>>> The material upshot of this is it can lead to apparent ?program >>>> incorrectness if the dev believes that it's not the case, and 100% >>>> of >>>> devs I've talked to think it's not possible. >>>> >>>> I am happy to post or attach the classes or modules as requested >>>> but >>>> first I wanted to check to see if in fact this is already known to >>>> be >>>> true and is in fact ?expected behavior, in which case it's a >>>> non-issue >>>> and just a subtlety people are not aware of. >>>> >>>> Thank you so much ! From brian.r.hudson at gmail.com Mon Sep 10 15:22:23 2018 From: brian.r.hudson at gmail.com (Brian Hudson) Date: Mon, 10 Sep 2018 11:22:23 -0400 Subject: Animation enhancements Message-ID: I would love to see "Animation needs more events" resolved [1]. Maybe following events: started, paused, resumed, cycleStarted, cycleEnded, stopped/ended? These additional life cycle events would allow me to do some things with animations/transitions that I've been struggling to do. There may even be use cases events for starting, pausing, resuming, cycleStarting, cycleEnding, stopping/ending. [1]: https://bugs.openjdk.java.net/browse/JDK-8092408 From nlisker at gmail.com Tue Sep 11 08:42:23 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 11 Sep 2018 11:42:23 +0300 Subject: Animation enhancements In-Reply-To: References: Message-ID: Hi Brian, Thanks for the input. How is "starting" different from "started" etc.? On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson wrote: > I would love to see "Animation needs more events" resolved [1]. > > Maybe following events: started, paused, resumed, cycleStarted, cycleEnded, > stopped/ended? These additional life cycle events would allow me to do some > things with animations/transitions that I've been struggling to do. > > There may even be use cases events for starting, pausing, resuming, > cycleStarting, cycleEnding, stopping/ending. > > [1]: https://bugs.openjdk.java.net/browse/JDK-8092408 > From brian.r.hudson at gmail.com Tue Sep 11 13:09:18 2018 From: brian.r.hudson at gmail.com (Brian Hudson) Date: Tue, 11 Sep 2018 09:09:18 -0400 Subject: Animation enhancements In-Reply-To: References: Message-ID: starting: Indicates that the animation is about to start. This is the last opportunity to change an aspect of the animation that cannot be changed once the animation has started. PathTransition duration for example. started: The animation has started. The "-ed" actions are really what I've had a need for, other than "starting" I can't really think of use cases for the other "-ing" events On Tue, Sep 11, 2018 at 4:42 AM Nir Lisker wrote: > Hi Brian, > > Thanks for the input. How is "starting" different from "started" etc.? > > On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson > wrote: > >> I would love to see "Animation needs more events" resolved [1]. >> >> Maybe following events: started, paused, resumed, cycleStarted, >> cycleEnded, >> stopped/ended? These additional life cycle events would allow me to do >> some >> things with animations/transitions that I've been struggling to do. >> >> There may even be use cases events for starting, pausing, resuming, >> cycleStarting, cycleEnding, stopping/ending. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8092408 >> > From nlisker at gmail.com Tue Sep 11 13:50:56 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 11 Sep 2018 16:50:56 +0300 Subject: Animation enhancements In-Reply-To: References: Message-ID: Hi Rick, Seems to me like multiple onFinished event handlers [1]. The first comment there lists a plan for multiple event handlers in general. [1] https://bugs.openjdk.java.net/browse/JDK-8091406 On Tue, Sep 11, 2018 at 4:07 PM Rick Walker wrote: > Dear Nir, > > Please forgive me if I am not following protocol - I rarely contribute to > this mailing list. > > I find myself constantly wrapping an animation within a ParallelTransition > or SerialTransition so that setOnFinished can be called twice - once for > the core animation and again by higher level code. > Can you figure out a way to do this in a cleaner, simpler way? > > Like this: > > public Animation getFadeOut() > { > // create a transition to fade out this node > FadeTransition fade = new FadeTransition(Duration.millis(300), this); > fade.setFromValue(this.getOpacity()); > fade.setToValue(0); > > // when complete, do something > fade.setOnFinished(e -> { /* do something here */ }); > > // wrap the fade out transition so that the caller of this method can > separately call setOnFinished() > ParallelTransition pt = new ParallelTransition(); > pt.getChildren().setAll(fade); > return pt; > } > > Best regards, > Rick Walker > > > On Tue, 11 Sep 2018 at 04:54, Nir Lisker wrote: > >> Hi Brian, >> >> Thanks for the input. How is "starting" different from "started" etc.? >> >> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson >> wrote: >> >> > I would love to see "Animation needs more events" resolved [1]. >> > >> > Maybe following events: started, paused, resumed, cycleStarted, >> cycleEnded, >> > stopped/ended? These additional life cycle events would allow me to do >> some >> > things with animations/transitions that I've been struggling to do. >> > >> > There may even be use cases events for starting, pausing, resuming, >> > cycleStarting, cycleEnding, stopping/ending. >> > >> > [1]: https://bugs.openjdk.java.net/browse/JDK-8092408 >> > >> > > > -- > Richard P. Walker > thoughtslinger at gmail.com > > This email is intended only for the use of the individual(s) to whom it is > addressed and may be privileged and confidential. Unauthorised use or > disclosure is prohibited. If you receive this e-mail in error, please > advise immediately and delete the original message. This message may have > been altered without your or our knowledge and the sender does not accept > any liability for any errors or omissions in the message. > > Ce courriel est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux > droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou > copie de ce message ou des renseignements qu'il contient par une personne > autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous > recevez ce courriel par erreur, veuillez m'en aviser imm?diatement, par > retour de courriel ou par un autre moyen. > From nlisker at gmail.com Tue Sep 11 14:11:21 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 11 Sep 2018 17:11:21 +0300 Subject: Animation enhancements In-Reply-To: References: Message-ID: So the "-ed" events are synchronous? That is, in case of "started", the animation needs to wait until the event handling finished and then start. In the case of "starting", the animation would start and call the event handler asynchronously (like "finished" does now). Synchronous events can be problematic because they interfere with the running of the animation. A "cycleStarting" (for example) handler will need to suspend the animation somehow before each cycle for an unknown duration (because it can't know what you put in the handler code). This can be done in practice via something like Future, but I'm skeptical about how much this would fit with the current animation semantics. There is a case for "starting" though, which is that it doesn't interfere with a running animation, and that it can be used as a "prepare-then-start", as you said. But what happens when the animation is embedded in a sequential and parallel transitions? I agree that other "-ed" events are not that useful. We can discuss a "prepare-then-start" mechanism. On Tue, Sep 11, 2018 at 4:09 PM Brian Hudson wrote: > starting: Indicates that the animation is about to start. This is the last > opportunity to change an aspect of the animation that cannot be changed > once the animation has started. PathTransition duration for example. > > started: The animation has started. > > The "-ed" actions are really what I've had a need for, other than > "starting" I can't really think of use cases for the other "-ing" events > > On Tue, Sep 11, 2018 at 4:42 AM Nir Lisker wrote: > >> Hi Brian, >> >> Thanks for the input. How is "starting" different from "started" etc.? >> >> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson >> wrote: >> >>> I would love to see "Animation needs more events" resolved [1]. >>> >>> Maybe following events: started, paused, resumed, cycleStarted, >>> cycleEnded, >>> stopped/ended? These additional life cycle events would allow me to do >>> some >>> things with animations/transitions that I've been struggling to do. >>> >>> There may even be use cases events for starting, pausing, resuming, >>> cycleStarting, cycleEnding, stopping/ending. >>> >>> [1]: https://bugs.openjdk.java.net/browse/JDK-8092408 >>> >> From nlisker at gmail.com Tue Sep 11 14:20:21 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 11 Sep 2018 17:20:21 +0300 Subject: Animation enhancements In-Reply-To: References: Message-ID: Alright, Iv'e queued the multiple event handlers issue after the additional event types issue. On Tue, Sep 11, 2018 at 5:15 PM Rick Walker wrote: > Thank you, yes that looks like it, I had not seen that comment. > > On Tue, 11 Sep 2018 at 09:51, Nir Lisker wrote: > >> Hi Rick, >> >> Seems to me like multiple onFinished event handlers [1]. The first >> comment there lists a plan for multiple event handlers in general. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8091406 >> >> On Tue, Sep 11, 2018 at 4:07 PM Rick Walker >> wrote: >> >>> Dear Nir, >>> >>> Please forgive me if I am not following protocol - I rarely contribute >>> to this mailing list. >>> >>> I find myself constantly wrapping an animation within a >>> ParallelTransition or SerialTransition so that setOnFinished can be called >>> twice - once for the core animation and again by higher level code. >>> Can you figure out a way to do this in a cleaner, simpler way? >>> >>> Like this: >>> >>> public Animation getFadeOut() >>> { >>> // create a transition to fade out this node >>> FadeTransition fade = new FadeTransition(Duration.millis(300), this); >>> fade.setFromValue(this.getOpacity()); >>> fade.setToValue(0); >>> >>> // when complete, do something >>> fade.setOnFinished(e -> { /* do something here */ }); >>> >>> // wrap the fade out transition so that the caller of this method >>> can separately call setOnFinished() >>> ParallelTransition pt = new ParallelTransition(); >>> pt.getChildren().setAll(fade); >>> return pt; >>> } >>> >>> Best regards, >>> Rick Walker >>> >>> >>> On Tue, 11 Sep 2018 at 04:54, Nir Lisker wrote: >>> >>>> Hi Brian, >>>> >>>> Thanks for the input. How is "starting" different from "started" etc.? >>>> >>>> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson >>>> wrote: >>>> >>>> > I would love to see "Animation needs more events" resolved [1]. >>>> > >>>> > Maybe following events: started, paused, resumed, cycleStarted, >>>> cycleEnded, >>>> > stopped/ended? These additional life cycle events would allow me to >>>> do some >>>> > things with animations/transitions that I've been struggling to do. >>>> > >>>> > There may even be use cases events for starting, pausing, resuming, >>>> > cycleStarting, cycleEnding, stopping/ending. >>>> > >>>> > [1]: https://bugs.openjdk.java.net/browse/JDK-8092408 >>>> > >>>> >>> >>> >>> -- >>> Richard P. Walker >>> thoughtslinger at gmail.com >>> >>> This email is intended only for the use of the individual(s) to whom it >>> is addressed and may be privileged and confidential. Unauthorised use or >>> disclosure is prohibited. If you receive this e-mail in error, please >>> advise immediately and delete the original message. This message may have >>> been altered without your or our knowledge and the sender does not accept >>> any liability for any errors or omissions in the message. >>> >>> Ce courriel est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux >>> droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou >>> copie de ce message ou des renseignements qu'il contient par une personne >>> autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous >>> recevez ce courriel par erreur, veuillez m'en aviser imm?diatement, par >>> retour de courriel ou par un autre moyen. >>> >> > > -- > Richard P. Walker > thoughtslinger at gmail.com > > This email is intended only for the use of the individual(s) to whom it is > addressed and may be privileged and confidential. Unauthorised use or > disclosure is prohibited. If you receive this e-mail in error, please > advise immediately and delete the original message. This message may have > been altered without your or our knowledge and the sender does not accept > any liability for any errors or omissions in the message. > > Ce courriel est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux > droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou > copie de ce message ou des renseignements qu'il contient par une personne > autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous > recevez ce courriel par erreur, veuillez m'en aviser imm?diatement, par > retour de courriel ou par un autre moyen. > From brian.r.hudson at gmail.com Tue Sep 11 15:49:49 2018 From: brian.r.hudson at gmail.com (Brian Hudson) Date: Tue, 11 Sep 2018 11:49:49 -0400 Subject: Animation enhancements In-Reply-To: References: Message-ID: Async: started, cycleStarted, cycleEnded, ended, paused, resumed A "starting" event would have to be synchronous to work as I described. The other "-ing" events probably aren't useful an cause the complications you describe. On Tue, Sep 11, 2018 at 10:11 AM Nir Lisker wrote: > So the "-ed" events are synchronous? That is, in case of "started", the > animation needs to wait until the event handling finished and then start. > In the case of "starting", the animation would start and call the event > handler asynchronously (like "finished" does now). > > Synchronous events can be problematic because they interfere with the > running of the animation. A "cycleStarting" (for example) handler will need > to suspend the animation somehow before each cycle for an unknown duration > (because it can't know what you put in the handler code). This can be done > in practice via something like Future, but I'm skeptical about how much > this would fit with the current animation semantics. > > There is a case for "starting" though, which is that it doesn't interfere > with a running animation, and that it can be used as a > "prepare-then-start", as you said. But what happens when the animation is > embedded in a sequential and parallel transitions? > > I agree that other "-ed" events are not that useful. We can discuss a > "prepare-then-start" mechanism. > > On Tue, Sep 11, 2018 at 4:09 PM Brian Hudson > wrote: > >> starting: Indicates that the animation is about to start. This is the >> last opportunity to change an aspect of the animation that cannot be >> changed once the animation has started. PathTransition duration for example. >> >> started: The animation has started. >> >> The "-ed" actions are really what I've had a need for, other than >> "starting" I can't really think of use cases for the other "-ing" events >> >> On Tue, Sep 11, 2018 at 4:42 AM Nir Lisker wrote: >> >>> Hi Brian, >>> >>> Thanks for the input. How is "starting" different from "started" etc.? >>> >>> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson >>> wrote: >>> >>>> I would love to see "Animation needs more events" resolved [1]. >>>> >>>> Maybe following events: started, paused, resumed, cycleStarted, >>>> cycleEnded, >>>> stopped/ended? These additional life cycle events would allow me to do >>>> some >>>> things with animations/transitions that I've been struggling to do. >>>> >>>> There may even be use cases events for starting, pausing, resuming, >>>> cycleStarting, cycleEnding, stopping/ending. >>>> >>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8092408 >>>> >>> From nlisker at gmail.com Tue Sep 11 16:00:12 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 11 Sep 2018 19:00:12 +0300 Subject: Animation enhancements In-Reply-To: References: Message-ID: So the questions remain about embedded animations. If an animation has a "starting" and it is embedded, should it pause a sequential animation? This is the same problem with the the cycle synchronous events. For parallel, does it delay only itself so that the animations are not parallel anymore? Or, we could ignore this event when embedded. Do you have any other idea? On Tue, Sep 11, 2018 at 6:50 PM Brian Hudson wrote: > Async: started, cycleStarted, cycleEnded, ended, paused, resumed > > A "starting" event would have to be synchronous to work as I described. > The other "-ing" events probably aren't useful an cause the complications > you describe. > > > > On Tue, Sep 11, 2018 at 10:11 AM Nir Lisker wrote: > >> So the "-ed" events are synchronous? That is, in case of "started", the >> animation needs to wait until the event handling finished and then start. >> In the case of "starting", the animation would start and call the event >> handler asynchronously (like "finished" does now). >> >> Synchronous events can be problematic because they interfere with the >> running of the animation. A "cycleStarting" (for example) handler will need >> to suspend the animation somehow before each cycle for an unknown duration >> (because it can't know what you put in the handler code). This can be done >> in practice via something like Future, but I'm skeptical about how much >> this would fit with the current animation semantics. >> >> There is a case for "starting" though, which is that it doesn't interfere >> with a running animation, and that it can be used as a >> "prepare-then-start", as you said. But what happens when the animation is >> embedded in a sequential and parallel transitions? >> >> I agree that other "-ed" events are not that useful. We can discuss a >> "prepare-then-start" mechanism. >> >> On Tue, Sep 11, 2018 at 4:09 PM Brian Hudson >> wrote: >> >>> starting: Indicates that the animation is about to start. This is the >>> last opportunity to change an aspect of the animation that cannot be >>> changed once the animation has started. PathTransition duration for example. >>> >>> started: The animation has started. >>> >>> The "-ed" actions are really what I've had a need for, other than >>> "starting" I can't really think of use cases for the other "-ing" events >>> >>> On Tue, Sep 11, 2018 at 4:42 AM Nir Lisker wrote: >>> >>>> Hi Brian, >>>> >>>> Thanks for the input. How is "starting" different from "started" etc.? >>>> >>>> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson >>>> wrote: >>>> >>>>> I would love to see "Animation needs more events" resolved [1]. >>>>> >>>>> Maybe following events: started, paused, resumed, cycleStarted, >>>>> cycleEnded, >>>>> stopped/ended? These additional life cycle events would allow me to do >>>>> some >>>>> things with animations/transitions that I've been struggling to do. >>>>> >>>>> There may even be use cases events for starting, pausing, resuming, >>>>> cycleStarting, cycleEnding, stopping/ending. >>>>> >>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8092408 >>>>> >>>> From nlisker at gmail.com Wed Sep 12 08:42:20 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 12 Sep 2018 11:42:20 +0300 Subject: JDK-8210361: Add images to docs for public API classes of controls Message-ID: Hi, Iv'e started working on JDK-8210361 [1] and I'd like my comment there addressed before continuing. [1] https://bugs.openjdk.java.net/browse/JDK-8210361 Thanks, Nir From venatorxoa at gmail.com Wed Sep 12 08:52:39 2018 From: venatorxoa at gmail.com (Vincent MOLLIERE) Date: Wed, 12 Sep 2018 10:52:39 +0200 Subject: Parallel Camera in Java 9+ Message-ID: Hi, I am new to this list so let me know if I?m wrong somewhere. In my development, I?m using JavaFX 3d in an extensive manner. I developed a JavaFX 3D framework, compensating flows and missing features. One of this flaws in the ParallelCamera, the position and clippings are calculated weirdly. And there is no zoom. I have developed a new implementation of camera that calculate correctly this parameters. This new class only work if I put in a jar, and copy it the the ext folder in the jdk, if not, its implemented functions are not called. The problem is from JDK 9, the ext folder was deleted, and I cannot use anymore this camera. I tried in JDK10 with JavaFX libraries from Maven and it does not work too (the implemented functions are not called) What could be a solution for this problem ? Thank you for your help. From kevin.rushforth at oracle.com Wed Sep 12 11:44:59 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 12 Sep 2018 04:44:59 -0700 Subject: JDK-8210361: Add images to docs for public API classes of controls In-Reply-To: References: Message-ID: They look fine to me. I think placing them next to the code sample, near the bottom, seems best. -- Kevin On 9/12/2018 1:42 AM, Nir Lisker wrote: > Hi, > > Iv'e started working on JDK-8210361 [1] and I'd like my comment there > addressed before continuing. > > [1] https://bugs.openjdk.java.net/browse/JDK-8210361 > > Thanks, > Nir From kevin.rushforth at oracle.com Wed Sep 12 12:16:18 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 12 Sep 2018 05:16:18 -0700 Subject: Parallel Camera in Java 9+ In-Reply-To: References: Message-ID: <151d4619-7718-f6d8-d803-d1376cc86acf@oracle.com> Hi Vincent, As of JDK 9 the Standard Extension mechanism, as implemented by the "lib/ext" directory in the JDK, has been removed. If you need to locally modify a class in one of the javafx.* modules you will either need to build JavaFX from source or patch the module (presumably, javafx.graphics) using the "--patch-module" option of "java". -- Kevin On 9/12/2018 1:52 AM, Vincent MOLLIERE wrote: > Hi, > > I am new to this list so let me know if I?m wrong somewhere. > > In my development, I?m using JavaFX 3d in an extensive manner. > > I developed a JavaFX 3D framework, compensating flows and missing features. > > One of this flaws in the ParallelCamera, the position and clippings are > calculated weirdly. And there is no zoom. > > I have developed a new implementation of camera that calculate correctly > this parameters. This new class only work if I put in a jar, and copy it > the the ext folder in the jdk, if not, its implemented functions are not > called. > > The problem is from JDK 9, the ext folder was deleted, and I cannot use > anymore this camera. I tried in JDK10 with JavaFX libraries from Maven and > it does not work too (the implemented functions are not called) > > What could be a solution for this problem ? > > Thank you for your help. From venatorxoa at gmail.com Wed Sep 12 12:24:40 2018 From: venatorxoa at gmail.com (Vincent MOLLIERE) Date: Wed, 12 Sep 2018 14:24:40 +0200 Subject: Parallel Camera in Java 9+ In-Reply-To: <151d4619-7718-f6d8-d803-d1376cc86acf@oracle.com> References: <151d4619-7718-f6d8-d803-d1376cc86acf@oracle.com> Message-ID: I understand that, but for commercial products we try to avoid touching the jdk. I did it to disable image view smoothing. My point beyond that (we can stay in jdk 8 there is no rush to update to the latest jdk) is to improve JavaFx 3D API and implementations. I have some feature request I think are necessary, and one of them is a working parallel camera. We use it in our analysis software. Le mer. 12 sept. 2018 ? 14:16, Kevin Rushforth a ?crit : > Hi Vincent, > > As of JDK 9 the Standard Extension mechanism, as implemented by the > "lib/ext" directory in the JDK, has been removed. If you need to locally > modify a class in one of the javafx.* modules you will either need to > build JavaFX from source or patch the module (presumably, > javafx.graphics) using the "--patch-module" option of "java". > > -- Kevin > > > On 9/12/2018 1:52 AM, Vincent MOLLIERE wrote: > > Hi, > > > > I am new to this list so let me know if I?m wrong somewhere. > > > > In my development, I?m using JavaFX 3d in an extensive manner. > > > > I developed a JavaFX 3D framework, compensating flows and missing > features. > > > > One of this flaws in the ParallelCamera, the position and clippings are > > calculated weirdly. And there is no zoom. > > > > I have developed a new implementation of camera that calculate correctly > > this parameters. This new class only work if I put in a jar, and copy it > > the the ext folder in the jdk, if not, its implemented functions are not > > called. > > > > The problem is from JDK 9, the ext folder was deleted, and I cannot use > > anymore this camera. I tried in JDK10 with JavaFX libraries from Maven > and > > it does not work too (the implemented functions are not called) > > > > What could be a solution for this problem ? > > > > Thank you for your help. > > From pedro.duquevieira at gmail.com Wed Sep 12 13:18:35 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 12 Sep 2018 14:18:35 +0100 Subject: JDK-8210361: Add images to docs for public API classes of controls Message-ID: I would remove the window decorations. That's platform dependent, windows, linux, mac have different aesthetics for this. They also don't add any value to the representation of the control. That's what I usually do. Cheers, -- Pedro Duque Vieira - https://www.pixelduke.com From kevin.rushforth at oracle.com Wed Sep 12 14:41:17 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 12 Sep 2018 07:41:17 -0700 Subject: Parallel Camera in Java 9+ In-Reply-To: References: <151d4619-7718-f6d8-d803-d1376cc86acf@oracle.com> Message-ID: I thought your question was about a replacement for copying a jar file into $JAVA_HOME/lib/ext (which also touches the JDK). If you are interested in fixing a bug or otherwise improving JavaFX, then please see the OpenJDK page [1] about becoming a contributor. There is a GitHub sandbox [2] that you can fork and use to prototype your fix and eventually send a pull request when ready. See CONTRIBUTING.md [3] if you are interesting in contributing using the GitHub sandbox. There are a couple of known bugs in ParallelCamera when working with 3D objects, so you might check the bug database [4] to see if it has already been filed. Otherwise, you can file a new bug [5]. -- Kevin [1] http://openjdk.java.net/contribute/ [2] https://github.com/javafxports/openjdk-jfx [3] https://github.com/javafxports/openjdk-jfx/blob/develop/.github/CONTRIBUTING.md [4] https://bugs.openjdk.java.net/ [5] https://bugreport.java.com/bugreport/ On 9/12/2018 5:24 AM, Vincent MOLLIERE wrote: > > I understand that, but for commercial products we try to avoid > touching the jdk. I did it to disable image view smoothing. My point > beyond that (we can stay in jdk 8 there is no rush to update to the > latest jdk) is to improve JavaFx 3D API and implementations. I have > some feature request I think are necessary, and one of them is a > working parallel camera. We use it in our analysis software. > > > Le?mer. 12 sept. 2018 ??14:16, Kevin Rushforth > > a ?crit?: > > Hi Vincent, > > As of JDK 9 the Standard Extension mechanism, as implemented by the > "lib/ext" directory in the JDK, has been removed. If you need to > locally > modify a class in one of the javafx.* modules you will either need to > build JavaFX from source or patch the module (presumably, > javafx.graphics) using the "--patch-module" option of "java". > > -- Kevin > > > On 9/12/2018 1:52 AM, Vincent MOLLIERE wrote: > > Hi, > > > > I am new to this list so let me know if I?m wrong somewhere. > > > > In my development, I?m using JavaFX 3d in an extensive manner. > > > > I developed a JavaFX 3D framework, compensating flows and > missing features. > > > > One of this flaws in the ParallelCamera, the position and > clippings are > > calculated weirdly. And there is no zoom. > > > > I have developed a new implementation of camera that calculate > correctly > > this parameters. This new class only work if I put in a jar, and > copy it > > the the ext folder in the jdk, if not, its implemented functions > are not > > called. > > > > The problem is from JDK 9, the ext folder was deleted, and I > cannot use > > anymore this camera. I tried in JDK10 with JavaFX libraries from > Maven and > > it does not work too (the implemented functions are not called) > > > > What could be a solution for this problem ? > > > > Thank you for your help. > From nlisker at gmail.com Wed Sep 12 14:50:59 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 12 Sep 2018 17:50:59 +0300 Subject: JDK-8210361: Add images to docs for public API classes of controls In-Reply-To: References: Message-ID: That's sensible, though for Alert and the like I think they should stay as it's effectively part of the control. On Wed, Sep 12, 2018 at 4:19 PM Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > I would remove the window decorations. That's platform dependent, windows, > linux, mac have different aesthetics for this. They also don't add any > value to the representation of the control. > > That's what I usually do. > > Cheers, > > > > > -- > Pedro Duque Vieira - https://www.pixelduke.com > From pedro.duquevieira at gmail.com Wed Sep 12 14:57:10 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 12 Sep 2018 15:57:10 +0100 Subject: JDK-8210361: Add images to docs for public API classes of controls In-Reply-To: References: Message-ID: Yes I agree with you. Controls on which their window decorations are a part of them, should show up with them. If those decorations change depending on the platform their running, I would put a note saying that. The vast majority of controls don't belong to that category. Cheers, On Wed, Sep 12, 2018 at 3:51 PM Nir Lisker wrote: > That's sensible, though for Alert and the like I think they should stay as > it's effectively part of the control. > > On Wed, Sep 12, 2018 at 4:19 PM Pedro Duque Vieira < > pedro.duquevieira at gmail.com> wrote: > >> I would remove the window decorations. That's platform dependent, windows, >> linux, mac have different aesthetics for this. They also don't add any >> value to the representation of the control. >> >> That's what I usually do. >> >> Cheers, >> >> >> >> >> -- >> Pedro Duque Vieira - https://www.pixelduke.com >> > -- Pedro Duque Vieira - https://www.pixelduke.com From kevin.rushforth at oracle.com Wed Sep 12 15:07:12 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 12 Sep 2018 08:07:12 -0700 Subject: JDK-8210361: Add images to docs for public API classes of controls In-Reply-To: References: Message-ID: <1b7e836d-7fd1-03ba-c746-5ff9ba3eb3ac@oracle.com> Agreed. For simple controls like checkbox, button, etc., it makes sense to use an undecorated Stage. It's less busy and puts the emphasis on the control being illustrated. -- Kevin On 9/12/2018 7:57 AM, Pedro Duque Vieira wrote: > Yes I agree with you. Controls on which their window decorations are a part > of them, should show up with them. If those decorations change depending on > the platform their running, I would put a note saying that. > > The vast majority of controls don't belong to that category. > > Cheers, > > On Wed, Sep 12, 2018 at 3:51 PM Nir Lisker wrote: > >> That's sensible, though for Alert and the like I think they should stay as >> it's effectively part of the control. >> >> On Wed, Sep 12, 2018 at 4:19 PM Pedro Duque Vieira < >> pedro.duquevieira at gmail.com> wrote: >> >>> I would remove the window decorations. That's platform dependent, windows, >>> linux, mac have different aesthetics for this. They also don't add any >>> value to the representation of the control. >>> >>> That's what I usually do. >>> >>> Cheers, >>> >>> >>> >>> >>> -- >>> Pedro Duque Vieira - https://www.pixelduke.com >>> From powers.anirvan at gmail.com Wed Sep 12 19:33:30 2018 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Thu, 13 Sep 2018 04:33:30 +0900 Subject: JDK-8210361: Add images to docs for public API classes of controls In-Reply-To: <1b7e836d-7fd1-03ba-c746-5ff9ba3eb3ac@oracle.com> References: <1b7e836d-7fd1-03ba-c746-5ff9ba3eb3ac@oracle.com> Message-ID: Hi Nir, Thanks for this RFE. Now other UI toolkits like GTK and QT have a separate gallery of controls[1][2]. I was considering to add something similar in JavaFX but I never got around to start working on it, mostly due to all the screenshots which is needed to be taken beforehand ! Since you will now take images of all the controls, you can consider to add a gallery in this RFE itself. But if you don't want then someone else (me) can volunteer to do this once this RFE is merged. Let me know what you decide :-) [1] : https://developer.gnome.org/gtk4/stable/ch03.html [2] : http://doc.qt.io/archives/qt-4.8/gallery.html On Thu 13 Sep, 2018, 12:07 AM Kevin Rushforth, wrote: > Agreed. For simple controls like checkbox, button, etc., it makes sense > to use an undecorated Stage. It's less busy and puts the emphasis on the > control being illustrated. > > -- Kevin > > > On 9/12/2018 7:57 AM, Pedro Duque Vieira wrote: > > Yes I agree with you. Controls on which their window decorations are a > part > > of them, should show up with them. If those decorations change depending > on > > the platform their running, I would put a note saying that. > > > > The vast majority of controls don't belong to that category. > > > > Cheers, > > > > On Wed, Sep 12, 2018 at 3:51 PM Nir Lisker wrote: > > > >> That's sensible, though for Alert and the like I think they should stay > as > >> it's effectively part of the control. > >> > >> On Wed, Sep 12, 2018 at 4:19 PM Pedro Duque Vieira < > >> pedro.duquevieira at gmail.com> wrote: > >> > >>> I would remove the window decorations. That's platform dependent, > windows, > >>> linux, mac have different aesthetics for this. They also don't add any > >>> value to the representation of the control. > >>> > >>> That's what I usually do. > >>> > >>> Cheers, > >>> > >>> > >>> > >>> > >>> -- > >>> Pedro Duque Vieira - https://www.pixelduke.com > >>> > > From nlisker at gmail.com Wed Sep 12 20:23:58 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 12 Sep 2018 23:23:58 +0300 Subject: JDK-8210361: Add images to docs for public API classes of controls In-Reply-To: References: <1b7e836d-7fd1-03ba-c746-5ff9ba3eb3ac@oracle.com> Message-ID: Hi Anirvan, A gallery will fit best in the tutorials. The page for UI controls [1] will be ideal in my opinion (put the gallery as the first link). About the screenshots: that page contains much more suitable screenshots in each control's page when it comes to a gallery. They are stylistic, show-off-ish, and present a wider range of possibilities and states for each control. The examples in the JavaDocs are minimalistic, with the point of showing how easy it is to create the control. They don't make for much of a gallery, but they do show the developer very quickly what that control they are looking at is for a WYSIWYG code example. I suggest you submit an RFE which relates to the general "update the tutorials" issue [2] (instead of the one I'm working on) and take the screenshots from those pages. [1] https://docs.oracle.com/javase/8/javafx/user-interface-tutorial/ui_controls.htm#JFXUI336 [2] https://bugs.openjdk.java.net/browse/JDK-8210360 - Nir On Wed, Sep 12, 2018 at 10:33 PM Anirvan Sarkar wrote: > Hi Nir, > > Thanks for this RFE. > > Now other UI toolkits like GTK and QT have a separate gallery of > controls[1][2]. > > I was considering to add something similar in JavaFX but I never got > around to start working on it, mostly due to all the screenshots which is > needed to be taken beforehand ! > > Since you will now take images of all the controls, you can consider to > add a gallery in this RFE itself. > > But if you don't want then someone else (me) can volunteer to do this once > this RFE is merged. > > Let me know what you decide :-) > > [1] : https://developer.gnome.org/gtk4/stable/ch03.html > [2] : http://doc.qt.io/archives/qt-4.8/gallery.html > > > On Thu 13 Sep, 2018, 12:07 AM Kevin Rushforth, > wrote: > >> Agreed. For simple controls like checkbox, button, etc., it makes sense >> to use an undecorated Stage. It's less busy and puts the emphasis on the >> control being illustrated. >> >> -- Kevin >> >> >> On 9/12/2018 7:57 AM, Pedro Duque Vieira wrote: >> > Yes I agree with you. Controls on which their window decorations are a >> part >> > of them, should show up with them. If those decorations change >> depending on >> > the platform their running, I would put a note saying that. >> > >> > The vast majority of controls don't belong to that category. >> > >> > Cheers, >> > >> > On Wed, Sep 12, 2018 at 3:51 PM Nir Lisker wrote: >> > >> >> That's sensible, though for Alert and the like I think they should >> stay as >> >> it's effectively part of the control. >> >> >> >> On Wed, Sep 12, 2018 at 4:19 PM Pedro Duque Vieira < >> >> pedro.duquevieira at gmail.com> wrote: >> >> >> >>> I would remove the window decorations. That's platform dependent, >> windows, >> >>> linux, mac have different aesthetics for this. They also don't add any >> >>> value to the representation of the control. >> >>> >> >>> That's what I usually do. >> >>> >> >>> Cheers, >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Pedro Duque Vieira - https://www.pixelduke.com >> >>> >> >> From kevin.rushforth at oracle.com Thu Sep 13 12:42:04 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Sep 2018 05:42:04 -0700 Subject: [11] RFR: JDK-8210691: Deliver release notes for JavaFX 11 Message-ID: <54c53052-9178-68bb-c67a-71a7e6dc2e7c@oracle.com> Please review the following: https://bugs.openjdk.java.net/browse/JDK-8210691 https://github.com/javafxports/openjdk-jfx/pull/201 Here is the file is a human readable form: https://github.com/kevinrushforth/openjdk-jfx/blob/release-notes/doc-files/release-notes-11.md The review is happening on GitHub. -- Kevin From johan at lodgon.com Thu Sep 13 12:57:09 2018 From: johan at lodgon.com (Johan Vos) Date: Thu, 13 Sep 2018 14:57:09 +0200 Subject: [11] RFR: JDK-8210691: Deliver release notes for JavaFX 11 In-Reply-To: <54c53052-9178-68bb-c67a-71a7e6dc2e7c@oracle.com> References: <54c53052-9178-68bb-c67a-71a7e6dc2e7c@oracle.com> Message-ID: +1 (reviewed on GitHub) Op do 13 sep. 2018 om 14:55 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8210691 > https://github.com/javafxports/openjdk-jfx/pull/201 > > Here is the file is a human readable form: > > https://github.com/kevinrushforth/openjdk-jfx/blob/release-notes/doc-files/release-notes-11.md > > The review is happening on GitHub. > > -- Kevin > > From amnojeeuw at gmail.com Thu Sep 13 18:47:32 2018 From: amnojeeuw at gmail.com (Amno Jeeuw) Date: Thu, 13 Sep 2018 14:47:32 -0400 Subject: Tutorial Message-ID: I'm looking for a installation tutorial for OpenJavaFX. Is there one that's up-to-date? Thanks in advance. From nlisker at gmail.com Fri Sep 14 12:22:38 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 14 Sep 2018 15:22:38 +0300 Subject: JI-9056801 : Scene: Allow to add a stylesheet using a typed URL, not a stringified URL In-Reply-To: References: Message-ID: Hi Michael, The issue in the JBS is JDK-8209921 [1]. getStylesheets() returns an ObservableList, it cannot be changed to ObservableList. What solution do you propose? [1] https://bugs.openjdk.java.net/browse/JDK-8209921 - Nir On Wed, Aug 22, 2018 at 9:47 PM Michael Binz wrote: > Hi all, > > I opened a proposal for an extension of the javafx.scene.Scene API to allow > to add a stylesheet using a typed java.net.URL. > > Currently the Scene class offers a list of stylesheet URLs in their > stringified representation accessible by Scene.getStylesheets(). > > The problem is that in some cases an URL instance encapsulates internal > state that gets lost in the conversion into its external form and back into > an URL instance, namely information on an URL handler. This ultimately > results in a failure (IOException file not found) when the Screen class > tries to load a stylesheet though code that loads the file contents using > URL#openStream() on the original URL instance can read the file contents > successfully. > > In my case the problem showed up when creating an executable jar file > containing my JavaFX application (using OneJar). The application startup > in this case installs a customized Classloader that implements special > logic for accessing the jars contained classes, This works transparently > for classes and resources, but the URLs returned by Class#getResource( name > ) do not survive the conversion to string and back because of the described > reason. > > There is a workaround that caches the resource in a temporary file and > passes this file's URL to the Scene's list of stylesheets, but this poses > other problems. > As a remark, other APIs in JavaFX use the same pattern of expecting > stringified URLs like the Image() constructor and have the same problem, > but offer alternative constructors accepting a stream which allows to solve > the problem nicely. > > Please discuss and decide if the proposal can be added as a change request > for JavaFX. > > Best wishes, > Michael. > From kevin.rushforth at oracle.com Fri Sep 14 12:51:25 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Sep 2018 05:51:25 -0700 Subject: Tutorial In-Reply-To: References: Message-ID: <8c314b9f-9369-d09a-2400-6d416f7d3fe4@oracle.com> A basic set of instructions is here: http://docs.gluonhq.com/javafx11/ Read the Introduction and then click on the other links for information on downloading the SDK or using JavaFX via maven modules. -- Kevin On 9/13/2018 11:47 AM, Amno Jeeuw wrote: > I'm looking for a installation tutorial for OpenJavaFX. Is there one that's > up-to-date? Thanks in advance. From kevin.rushforth at oracle.com Fri Sep 14 13:15:57 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Sep 2018 06:15:57 -0700 Subject: Tutorial In-Reply-To: <8c314b9f-9369-d09a-2400-6d416f7d3fe4@oracle.com> References: <8c314b9f-9369-d09a-2400-6d416f7d3fe4@oracle.com> Message-ID: <57d126b4-c4a6-8cf7-69a8-8e2246005b5e@oracle.com> I should note that this is an early-access build. The final release is planned for next week [1] at which time we will send out an announcement with more information. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/022004.html On 9/14/2018 5:51 AM, Kevin Rushforth wrote: > A basic set of instructions is here: > > http://docs.gluonhq.com/javafx11/ > > Read the Introduction and then click on the other links for > information on downloading the SDK or using JavaFX via maven modules. > > -- Kevin > > > On 9/13/2018 11:47 AM, Amno Jeeuw wrote: >> I'm looking for a installation tutorial for OpenJavaFX. Is there one >> that's >> up-to-date? Thanks in advance. > From kevin.rushforth at oracle.com Sat Sep 15 15:59:58 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 15 Sep 2018 08:59:58 -0700 Subject: [11] RFR: JDK-8210791: Update release notes for JavaFX 11 Message-ID: Please review the following updates for the JavaFX 11 release notes: https://bugs.openjdk.java.net/browse/JDK-8210791 https://github.com/javafxports/openjdk-jfx/pull/202 -- Kevin From tom.schindl at bestsolution.at Sat Sep 15 18:39:36 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 15 Sep 2018 20:39:36 +0200 Subject: JI-9056801 : Scene: Allow to add a stylesheet using a typed URL, not a stringified URL In-Reply-To: References: Message-ID: <17a71624-61eb-60d7-46ab-f37e6977d6e8@bestsolution.at> Hi, I don't understand why something should be lost but anyways I don't think JavaFX API is not the right place to fix a short coming of OneJar. As Nir pointed out it is next to impossible to retrofit the JavaFX API to URL with breaking it. Tom On 22.08.18 20:47, Michael Binz wrote: > Hi all, > > I opened a proposal for an extension of the javafx.scene.Scene API to allow > to add a stylesheet using a typed java.net.URL. > > Currently the Scene class offers a list of stylesheet URLs in their > stringified representation accessible by Scene.getStylesheets(). > > The problem is that in some cases an URL instance encapsulates internal > state that gets lost in the conversion into its external form and back into > an URL instance, namely information on an URL handler. This ultimately > results in a failure (IOException file not found) when the Screen class > tries to load a stylesheet though code that loads the file contents using > URL#openStream() on the original URL instance can read the file contents > successfully. > > In my case the problem showed up when creating an executable jar file > containing my JavaFX application (using OneJar). The application startup > in this case installs a customized Classloader that implements special > logic for accessing the jars contained classes, This works transparently > for classes and resources, but the URLs returned by Class#getResource( name > ) do not survive the conversion to string and back because of the described > reason. > > There is a workaround that caches the resource in a temporary file and > passes this file's URL to the Scene's list of stylesheets, but this poses > other problems. > As a remark, other APIs in JavaFX use the same pattern of expecting > stringified URLs like the Image() constructor and have the same problem, > but offer alternative constructors accepting a stream which allows to solve > the problem nicely. > > Please discuss and decide if the proposal can be added as a change request > for JavaFX. > > Best wishes, > Michael. > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From nlisker at gmail.com Sun Sep 16 13:01:33 2018 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 16 Sep 2018 16:01:33 +0300 Subject: JI-9056801 : Scene: Allow to add a stylesheet using a typed URL, not a stringified URL In-Reply-To: References: Message-ID: I think this needs to be discussed with a project lead - Kevin or Johan. On Sun, Sep 16, 2018 at 6:07 AM Michael Binz wrote: > Hi Nir, > > I understand that switching the API to use net.URL is not trivial. > > The only idea that comes to mind is to offer two list properties, the one > existing as today, holding stringified URLs for backwards compatibility, > and a second one that holds typed .net.URLs. The existing version can be > deprecated in favour of the typed version. > > Before starting such an effort it would be interesting if it is common > understanding that an URL instance is preferrable over a string URL. > Was there a special reason that JavaFX uses in its interfaces in many > places stringified URLs instead of the existing java.net.URL? > > Best wishes, > Michael. > > > Am Fr., 14. Sep. 2018 um 14:23 Uhr schrieb Nir Lisker : > >> Hi Michael, >> >> The issue in the JBS is JDK-8209921 [1]. >> >> getStylesheets() returns an ObservableList, it cannot be changed >> to ObservableList. What solution do you propose? >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8209921 >> >> - Nir >> >> On Wed, Aug 22, 2018 at 9:47 PM Michael Binz wrote: >> >>> Hi all, >>> >>> I opened a proposal for an extension of the javafx.scene.Scene API to >>> allow >>> to add a stylesheet using a typed java.net.URL. >>> >>> Currently the Scene class offers a list of stylesheet URLs in their >>> stringified representation accessible by Scene.getStylesheets(). >>> >>> The problem is that in some cases an URL instance encapsulates internal >>> state that gets lost in the conversion into its external form and back >>> into >>> an URL instance, namely information on an URL handler. This ultimately >>> results in a failure (IOException file not found) when the Screen class >>> tries to load a stylesheet though code that loads the file contents using >>> URL#openStream() on the original URL instance can read the file contents >>> successfully. >>> >>> In my case the problem showed up when creating an executable jar file >>> containing my JavaFX application (using OneJar). The application startup >>> in this case installs a customized Classloader that implements special >>> logic for accessing the jars contained classes, This works transparently >>> for classes and resources, but the URLs returned by Class#getResource( >>> name >>> ) do not survive the conversion to string and back because of the >>> described >>> reason. >>> >>> There is a workaround that caches the resource in a temporary file and >>> passes this file's URL to the Scene's list of stylesheets, but this poses >>> other problems. >>> As a remark, other APIs in JavaFX use the same pattern of expecting >>> stringified URLs like the Image() constructor and have the same problem, >>> but offer alternative constructors accepting a stream which allows to >>> solve >>> the problem nicely. >>> >>> Please discuss and decide if the proposal can be added as a change >>> request >>> for JavaFX. >>> >>> Best wishes, >>> Michael. >>> >> From tom.schindl at bestsolution.at Mon Sep 17 05:27:42 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 17 Sep 2018 07:27:42 +0200 Subject: JI-9056801 : Scene: Allow to add a stylesheet using a typed URL, not a stringified URL In-Reply-To: References: <17a71624-61eb-60d7-46ab-f37e6977d6e8@bestsolution.at> Message-ID: <9500dfac-3bd3-887a-a84c-e06cc193b908@bestsolution.at> [you replied offlist but I guess that was an oversight so I bring it back] Reading through the document I don't see what concept is not working, but indeed the URL-constructor says that the protocol handler is resolved when constructing the URL. Does OneJar rely on that fact? The Stackoverflow problem who talks about Felix is strange as Felix returns in the toExternalForm() approach a custom protocol (bundle:) and Felix like eg Equinox installs an URLHandler for that protocol. URL-Handlers work prefectly fine - I know that because I maintain e(fx)clipse who is based on Equinox and we there make extensive usage of that and never had any trouble. I also found: http://one-jar.sourceforge.net/index.php?page=frameworks who talks about a custom protocol supported by OneJar but as I've never used OneJar (we use maven-shade for stuff like this) I don't know if this applies to this problem. Tom On 16.09.18 05:24, Michael Binz wrote: > Hi, > > actually this is not a problem with a particular tool we use.? The > problem is that some of the concepts described in [1] that are used for > resource loading do not longer work. This impacts all tools that base > their functionality on this,? See [2] for other situations where > classloader-based resource-loading fails. > > Michael. > > [1] > https://docs.oracle.com/javase/8/docs/technotes/guides/lang/resources.html > [2] > https://stackoverflow.com/questions/20000897/javafx-stylesheets-inside-osgi-bundle > > > Am Sa., 15. Sep. 2018 um 20:40?Uhr schrieb Tom Schindl > >: > > Hi, > > I don't understand why something should be lost but anyways I don't > think JavaFX API is not the right place to fix a short coming of OneJar. > As Nir pointed out it is next to impossible to retrofit the JavaFX API > to URL with breaking it. > > Tom > > On 22.08.18 20:47, Michael Binz wrote: > > Hi all, > > > > I opened a proposal for an extension of the javafx.scene.Scene API > to allow > > to add a stylesheet using a typed java.net.URL. > > > > Currently the Scene class offers a list of stylesheet URLs in their > > stringified representation accessible by Scene.getStylesheets(). > > > > The problem is that in some cases an URL instance encapsulates > internal > > state that gets lost in the conversion into its external form and > back into > > an URL instance, namely information on an URL handler. This ultimately > > results in a failure (IOException file not found) when the Screen > class > > tries to load a stylesheet though code that loads the file > contents using > > URL#openStream() on the original URL instance can read the file > contents > > successfully. > > > > In my case the problem showed up when creating an executable jar file > > containing my JavaFX application (using OneJar).? The application > startup > > in this case installs a customized Classloader that implements special > > logic for accessing the jars contained classes,? This works > transparently > > for classes and resources, but the URLs returned by > Class#getResource( name > > ) do not survive the conversion to string and back because of the > described > > reason. > > > > There is a workaround that caches the resource in a temporary file and > > passes this file's URL to the Scene's list of stylesheets, but > this poses > > other problems. > > As a remark, other APIs in JavaFX use the same pattern of expecting > > stringified URLs like the Image() constructor and have the same > problem, > > but offer alternative constructors accepting a stream which allows > to solve > > the problem nicely. > > > > Please discuss and decide if the proposal can be added as a change > request > > for JavaFX. > > > > Best wishes, > > Michael. > > > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From kevin.rushforth at oracle.com Tue Sep 18 13:02:24 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Sep 2018 06:02:24 -0700 Subject: JavaFX 11 is released Message-ID: I am pleased to announce the final release of JavaFX 11 as well as the launch of a new OpenJFX community site at: http://openjfx.io/ The GA version of JavaFX 11 is now live and can be downloaded by going to the openjfx.io site or by accessing javafx modules from maven central at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base, graphics, controls, and so forth). This is the first standalone release of JavaFX 11. It runs with JDK 11, which is available as a release candidate now and will be shipped as a GA version next week, or on JDK 10 (OpenJDK build only). A big thank you to all who have contributed to OpenJFX make this release possible! I especially thank Johan Vos, both for taking on the role as Co-Lead of the OpenJFX Project and for the work that Gluon as done to build and host the JavaFX 11 release. I look forward to working with you all on JavaFX 12 and beyond. -- Kevin From johan.vos at gluonhq.com Tue Sep 18 13:08:48 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 18 Sep 2018 15:08:48 +0200 Subject: JavaFX 11 is released In-Reply-To: References: Message-ID: Adding to what Kevin already said (huge thanks to Kevin and Oracle for all they did), I want to thank everyone on this list for being part of this release. The JavaFX 11 release is a huge milestone, and there are many people who contributed, some of them who have been working with JavaFX from day 1, some who just started working. As for the site http://openjfx.io: this is something we created with Gluon, but we really want it to be a community-organised site. Therefore, it is all available via github, and open for PR's: https://github.com/openjfx/hugo-site. Thanks again, - Johan On Tue, Sep 18, 2018 at 3:02 PM Kevin Rushforth wrote: > I am pleased to announce the final release of JavaFX 11 as well as the > launch of a new OpenJFX community site at: > > http://openjfx.io/ > > The GA version of JavaFX 11 is now live and can be downloaded by going > to the openjfx.io site or by accessing javafx modules from maven central > at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base, > graphics, controls, and so forth). > > This is the first standalone release of JavaFX 11. It runs with JDK 11, > which is available as a release candidate now and will be shipped as a > GA version next week, or on JDK 10 (OpenJDK build only). > > A big thank you to all who have contributed to OpenJFX make this release > possible! I especially thank Johan Vos, both for taking on the role as > Co-Lead of the OpenJFX Project and for the work that Gluon as done to > build and host the JavaFX 11 release. > > I look forward to working with you all on JavaFX 12 and beyond. > > -- Kevin > > From dlemmermann at gmail.com Tue Sep 18 13:30:16 2018 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Tue, 18 Sep 2018 15:30:16 +0200 Subject: JavaFX 11 is released In-Reply-To: References: Message-ID: <9639538F-569B-4ABF-9A6D-4E40B936F699@gmail.com> Johan, Kevin, a big "thank you!" from someone who has based his company and career on JavaFX. This release will put an end to all of the ?JavaFX is dead? speculations / rumors out there and it will hopefully also mark the beginning of ongoing and accelerated development of this fantastic piece of technology. Dirk http://www.dlsc.com http://javafx-days.com > Am 18.09.2018 um 15:08 schrieb Johan Vos : > > Adding to what Kevin already said (huge thanks to Kevin and Oracle for all > they did), I want to thank everyone on this list for being part of this > release. The JavaFX 11 release is a huge milestone, and there are many > people who contributed, some of them who have been working with JavaFX from > day 1, some who just started working. > > As for the site http://openjfx.io: this is something we created with Gluon, > but we really want it to be a community-organised site. Therefore, it is > all available via github, and open for PR's: > https://github.com/openjfx/hugo-site. > > Thanks again, > > - Johan > > On Tue, Sep 18, 2018 at 3:02 PM Kevin Rushforth > wrote: > >> I am pleased to announce the final release of JavaFX 11 as well as the >> launch of a new OpenJFX community site at: >> >> http://openjfx.io/ >> >> The GA version of JavaFX 11 is now live and can be downloaded by going >> to the openjfx.io site or by accessing javafx modules from maven central >> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base, >> graphics, controls, and so forth). >> >> This is the first standalone release of JavaFX 11. It runs with JDK 11, >> which is available as a release candidate now and will be shipped as a >> GA version next week, or on JDK 10 (OpenJDK build only). >> >> A big thank you to all who have contributed to OpenJFX make this release >> possible! I especially thank Johan Vos, both for taking on the role as >> Co-Lead of the OpenJFX Project and for the work that Gluon as done to >> build and host the JavaFX 11 release. >> >> I look forward to working with you all on JavaFX 12 and beyond. >> >> -- Kevin >> >> From r.lichtenberger at gmail.com Tue Sep 18 13:51:58 2018 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Tue, 18 Sep 2018 15:51:58 +0200 Subject: Compiling OpenJFX Message-ID: I am trying (again) to get my toes wet with building OpenJFX myself. Here are some things I am wondering about: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle says: Gradle is the primary build tool for building OpenJFX. We currently use Gradle 4.8 for jfx-dev but a few lines down it says: add gradle-4.3/bin to your PATH I assume it should say gradle-4.8/bin here too. Other than that, I was able to build OpenJFX on Windows 64-bit without web and media. So after that I tried to build with web and media, where I got this error: > Task :web:compileNativeWin FAILED Can't locate English.pm in @INC (you may need to install the English module) (@INC contains: /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts /usr/local/lib/perl5/site_perl/5.26/x86_64-cygwin-threads /usr/local/share/perl5/site_perl/5.26 /usr/lib/perl5/vendor_perl/5.26/x86_64-cygwin-threads /usr/share/perl5/vendor_perl/5.26 /usr/lib/perl5/5.26/x86_64-cygwin-threads /usr/share/perl5/5.26) at /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm line 37. BEGIN failed--compilation aborted at /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm line 37. Compilation failed in require at /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm line 48. BEGIN failed--compilation aborted at /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm line 48. Compilation failed in require at C:\openjfx\rt\modules\javafx.web/src/main/native/Tools/Scripts/set-webkit-configuration line 33. BEGIN failed--compilation aborted at C:\openjfx\rt\modules\javafx.web/src/main/native/Tools/Scripts/set-webkit-configuration line 33. FAILURE: Build failed with an exception. I then upgraded perl from the cygwin setup to revision 5 version 26 subversion 2, then the build was able to continue. Maybe the build instructions could mention the exact minimum perl version required? The build then took about an hour but otherwise completed successfully, which is a pretty smooth experience considering the complexity of JavaFX and WebKit ;-). What about Windows 32-bit though? There will be no Oracle JDK from JDK-11 onwards, however https://adoptopenjdk.net/ have said they are willing to produce a JDK for Windows-32 bit. But will OpenJFX be buildable for that platform? If yes, how? Robert Lichtenberger From mike at plan99.net Tue Sep 18 14:07:17 2018 From: mike at plan99.net (Mike Hearn) Date: Tue, 18 Sep 2018 07:07:17 -0700 Subject: JavaFX 11 is released In-Reply-To: References: Message-ID: Excellent work, congratulations to everyone involved and the new site is wonderful. From namannigam12 at gmail.com Tue Sep 18 14:36:25 2018 From: namannigam12 at gmail.com (Naman Nigam) Date: Tue, 18 Sep 2018 20:06:25 +0530 Subject: Improve the pom.xml referenced in Maven example Message-ID: Hi! I am not sure if there is a format to reporting such minor possible improvements. Pardon me if this is not the correct mailing list to share such minor enhancements and please help redirect this to the correct person in that case. (Since I couldn't find the source on GitHub as well) The Run HelloWorld using Maven makes reference to a pom.xml which can be further improved with the use of org.apache.maven.plugins maven-compiler-plugin 3.8.0 11 or as mentioned in another StackOverflow answer as well. PS: I made that answer some time back and coincidently saw the usage of the formerly suggested answer in the production links via this mailing list as well. Thought Regards Naman Nigam +91-9761212401 | LinkedIn From abhinay_agarwal at live.com Tue Sep 18 14:44:11 2018 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Tue, 18 Sep 2018 14:44:11 +0000 Subject: Improve the pom.xml referenced in Maven example In-Reply-To: References: Message-ID: Hi Nigam, Please raise a PR in https://github.com/openjfx/openjfx-docs Regards, Abhinay ________________________________ From: openjfx-dev on behalf of Naman Nigam Sent: Tuesday, September 18, 2018 8:06 PM To: openjfx-dev at openjdk.java.net Subject: Improve the pom.xml referenced in Maven example Hi! I am not sure if there is a format to reporting such minor possible improvements. Pardon me if this is not the correct mailing list to share such minor enhancements and please help redirect this to the correct person in that case. (Since I couldn't find the source on GitHub as well) The Run HelloWorld using Maven makes reference to a pom.xml which can be further improved with the use of org.apache.maven.plugins maven-compiler-plugin 3.8.0 11 or as mentioned in another StackOverflow answer as well. PS: I made that answer some time back and coincidently saw the usage of the formerly suggested answer in the production links via this mailing list as well. Thought Regards Naman Nigam +91-9761212401 | LinkedIn From kevin.rushforth at oracle.com Tue Sep 18 14:51:27 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Sep 2018 07:51:27 -0700 Subject: Compiling OpenJFX In-Reply-To: References: Message-ID: <3c202106-cab5-3866-3d60-cba663c6d414@oracle.com> Good catch. I fixed it to reference to gradle-4.8/ bin. -- Kevin On 9/18/2018 6:51 AM, Robert Lichtenberger wrote: > I am trying (again) to get my toes wet with building OpenJFX myself. > > Here are some things I am wondering about: > > > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle > says: > > Gradle is the primary build tool for building OpenJFX. We currently use > Gradle 4.8 for jfx-dev > > but a few lines down it says: > > add gradle-4.3/bin to your PATH > > I assume it should say gradle-4.8/bin here too. > > > Other than that, I was able to build OpenJFX on Windows 64-bit without > web and media. So after that I tried to build with web and media, where > I got this error: > >> Task :web:compileNativeWin FAILED > Can't locate English.pm in @INC (you may need to install the English > module) (@INC contains: > /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts > /usr/local/lib/perl5/site_perl/5.26/x86_64-cygwin-threads > /usr/local/share/perl5/site_perl/5.26 > /usr/lib/perl5/vendor_perl/5.26/x86_64-cygwin-threads > /usr/share/perl5/vendor_perl/5.26 > /usr/lib/perl5/5.26/x86_64-cygwin-threads /usr/share/perl5/5.26) at > /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm > line 37. > BEGIN failed--compilation aborted at > /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm > line 37. > Compilation failed in require at > /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm > line 48. > BEGIN failed--compilation aborted at > /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm > line 48. > Compilation failed in require at > C:\openjfx\rt\modules\javafx.web/src/main/native/Tools/Scripts/set-webkit-configuration > line 33. > BEGIN failed--compilation aborted at > C:\openjfx\rt\modules\javafx.web/src/main/native/Tools/Scripts/set-webkit-configuration > line 33. > > FAILURE: Build failed with an exception. > > I then upgraded perl from the cygwin setup to revision 5 version 26 > subversion 2, then the build was able to continue. Maybe the build > instructions could mention the exact minimum perl version required? > > The build then took about an hour but otherwise completed successfully, > which is a pretty smooth experience considering the complexity of JavaFX > and WebKit ;-). > > > What about Windows 32-bit though? There will be no Oracle JDK from > JDK-11 onwards, however https://adoptopenjdk.net/ have said they are > willing to produce a JDK for Windows-32 bit. But will OpenJFX be > buildable for that platform? If yes, how? > > > Robert Lichtenberger > > > > From namannigam12 at gmail.com Tue Sep 18 15:13:59 2018 From: namannigam12 at gmail.com (Naman Nigam) Date: Tue, 18 Sep 2018 20:43:59 +0530 Subject: Improve the pom.xml referenced in Maven example In-Reply-To: References: Message-ID: Sure, thanks for pointing out the docs repository. Did that => https://github.com/openjfx/openjfx-docs/pull/2 Regards Naman Nigam +91-9761212401 | LinkedIn On Tue, Sep 18, 2018 at 8:14 PM Abhinay Agarwal wrote: > Hi Nigam, > > Please raise a PR in https://github.com/openjfx/openjfx-docs > > Regards, > Abhinay > > ------------------------------ > *From:* openjfx-dev on behalf of > Naman Nigam > *Sent:* Tuesday, September 18, 2018 8:06 PM > *To:* openjfx-dev at openjdk.java.net > *Subject:* Improve the pom.xml referenced in Maven example > > Hi! I am not sure if there is a format to reporting such minor possible > improvements. Pardon me if this is not the correct mailing list to share > such minor enhancements and please help redirect this to the correct person > in that case. (Since I couldn't find the source on GitHub as well) > The Run HelloWorld using Maven > makes > reference to a pom.xml which can > be further improved with the use of > > > org.apache.maven.plugins > maven-compiler-plugin > 3.8.0 > > 11 or > > > > as mentioned in another StackOverflow answer > < > https://stackoverflow.com/questions/49398894/unable-to-compile-simple-java-10-project-with-maven/51586202#51586202 > > > as > well. > > PS: I made that answer some time back and coincidently saw the usage of the > formerly suggested answer in the production links via this mailing list as > well. Thought > > > Regards > Naman Nigam > +91-9761212401 | LinkedIn > From javafx at use.startmail.com Tue Sep 18 16:31:33 2018 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Tue, 18 Sep 2018 12:31:33 -0400 Subject: JavaFX 11 is released In-Reply-To: References: Message-ID: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> I don't see a way to attach java classes at the bug report form located here: https://bugreport.java.com/bugreport/start_form.do Is there some way to do this?? Thank you.? ? On Tuesday, September 18, 2018 at 9:02 AM, Kevin Rushforth wrote: ? > I am pleased to announce the final release of JavaFX 11 as well as > the > launch of a new OpenJFX community site at: > > http://openjfx.io/ > > The GA version of JavaFX 11 is now live and can be downloaded by > going > to the openjfx.io site or by accessing javafx modules from maven > central > at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base, > graphics, controls, and so forth). > > This is the first standalone release of JavaFX 11. It runs with JDK > 11, > which is available as a release candidate now and will be shipped as > a > GA version next week, or on JDK 10 (OpenJDK build only). > > A big thank you to all who have contributed to OpenJFX make this > release > possible! I especially thank Johan Vos, both for taking on the role > as > Co-Lead of the OpenJFX Project and for the work that Gluon as done to > build and host the JavaFX 11 release. > > I look forward to working with you all on JavaFX 12 and beyond. > > -- Kevin > ? From kevin.rushforth at oracle.com Tue Sep 18 16:35:48 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Sep 2018 09:35:48 -0700 Subject: JavaFX 11 is released In-Reply-To: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> References: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> Message-ID: You can either paste the code in line, upload it to Google Drive or similar, or else email the bundle to one of us and we will attach it. -- Kevin On 9/18/2018 9:31 AM, javafx at use.startmail.com wrote: > I don't see a way to attach java classes at the bug report form > located here: > > https://bugreport.java.com/bugreport/start_form.do > > Is there some way to do this? > > Thank you. > > > On Tuesday, September 18, 2018 at 9:02 AM, Kevin Rushforth > wrote: > >> I am pleased to announce the final release of JavaFX 11 as well as the >> launch of a new OpenJFX community site at: >> >> http://openjfx.io/ >> >> The GA version of JavaFX 11 is now live and can be downloaded by going >> to the openjfx.io site or by accessing javafx modules from maven central >> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base, >> graphics, controls, and so forth). >> >> This is the first standalone release of JavaFX 11. It runs with JDK 11, >> which is available as a release candidate now and will be shipped as a >> GA version next week, or on JDK 10 (OpenJDK build only). >> >> A big thank you to all who have contributed to OpenJFX make this release >> possible! I especially thank Johan Vos, both for taking on the role as >> Co-Lead of the OpenJFX Project and for the work that Gluon as done to >> build and host the JavaFX 11 release. >> >> I look forward to working with you all on JavaFX 12 and beyond. >> >> -- Kevin >> From philip.race at oracle.com Tue Sep 18 16:37:13 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 18 Sep 2018 09:37:13 -0700 Subject: JavaFX 11 is released In-Reply-To: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> References: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> Message-ID: <4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com> No. If you have a test case, include it in the body. if its too big for that .. then maybe it needs to be trimmed down anyway. -phil. On 09/18/2018 09:31 AM, javafx at use.startmail.com wrote: > I don't see a way to attach java classes at the bug report form > located here: > > https://bugreport.java.com/bugreport/start_form.do > > Is there some way to do this? > > Thank you. > > > On Tuesday, September 18, 2018 at 9:02 AM, Kevin Rushforth > wrote: > >> I am pleased to announce the final release of JavaFX 11 as well as the >> launch of a new OpenJFX community site at: >> >> http://openjfx.io/ >> >> The GA version of JavaFX 11 is now live and can be downloaded by going >> to the openjfx.io site or by accessing javafx modules from maven central >> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base, >> graphics, controls, and so forth). >> >> This is the first standalone release of JavaFX 11. It runs with JDK 11, >> which is available as a release candidate now and will be shipped as a >> GA version next week, or on JDK 10 (OpenJDK build only). >> >> A big thank you to all who have contributed to OpenJFX make this release >> possible! I especially thank Johan Vos, both for taking on the role as >> Co-Lead of the OpenJFX Project and for the work that Gluon as done to >> build and host the JavaFX 11 release. >> >> I look forward to working with you all on JavaFX 12 and beyond. >> >> -- Kevin >> From kevin.rushforth at oracle.com Tue Sep 18 16:49:19 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Sep 2018 09:49:19 -0700 Subject: JavaFX 11 is released In-Reply-To: <4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com> References: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> <4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com> Message-ID: <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com> In general, smaller test cases are better, so this the preferred choice. -- Kevin On 9/18/2018 9:37 AM, Phil Race wrote: > No. If you have a test case, include it in the body. > if its too big for that .. then maybe it needs to be trimmed down anyway. > > -phil. > > On 09/18/2018 09:31 AM, javafx at use.startmail.com wrote: >> I don't see a way to attach java classes at the bug report form >> located here: >> >> https://bugreport.java.com/bugreport/start_form.do >> >> Is there some way to do this? >> >> Thank you. >> >> >> On Tuesday, September 18, 2018 at 9:02 AM, Kevin Rushforth >> wrote: >> >>> I am pleased to announce the final release of JavaFX 11 as well as the >>> launch of a new OpenJFX community site at: >>> >>> http://openjfx.io/ >>> >>> The GA version of JavaFX 11 is now live and can be downloaded by going >>> to the openjfx.io site or by accessing javafx modules from maven >>> central >>> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base, >>> graphics, controls, and so forth). >>> >>> This is the first standalone release of JavaFX 11. It runs with JDK 11, >>> which is available as a release candidate now and will be shipped as a >>> GA version next week, or on JDK 10 (OpenJDK build only). >>> >>> A big thank you to all who have contributed to OpenJFX make this >>> release >>> possible! I especially thank Johan Vos, both for taking on the role as >>> Co-Lead of the OpenJFX Project and for the work that Gluon as done to >>> build and host the JavaFX 11 release. >>> >>> I look forward to working with you all on JavaFX 12 and beyond. >>> >>> -- Kevin >>> > From javafx at use.startmail.com Tue Sep 18 18:26:04 2018 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Tue, 18 Sep 2018 14:26:04 -0400 Subject: JavaFX 11 is released In-Reply-To: <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com> References: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> <4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com> <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com> Message-ID: Thanks Kevin. I will paste it all in this email. I have essentially three versions. Two are so compressed it's hard for people to get what the issue is. Since in those programs the proof only takes the form of the value of a class variable, and that proof is demonstrated only by? System.out.printlns of that variable's value, it's understandable that the significance of what's being output could easily be missed or misinterpreted/ dismissed etc.? ?The other one is a proper demo application which throws a ConcurrentModificationException which can't be so easily misunderstood or dismissed, but it has multiple *very small , very well documented* classes. You can't? read the documentation and not get at what's being shown (and still call yourself a developer LOL...), but you have to read the javadoc.? Note: don't shoot from the hip based on a cursory examination of the output or stack trace (like I did LOL). I have probably already considered your alternate explanation,? things from overridden methods to the confusion about how and why? ConcurrentModificationExceptions are thrown? to the (non) presence of multiple class loaders etc etc. It took me real time to even entertain the idea that this was not a subtle programming mistake but instead a bug in JavaFX. I can't avoid writing these so that you have to read the javadoc? - you just have to read the javadoc.? My experience tells me the brief? versions were not easy to understand so I'll post the bigger version here. All but one or two of these classes should be? easy, one-glance classes for most everyone here and the others are also very easy, with brief methods? and anyway thoroughly javadoced.: OK: 1)? A Receiver receives a mouse event.? *********************************************************************** package javaApplicationThreadCuriosityComplex; import javafx.scene.input.MouseEvent; public interface Receiver { ? void receiveEvent(MouseEvent event); } ************************************************************************** A do-nothing receiver receives? the mouse event and does nothing ************************************************************************** package javaApplicationThreadCuriosityComplex; import javafx.scene.input.MouseEvent; /** ?* A {@link Receiver} implementation which literally does nothing except receive the {@link MouseEvent} in {@link #receiveEvent(MouseEvent)}, as defined in {@link Receiver}.

?* Exists in order that we can create many instances of a {@link Receiver} implementation, where the mere existence and not the functionality of the implementation is of any consequence to the program.

?* See {@link PaneEventHandlerExceptionThrower}? for details. ?*

?* To satisfy yourself that these objects are being invoked, uncomment-out the line in {@link #receiveEvent(MouseEvent)}, which will print "Hello" to standard output. ?*/ public class DoNothingReceiver implements Receiver { ? @Override ? public void receiveEvent(MouseEvent event) ? { ? ? //System.out.println("Hello"); ? } } **************************************************************************************************** ? A rectangle drawing Receiver implementation. Very simple class; long only because it's? written to be? transparent in its behavior.? If the received mouse event is a certain type (arbitrarily selected for ease of use in the application - mouse pressed on the primary button) then it just removes the sole? Rectangle from the application's sole Pane, if? such a Rectangle is there. In any case, it next? immediately creates a new Rectangle,? sizes it, changes its color,? positions it and adds it? to? the same Pane. The effect is the Rectangle either? appears for the first time, or appears to change color.? That's it.? **************************************************************************************************** package javaApplicationThreadCuriosityComplex; import javafx.scene.input.MouseEvent; import javafx.scene.layout.Pane; import javafx.scene.paint.Color; import javafx.scene.shape.Rectangle; import java.util.List; /** ?*? ?* This object receives {@link MouseEvent}s from the {@link javafx.event.EventHandler}.

?* If the event is the primary button of the mouse being pressed, this object removes the member {@link RectangleDrawingReceiver#rectangle} from the list of the {@link Pane}'s children if that {@link Rectangle} is present in that list.

?* It then assigns a new instance of a {@link Rectangle} to the member {@link RectangleDrawingReceiver#rectangle}.

?* Finally it adds that member to the list of the {@link Pane}'s children. ?* */ public class RectangleDrawingReceiver implements Receiver { ? /** ? ?* The {@link Rectangle} which will appear after the Mouse is pressed for the first time and be replaced on subsequent MOUSE_PRESSED events. ? ?*/ ? private Rectangle rectangle; ? /** ? ?* boolean value which is reversed each time the primamry button of the mouse is pressed and a new {@link Rectangle } appears. ? ?*/ ? private boolean doDrawRectangleRed =true; ? /** ? ?* No-arg constrcutor added for clarity. ? ?*/ ? public RectangleDrawingReceiver() ? { ? } ? /** ? ?* If the signal to add and remove the {@link Rectangle} is received, then this method invokes {@link RectangleDrawingReceiver#addAndRemoveRectangle(Pane)}. Otherwise returns without doing anything. ? ?* @param mouseEvent the {@link MouseEvent} received from the {@link PaneEventHandlerExceptionThrower} ? ?*/ ? @Override ? public void receiveEvent(MouseEvent mouseEvent) ? { ? ? if (isAddAndRemoveRectangleSignal(mouseEvent)) ? ? { ? ? ? Pane pane = (Pane) mouseEvent.getSource(); ? ? ? addAndRemoveRectangle(pane); ? ? } ? } ? /** ? ?* Define the specific Mouse gesture, MOUSE_PRESSED and primary button down, which will cause this object to possibly remove, then defintely add a {@link Rectangle} to its list of children. ? ?* @param mouseEvent the {@link MouseEvent} which may or may not be the trigger to remove and add a {@link Rectangle} ? ?* @return true iff the primary button of the mouse is pressed. ? ?*/ ? private boolean isAddAndRemoveRectangleSignal(MouseEvent mouseEvent) ? { ? ? return mouseEvent.getEventType().equals(MouseEvent.MOUSE_PRESSED) && mouseEvent.isPrimaryButtonDown(); ? } ? /** ? ?* Remove the {@link Rectangle} from the {@link Pane}, if it is there. In either case, add a new {@link Rectangle} of pre-determined size to the {@link Pane} at a pre-determined location. ? ?* @param pane the {@link Pane} which may or may not currently have a {@link Rectangle} as a child. ? ?*/ ? private void addAndRemoveRectangle(Pane pane) ? { ? ? pane.getChildren().remove(rectangle); ? ? reassignRectangle(); ? ? pane.getChildren().add(rectangle); ? } ? /** ? ?* Create a completely new instance of the {@link Rectangle} with the same size and location but with the opposite {@link Color} either {@link Color#RED} or {@link Color#BLUE}. ? ?*/ ? private void reassignRectangle() ? { ? ? rectangle = new Rectangle(); ? ? sizeAndPositionRectangle(); ? ? setRectangleColor(); ? } ? /** ? ?* Establish the size and position of the {@link Rectangle} ? ?*/ ? private void sizeAndPositionRectangle() ? { ? ? rectangle.setX(200); ? ? rectangle.setY(200); ? ? rectangle.setWidth(200); ? ? rectangle.setHeight(200); ? } ? /** ? ?* To make it apparent that the rectangle is being changed, we change its color every other time ? ?*/ ? private void setRectangleColor() ? { ? ? if (doDrawRectangleRed) ? ? { ? ? ? rectangle.setFill(Color.RED); ? ? ? doDrawRectangleRed= false; ? ? } ? ? else ? ? { ? ? ? rectangle.setFill(Color.BLUE); ? ? ? doDrawRectangleRed= true; ? ? } ? } } ********************************************************************************************************************** The meat of the processing loop. This generates and displays the bug. This is an EventHandler which gets attached to a the Application's sole Pane . It handles all MouseEvents which occur on the Pane. In its constructor, creates a List of 100 do nothing receivers and? one rectangle drawing receiver.? For each received mouse event, it iterates through a List of Receivers reserveReceiver and transfers them into a Set of Receivers, activeReceivers. Then goes through that Set and invokes each one's receive method. This ensures? this method? first? adds to activeReceivers and then when that is completely done,? iterates over? activeReceivers. If there aren't two threads? *then given the way this is written*,? ?there will be? no problem. A ConcurrentModicationException can be created on one Thread, I am aware.? That's it.? Because this method is entered into recursively, as it goes through its member activeReceivers in the method sendEvent it throws a ConcurrentModificationException.? As a secondary proof, this class keeps a static int , recursiveDepth, whose value can only be 1 *in the debug output methods*. (elsewhere it does assume? a value of 1) in the event the JavaFX Application Thread has recursed into this class's handle(). ****You should absolutely satisfy yourself that under no circumstances should the output of the debug methods, as this program is written,? show recursiveDepth to be other than 0 (zero) . You should convince yourself of this before running this program**** In fact, if you search the resultant (copious LOL)? output for the words stackTraceElement to find the point at which the exception is thrown, you will see just above it the output produced from the debug methods which are invoked just upon? entering and just before? exiting of handle itself ,? reporting the impossible event that the value of recursiveDepth? is 1. This is also when the ConcurrentModificationException is thrown.? Those two independent? ?output events are always paired because they are not, in fact independent. The Application Thread is recursively re-entrant? at that point.? ******************************************************************************************************************** package javaApplicationThreadCuriosityComplex; import com.sun.javafx.tk.quantum.QuantumToolkit; import javaApplicationThreadCuriositySimple.JavaFXAnomalySimpleVersionApplication; import javaApplicationThreadCuriositySimple.PaneEventHandler; import javafx.event.EventHandler; import javafx.scene.input.MouseEvent; import javafx.scene.layout.Pane; import java.util.*; import java.util.function.Supplier; /** ?*? ?* This has two {@link List}s of {@link Receiver}s and transfers the contents of one {@link List} to the other for the sole purpose of invoking {@link Collection#add(Object)} within the scope of this method's {@link #handle(MouseEvent)}

?* This invocation demonstrates the bug by throwing a {@link ConcurrentModificationException}.

?* ?* ?*? With enough elements in {@link #activeReceivers}, a {@link ConcurrentModificationException} is reliably generated, proving that the recursive re-entry? of the JavaFX Application Thread and that this re-entry is deterimentally consequential to program correctness.

?*? ?We catch any such {@link Exception} and display its details.

?*

?* ?*/ public class PaneEventExceptionGeneratingHandler implements EventHandler { ? /** ? ?* Class level variable which will only ever be 0 (zero) in the methods {@link #showEnterDebugInformation(int, String, boolean)} and {@link #showExitDebugInformation(int, String, boolean)} if the JavaFX Application Thread does not invoke {@link #handle(MouseEvent)} recursively and will be 1 (one) otherwise. ? ? */ ? private static int recursiveDepth; ? /** ? ?* a {@link List} of {@link Receiver}s which will have its contents transferred into {@link #activeReceivers} in order to provoke a {@link ConcurrentModificationException}. ? ?*/ ? private Set reserveReceivers = new HashSet<>(); ? /** ? ?* a {@link Set} of {@link Receiver}s which will have the contents of {@link #reserveReceivers} transferred into it order to provoke a {@link ConcurrentModificationException}. ? ? ? */ ? private List activeReceivers = new ArrayList<>(); ? /** ? ?* No-arg constructor which populates a {@link List } of {@link Receiver}s 101 elements long. The first 100 elements are {@link DoNothingReceiver}s. The final element is an instance of {@link RectangleDrawingReceiver}. ? ?*/ ? public PaneEventExceptionGeneratingHandler() ? { ? ? DoNothingReceiver doNothingReceiver = null; ? ? int numberOfDonthingReceivers=100;// increasing this to a large value such as here? where it is 100,? makes the ConcurrentModificationException more likely or even certain. Lowering the value to 1 prevents the Exception. In between values may or may not cause the Exception to be thrown. Any specific in-between value? *** RESULTS IN NON_DETERMINISITIC BEHAVIOR WRT TO EXCEPTION GENERATION FROM RUN TO RUN OF THE PROGRAM*** ? ? for (int i=0; i < numberOfDonthingReceivers; i++) ? ? { ? ? ? doNothingReceiver = new DoNothingReceiver(); ? ? ? reserveReceivers.add(new DoNothingReceiver()); ? ? } ? ? RectangleDrawingReceiver rectangleDrawingReceiver = new RectangleDrawingReceiver(); ? ? reserveReceivers.add(new RectangleDrawingReceiver()); ? } ? /** ? ?* First invokes {@link #showEnterDebugInformation(int, String, boolean)} to show the depth of recursion. Then clears the elements in {@link #activeReceivers}. Then transfers the elements in {@link #reserveReceivers} into {@link #activeReceivers}. Sends the {@link MouseEvent} to each element in {@link #activeReceivers}. Finally, invokes {@link #showExitDebugInformation(int, String, boolean)} to show the depth of recursion.

? ?* If an {@link Exception} is raised, catches that {@link Exception} and prints its relevant information to standard I?O. ? ?* ? ?* @param mouseEvent the {@link MouseEvent} which was generated on the {@link Pane} and passed to this object by the JavaFX Application Thread. ? ?*/ ? @Override ? public void handle(MouseEvent mouseEvent) ? { ? ? showEnterDebugInformation(0, "handle", true); ? ? recursiveDepth++; ? ? activeReceivers.clear(); ? ? transferReserveReceiversToActiveReceivers(); ? ? try ? ? { ? ? ? sendEvent(mouseEvent); ? ? } ? ? catch (Exception ex) ? ? { ? ? ? showExceptionTrace(ex); ? ? } ? ? recursiveDepth--; ? ? showExitDebugInformation(0, "handle", true); ? } ? /** ? ?* Sends the {@link MouseEvent} received from the {@link Pane} to all the {@link Receiver}s in {@link #activeReceivers}. ? ?* ? ?* @param mouseEvent ? ?*? ? ? ? ?the {@link MouseEvent} which was delivered from the {@link Pane} by the JavaFX Application Thread. ? ?*/ ? public void sendEvent(MouseEvent mouseEvent) ? { ? ? showEnterDebugInformation(2, "sendEvent", false); ? ? try ? ? { ? ? ? for (Receiver activeReceiver : activeReceivers) ? ? ? { ? ? ? ? activeReceiver.receiveEvent(mouseEvent); ? ? ? } ? ? } ? ? catch (Exception ex) ? ? { ? ? ? showExceptionTrace(ex); ? ? } ? ? showExitDebugInformation(2, "sendEvent", false); ? } ? /** ? ?* Prints spacesLength number of spaces to standard I/O. Used by debug statements to indent output statements from the same method the same amount. ? ?* ? ?* @param spacesLength ? ?*? ? ? ? ?the number of spaces to append to standard I/O ? ?*/ ? private void printSpaces(int spacesLength) ? { ? ? for (int i = 0; i <= spacesLength; i++) ? ? ? System.out.print("? "); ? } ? /** ? ?* Prints "ENTERING"? then the method name and optionally the value of {@link #recursiveDepth} at the time this method is invoked. ? ?* ? ?* @param prettyPrintOffset ? ?*? ? ? ? ?the amount of pretty printing indenting to be written to standard I/O for this method ? ?* @param method ? ?*? ? ? ? ?the name of the method which invoked this method ? ?* @param showCounter ? ?*? ? ? ? ?true iff {@link #recursiveDepth} should also be appended to standard I/O. ? ?*/ ? private void showEnterDebugInformation(int prettyPrintOffset, String method, boolean showCounter) ? { ? ? System.out.println(); ? ? printSpaces(prettyPrintOffset); ? ? System.out.print("ENTERING? " + method); ? ? if (showCounter) ? ? { ? ? ? System.out.print(" and recursiveDepth is " + recursiveDepth); ? ? } ? ? System.out.println(); ? } ? /** ? ?* Print to standard I/O some relevant information of the exception passed to this method, including the {@link StackTraceElement} elements. ? ?* ? ?* @param ex ? ?*? ? ? ? ?the {@link Exception} passed to this method whose information should be printedc to standard I/O. ? ?*/ ? private void showExceptionTrace(Exception ex) ? { ? ? System.out.println("ex = " + ex); ? ? StackTraceElement[] stackTrace = ex.getStackTrace(); ? ? for (int i = 0; i < stackTrace.length; i++) ? ? { ? ? ? StackTraceElement stackTraceElement = stackTrace[i]; ? ? ? System.out.println("stackTraceElement = " + stackTraceElement); ? ? } ? } ? /** ? ?* Prints "EXITING"? then the method name and optionally the value of {@link #recursiveDepth} at the time this method is invoked. ? ?* ? ?* @param prettyPrintOffset ? ?*? ? ? ? ?the amount of pretty printing indenting to be written to standard I/O for this method ? ?* @param method ? ?*? ? ? ? ?the name of the method which invoked this method ? ?* @param showCounter ? ?*? ? ? ? ?true iff {@link #recursiveDepth} should also be appended to standard I/O. ? ?*/ ? private void showExitDebugInformation(int prettyPrintOffset, String method, boolean showCounter) ? { ? ? System.out.println(); ? ? printSpaces(prettyPrintOffset); ? ? System.out.print("EXITING? " + method); ? ? if (showCounter) ? ? { ? ? ? System.out.print(" and recursiveDepth is " + recursiveDepth); ? ? } ? ? System.out.println(); ? } ? /** ? ?* Transfer the contents of {@link #reserveReceivers} into {@link #activeReceivers} as a means of invoking {@link Collection#add(Object)} and thereby provoking a {@link ConcurrentModificationException} in the event the JavaFX Application Thread recurses into {@link #handle(MouseEvent)} . ? ?*/ ? private void transferReserveReceiversToActiveReceivers() ? { ? ? for (Receiver reserveReceiver : reserveReceivers) ? ? { ? ? ? activeReceivers.add(reserveReceiver); ? ? } ? } }?// class package javaApplicationThreadCuriosityComplex; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.input.MouseEvent; import javafx.scene.layout.Pane; import javafx.scene.shape.Rectangle; import javafx.stage.Stage; import java.util.ConcurrentModificationException; /** ?* An {@link Application} with one {@link Pane}. The {@link Pane} has a single {@link javafx.event.EventHandler}, {@link PaneEventExceptionGeneratingHandler} which processes all {@link MouseEvent}s the {@link Pane} receives. ?*

?* To use this program, launch it and move the mouse. A stream of messages will appear in standard IO which you can ignore for now.? Click once anywhere in the {@link Pane}. A {@link Rectangle} will appear. Move the mouse over the {@link Rectangle} and click again. The Rectangle will change color and? a {@link ConcurrentModificationException} (unrelated to the change in color) will be thrown, caught and its stack trace will be printed to the screen. ?*

?* The messages to IO are are sent as the application enters into and later exits each method. They can help you understand the bug. When the exception is thrown, its stack trace elements are printed also. ?*

?* It's not enough to look at the stack trace to understand the bug. You have to read the? the javadoc in {@link PaneEventExceptionGeneratingHandler} for an explanation of how this program demonstrates the bug. ?*/ public class JavaFXAnomalyComplexVersionApplication extends Application { ? ? public void start(Stage primaryStage) ? ? { ? ? ? Pane mainPane = new Pane(); ? ? ? mainPane.setMinHeight(800); ? ? ? mainPane.setMinWidth(800); ? ? ? PaneEventExceptionGeneratingHandler paneEventSender = new PaneEventExceptionGeneratingHandler(); ? ? ? mainPane.addEventHandler(MouseEvent.ANY, paneEventSender); ? ? ? Scene scene = new Scene(mainPane); ? ? ? primaryStage.setScene(scene); ? ? ? primaryStage.show(); ? ? } ? ? /** ? ? ?* The entry point of application. ? ? ?* ? ? ?* @param args ? ? ?*? ? ? ? ?the input arguments ? ? ?*/ ? ? public static void main(String[] args) ? ? { ? ? ? ? launch(args); ? ? } } ***************************END ****************************************** ? On Tuesday, September 18, 2018 at 12:49 PM, Kevin Rushforth wrote: ? > In general, smaller test cases are better, so this the preferred > choice. > > -- Kevin > > > On 9/18/2018 9:37 AM, Phil Race wrote: >> No. If you have a test case, include it in the body. >> if its too big for that .. then maybe it needs to be trimmed down >> anyway. >> >> -phil. >> >> On 09/18/2018 09:31 AM, javafx at use.startmail.com wrote: >>> I don't see a way to attach java classes at the bug report form >>> located here: >>> >>> https://bugreport.java.com/bugreport/start_form.do >>> >>> Is there some way to do this? >>> >>> Thank you. >>> >>> >>> On Tuesday, September 18, 2018 at 9:02 AM, Kevin Rushforth >>> wrote: >>> ? >>>> I am pleased to announce the final release of JavaFX 11 as well as >>>> the >>>> launch of a new OpenJFX community site at: >>>> >>>> http://openjfx.io/ >>>> >>>> The GA version of JavaFX 11 is now live and can be downloaded by >>>> going >>>> to the openjfx.io site or by accessing javafx modules from maven >>>> central >>>> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base, >>>> graphics, controls, and so forth). >>>> >>>> This is the first standalone release of JavaFX 11. It runs with >>>> JDK 11, >>>> which is available as a release candidate now and will be shipped >>>> as a >>>> GA version next week, or on JDK 10 (OpenJDK build only). >>>> >>>> A big thank you to all who have contributed to OpenJFX make this >>>> release >>>> possible! I especially thank Johan Vos, both for taking on the >>>> role as >>>> Co-Lead of the OpenJFX Project and for the work that Gluon as done >>>> to >>>> build and host the JavaFX 11 release. >>>> >>>> I look forward to working with you all on JavaFX 12 and beyond. >>>> >>>> -- Kevin >>>> ? From kevin.rushforth at oracle.com Tue Sep 18 19:24:42 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Sep 2018 12:24:42 -0700 Subject: JavaFX 11 is released In-Reply-To: References: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> <4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com> <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com> Message-ID: I really meant that when you file a bug at https://bugreport.java.com/ you can paste it inline there, along with your description of the bug. If you have already filed a bug, send me the ID and I can copy the info into that bug. Thanks. -- Kevin On 9/18/2018 11:26 AM, javafx at use.startmail.com wrote: > Thanks Kevin. > > I will paste it all in this email. From javafx at use.startmail.com Tue Sep 18 19:30:33 2018 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Tue, 18 Sep 2018 15:30:33 -0400 Subject: JavaFX 11 is released In-Reply-To: References: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> <4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com> <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com> Message-ID: <8b93794cc1182b0c4605a9d6e04a9ac5.startmail@startmail.com> We will review your report and have assigned it an internal review ID : 9057296. hth... ? On Tuesday, September 18, 2018 at 3:24 PM, Kevin Rushforth wrote: ? > I really meant that when you file a bug at > https://bugreport.java.com/ > you can paste it inline there, along with your description of the > bug. > If you have already filed a bug, send me the ID and I can copy the > info > into that bug. > > Thanks. > > -- Kevin > > > On 9/18/2018 11:26 AM, javafx at use.startmail.com wrote: >> Thanks Kevin. >> >> I will paste it all in this email. From bourges.laurent at gmail.com Tue Sep 18 17:52:04 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 18 Sep 2018 19:52:04 +0200 Subject: [12] RFR: JDK-8210386: Clipping problems with complex affine transforms Message-ID: Please review the following bug fix in the MarlinFX renderer for JavaFX 12: https://bugs.openjdk.java.net/browse/JDK-8210386 https://github.com/javafxports/openjdk-jfx/pull/206 PS: What is the process to backport this bug fix to OpenJFX 11 updates ? This patch is small and can be applied directly to OpenJFX 11. Thanks, Laurent From kevin.rushforth at oracle.com Tue Sep 18 20:06:41 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Sep 2018 13:06:41 -0700 Subject: JavaFX 11 is released In-Reply-To: <8b93794cc1182b0c4605a9d6e04a9ac5.startmail@startmail.com> References: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> <4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com> <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com> <8b93794cc1182b0c4605a9d6e04a9ac5.startmail@startmail.com> Message-ID: <74cfe381-902d-3dac-bb7a-508b8d1a6049@oracle.com> Yes, thank you for filing it. It should be transferred to the JDK project tomorrow. -- Kevin On 9/18/2018 12:30 PM, javafx at use.startmail.com wrote: > We will review your report and have assigned it an internal review ID > : 9057296. > > hth... > > On Tuesday, September 18, 2018 at 3:24 PM, Kevin Rushforth > wrote: >> I really meant that when you file a bug at https://bugreport.java.com/ >> you can paste it inline there, along with your description of the bug. >> If you have already filed a bug, send me the ID and I can copy the info >> into that bug. >> >> Thanks. >> >> -- Kevin >> >> >> On 9/18/2018 11:26 AM, javafx at use.startmail.com wrote: >>> Thanks Kevin. >>> >>> I will paste it all in this email. From tgolden at andplus.com Tue Sep 18 20:37:56 2018 From: tgolden at andplus.com (Tom Golden) Date: Tue, 18 Sep 2018 16:37:56 -0400 Subject: "javapackager" in no-mans-land? Message-ID: I understand that along with JavaFX being removed from the Oracle JDK distribution in Java 11, the Oracle team will no longer release the `javapackager` tool. I also see there is a JEP discussing an eventual replacement, JEP-343 ( http://openjdk.java.net/jeps/343). Just to confirm, the tool was NOT migrated to OpenJFX with the rest of the JavaFX code, correct? So until JEP-343 is implemented in a future release (?) there is no "official" way to package native installers for JavaFX applications? If so, is it in theory still possible to use the Oracle javapackager tool from earlier releases? Or should we remain on Java 10 for the time being? -- Thanks, Tom Golden Technical Architect AndPlus, LLC 257 Turnpike Road Southborough, MA 01772 Phone 508-425-7533 http://www.andplus.com From cnewland at chrisnewland.com Tue Sep 18 21:32:19 2018 From: cnewland at chrisnewland.com (Chris Newland) Date: Tue, 18 Sep 2018 22:32:19 +0100 Subject: JavaFX 11 is released In-Reply-To: References: Message-ID: <68839d620ecf44e92ea1482b677f68de.squirrel@excalibur.xssl.net> Congratulations to all involved in this! Looking forward to seeing JavaFX grow now it's outside of the JDK. -Chris On Tue, September 18, 2018 14:08, Johan Vos wrote: > Adding to what Kevin already said (huge thanks to Kevin and Oracle for > all they did), I want to thank everyone on this list for being part of > this release. The JavaFX 11 release is a huge milestone, and there are > many people who contributed, some of them who have been working with > JavaFX from > day 1, some who just started working. > > As for the site http://openjfx.io: this is something we created with > Gluon, > but we really want it to be a community-organised site. Therefore, it is > all available via github, and open for PR's: > https://github.com/openjfx/hugo-site. > > > Thanks again, > > > - Johan > > > On Tue, Sep 18, 2018 at 3:02 PM Kevin Rushforth > > wrote: > > >> I am pleased to announce the final release of JavaFX 11 as well as the >> launch of a new OpenJFX community site at: >> >> http://openjfx.io/ >> >> >> The GA version of JavaFX 11 is now live and can be downloaded by going >> to the openjfx.io site or by accessing javafx modules from maven central >> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base, >> graphics, controls, and so forth). >> >> This is the first standalone release of JavaFX 11. It runs with JDK 11, >> which is available as a release candidate now and will be shipped as a >> GA version next week, or on JDK 10 (OpenJDK build only). >> >> >> A big thank you to all who have contributed to OpenJFX make this >> release possible! I especially thank Johan Vos, both for taking on the >> role as Co-Lead of the OpenJFX Project and for the work that Gluon as >> done to build and host the JavaFX 11 release. >> >> I look forward to working with you all on JavaFX 12 and beyond. >> >> >> -- Kevin >> >> >> > From nlisker at gmail.com Wed Sep 19 01:58:59 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 19 Sep 2018 04:58:59 +0300 Subject: Compiling OpenJFX In-Reply-To: References: Message-ID: Yeah, I missed that one during the recent update of the instructions. Thanks. If you have any other improvements you'd like to suggest that are not related to WebKit please send them my way. I never built Webkit so I can't help with that. On Tue, Sep 18, 2018 at 4:52 PM Robert Lichtenberger < r.lichtenberger at gmail.com> wrote: > I am trying (again) to get my toes wet with building OpenJFX myself. > > Here are some things I am wondering about: > > > > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle > says: > > Gradle is the primary build tool for building OpenJFX. We currently use > Gradle 4.8 for jfx-dev > > but a few lines down it says: > > add gradle-4.3/bin to your PATH > > I assume it should say gradle-4.8/bin here too. > > > Other than that, I was able to build OpenJFX on Windows 64-bit without > web and media. So after that I tried to build with web and media, where > I got this error: > > > Task :web:compileNativeWin FAILED > Can't locate English.pm in @INC (you may need to install the English > module) (@INC contains: > /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts > /usr/local/lib/perl5/site_perl/5.26/x86_64-cygwin-threads > /usr/local/share/perl5/site_perl/5.26 > /usr/lib/perl5/vendor_perl/5.26/x86_64-cygwin-threads > /usr/share/perl5/vendor_perl/5.26 > /usr/lib/perl5/5.26/x86_64-cygwin-threads /usr/share/perl5/5.26) at > > /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm > line 37. > BEGIN failed--compilation aborted at > > /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm > line 37. > Compilation failed in require at > /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/ > webkitdirs.pm > line 48. > BEGIN failed--compilation aborted at > /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/ > webkitdirs.pm > line 48. > Compilation failed in require at > > C:\openjfx\rt\modules\javafx.web/src/main/native/Tools/Scripts/set-webkit-configuration > line 33. > BEGIN failed--compilation aborted at > > C:\openjfx\rt\modules\javafx.web/src/main/native/Tools/Scripts/set-webkit-configuration > line 33. > > FAILURE: Build failed with an exception. > > I then upgraded perl from the cygwin setup to revision 5 version 26 > subversion 2, then the build was able to continue. Maybe the build > instructions could mention the exact minimum perl version required? > > The build then took about an hour but otherwise completed successfully, > which is a pretty smooth experience considering the complexity of JavaFX > and WebKit ;-). > > > What about Windows 32-bit though? There will be no Oracle JDK from > JDK-11 onwards, however https://adoptopenjdk.net/ have said they are > willing to produce a JDK for Windows-32 bit. But will OpenJFX be > buildable for that platform? If yes, how? > > > Robert Lichtenberger > > > > > From youngty1997 at gmail.com Wed Sep 19 02:11:55 2018 From: youngty1997 at gmail.com (Ty Young) Date: Tue, 18 Sep 2018 21:11:55 -0500 Subject: BUG: TableView's setMouseTransparent method does not make mouse transparent Message-ID: Bug review ID: 9057302. TavleView's setMouseTransparent no longer makes mouse events(like clicking) transparent for that TableView when set to true in JavaFX 11. In Oracle 9 and 10 it did, however. I vaguely remember compiling OpenJDK 10 with JavaFX integrated and had the same issue even though Oracle 10 did not have the bug. I personally use this to create an On Screen Display for displaying some GPU information while playing games in Linux(Yes, I know it's incredibly bad to do that since the desktop is still being rendered). Because of this bug, in-game menus cannot be clicked if they are in the top left corner(where the window is) as the mouse transparent method is no longer working. (While i'm at it, does JavaFX *always* render the desktop even if a JavaFX application is fullscreen?) From youngty1997 at gmail.com Wed Sep 19 02:30:22 2018 From: youngty1997 at gmail.com (Ty Young) Date: Tue, 18 Sep 2018 21:30:22 -0500 Subject: BUG: zip file in sdk lib folder causes bugged JDK build Message-ID: <527442d0-2554-61a1-93e9-1a27a1eea338@gmail.com> The zip file "src.zip" located in rt/build/sdk/lib/ after building JavaFX from source causes a bugged build of OpenJDK with JavaFX integrated into it. The build itself completes just fine, it's just that resulting build has issues. Because a zip file isn't a supported module format, Netbeans spits out an error saying as such when attempting to compile a JavaFX application(unsure if the project being modular matters here or not, but it is.). It also seems to cause any attempt to build a new build of OpenJDK to segmentation fault using that same bugged JDK as the boot jdk. Is there somekind of special exception for unsupported module formats for the standalone SDK or is it just manually removed after it's done being compiled? Not sure if it's worth creating a bug report for this since this seems to be some minor mishap. Including a zipped file of the source code in a lib file doesn't make a whole lot of sense to me... I would think it should be in the parent directory(rt/buid/sdk), next to the legal and lib folders. From lenborje at gmail.com Wed Sep 19 06:12:42 2018 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Wed, 19 Sep 2018 08:12:42 +0200 Subject: "javapackager" in no-mans-land? In-Reply-To: References: Message-ID: <3F07CAF6-1614-46FE-850B-99A7D5409AE0@gmail.com> It was migrated, but removed... The recommended work-around is to use the javapackager in OracleJDK 10 when packing Java/OpenJfx 11 applications. That may or may not be practical depending on your build setup. Also, if you?re currently using the UserJvmOptions services, these are also gone in Java/OpenJfx 11, and it would complicate the build process even further if you were required to separate the parts needing to compile with OracleJDK 10, too. I?m using Gradle to build my project, and it is currently dependent on the javafx-Gradle-plugin to package. To upgrade to Java/OpenJfx 11, and still keep the javapackager, I would need to refactor: 1) my code base, to separate the parts needed to compile with OracleJDK 10 to get the UserJvmOptions, 2) my Gradle structure, to run in three steps (compile some parts with 10, compile most parts with 11, package all with 10 while still linking most from 11). It?s too much for me. I?ve decided to remain at Java 10 and wait until there?s a javapackager replacement. The javafx-Gradle-plugin has also been deprecated due to the loss of the javapackager, so I?m stuck anyway with Java 10 unless I rework my entire build structure substantially. I?m hoping for a future Gradle plugin replacement. Seriously, it would be much easier to build my own JDK with OpenJfx, the javapackager and UserJvmOptions Service still bundled with it, but then I?d step up to a completely different level of support commitment... /Lennart B?rjeson Epistula electronica a meo computatro tabulari missa est > 18 sep. 2018 kl. 22:37 skrev Tom Golden : > > I understand that along with JavaFX being removed from the Oracle JDK > distribution in Java 11, the Oracle team will no longer release the > `javapackager` tool. > > I also see there is a JEP discussing an eventual replacement, JEP-343 ( > http://openjdk.java.net/jeps/343). > > Just to confirm, the tool was NOT migrated to OpenJFX with the rest of the > JavaFX code, correct? So until JEP-343 is implemented in a future release > (?) there is no "official" way to package native installers for JavaFX > applications? > > If so, is it in theory still possible to use the Oracle javapackager tool > from earlier releases? Or should we remain on Java 10 for the time being? > > -- > Thanks, > Tom Golden > Technical Architect > AndPlus, LLC > 257 Turnpike Road > Southborough, MA 01772 > > Phone 508-425-7533 > http://www.andplus.com From sverre.moe at gmail.com Wed Sep 19 07:22:14 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 19 Sep 2018 09:22:14 +0200 Subject: JavaFX 11 is released In-Reply-To: <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com> References: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> <4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com> <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com> Message-ID: Great work with JavaFX 11. Looking forward to trying it out. About license for OpenJDK and OpenJFX: Given that OpenJDK has a GPLv2-CE license, is it possible to use it with a commercial application, when bundling with a native runtime, or do we need a commercial license from Oracle? We will not be providing the source code for our application which is required when using software with GPL. We deliver both software and hardware to our customers. The server hardware running SUSE Linux Enterprise Server, which provides the OpenJDK builds, comes preinstalled with our applications. SLES 15.0 has the OpenJDK 10 build, but I reckon later SP will probably provide OpenJDK 11. We pay for SLES and are getting LTSS updates from SUSE which includes the OpenJDK. Given that Oracle JDK which we have used up to now to build our application cannot any longer be used in production without license from Oracle, we then would either need a license or use the OpenJDK to build and deliver with out application. Using the OpenJDK I am not sure we can because of the GPLv2 license it is under. I guess it would not be an issue if we did not bundle the JRE runtime, but required the client computer to have it installed, like we do today when using Java Web Start. However with the removal of Java Web Start we are looking into creating native packages for Linux, Windows and Mac. When it comes to third party Java libraries we have been carefully to only use those which is possible in a commercial application, like Apache, BSD and LGPL, such as JFXtras (BSD License 2.0), Medusa (Apache License v2.0) and JFreechart-FX (LGPL 2.1). Now that we will provide JavaFX in the same way as a OpenJFX dependency I have the same concern with it as I do with OpenJDK if it also is under GPLv2. /Sverre From johan.vos at gluonhq.com Wed Sep 19 08:55:57 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 19 Sep 2018 10:55:57 +0200 Subject: Filling the Packager gap Message-ID: Hi, As promised, we looked into an interim solution for the packager-gap. Work for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. We backported the required changes to an OpenJDK 11 mirror: https://github.com/johanvos/openjdk-mobile11/tree/packager With this, we created modified OpenJDK 11 builds that contain the packager (wrapper/exe + module including native library). They can be downloaded and tested/used at http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip For Windows, you have to unzip the bundle in the same directory as the JDK, as the packager wrapper expect to find the java binary at the same level. Note that these are not products. We use them internally to create installers (e.g. we're using them for Scene Builder 11 and that works fine), and they do what we expect them to do, but there are no guarantees of course so at least for now I recommend using them in development only (or even better, look at the changes and contribute to https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) - Johan From blackdrag at gmx.org Wed Sep 19 09:05:24 2018 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 19 Sep 2018 11:05:24 +0200 Subject: ASF and Licensing Message-ID: Hi all, Because moving to an organization was recently mentioned here, or founding one for OpenJFX, I would like to mention a very few points. Corner stones for the Apache Foundation: *) clear and open project governance *) be open about decisions and develop the community the Apache way *) be Apache licensed and branded And while I think OpenJFX will manage the first two points I am really wondering about the licensing issue. GPL2 with or without CE is considered category-x, which means it cannot be included in an Apache product: https://www.apache.org/legal/resolved.html#category-x That means incubation involves (among other things) clearing up and transferring the "IP" to the Apache Software Foundation, and then licensing the project under Apache License. Right now the project is kind of unusable for the ASF bye Jochen From dlemmermann at gmail.com Wed Sep 19 12:07:44 2018 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Wed, 19 Sep 2018 14:07:44 +0200 Subject: JavaFX Days Zurich Message-ID: <3DC949DC-A9F1-401A-A58B-C74E9A35C781@gmail.com> With all this activity going on in the JavaFX space right now, I thought it is a good idea to inform people on this list that we are currently organizing a ?JavaFX-Only? conference in Zurich on Dec. 3rd until Dec. 5. More info on: javafx-days.com The first day will have a beginners and an expert training class (Anton Epple, Hendrik Ebbers). The second day will be filled with presentations from various JavaFX experts: Johan Vos, Hendrik Ebbers, Gerrit Grunwald, ?. me ( ** blushing **) The third day will be a ?JavaFX on Mobile? day with a Gluon Workshop. Hope to see you there ? Dirk From kevin.rushforth at oracle.com Wed Sep 19 12:47:07 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Sep 2018 05:47:07 -0700 Subject: ASF and Licensing In-Reply-To: References: Message-ID: <3656a7cd-f696-da3f-184c-d29b3ab3e4b1@oracle.com> > Because moving to an organization was recently mentioned here, or > founding one for OpenJFX, I would like to mention a very few points. It has been mentioned, but there are no plans to do this. -- Kevin On 9/19/2018 2:05 AM, Jochen Theodorou wrote: > Hi all, > > Because moving to an organization was recently mentioned here, or > founding one for OpenJFX, I would like to mention a very few points. > > Corner stones for the Apache Foundation: > *) clear and open project governance > *) be open about decisions and develop the community the Apache way > *) be Apache licensed and branded > > And while I think OpenJFX will manage the first two points I am really > wondering about the licensing issue. GPL2 with or without CE is > considered category-x, which means it cannot be included in an Apache > product: https://www.apache.org/legal/resolved.html#category-x > > That means incubation involves (among other things) clearing up and > transferring the "IP" to the Apache Software Foundation, and then > licensing the project under Apache License. > > Right now the project is kind of unusable for the ASF > > bye Jochen From kevin.rushforth at oracle.com Wed Sep 19 12:51:11 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Sep 2018 05:51:11 -0700 Subject: JavaFX 11 is released In-Reply-To: References: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> <4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com> <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com> Message-ID: <113e2a22-3ad3-fb08-6e03-37872c219d83@oracle.com> While this is not meant to be legal advice... The purpose of the Classpath exception to GPL v2 [1], both for the JDK itself and for JavaFX, is to allow applications to use it without requiring that the application itself be licensed under GPL nor requiring that the source for the application be provided. This applies whether you use OpenJDK 11 + OpenJFX 11 or Oracle JDK 11 + OpenJFX 11. -- Kevin [1] http://openjdk.java.net/legal/gplv2+ce.html On 9/19/2018 12:22 AM, Sverre Moe wrote: > Great work with JavaFX 11. Looking forward to trying it out. > > About license for OpenJDK and OpenJFX: > > Given that OpenJDK has a GPLv2-CE license, is it possible to use it > with a commercial application, when bundling with a native runtime, or > do we need a commercial license from Oracle? We will not be providing > the source code for our application which is required when using > software with GPL. > > We deliver both software and hardware to our customers. The server > hardware running SUSE Linux Enterprise Server, which provides the > OpenJDK builds, comes preinstalled with our applications. SLES 15.0 > has the OpenJDK 10 build, but I reckon later SP will probably provide > OpenJDK 11. We pay for SLES and are getting LTSS updates from SUSE > which includes the OpenJDK. > > Given that Oracle JDK which we have used up to now to build our > application cannot any longer be used in production without license > from Oracle, we then would either need a license or use the OpenJDK to > build and deliver with out application. Using the OpenJDK I am not > sure we can because of the GPLv2 license it is under. > > I guess it would not be an issue if we did not bundle the JRE runtime, > but required the client computer to have it installed, like we do > today when using Java Web Start. However with the removal of Java Web > Start we are looking into creating native packages for Linux, Windows > and Mac. > > When it comes to third party Java libraries we have been carefully to > only use those which is possible in a commercial application, like > Apache, BSD and LGPL, such as JFXtras (BSD License 2.0), Medusa > (Apache License v2.0) and JFreechart-FX (LGPL 2.1). > Now that we will provide JavaFX in the same way as a OpenJFX > dependency I have the same concern with it as I do with OpenJDK if it > also is under GPLv2. > > /Sverre From kevin.rushforth at oracle.com Wed Sep 19 13:01:35 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Sep 2018 06:01:35 -0700 Subject: BUG: TableView's setMouseTransparent method does not make mouse transparent In-Reply-To: References: Message-ID: Thanks for reporting the issue. I see it in the bug system, and it should be transferred to the JDK project in JBS in a day or so. I'm not sure I understand your question: > (While i'm at it, does JavaFX *always* render the desktop even if a JavaFX application is fullscreen?) What do you mean by "render the desktop" ? -- Kevin On 9/18/2018 7:11 PM, Ty Young wrote: > Bug review ID: 9057302. > > > TavleView's setMouseTransparent no longer makes mouse events(like > clicking) transparent for that TableView when set to true in JavaFX > 11. In Oracle 9 and 10 it did, however. I vaguely remember compiling > OpenJDK 10 with JavaFX integrated and had the same issue even though > Oracle 10 did not have the bug. > > > I personally use this to create an On Screen Display for displaying > some GPU information while playing games in Linux(Yes, I know it's > incredibly bad to do that since the desktop is still being rendered). > Because of this bug, in-game menus cannot be clicked if they are in > the top left corner(where the window is) as the mouse transparent > method is no longer working. > > > (While i'm at it, does JavaFX *always* render the desktop even if a > JavaFX application is fullscreen?) > From youngty1997 at gmail.com Wed Sep 19 14:52:48 2018 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 19 Sep 2018 09:52:48 -0500 Subject: BUG: TableView's setMouseTransparent method does not make mouse transparent In-Reply-To: References: Message-ID: <651f2ccf-bf8a-eea5-2603-eb9114b9c3c2@gmail.com> On 9/19/18 8:01 AM, Kevin Rushforth wrote: > Thanks for reporting the issue. I see it in the bug system, and it > should be transferred to the JDK project in JBS in a day or so. > > I'm not sure I understand your question: > > > (While i'm at it, does JavaFX *always* render the desktop even if a > JavaFX application is fullscreen?) > > What do you mean by "render the desktop" ? > > -- Kevin > Typically when a game(or potentially any 3d application) is fullscreen, that game(or 3d application) has exclusive control and desktop elements(the desktop environment and the windows within) are no longer rendered. As a result, frame rate is increased, latency is reduced, and stuttering/jittering are reduced or non existent. However, it's possible to "fake" fullscreen by using borderless windowed mode which does not provide the performance benefits of fullscreen while being 'fullscreen". Basically what I'm asking is: Does JavaFX just disable window decorations(title bar/resize borders) and overlays the application over the OS's desktop or is it *truly* fullscreen? > On 9/18/2018 7:11 PM, Ty Young wrote: >> Bug review ID: 9057302. >> >> >> TavleView's setMouseTransparent no longer makes mouse events(like >> clicking) transparent for that TableView when set to true in JavaFX >> 11. In Oracle 9 and 10 it did, however. I vaguely remember compiling >> OpenJDK 10 with JavaFX integrated and had the same issue even though >> Oracle 10 did not have the bug. >> >> >> I personally use this to create an On Screen Display for displaying >> some GPU information while playing games in Linux(Yes, I know it's >> incredibly bad to do that since the desktop is still being rendered). >> Because of this bug, in-game menus cannot be clicked if they are in >> the top left corner(where the window is) as the mouse transparent >> method is no longer working. >> >> >> (While i'm at it, does JavaFX *always* render the desktop even if a >> JavaFX application is fullscreen?) >> > From kevin.rushforth at oracle.com Wed Sep 19 15:27:01 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Sep 2018 08:27:01 -0700 Subject: BUG: TableView's setMouseTransparent method does not make mouse transparent In-Reply-To: <651f2ccf-bf8a-eea5-2603-eb9114b9c3c2@gmail.com> References: <651f2ccf-bf8a-eea5-2603-eb9114b9c3c2@gmail.com> Message-ID: <8a7da427-eade-16e3-e468-8ebc898f0f82@oracle.com> JavaFX does not use exclusive full-screen mode. It simulates full screen by using an undecorated window that is exactly the size of the screen. This means that pop-ups, such as those used by ComboBox and content menus, will continue to work (they use separate windows). -- Kevin On 9/19/2018 7:52 AM, Ty Young wrote: > > On 9/19/18 8:01 AM, Kevin Rushforth wrote: >> Thanks for reporting the issue. I see it in the bug system, and it >> should be transferred to the JDK project in JBS in a day or so. >> >> I'm not sure I understand your question: >> >> > (While i'm at it, does JavaFX *always* render the desktop even if a >> JavaFX application is fullscreen?) >> >> What do you mean by "render the desktop" ? >> >> -- Kevin >> > > Typically when a game(or potentially any 3d application) is > fullscreen, that game(or 3d application) has exclusive control and > desktop elements(the desktop environment and the windows within) are > no longer rendered. As a result, frame rate is increased, latency is > reduced, and stuttering/jittering are reduced or non existent. > > However, it's possible to "fake" fullscreen by using borderless > windowed mode which does not provide the performance benefits of > fullscreen while being 'fullscreen". > > Basically what I'm asking is: Does JavaFX just disable window > decorations(title bar/resize borders) and overlays the application > over the OS's desktop or is it *truly* fullscreen? > > >> On 9/18/2018 7:11 PM, Ty Young wrote: >>> Bug review ID: 9057302. >>> >>> >>> TavleView's setMouseTransparent no longer makes mouse events(like >>> clicking) transparent for that TableView when set to true in JavaFX >>> 11. In Oracle 9 and 10 it did, however. I vaguely remember compiling >>> OpenJDK 10 with JavaFX integrated and had the same issue even though >>> Oracle 10 did not have the bug. >>> >>> >>> I personally use this to create an On Screen Display for displaying >>> some GPU information while playing games in Linux(Yes, I know it's >>> incredibly bad to do that since the desktop is still being >>> rendered). Because of this bug, in-game menus cannot be clicked if >>> they are in the top left corner(where the window is) as the mouse >>> transparent method is no longer working. >>> >>> >>> (While i'm at it, does JavaFX *always* render the desktop even if a >>> JavaFX application is fullscreen?) >>> >> From sverre.moe at gmail.com Wed Sep 19 17:17:08 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 19 Sep 2018 19:17:08 +0200 Subject: JavaFX 11 is released In-Reply-To: <113e2a22-3ad3-fb08-6e03-37872c219d83@oracle.com> References: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com> <4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com> <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com> <113e2a22-3ad3-fb08-6e03-37872c219d83@oracle.com> Message-ID: Thanks for the clarification. I tried to read the GPLv2-CE license, but it gave me a headache. /Sverre Den ons. 19. sep. 2018 kl. 14:51 skrev Kevin Rushforth < kevin.rushforth at oracle.com>: > While this is not meant to be legal advice... The purpose of the > Classpath exception to GPL v2 [1], both for the JDK itself and for > JavaFX, is to allow applications to use it without requiring that the > application itself be licensed under GPL nor requiring that the source > for the application be provided. This applies whether you use OpenJDK 11 > + OpenJFX 11 or Oracle JDK 11 + OpenJFX 11. > > -- Kevin > > [1] http://openjdk.java.net/legal/gplv2+ce.html > > > On 9/19/2018 12:22 AM, Sverre Moe wrote: > > Great work with JavaFX 11. Looking forward to trying it out. > > > > About license for OpenJDK and OpenJFX: > > > > Given that OpenJDK has a GPLv2-CE license, is it possible to use it > > with a commercial application, when bundling with a native runtime, or > > do we need a commercial license from Oracle? We will not be providing > > the source code for our application which is required when using > > software with GPL. > > > > We deliver both software and hardware to our customers. The server > > hardware running SUSE Linux Enterprise Server, which provides the > > OpenJDK builds, comes preinstalled with our applications. SLES 15.0 > > has the OpenJDK 10 build, but I reckon later SP will probably provide > > OpenJDK 11. We pay for SLES and are getting LTSS updates from SUSE > > which includes the OpenJDK. > > > > Given that Oracle JDK which we have used up to now to build our > > application cannot any longer be used in production without license > > from Oracle, we then would either need a license or use the OpenJDK to > > build and deliver with out application. Using the OpenJDK I am not > > sure we can because of the GPLv2 license it is under. > > > > I guess it would not be an issue if we did not bundle the JRE runtime, > > but required the client computer to have it installed, like we do > > today when using Java Web Start. However with the removal of Java Web > > Start we are looking into creating native packages for Linux, Windows > > and Mac. > > > > When it comes to third party Java libraries we have been carefully to > > only use those which is possible in a commercial application, like > > Apache, BSD and LGPL, such as JFXtras (BSD License 2.0), Medusa > > (Apache License v2.0) and JFreechart-FX (LGPL 2.1). > > Now that we will provide JavaFX in the same way as a OpenJFX > > dependency I have the same concern with it as I do with OpenJDK if it > > also is under GPLv2. > > > > /Sverre > > From guy.abossolo.foh at scientificware.com Wed Sep 19 21:03:05 2018 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Wed, 19 Sep 2018 23:03:05 +0200 Subject: JBS report status. In-Reply-To: References: Message-ID: Hi, May be my first bug report in 2008 :-) I felt very pride when I recieved this mail, even thougt it was a robot answer :-) > Dear Java Developer, > > Thank you for your interest in improving the quality of Java Technology. Your report has been assigned an internal review ID of 1379474, which is NOT visible on the Sun Developer Network (SDN). Please be aware that the large volume of reports we receive sometimes prevents us from responding individually to each message. If the information is determined to be a new Bug or RFE, or a duplicate of a known Bug or RFE, you will receive a followup email containing a seven digit bug number. You may search for, view, or vote for this bug in the Bug Database at http://bugs.sun.com/. If you just reported an issue that could have a major impact on your project and require a timely response, please consider purchasing one of the support offerings described at http://developers.sun.com/services/. The Sun Developer Network (http://developers.sun.com) is a free service that Sun offers. To join, visit http://developers.sun.com/global/join_sdn.html. For a limited time, SDN members can obtain fully licensed Java IDEs for web and enterprise development. More information is at http://developers.sun.com/prodtech/javatools/free/. Thank you for using our bug submit page. > > Regards, Java Developer Bug Report Review Team But since some years, no more information. How to know the status of a bug report ? I'm present (trying to be not "noisy") in the JDK and JFX lists since I discovered that one of my bug report (JDK-8133864) was treated without a feedback from JBS. I saw that the bug was corrected only after installing a new Java version. I never received a bug ID ? Could bug reporter have at least an automatic feedback of the status of his bug report. Best regards. From kevin.rushforth at oracle.com Wed Sep 19 22:19:06 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Sep 2018 15:19:06 -0700 Subject: JBS report status. In-Reply-To: References: Message-ID: <90b634e3-d2df-298f-949d-a7c0af59311d@oracle.com> Back in 2015, when the bug in question was filed, there was no additional communication sent. Today you should receive an email once a bug is moved to the JDK project, so you can track it. -- Kevin On 9/19/2018 2:03 PM, Abossolo Foh Guy wrote: > > > Hi, > > May be my first bug report in 2008 :-) > I felt very pride when I recieved this mail, even thougt it was a robot > answer :-) > >> Dear Java Developer, >> >> Thank you for your interest in improving the quality of Java Technology. Your report has been assigned an internal review ID of 1379474, which is NOT visible on the Sun Developer Network (SDN). Please be aware that the large volume of reports we receive sometimes prevents us from responding individually to each message. If the information is determined to be a new Bug or RFE, or a duplicate of a known Bug or RFE, you will receive a followup email containing a seven digit bug number. You may search for, view, or vote for this bug in the Bug Database at http://bugs.sun.com/. If you just reported an issue that could have a major impact on your project and require a timely response, please consider purchasing one of the support offerings described at http://developers.sun.com/services/. The Sun Developer Network (http://developers.sun.com) is a free service that Sun offers. To join, visit http://developers.sun.com/global/join_sdn.html. For a limited time, SDN members can obtain > fully > licensed Java IDEs for web and enterprise development. More information is at http://developers.sun.com/prodtech/javatools/free/. Thank you for using our bug submit page. >> Regards, Java Developer Bug Report Review Team > But since some years, no more information. > > How to know the status of a bug report ? > > I'm present (trying to be not "noisy") in the JDK and JFX lists since I > discovered that one of my bug report (JDK-8133864) was treated without a > feedback from JBS. > > I saw that the bug was corrected only after installing a new Java > version. > > I never received a bug ID ? > > Could bug reporter have at least an automatic feedback of the status of > his bug report. > > Best regards. From geir.helleloid at gmail.com Thu Sep 20 14:20:13 2018 From: geir.helleloid at gmail.com (Geir Helleloid) Date: Thu, 20 Sep 2018 10:20:13 -0400 Subject: Cross-platform JavaFX 11 deployment Message-ID: I am working on moving my company's codebase from Java 8 to Java 11. Our build/deployment pipeline uses Maven, Jenkins, an internal Nexus repository, and custom deployment code. We deploy our software to multiple platforms (Linux, Windows, and Mac). I am wondering how to handle the JavaFX 11 dependencies for cross-platform deployment. I cannot just declare a dependency on (for example) org.openjfx:javafx-graphics:11 in our poms; the Jenkins build will only pull in the platform-specific org.openjfx:javafx-graphics:11:linux dependency, and deployment from Nexus to Windows or Mac will not include org.openjfx:javafx-graphics:11:win or org.openjfx:javafx-graphics:11:mac. I could explicitly declare org.openjfx:javafx-graphics:11:linux, org.openjfx:javafx-graphics:11:win, AND org.openjfx:javafx-graphics:11:mac as dependencies in our poms. Then all three dependencies would be deployed to every platform, but JavaFX would use the appropriate one at runtime. Not only is this clunky, but I think(?) that it fails if we switch to using the module path instead of the classpath, since there will be split/overlapping packages. That suggests that our custom deployment code needs special handling to only deploy the correct JavaFX artifacts for the target platform (or to set up the classpath to only include the correct JavaFX artifacts). Perhaps this is avoidable by building an uber-jar of JavaFX dependencies with the maven-shade-plugin, although I believe the maven-shade-plugin will at least spit out a lot of warnings about the overlapping packages. I think one solution to all of this is for OpenJFX is to provide org.openjfx:javafx-{name}:11:all artifacts that contain all the code, include the platform-specific code for each platform, but those do not currently exist. I would love to hear how other people are handling this situation. Am I misunderstanding the situation? Is there a good (obvious or non-obvious!) solution that I'm missing? Is there something about this scenario that is atypical? (My guess is that this is a very typical scenario.) Thanks, Geir Helleloid From kamlesh.prajapati at hops.healthcare Thu Sep 20 19:05:50 2018 From: kamlesh.prajapati at hops.healthcare (Kamlesh Prajapati) Date: Fri, 21 Sep 2018 00:35:50 +0530 Subject: "javapackager" in no-mans-land? In-Reply-To: <3F07CAF6-1614-46FE-850B-99A7D5409AE0@gmail.com> References: <3F07CAF6-1614-46FE-850B-99A7D5409AE0@gmail.com> Message-ID: Hi, Currently , I used javafx 8 with JNLP Application. Is JNLP application support in javafx11 + java11 ? Any idea about auto update application in win(exe),mac,linux base application ? On Wed, Sep 19, 2018 at 11:54 AM Lennart B?rjeson wrote: > It was migrated, but removed... > > The recommended work-around is to use the javapackager in OracleJDK 10 > when packing Java/OpenJfx 11 applications. > > That may or may not be practical depending on your build setup. Also, if > you?re currently using the UserJvmOptions services, these are also gone in > Java/OpenJfx 11, and it would complicate the build process even further if > you were required to separate the parts needing to compile with OracleJDK > 10, too. > > I?m using Gradle to build my project, and it is currently dependent on the > javafx-Gradle-plugin to package. To upgrade to Java/OpenJfx 11, and still > keep the javapackager, I would need to refactor: > > 1) my code base, to separate the parts needed to compile with OracleJDK 10 > to get the UserJvmOptions, > 2) my Gradle structure, to run in three steps (compile some parts with 10, > compile most parts with 11, package all with 10 while still linking most > from 11). > > It?s too much for me. I?ve decided to remain at Java 10 and wait until > there?s a javapackager replacement. The javafx-Gradle-plugin has also been > deprecated due to the loss of the javapackager, so I?m stuck anyway with > Java 10 unless I rework my entire build structure substantially. I?m hoping > for a future Gradle plugin replacement. > > Seriously, it would be much easier to build my own JDK with OpenJfx, the > javapackager and UserJvmOptions Service still bundled with it, but then I?d > step up to a completely different level of support commitment... > > /Lennart B?rjeson > Epistula electronica a meo computatro tabulari missa est > > > 18 sep. 2018 kl. 22:37 skrev Tom Golden : > > > > I understand that along with JavaFX being removed from the Oracle JDK > > distribution in Java 11, the Oracle team will no longer release the > > `javapackager` tool. > > > > I also see there is a JEP discussing an eventual replacement, JEP-343 ( > > http://openjdk.java.net/jeps/343). > > > > Just to confirm, the tool was NOT migrated to OpenJFX with the rest of > the > > JavaFX code, correct? So until JEP-343 is implemented in a future release > > (?) there is no "official" way to package native installers for JavaFX > > applications? > > > > If so, is it in theory still possible to use the Oracle javapackager tool > > from earlier releases? Or should we remain on Java 10 for the time being? > > > > -- > > Thanks, > > Tom Golden > > Technical Architect > > AndPlus, LLC > > 257 Turnpike Road > > Southborough, MA 01772 > > > > Phone 508-425-7533 > > http://www.andplus.com > -- Thanks With Regards, Kamlesh Prajapati From sverre.moe at gmail.com Thu Sep 20 19:08:11 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 20 Sep 2018 21:08:11 +0200 Subject: Cross-platform JavaFX 11 deployment In-Reply-To: References: Message-ID: An all-in-one solution does exist when using OpenJFX as an SDK instead as dependencies from Maven/Gradle. There was a discussion about empty JARs here on the mailingslist. A problem it seemed to be with Gradle and Eclipse The Gradle build instruction for Java 11 suggest setting platform as a classifier, thus taking only the one from the platform. compile "org.openjfx:javafx-base:11:${platform}" compile group: "org.openjfx", name: "javafx-base", version: "11", classifier: platform https://openjfx.io/openjfx-docs/#gradle Den tor. 20. sep. 2018 kl. 16:20 skrev Geir Helleloid < geir.helleloid at gmail.com>: > I am working on moving my company's codebase from Java 8 to Java 11. > Our build/deployment pipeline uses Maven, Jenkins, an internal Nexus > repository, and custom deployment code. We deploy our software to > multiple platforms (Linux, Windows, and Mac). > > I am wondering how to handle the JavaFX 11 dependencies for > cross-platform deployment. I cannot just declare a dependency on (for > example) org.openjfx:javafx-graphics:11 in our poms; the Jenkins build > will only pull in the platform-specific > org.openjfx:javafx-graphics:11:linux dependency, and deployment from > Nexus to Windows or Mac will not include > org.openjfx:javafx-graphics:11:win or > org.openjfx:javafx-graphics:11:mac. > > I could explicitly declare org.openjfx:javafx-graphics:11:linux, > org.openjfx:javafx-graphics:11:win, AND > org.openjfx:javafx-graphics:11:mac as dependencies in our poms. Then > all three dependencies would be deployed to every platform, but JavaFX > would use the appropriate one at runtime. Not only is this clunky, but > I think(?) that it fails if we switch to using the module path instead > of the classpath, since there will be split/overlapping packages. That > suggests that our custom deployment code needs special handling to > only deploy the correct JavaFX artifacts for the target platform (or > to set up the classpath to only include the correct JavaFX artifacts). > Perhaps this is avoidable by building an uber-jar of JavaFX > dependencies with the maven-shade-plugin, although I believe the > maven-shade-plugin will at least spit out a lot of warnings about the > overlapping packages. > > I think one solution to all of this is for OpenJFX is to provide > org.openjfx:javafx-{name}:11:all artifacts that contain all the code, > include the platform-specific code for each platform, but those do not > currently exist. > > I would love to hear how other people are handling this situation. Am > I misunderstanding the situation? Is there a good (obvious or > non-obvious!) solution that I'm missing? Is there something about this > scenario that is atypical? (My guess is that this is a very typical > scenario.) > > Thanks, > Geir Helleloid > From a1032453509 at 163.com Thu Sep 20 19:10:57 2018 From: a1032453509 at 163.com (a1032453509 at 163.com) Date: Fri, 21 Sep 2018 03:10:57 +0800 Subject: Talk about OPENJFX's future Message-ID: <5BA3F0C2.ADBD9C.32583@m12-14.163.com> First, I call JavaFX/OpenJFX JFX here. I'm not an expert at JFX, I just read half of a book about JFX and be amazed by it. Then I began to take some attention to JFX and be interested in it. JFX is separated from JDK, well the news sound not so bad actually. The fact is JFX isn't well-known, we sound little even noting about JFX in school and lots of books which just teach awt/swing. Thus, the "bad" news at least can let some guys notice what JFX is (*^_^*). And Here I can here only talk about the future of JFX. Why we use a technology? The answer is simple, just the technology is useful in some application scenarios and better than the others. What are JFX's application scenarios? It is written in https://github.com/javafxports/openjdk-jfx, the mirror of the OpenJFX repository: OpenJFX is an open source, next-generation client application platform for desktop, mobile and embedded systems based on JavaSE. ....BALABALABALA So JFX's scenarios are desktop, mobile, and embedded systems, let us analyze one-by-one. 1. Desktop: competitors?QT?WebApp advantages?Write once run everywhere(solve Why Linux haven't XXX?). Easy than QT, build beautiful client quickly. Because of desktop's hardware higher and higher. We can regard JFX'performance same as QT. limitations?Well, nowadays WebApp are everywhere, a browser can solve almost all of the problem, the desktop market is smaller and smaller, though client app suite for some special scenarios, these scenarios are too small to feed many programmers. 2. Mobile: competitors?ReactNative, Flutter limitations?Though ReactNative own many denounce, it also own huge developers and full toolchain. Flutter is the other technology which bright me. With beautiful UI and handy language Dart( similar to java ). It is perfect in my eyes. advantages?I haven't used JFX in mobile so I can't see what advantage JFX have. If JFX can perform well like Flutter, well, JFX would have a good future in Mobile. 3.Embedded systems: competitors?QT advantages?The embedded device is a big market, The car, all the screen in your home in the future(Internet of things(IoT)), the public service devices like the vending machine and other interactive devices, so embedded absolutely is a huge enough market which can feed many JFX programmers. Compare with QT, same as Desktop, JFX can quickly and easily write beautiful app although QT can write the beautiful app too, it needs higher technological level and more time. limitations?Performance, the inherent shortage(VM) let JFX can't run at some performance sensitive scenarios like plant/workshop control system or spacecraft control system ~~~///(^v^)\\\~~~?but with the development of science and technology (hardware upgrade), lots of devices have higher performance, so It is highly feasible by using JFX to build for-civil-use/home application. We can't defeat QT in performance, but we can defeat it at applicability and just don't get too far behind QT in performance. (bad example https://www.youtube.com/watch?v=Kh6K-yEp_JY) What are you think about? Let's talk about it and draw a brilliant future for JFX. If this mail has no intention of offending someone, I hope you can forgive me. Thank all those who contribute to JFX. From guy.abossolo.foh at scientificware.com Thu Sep 20 20:16:22 2018 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Thu, 20 Sep 2018 22:16:22 +0200 Subject: JBS report status. In-Reply-To: <90b634e3-d2df-298f-949d-a7c0af59311d@oracle.com> References: <90b634e3-d2df-298f-949d-a7c0af59311d@oracle.com> Message-ID: <3589fb4e3e56eafaaf81e8820524db26@scientificware.com> Thanks a lot. - Guy. Le 2018-09-20 0:19, Kevin Rushforth a ?crit?: > Back in 2015, when the bug in question was filed, there was no > additional communication sent. Today you should receive an email once > a bug is moved to the JDK project, so you can track it. > > -- Kevin > > > On 9/19/2018 2:03 PM, Abossolo Foh Guy wrote: >> Hi, >> >> May be my first bug report in 2008 :-) >> I felt very pride when I recieved this mail, even thougt it was a >> robot >> answer :-) >> >>> Dear Java Developer, >>> >>> Thank you for your interest in improving the quality of Java >>> Technology. Your report has been assigned an internal review ID of >>> 1379474, which is NOT visible on the Sun Developer Network (SDN). >>> Please be aware that the large volume of reports we receive sometimes >>> prevents us from responding individually to each message. If the >>> information is determined to be a new Bug or RFE, or a duplicate of a >>> known Bug or RFE, you will receive a followup email containing a >>> seven digit bug number. You may search for, view, or vote for this >>> bug in the Bug Database at http://bugs.sun.com/. If you just reported >>> an issue that could have a major impact on your project and require a >>> timely response, please consider purchasing one of the support >>> offerings described at http://developers.sun.com/services/. The Sun >>> Developer Network (http://developers.sun.com) is a free service that >>> Sun offers. To join, visit >>> http://developers.sun.com/global/join_sdn.html. For a limited time, >>> SDN members can obtain >> fully >> licensed Java IDEs for web and enterprise development. More >> information is at http://developers.sun.com/prodtech/javatools/free/. >> Thank you for using our bug submit page. >>> Regards, Java Developer Bug Report Review Team >> But since some years, no more information. >> >> How to know the status of a bug report ? >> >> I'm present (trying to be not "noisy") in the JDK and JFX lists since >> I >> discovered that one of my bug report (JDK-8133864) was treated without >> a >> feedback from JBS. >> >> I saw that the bug was corrected only after installing a new Java >> version. >> >> I never received a bug ID ? >> >> Could bug reporter have at least an automatic feedback of the status >> of >> his bug report. >> >> Best regards. From lenborje at gmail.com Thu Sep 20 21:28:44 2018 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Thu, 20 Sep 2018 23:28:44 +0200 Subject: "javapackager" in no-mans-land? In-Reply-To: References: <3F07CAF6-1614-46FE-850B-99A7D5409AE0@gmail.com> Message-ID: <29743C48-228A-4221-9D8F-7378C982DC45@gmail.com> Java Webstart is gone in Java 11. This means there are no means left to build and distribute standalone Java applications across multiple platforms. Java Webstart was deprecated since the ?old model? of having a separate system-wide JRE capable of running Java programs from different sources, was supposedly outmoded by the ?new model?, i.e. stand-alone apps, complete with their own bundled JRE. ...but then all means to create a stand-alone application was also deprecated and removed. If you need webstart or application packaging, you must wait for the proposed jpackager, and remain at Java 10 until then. /Lennart B?rjeson Electrogramma ab iPhono meo missum est > 20 sep. 2018 kl. 21:05 skrev Kamlesh Prajapati : > > Hi, > > Currently , I used javafx 8 with JNLP Application. > > Is JNLP application support in javafx11 + java11 ? > > Any idea about auto update application in win(exe),mac,linux base application ? > > > > > >> On Wed, Sep 19, 2018 at 11:54 AM Lennart B?rjeson wrote: >> It was migrated, but removed... >> >> The recommended work-around is to use the javapackager in OracleJDK 10 when packing Java/OpenJfx 11 applications. >> >> That may or may not be practical depending on your build setup. Also, if you?re currently using the UserJvmOptions services, these are also gone in Java/OpenJfx 11, and it would complicate the build process even further if you were required to separate the parts needing to compile with OracleJDK 10, too. >> >> I?m using Gradle to build my project, and it is currently dependent on the javafx-Gradle-plugin to package. To upgrade to Java/OpenJfx 11, and still keep the javapackager, I would need to refactor: >> >> 1) my code base, to separate the parts needed to compile with OracleJDK 10 to get the UserJvmOptions, >> 2) my Gradle structure, to run in three steps (compile some parts with 10, compile most parts with 11, package all with 10 while still linking most from 11). >> >> It?s too much for me. I?ve decided to remain at Java 10 and wait until there?s a javapackager replacement. The javafx-Gradle-plugin has also been deprecated due to the loss of the javapackager, so I?m stuck anyway with Java 10 unless I rework my entire build structure substantially. I?m hoping for a future Gradle plugin replacement. >> >> Seriously, it would be much easier to build my own JDK with OpenJfx, the javapackager and UserJvmOptions Service still bundled with it, but then I?d step up to a completely different level of support commitment... >> >> /Lennart B?rjeson >> Epistula electronica a meo computatro tabulari missa est >> >> > 18 sep. 2018 kl. 22:37 skrev Tom Golden : >> > >> > I understand that along with JavaFX being removed from the Oracle JDK >> > distribution in Java 11, the Oracle team will no longer release the >> > `javapackager` tool. >> > >> > I also see there is a JEP discussing an eventual replacement, JEP-343 ( >> > http://openjdk.java.net/jeps/343). >> > >> > Just to confirm, the tool was NOT migrated to OpenJFX with the rest of the >> > JavaFX code, correct? So until JEP-343 is implemented in a future release >> > (?) there is no "official" way to package native installers for JavaFX >> > applications? >> > >> > If so, is it in theory still possible to use the Oracle javapackager tool >> > from earlier releases? Or should we remain on Java 10 for the time being? >> > >> > -- >> > Thanks, >> > Tom Golden >> > Technical Architect >> > AndPlus, LLC >> > 257 Turnpike Road >> > Southborough, MA 01772 >> > >> > Phone 508-425-7533 >> > http://www.andplus.com > > > -- > Thanks With Regards, > Kamlesh Prajapati From kevin.rushforth at oracle.com Thu Sep 20 21:29:47 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 Sep 2018 14:29:47 -0700 Subject: "javapackager" in no-mans-land? In-Reply-To: References: <3F07CAF6-1614-46FE-850B-99A7D5409AE0@gmail.com> Message-ID: On 9/20/2018 12:05 PM, Kamlesh Prajapati wrote: > Currently , I used javafx 8 with JNLP Application. > > Is JNLP application support in javafx11 + java11 ? The deployment stack, including Java Web Start and Applet support, has been removed from JDK 11. You will either need to find an alternative to Java Web Start or keep your application on JDK 8. Packaging your application with the JDK might be an alternative to Java Web Start. If so, the new jpackager tool could help you, in which case an interim solution would be to use use the javapackager, either the one from JDK 10 or an unbundled javapackager, as suggested by others. > Any idea about auto update application in win(exe),mac,linux base > application ? Auto-update is something the application would need to provide. -- Kevin From johan.vos at gluonhq.com Fri Sep 21 09:29:17 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 21 Sep 2018 11:29:17 +0200 Subject: Talk about OPENJFX's future In-Reply-To: <5BA3F0C2.ADBD9C.32583@m12-14.163.com> References: <5BA3F0C2.ADBD9C.32583@m12-14.163.com> Message-ID: > > We can't defeat QT in performance, but we can defeat it at applicability > and just don't get too far behind QT in performance. (bad example > https://www.youtube.com/watch?v=Kh6K-yEp_JY) > That video demonstrates the creator has absolutely no development skills in Java, or he intentionally misleads the viewer. I leave it to the reader to judge what would be worst. I am not going to make performance statements without numbers, but my first observations using JavaFX 11 with the Bellsoft Liberica VM are very encouraging (see https://gluonhq.com/javafx-11-early-access-on-embedded/) - Johan From johnvalrose at gmail.com Fri Sep 21 09:52:01 2018 From: johnvalrose at gmail.com (John-Val Rose) Date: Fri, 21 Sep 2018 19:52:01 +1000 Subject: Talk about OPENJFX's future In-Reply-To: References: <5BA3F0C2.ADBD9C.32583@m12-14.163.com> Message-ID: <10A55A94-DD76-427C-B5F9-F4B750F0FCD3@gmail.com> That video is typical marketing ?smoke and mirrors?. With no access to the code of either app, it is simply unfair and disingenuous to claim a performance advantage. I am certain I could post an almost identical comparison video where the results would be the complete opposite. Yeah, good programmers can write slow code (especially if you have a motive)... On 21 Sep 2018, at 19:29, Johan Vos wrote: >> >> We can't defeat QT in performance, but we can defeat it at applicability >> and just don't get too far behind QT in performance. (bad example >> https://www.youtube.com/watch?v=Kh6K-yEp_JY) >> > > That video demonstrates the creator has absolutely no development skills in > Java, or he intentionally misleads the viewer. I leave it to the reader to > judge what would be worst. > > I am not going to make performance statements without numbers, but my first > observations using JavaFX 11 with the Bellsoft Liberica VM are very > encouraging (see https://gluonhq.com/javafx-11-early-access-on-embedded/) > > - Johan From a1032453509 at 163.com Fri Sep 21 12:03:33 2018 From: a1032453509 at 163.com (a1032453509 at 163.com) Date: Fri, 21 Sep 2018 20:03:33 +0800 Subject: =?utf-8?Q?=E7=AD=94=E5=A4=8D:_Talk_about_OPENJFX's_future?= In-Reply-To: <10A55A94-DD76-427C-B5F9-F4B750F0FCD3@gmail.com> References: <5BA3F0C2.ADBD9C.32583@m12-14.163.com> <10A55A94-DD76-427C-B5F9-F4B750F0FCD3@gmail.com> Message-ID: <5BA4DE15.B27F95.08090@m12-17.163.com> Well, it is happy hear that JavaFX perform well in embedded, my original intention isn?t condemn this video, just for an example, though it is little ridiculous.. ???: John-Val Rose ????: 2018?9?21? 17:52 ???: Johan Vos ??: a1032453509 at 163.com; openjfx-dev at openjdk.java.net ??: Re: Talk about OPENJFX's future That video is typical marketing ?smoke and mirrors?. With no access to the code of either app, it is simply unfair and disingenuous to claim a performance advantage. I am certain I could post an almost identical comparison video where the results would be the complete opposite. Yeah, good programmers can write slow code (especially if you have a motive)... On 21 Sep 2018, at 19:29, Johan Vos wrote: >> >> We can't defeat QT in performance, but we can defeat it at applicability >> and just don't get too far behind QT in performance. (bad example >> https://www.youtube.com/watch?v=Kh6K-yEp_JY) >> > > That video demonstrates the creator has absolutely no development skills in > Java, or he intentionally misleads the viewer. I leave it to the reader to > judge what would be worst. > > I am not going to make performance statements without numbers, but my first > observations using JavaFX 11 with the Bellsoft Liberica VM are very > encouraging (see https://gluonhq.com/javafx-11-early-access-on-embedded/) > > - Johan From javafx at use.startmail.com Fri Sep 21 16:04:19 2018 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Fri, 21 Sep 2018 12:04:19 -0400 Subject: Talk about OPENJFX's future In-Reply-To: <10A55A94-DD76-427C-B5F9-F4B750F0FCD3@gmail.com> References: <5BA3F0C2.ADBD9C.32583@m12-14.163.com> <10A55A94-DD76-427C-B5F9-F4B750F0FCD3@gmail.com> Message-ID: <5cbb1edd4a37565869e7bf08767231dd.startmail@startmail.com> Two items? for us 1) focus on bug-free functionality over new features.? 2) require a U.S. $50.00 a year fee per corporate entity for commercial application usage. This is very reasonable and? would finally secure JavaFX's future as a development platform.?? I feel without 2) above we will find ourselves wandering around cyberspace hoping for a benefactor or the charity of volunteers and their spare time.? hth.? ? On Friday, September 21, 2018 at 5:52 AM, John-Val Rose wrote: ? > That video is typical marketing ?smoke and mirrors?. > > With no access to the code of either app, it is simply unfair and > disingenuous to claim a performance advantage. > > I am certain I could post an almost identical comparison video where > the results would be the complete opposite. > > Yeah, good programmers can write slow code (especially if you have a > motive)... > > On 21 Sep 2018, at 19:29, Johan Vos wrote: > ? >>> We can't defeat QT in performance, but we can defeat it at >>> applicability >>> and just don't get too far behind QT in performance. (bad example >>> https://www.youtube.com/watch?v=Kh6K-yEp_JY) >>> ? >> That video demonstrates the creator has absolutely no development >> skills in >> Java, or he intentionally misleads the viewer. I leave it to the >> reader to >> judge what would be worst. >> >> I am not going to make performance statements without numbers, but >> my first >> observations using JavaFX 11 with the Bellsoft Liberica VM are very >> encouraging (see >> https://gluonhq.com/javafx-11-early-access-on-embedded/) >> >> - Johan From swpalmer at gmail.com Fri Sep 21 16:13:16 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 21 Sep 2018 12:13:16 -0400 Subject: Talk about OPENJFX's future In-Reply-To: <5cbb1edd4a37565869e7bf08767231dd.startmail@startmail.com> References: <5BA3F0C2.ADBD9C.32583@m12-14.163.com> <10A55A94-DD76-427C-B5F9-F4B750F0FCD3@gmail.com> <5cbb1edd4a37565869e7bf08767231dd.startmail@startmail.com> Message-ID: I would focus on bug-free functionality and *performance* over new features. Layout and CSS issues still seem to have a significant drag on JavaFX rendering. Much of the new features I want are somewhat motivated by performance anyway. E.g. getting native window handles? to handle performance issues with 3D and video overlays. I think #2, while cheap, will severely harm JavaFX adoption just from the added nuisance alone. Is there a precedent where this has worked out? Regards, Scott > On Sep 21, 2018, at 12:04 PM, javafx at use.startmail.com wrote: > > Two items for us > > 1) focus on bug-free functionality over new features. > 2) require a U.S. $50.00 a year fee per corporate entity for commercial application usage. This is very reasonable and would finally secure JavaFX's future as a development platform. > > I feel without 2) above we will find ourselves wandering around cyberspace hoping for a benefactor or the charity of volunteers and their spare time. > > hth. > > On Friday, September 21, 2018 at 5:52 AM, John-Val Rose wrote: > >> That video is typical marketing ?smoke and mirrors?. >> With no access to the code of either app, it is simply unfair and disingenuous to claim a performance advantage. >> I am certain I could post an almost identical comparison video where the results would be the complete opposite. >> Yeah, good programmers can write slow code (especially if you have a motive)... >> On 21 Sep 2018, at 19:29, Johan Vos wrote: >> >>>> We can't defeat QT in performance, but we can defeat it at applicability >>>> and just don't get too far behind QT in performance. (bad example >>>> https://www.youtube.com/watch?v=Kh6K-yEp_JY) >>>> >>> That video demonstrates the creator has absolutely no development skills in >>> Java, or he intentionally misleads the viewer. I leave it to the reader to >>> judge what would be worst. >>> I am not going to make performance statements without numbers, but my first >>> observations using JavaFX 11 with the Bellsoft Liberica VM are very >>> encouraging (see https://gluonhq.com/javafx-11-early-access-on-embedded/) >>> - Johan From javafx at use.startmail.com Fri Sep 21 16:51:19 2018 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Fri, 21 Sep 2018 12:51:19 -0400 Subject: Talk about OPENJFX's future In-Reply-To: References: <5BA3F0C2.ADBD9C.32583@m12-14.163.com> <10A55A94-DD76-427C-B5F9-F4B750F0FCD3@gmail.com> <5cbb1edd4a37565869e7bf08767231dd.startmail@startmail.com> Message-ID: <2475d182e787b8fcc4e60ef5e421f39c.startmail@startmail.com> Well a technical enforcement mechanism is impractical, it's true. What would be involved is a commercial license- an electronic thing like the agreement you clicked on when you downloaded the JDK from Oracle. For people using it commercially, you just make a payment through the usual payment processors. It's more or less an honor thing, right, but we're an honorable lot, LOL.? I buy my IDE. I buy other tools. That's all so I can use JavaFX. It makes no economic sense to think this manna is always going to just fall from heaven. Let's just all pony up and put our own futures on a financially secure footing. For us, it creates a huge amount of FUD watching this technology stagger around? from Sun to Oracle to somewhere else because , financially, it is not perceived to? pay for its own development effort If you need an enforcement mechanism then you could require that your license GUID / license acknowledgment appear in your application along with other such legal announcements. So that would be a public-shame-based enforcement mechanism.? We have corporations, schools, research institutes, ISVs who would not miss 50 bucks a year and it would mean everything to JavaFX.? Disregarding what each of us may think what OTHER people might think, does anyone seriously personally object? to some lightweight? scheme like this? I mean you personally- are you offended and likely to look for an alternative on account of it? Serious question, not rhetoric (email nukes nuances LOL). I would feel good about it. I would be more involved, feel like I have an ownership stake and if the resultant cash flow means we can hire (back) some talent and ease the burden on what devs are left, then we all benefit from fewer bugs and more features, which is what we all want and where real money ultimately comes from, right? Suggested donations have a less than 1% "compliance" rate.?? On Friday, September 21, 2018 at 12:13 PM, Scott Palmer wrote: ? > I would focus on bug-free functionality and *performance* over new > features. ?Layout and CSS issues still seem to have a significant > drag on JavaFX rendering. > > Much of the new features I want are somewhat motivated by performance > anyway. E.g. getting native window handles? to handle performance > issues with 3D and video overlays. > > I think #2, while cheap, will severely harm JavaFX adoption just from > the added nuisance alone. ?Is there a precedent where this has worked > out? > > > Regards, > > Scott > ? >> On Sep 21, 2018, at 12:04 PM, javafx at use.startmail.com wrote: >> >> Two items ?for us >> >> 1) focus on bug-free functionality over new features. >> 2) require a U.S. $50.00 a year fee per corporate entity for >> commercial application usage. This is very reasonable and ?would >> finally secure JavaFX's future as a development platform. ? >> >> I feel without 2) above we will find ourselves wandering around >> cyberspace hoping for a benefactor or the charity of volunteers and >> their spare time. >> >> hth. >> ? >> On Friday, September 21, 2018 at 5:52 AM, John-Val Rose >> wrote: >> ? >>> That video is typical marketing ?smoke and mirrors?. >>> With no access to the code of either app, it is simply unfair and >>> disingenuous to claim a performance advantage. >>> I am certain I could post an almost identical comparison video >>> where the results would be the complete opposite. >>> Yeah, good programmers can write slow code (especially if you have >>> a motive)... >>> On 21 Sep 2018, at 19:29, Johan Vos wrote: >>> ? >>>>> We can't defeat QT in performance, but we can defeat it at >>>>> applicability >>>>> and just don't get too far behind QT in performance. (bad example >>>>> https://www.youtube.com/watch?v=Kh6K-yEp_JY) >>>>> ? >>>> That video demonstrates the creator has absolutely no development >>>> skills in >>>> Java, or he intentionally misleads the viewer. I leave it to the >>>> reader to >>>> judge what would be worst. >>>> I am not going to make performance statements without numbers, but >>>> my first >>>> observations using JavaFX 11 with the Bellsoft Liberica VM are >>>> very >>>> encouraging (see >>>> https://gluonhq.com/javafx-11-early-access-on-embedded/) >>>> - Johan From kevin.rushforth at oracle.com Fri Sep 21 17:29:54 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Sep 2018 10:29:54 -0700 Subject: Talk about OPENJFX's future In-Reply-To: <2475d182e787b8fcc4e60ef5e421f39c.startmail@startmail.com> References: <5BA3F0C2.ADBD9C.32583@m12-14.163.com> <10A55A94-DD76-427C-B5F9-F4B750F0FCD3@gmail.com> <5cbb1edd4a37565869e7bf08767231dd.startmail@startmail.com> <2475d182e787b8fcc4e60ef5e421f39c.startmail@startmail.com> Message-ID: I note that this isn't really the right forum for discussing the cost or support model of JavaFX, but since the question has come up, I'll add my 2 cents. The notion of requiring commercial vendors to pay to use the latest feature release of JavaFX is impractical at best. As a community-driven open-source project, one can take the sources and produce binaries from the openjfx repo that can be distributed for free, so if someone started charging for binaries built from those same sources, there would be no incentive for anyone to buy them. That leaves a support-based model, which seems more workable anyway. In this model, using the JavaFX libraries would remain free, but application vendors could pay for support from a commercial vendor willing to offer it. -- Kevin On 9/21/2018 9:51 AM, javafx at use.startmail.com wrote: > Well a technical enforcement mechanism is impractical, it's true. What > would be involved is a commercial license- an electronic thing like > the agreement you clicked on when you downloaded the JDK from Oracle. > For people using it commercially, you just make a payment through the > usual payment processors. It's more or less an honor thing, right, but > we're an honorable lot, LOL. > > I buy my IDE. I buy other tools. That's all so I can use JavaFX. It > makes no economic sense to think this manna is always going to just > fall from heaven. Let's just all pony up and put our own futures on a > financially secure footing. For us, it creates a huge amount of FUD > watching this technology stagger around? from Sun to Oracle to > somewhere else because , financially, it is not perceived to? pay for > its own development effort > > If you need an enforcement mechanism then you could require that your > license GUID / license acknowledgment appear in your application along > with other such legal announcements. So that would be a > public-shame-based enforcement mechanism. > We have corporations, schools, research institutes, ISVs who would not > miss 50 bucks a year and it would mean everything to JavaFX. > > Disregarding what each of us may think what OTHER people might think, > does anyone seriously personally object? to some lightweight? scheme > like this? I mean you personally- are you offended and likely to look > for an alternative on account of it? Serious question, not rhetoric > (email nukes nuances LOL). > > I would feel good about it. I would be more involved, feel like I have > an ownership stake and if the resultant cash flow means we can hire > (back) some talent and ease the burden on what devs are left, then we > all benefit from fewer bugs and more features, which is what we all > want and where real money ultimately comes from, right? > > > > > > Suggested donations have a less than 1% "compliance" rate. > On Friday, September 21, 2018 at 12:13 PM, Scott Palmer > wrote: > >> I would focus on bug-free functionality and *performance* over new >> features. ?Layout and CSS issues still seem to have a significant >> drag on JavaFX rendering. >> >> Much of the new features I want are somewhat motivated by performance >> anyway. E.g. getting native window handles? to handle performance >> issues with 3D and video overlays. >> >> I think #2, while cheap, will severely harm JavaFX adoption just from >> the added nuisance alone. ?Is there a precedent where this has worked >> out? >> >> >> Regards, >> >> Scott >> >>> On Sep 21, 2018, at 12:04 PM, javafx at use.startmail.com wrote: >>> >>> Two items ?for us >>> >>> 1) focus on bug-free functionality over new features. >>> 2) require a U.S. $50.00 a year fee per corporate entity for >>> commercial application usage. This is very reasonable and ?would >>> finally secure JavaFX's future as a development platform. >>> >>> I feel without 2) above we will find ourselves wandering around >>> cyberspace hoping for a benefactor or the charity of volunteers and >>> their spare time. >>> >>> hth. >>> >>> On Friday, September 21, 2018 at 5:52 AM, John-Val Rose >>> wrote: >>> >>>> That video is typical marketing ?smoke and mirrors?. >>>> With no access to the code of either app, it is simply unfair and >>>> disingenuous to claim a performance advantage. >>>> I am certain I could post an almost identical comparison video >>>> where the results would be the complete opposite. >>>> Yeah, good programmers can write slow code (especially if you have >>>> a motive)... >>>> On 21 Sep 2018, at 19:29, Johan Vos wrote: >>>> >>>>>> We can't defeat QT in performance, but we can defeat it at >>>>>> applicability >>>>>> and just don't get too far behind QT in performance. (bad example >>>>>> https://www.youtube.com/watch?v=Kh6K-yEp_JY) >>>>>> >>>>> That video demonstrates the creator has absolutely no development >>>>> skills in >>>>> Java, or he intentionally misleads the viewer. I leave it to the >>>>> reader to >>>>> judge what would be worst. >>>>> I am not going to make performance statements without numbers, but >>>>> my first >>>>> observations using JavaFX 11 with the Bellsoft Liberica VM are very >>>>> encouraging (see >>>>> https://gluonhq.com/javafx-11-early-access-on-embedded/) >>>>> - Johan From johan.vos at gluonhq.com Fri Sep 21 19:56:17 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 21 Sep 2018 21:56:17 +0200 Subject: Talk about OPENJFX's future In-Reply-To: References: <5BA3F0C2.ADBD9C.32583@m12-14.163.com> <10A55A94-DD76-427C-B5F9-F4B750F0FCD3@gmail.com> <5cbb1edd4a37565869e7bf08767231dd.startmail@startmail.com> Message-ID: Adding to #2: what we try to do with gluon is increasing adoption, allow free development and usage, while still getting revenues to fund the development. All builds created for the latest version of JavaFX are free to use (GPL + CPE) for private and commercial usage. With the Gluon JavaFX Enterprise support (see https://gluonhq.com/javafx-11-release-and-support-plans/), we provide LTS to companies that don't want to jump to the latest versions with every release but still require updates. If you go from JavaFX 11 to 12, 13, 14,... you'll always get a free, high-quality, supported build. If for some reasons you need to stick with JavaFX 11 but still want critical updates, you can buy Gluon JavaFX Enterprise support and you will get builds including critical patches. This is similar to the Java SE support: if you follow the release cadence and use the latest and greatest version, you're totally fine. If you don't want to do that, that's fine. If you want to stay on an old version but still get regular high-quality updates, you can get commercial support. - Johan On Fri, Sep 21, 2018 at 9:43 PM Scott Palmer wrote: > I would focus on bug-free functionality and *performance* over new > features. Layout and CSS issues still seem to have a significant drag on > JavaFX rendering. > > Much of the new features I want are somewhat motivated by performance > anyway. E.g. getting native window handles? to handle performance issues > with 3D and video overlays. > > I think #2, while cheap, will severely harm JavaFX adoption just from the > added nuisance alone. Is there a precedent where this has worked out? > > > Regards, > > Scott > > > On Sep 21, 2018, at 12:04 PM, javafx at use.startmail.com wrote: > > > > Two items for us > > > > 1) focus on bug-free functionality over new features. > > 2) require a U.S. $50.00 a year fee per corporate entity for commercial > application usage. This is very reasonable and would finally secure > JavaFX's future as a development platform. > > > > I feel without 2) above we will find ourselves wandering around > cyberspace hoping for a benefactor or the charity of volunteers and their > spare time. > > > > hth. > > > > On Friday, September 21, 2018 at 5:52 AM, John-Val Rose < > johnvalrose at gmail.com> wrote: > > > >> That video is typical marketing ?smoke and mirrors?. > >> With no access to the code of either app, it is simply unfair and > disingenuous to claim a performance advantage. > >> I am certain I could post an almost identical comparison video where > the results would be the complete opposite. > >> Yeah, good programmers can write slow code (especially if you have a > motive)... > >> On 21 Sep 2018, at 19:29, Johan Vos wrote: > >> > >>>> We can't defeat QT in performance, but we can defeat it at > applicability > >>>> and just don't get too far behind QT in performance. (bad example > >>>> https://www.youtube.com/watch?v=Kh6K-yEp_JY) > >>>> > >>> That video demonstrates the creator has absolutely no development > skills in > >>> Java, or he intentionally misleads the viewer. I leave it to the > reader to > >>> judge what would be worst. > >>> I am not going to make performance statements without numbers, but my > first > >>> observations using JavaFX 11 with the Bellsoft Liberica VM are very > >>> encouraging (see > https://gluonhq.com/javafx-11-early-access-on-embedded/) > >>> - Johan > > From kevin.rushforth at oracle.com Fri Sep 21 22:22:19 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Sep 2018 15:22:19 -0700 Subject: Talk about OPENJFX's future In-Reply-To: References: <5BA3F0C2.ADBD9C.32583@m12-14.163.com> <10A55A94-DD76-427C-B5F9-F4B750F0FCD3@gmail.com> <5cbb1edd4a37565869e7bf08767231dd.startmail@startmail.com> Message-ID: That seems like a very workable model to me. -- Kevin On 9/21/2018 12:56 PM, Johan Vos wrote: > Adding to #2: what we try to do with gluon is increasing adoption, allow > free development and usage, while still getting revenues to fund the > development. > All builds created for the latest version of JavaFX are free to use (GPL + > CPE) for private and commercial usage. > > With the Gluon JavaFX Enterprise support (see > https://gluonhq.com/javafx-11-release-and-support-plans/), we provide LTS > to companies that don't want to jump to the latest versions with every > release but still require updates. > If you go from JavaFX 11 to 12, 13, 14,... you'll always get a free, > high-quality, supported build. If for some reasons you need to stick with > JavaFX 11 but still want critical updates, you can buy Gluon JavaFX > Enterprise support and you will get builds including critical patches. > > This is similar to the Java SE support: if you follow the release cadence > and use the latest and greatest version, you're totally fine. If you don't > want to do that, that's fine. If you want to stay on an old version but > still get regular high-quality updates, you can get commercial support. > > - Johan > > > > On Fri, Sep 21, 2018 at 9:43 PM Scott Palmer wrote: > >> I would focus on bug-free functionality and *performance* over new >> features. Layout and CSS issues still seem to have a significant drag on >> JavaFX rendering. >> >> Much of the new features I want are somewhat motivated by performance >> anyway. E.g. getting native window handles? to handle performance issues >> with 3D and video overlays. >> >> I think #2, while cheap, will severely harm JavaFX adoption just from the >> added nuisance alone. Is there a precedent where this has worked out? >> >> >> Regards, >> >> Scott >> >>> On Sep 21, 2018, at 12:04 PM, javafx at use.startmail.com wrote: >>> >>> Two items for us >>> >>> 1) focus on bug-free functionality over new features. >>> 2) require a U.S. $50.00 a year fee per corporate entity for commercial >> application usage. This is very reasonable and would finally secure >> JavaFX's future as a development platform. >>> I feel without 2) above we will find ourselves wandering around >> cyberspace hoping for a benefactor or the charity of volunteers and their >> spare time. >>> hth. >>> >>> On Friday, September 21, 2018 at 5:52 AM, John-Val Rose < >> johnvalrose at gmail.com> wrote: >>>> That video is typical marketing ?smoke and mirrors?. >>>> With no access to the code of either app, it is simply unfair and >> disingenuous to claim a performance advantage. >>>> I am certain I could post an almost identical comparison video where >> the results would be the complete opposite. >>>> Yeah, good programmers can write slow code (especially if you have a >> motive)... >>>> On 21 Sep 2018, at 19:29, Johan Vos wrote: >>>> >>>>>> We can't defeat QT in performance, but we can defeat it at >> applicability >>>>>> and just don't get too far behind QT in performance. (bad example >>>>>> https://www.youtube.com/watch?v=Kh6K-yEp_JY) >>>>>> >>>>> That video demonstrates the creator has absolutely no development >> skills in >>>>> Java, or he intentionally misleads the viewer. I leave it to the >> reader to >>>>> judge what would be worst. >>>>> I am not going to make performance statements without numbers, but my >> first >>>>> observations using JavaFX 11 with the Bellsoft Liberica VM are very >>>>> encouraging (see >> https://gluonhq.com/javafx-11-early-access-on-embedded/) >>>>> - Johan >> From kevin.rushforth at oracle.com Fri Sep 21 22:27:28 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Sep 2018 15:27:28 -0700 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 Message-ID: Please review the following on GitHub: https://bugs.openjdk.java.net/browse/JDK-8209966 https://github.com/javafxports/openjdk-jfx/pull/174 This will bump the minimum boot JDK needed to build JavaFX 12 to JDK 11. -- Kevin From kevin.rushforth at oracle.com Fri Sep 21 22:33:45 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Sep 2018 15:33:45 -0700 Subject: [12] RFR: JDK-8210093: Build FX class files with -source 11 and -target 11 Message-ID: Please review the following on GitHub: https://bugs.openjdk.java.net/browse/JDK-8210093 https://github.com/javafxports/openjdk-jfx/pull/208 This will start building the FX class files with "-source 11" and "-target 11" for JavaFX 12. It is dependent on JDK-8209966. -- Kevin From kevin.rushforth at oracle.com Fri Sep 21 23:53:25 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Sep 2018 16:53:25 -0700 Subject: [12] RFR: JDK-8210092: Remove old javafx.swing implementation Message-ID: Please review the following on GitHub: https://bugs.openjdk.java.net/browse/JDK-8210092 https://github.com/javafxports/openjdk-jfx/pull/207 https://github.com/javafxports/openjdk-jfx/pull/207/files This will remove the old JDK-10-based implementation of FX / Swing interop and cleanup the build to remove the legacy qualified exports and the logic that optionally excludes the new implementation. It also changes the dependency that javafx.swing has on jdk.unsupported.desktop from "requires static" (optional) to "requires", which will fix an existing bug with jlinked images that include javafx.swing. -- Kevin From youngty1997 at gmail.com Sat Sep 22 01:08:39 2018 From: youngty1997 at gmail.com (Ty Young) Date: Fri, 21 Sep 2018 20:08:39 -0500 Subject: BUG: TableView's setMouseTransparent method does not make mouse transparent In-Reply-To: <8a7da427-eade-16e3-e468-8ebc898f0f82@oracle.com> References: <651f2ccf-bf8a-eea5-2603-eb9114b9c3c2@gmail.com> <8a7da427-eade-16e3-e468-8ebc898f0f82@oracle.com> Message-ID: <89831ad7-77b2-b2c6-9086-a74720950381@gmail.com> On 9/19/18 10:27 AM, Kevin Rushforth wrote: > JavaFX does not use exclusive full-screen mode. It simulates full > screen by using an undecorated window that is exactly the size of the > screen. This means that pop-ups, such as those used by ComboBox and > content menus, will continue to work (they use separate windows). > > -- Kevin > > Well, that kind of stinks. Regarding the bug itself, I've figured out that it's a GTK3 bug as hinted on the bug report[1]. Switching to GTK2 via the suggested argument fixes the bug for me. BTW, have you had a chance to read the other email I sent about the zip file causing a bugged JDK? [1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8211007 > On 9/19/2018 7:52 AM, Ty Young wrote: >> >> On 9/19/18 8:01 AM, Kevin Rushforth wrote: >>> Thanks for reporting the issue. I see it in the bug system, and it >>> should be transferred to the JDK project in JBS in a day or so. >>> >>> I'm not sure I understand your question: >>> >>> > (While i'm at it, does JavaFX *always* render the desktop even if >>> a JavaFX application is fullscreen?) >>> >>> What do you mean by "render the desktop" ? >>> >>> -- Kevin >>> >> >> Typically when a game(or potentially any 3d application) is >> fullscreen, that game(or 3d application) has exclusive control and >> desktop elements(the desktop environment and the windows within) are >> no longer rendered. As a result, frame rate is increased, latency is >> reduced, and stuttering/jittering are reduced or non existent. >> >> However, it's possible to "fake" fullscreen by using borderless >> windowed mode which does not provide the performance benefits of >> fullscreen while being 'fullscreen". >> >> Basically what I'm asking is: Does JavaFX just disable window >> decorations(title bar/resize borders) and overlays the application >> over the OS's desktop or is it *truly* fullscreen? >> >> >>> On 9/18/2018 7:11 PM, Ty Young wrote: >>>> Bug review ID: 9057302. >>>> >>>> >>>> TavleView's setMouseTransparent no longer makes mouse events(like >>>> clicking) transparent for that TableView when set to true in JavaFX >>>> 11. In Oracle 9 and 10 it did, however. I vaguely remember >>>> compiling OpenJDK 10 with JavaFX integrated and had the same issue >>>> even though Oracle 10 did not have the bug. >>>> >>>> >>>> I personally use this to create an On Screen Display for displaying >>>> some GPU information while playing games in Linux(Yes, I know it's >>>> incredibly bad to do that since the desktop is still being >>>> rendered). Because of this bug, in-game menus cannot be clicked if >>>> they are in the top left corner(where the window is) as the mouse >>>> transparent method is no longer working. >>>> >>>> >>>> (While i'm at it, does JavaFX *always* render the desktop even if a >>>> JavaFX application is fullscreen?) >>>> >>> > From youngty1997 at gmail.com Sat Sep 22 01:00:17 2018 From: youngty1997 at gmail.com (Ty Young) Date: Fri, 21 Sep 2018 20:00:17 -0500 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 In-Reply-To: References: Message-ID: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> On 9/21/18 5:27 PM, Kevin Rushforth wrote: > Please review the following on GitHub: > > https://bugs.openjdk.java.net/browse/JDK-8209966 > https://github.com/javafxports/openjdk-jfx/pull/174 > > This will bump the minimum boot JDK needed to build JavaFX 12 to JDK 11. > > -- Kevin > Is requiring the previously released JDK to build JavaFX really necessary? Does something *actually* break as a result of using an older boot JDK? If not, this is just going to make compiling JavaFX a real pain as you need to compile(or somehow find) a JDK that is one version behind, and if you don't have it then you need to compile the JDK with JavaFX before that(and repeat). In other words, if I wanted to compile JavaFX 12 right now I'd need to use Oracle JDK 10(which may not even be available for download in the future, who knows?), use it to compile JDK 11 with JavaFX 11, and then use that to compile JavaFX 12 if I couldn't find JDK 11 with JavaFX online somewhere. And it's only going to get worse as time goes on. Would it not be possible to support up until the last JDK LTS(Starting at 11) release for building JavaFX? I feel like maybe that would be more reasonable. Thanks. From paulrussell70 at gmail.com Sat Sep 22 07:43:39 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Sat, 22 Sep 2018 08:43:39 +0100 Subject: BUG: TableView's setMouseTransparent method does not make mouse transparent Message-ID: >> JavaFX does not use exclusive full-screen mode. It simulates full >> screen by using an undecorated window that is exactly the size of the >> screen. This means that pop-ups, such as those used by ComboBox and >> content menus, will continue to work (they use separate windows). >> >>-- Kevin >> >> > Well, that kind of stinks. I agree, Ty: it's a terrible idea, and in my experience makes JavaFX unworkable for games. There is no way to change native screen resolution, I have to go to command line to achieve this and use a C++ solution. It's one of my major gripes, along with no shader access. Ref: performance, I've found the canvas, currently the fastest way to render content, to be slow against pure native OpenGL/Vulcan/Dx solutions. From Alan.Bateman at oracle.com Sat Sep 22 10:03:56 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 22 Sep 2018 11:03:56 +0100 Subject: [12] RFR: JDK-8210092: Remove old javafx.swing implementation In-Reply-To: References: Message-ID: On 22/09/2018 00:53, Kevin Rushforth wrote: > Please review the following on GitHub: > > https://bugs.openjdk.java.net/browse/JDK-8210092 > https://github.com/javafxports/openjdk-jfx/pull/207 > https://github.com/javafxports/openjdk-jfx/pull/207/files > > This will remove the old JDK-10-based implementation of FX / Swing > interop and cleanup the build to remove the legacy qualified exports > and the logic that optionally excludes the new implementation. It also > changes the dependency that javafx.swing has on > jdk.unsupported.desktop from "requires static" (optional) to > "requires", which will fix an existing bug with jlinked images that > include javafx.swing. > I don't know the workflow or how reviews work in the javafxports/openjdk-jfx project work (I didn't want to hit the "Review changes" button) but the change to the make the dependency non-optional looks okay to me. -Alan. From kevin.rushforth at oracle.com Sat Sep 22 13:50:53 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 22 Sep 2018 06:50:53 -0700 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 In-Reply-To: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> References: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> Message-ID: <3c90e7b3-51d9-5c1a-3446-129846aa7338@oracle.com> On 9/21/2018 6:00 PM, Ty Young wrote: > Is requiring the previously released JDK to build JavaFX really > necessary? Does something *actually* break as a result of using an > older boot JDK? > Yes, there is a good reason to do this, and that is to fix JDK-8210092 [1], which gets rid of the legacy swing interop implementation and the associated qualified exports, and some crufty build logic to optionally exclude the classes that depend on JDK 11; this also fixes JDK-8210759 [2] . Also, JDK 10 is obsoleted by JDK 11, which is an LTS, so even if we don't adopt a model of always bumping the minimum boot JDK for each release, it is appropriate to do so now. > In other words, if I wanted to compile JavaFX 12 right now I'd need to > use Oracle JDK 10(which may not even be available for download in the > future, who knows?), use it to compile JDK 11 with JavaFX 11, and then > use that to compile JavaFX 12 if I couldn't find JDK 11 with JavaFX > online somewhere. You misunderstand. Today you need to use a JDK 10 (or JDK 11) *without* the JavaFX classes to build JavaFX 12, just like we did for building JavaFX 11. Starting with JDK 11 there are no more JDKs that include JavaFX. That's why we build JavaFX as a separate SDK and set of maven modules. > And it's only going to get worse as time goes on. Would it not be > possible to support up until the last JDK LTS(Starting at 11) release > for building JavaFX? I feel like maybe that would be more reasonable. This is a good question, and maybe in the future we might not be so quick to do this...or maybe we will.? We should discuss this before we get to this point for JavaFX 13, a little less than six months from now. The choices for the model are: 1. Allow building JavaFX N with either JDK N-1 or JDK N. 2. Allow building JavaFX N with the most recent LTS or later. Choice #1 will allow JavaFX to better keep pace with JDK features (API or language features). Choice #2 will allow JavaFX to build and run with the most current, stable JDK LTS at the cost of not being able to use newer JDK features. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8210092 [2] https://bugs.openjdk.java.net/browse/JDK-8210759 From kevin.rushforth at oracle.com Sat Sep 22 14:01:55 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 22 Sep 2018 07:01:55 -0700 Subject: BUG: zip file in sdk lib folder causes bugged JDK build In-Reply-To: <527442d0-2554-61a1-93e9-1a27a1eea338@gmail.com> References: <527442d0-2554-61a1-93e9-1a27a1eea338@gmail.com> Message-ID: I have never seen this problem. As for including src.zip in the "lib" directory, that matches what the JDK has done for years. It may have something to do with how you are building your JDK? In any case, as mentioned in a previous email, I do not recommend using a boot JDK with JavaFX modules to build FX. This is no longer the expected way to build FX and will quite likely stop working at some point. -- Kevin On 9/18/2018 7:30 PM, Ty Young wrote: > The zip file "src.zip" located in rt/build/sdk/lib/ after building > JavaFX from source causes a bugged build of OpenJDK with JavaFX > integrated into it. The build itself completes just fine, it's just > that resulting build has issues. > > Because a zip file isn't a supported module format, Netbeans spits out > an error saying as such when attempting to compile a JavaFX > application(unsure if the project being modular matters here or not, > but it is.). It also seems to cause any attempt to build a new build > of OpenJDK to segmentation fault using that same bugged JDK as the > boot jdk. > > > Is there somekind of special exception for unsupported module formats > for the standalone SDK or is it just manually removed after it's done > being compiled? > > > Not sure if it's worth creating a bug report for this since this seems > to be some minor mishap. Including a zipped file of the source code in > a lib file doesn't make a whole lot of sense to me... I would think it > should be in the parent directory(rt/buid/sdk), next to the legal and > lib folders. > > From kamlesh.prajapati at hops.healthcare Sun Sep 23 06:29:57 2018 From: kamlesh.prajapati at hops.healthcare (Kamlesh Prajapati) Date: Sun, 23 Sep 2018 11:59:57 +0530 Subject: "javapackager" in no-mans-land? In-Reply-To: References: <3F07CAF6-1614-46FE-850B-99A7D5409AE0@gmail.com> Message-ID: Hi, Thanks for your replay. I found exe build using maven with 'javafx-maven-plugin' Or Inno Setup tool but My project is update release every 2 week. so auto update tool for manage inside client system. Also i found auto update tool Like https://github.com/edvin/fxlauncher https://github.com/update4j/update4j But which is long term support with all java update. On Fri, Sep 21, 2018 at 2:59 AM Kevin Rushforth wrote: > On 9/20/2018 12:05 PM, Kamlesh Prajapati wrote: > > Currently , I used javafx 8 with JNLP Application. > > > > Is JNLP application support in javafx11 + java11 ? > > The deployment stack, including Java Web Start and Applet support, has > been removed from JDK 11. You will either need to find an alternative to > Java Web Start or keep your application on JDK 8. Packaging your > application with the JDK might be an alternative to Java Web Start. If > so, the new jpackager tool could help you, in which case an interim > solution would be to use use the javapackager, either the one from JDK > 10 or an unbundled javapackager, as suggested by others. > > > Any idea about auto update application in win(exe),mac,linux base > > application ? > > Auto-update is something the application would need to provide. > > -- Kevin > > -- Thanks With Regards, Kamlesh Prajapati From johan.vos at gluonhq.com Mon Sep 24 06:14:56 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 24 Sep 2018 08:14:56 +0200 Subject: "javapackager" in no-mans-land? In-Reply-To: References: <3F07CAF6-1614-46FE-850B-99A7D5409AE0@gmail.com> Message-ID: Auto-update and a packager are different things. Both are needed, but at this moment, there is only a JEP for the packager. I think it would be wise to have a standard (hence a JEP) for auto-update as well, as the use case you describe is not unique... - Johan On Sun, Sep 23, 2018 at 8:40 AM Kamlesh Prajapati wrote: > Hi, > > Thanks for your replay. > > I found exe build using maven with 'javafx-maven-plugin' Or Inno Setup tool > but My project is update release every 2 week. so auto update tool for > manage inside client system. > > Also i found auto update tool Like > https://github.com/edvin/fxlauncher > https://github.com/update4j/update4j > > But which is long term support with all java update. > > > > > On Fri, Sep 21, 2018 at 2:59 AM Kevin Rushforth < > kevin.rushforth at oracle.com> > wrote: > > > On 9/20/2018 12:05 PM, Kamlesh Prajapati wrote: > > > Currently , I used javafx 8 with JNLP Application. > > > > > > Is JNLP application support in javafx11 + java11 ? > > > > The deployment stack, including Java Web Start and Applet support, has > > been removed from JDK 11. You will either need to find an alternative to > > Java Web Start or keep your application on JDK 8. Packaging your > > application with the JDK might be an alternative to Java Web Start. If > > so, the new jpackager tool could help you, in which case an interim > > solution would be to use use the javapackager, either the one from JDK > > 10 or an unbundled javapackager, as suggested by others. > > > > > Any idea about auto update application in win(exe),mac,linux base > > > application ? > > > > Auto-update is something the application would need to provide. > > > > -- Kevin > > > > > > -- > Thanks With Regards, > Kamlesh Prajapati > From johan.vos at gluonhq.com Mon Sep 24 07:12:05 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 24 Sep 2018 09:12:05 +0200 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 In-Reply-To: <3c90e7b3-51d9-5c1a-3446-129846aa7338@oracle.com> References: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> <3c90e7b3-51d9-5c1a-3446-129846aa7338@oracle.com> Message-ID: > > > > And it's only going to get worse as time goes on. Would it not be > > possible to support up until the last JDK LTS(Starting at 11) release > > for building JavaFX? I feel like maybe that would be more reasonable. > > This is a good question, and maybe in the future we might not be so > quick to do this...or maybe we will. We should discuss this before we > get to this point for JavaFX 13, a little less than six months from now. > The choices for the model are: > > 1. Allow building JavaFX N with either JDK N-1 or JDK N. > 2. Allow building JavaFX N with the most recent LTS or later. > > Choice #1 will allow JavaFX to better keep pace with JDK features (API > or language features). Choice #2 will allow JavaFX to build and run with > the most current, stable JDK LTS at the cost of not being able to use > newer JDK features. > One of the reasons Java is moving to a fast release cadence is because today, this is required to stay relevant in a fast-changing landscape. I think we need to do the same with JavaFX. We should be able to leverage the latest and greatest advances in the JDK, since this will allow JavaFX to move fast as well, which is required to stay relevant. If you want to run on the latest stable JDK LTS, the logical consequence seems to me you use the latest stable JavaFX LTS. There is LTS support available for both Java and JavaFX 11 and they are pretty well aligned. Having said that, there is no point in moving forward just for the fun of it. We also have to distinguish between changes in the VM or in the core Java API's. My opinion is that if a new feature is added to JDK N, we can really take advantage of it in JavaFX (N+1). In some cases, there won't be new features relevant to OpenJFX. But even then, I don't think we can't change our rules on a per-release case (e.g. JavaFX 14 works with Java 13 and Java 14, and even Java 12; but JavaFX 15 works with Java 14 and Java 15 and not with Java 13). In general, I think developers updating from JavaFX 11-12-13 are also capable of updating the JDK from 11-12-13, so I prefer the coupling 1. Allow building JavaFX N with either JDK N-1 or JDK N. - Johan From kevin.rushforth at oracle.com Mon Sep 24 14:40:50 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 24 Sep 2018 07:40:50 -0700 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 In-Reply-To: References: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> <3c90e7b3-51d9-5c1a-3446-129846aa7338@oracle.com> Message-ID: <498052a2-6acf-757d-e457-7decca2865da@oracle.com> > In general, I think developers updating from JavaFX 11-12-13 are also > capable of updating the JDK from 11-12-13, so I prefer the coupling > > 1. Allow building JavaFX N with either JDK N-1 or JDK N. > This is also my preference. -- Kevin On 9/24/2018 12:12 AM, Johan Vos wrote: > > > > And it's only going to get worse as time goes on. Would it not be > > possible to support up until the last JDK LTS(Starting at 11) > release > > for building JavaFX? I feel like maybe that would be more > reasonable. > > This is a good question, and maybe in the future we might not be so > quick to do this...or maybe we will.? We should discuss this > before we > get to this point for JavaFX 13, a little less than six months > from now. > The choices for the model are: > > 1. Allow building JavaFX N with either JDK N-1 or JDK N. > 2. Allow building JavaFX N with the most recent LTS or later. > > Choice #1 will allow JavaFX to better keep pace with JDK features > (API > or language features). Choice #2 will allow JavaFX to build and > run with > the most current, stable JDK LTS at the cost of not being able to use > newer JDK features. > > > One of the reasons Java is moving to a fast release cadence is because > today, this is required to stay relevant in a fast-changing landscape. > I think we need to do the same with JavaFX. We should be able to > leverage the latest and greatest advances in the JDK, since this will > allow JavaFX to move fast as well, which is required to stay relevant. > > If you want to run on the latest stable JDK LTS, the logical > consequence seems to me you use the latest stable JavaFX LTS. There is > LTS support available for both Java and JavaFX 11 and they are pretty > well aligned. > > Having said that, there is no point in moving forward just for the fun > of it. We also have to distinguish between changes in the VM or in the > core Java API's. > My opinion is that if a new feature is added to JDK N, we can really > take advantage of it in JavaFX (N+1). > In some cases, there won't be new features relevant to OpenJFX. But > even then, I don't think we can't change our rules on a per-release > case (e.g. JavaFX 14 works with Java 13 and Java 14, and even Java 12; > but JavaFX 15 works with Java 14 and Java 15 and not with Java 13). > > In general, I think developers updating from JavaFX 11-12-13 are also > capable of updating the JDK from 11-12-13, so I prefer the coupling > > 1. Allow building JavaFX N with either JDK N-1 or JDK N. > > - Johan > > > From tom.schindl at bestsolution.at Mon Sep 24 19:14:22 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 24 Sep 2018 21:14:22 +0200 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 In-Reply-To: <498052a2-6acf-757d-e457-7decca2865da@oracle.com> References: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> <3c90e7b3-51d9-5c1a-3446-129846aa7338@oracle.com> <498052a2-6acf-757d-e457-7decca2865da@oracle.com> Message-ID: <3017d185-5314-bec8-0cf2-0f305da5fab2@bestsolution.at> Hi, As a general rule I'm fine with that but as outlined in another reply we should only break building with older JDKs in case it really adds value. So I think we should official define the JDK N-1 and JDK N but don't pro actively break JDK N-2, ... if there's no real value. Tom On 24.09.18 16:40, Kevin Rushforth wrote: > >> In general, I think developers updating from JavaFX 11-12-13 are also >> capable of updating the JDK from 11-12-13, so I prefer the coupling >> >> 1. Allow building JavaFX N with either JDK N-1 or JDK N. >> > > This is also my preference. > > -- Kevin > > > On 9/24/2018 12:12 AM, Johan Vos wrote: >> >> >> ??? > And it's only going to get worse as time goes on. Would it not be >> ??? > possible to support up until the last JDK LTS(Starting at 11) >> ??? release >> ??? > for building JavaFX? I feel like maybe that would be more >> ??? reasonable. >> >> ??? This is a good question, and maybe in the future we might not be so >> ??? quick to do this...or maybe we will.? We should discuss this >> ??? before we >> ??? get to this point for JavaFX 13, a little less than six months >> ??? from now. >> ??? The choices for the model are: >> >> ??? 1. Allow building JavaFX N with either JDK N-1 or JDK N. >> ??? 2. Allow building JavaFX N with the most recent LTS or later. >> >> ??? Choice #1 will allow JavaFX to better keep pace with JDK features >> ??? (API >> ??? or language features). Choice #2 will allow JavaFX to build and >> ??? run with >> ??? the most current, stable JDK LTS at the cost of not being able to use >> ??? newer JDK features. >> >> >> One of the reasons Java is moving to a fast release cadence is because >> today, this is required to stay relevant in a fast-changing landscape. >> I think we need to do the same with JavaFX. We should be able to >> leverage the latest and greatest advances in the JDK, since this will >> allow JavaFX to move fast as well, which is required to stay relevant. >> >> If you want to run on the latest stable JDK LTS, the logical >> consequence seems to me you use the latest stable JavaFX LTS. There is >> LTS support available for both Java and JavaFX 11 and they are pretty >> well aligned. >> >> Having said that, there is no point in moving forward just for the fun >> of it. We also have to distinguish between changes in the VM or in the >> core Java API's. >> My opinion is that if a new feature is added to JDK N, we can really >> take advantage of it in JavaFX (N+1). >> In some cases, there won't be new features relevant to OpenJFX. But >> even then, I don't think we can't change our rules on a per-release >> case (e.g. JavaFX 14 works with Java 13 and Java 14, and even Java 12; >> but JavaFX 15 works with Java 14 and Java 15 and not with Java 13). >> >> In general, I think developers updating from JavaFX 11-12-13 are also >> capable of updating the JDK from 11-12-13, so I prefer the coupling >> >> 1. Allow building JavaFX N with either JDK N-1 or JDK N. >> >> - Johan >> >> >> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From kevin.rushforth at oracle.com Mon Sep 24 19:41:46 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 24 Sep 2018 12:41:46 -0700 Subject: [12] RFR: JDK-8210386: Clipping problems with complex affine transforms In-Reply-To: References: Message-ID: Hi Laurent, I see that the Java2D fix was just pushed to jdk/jdk. Now that the JDK fix is in, I'll review it this week. It will need a second reviewer (maybe Phil or Sergey?) There isn't an openjfx-11 updates repo available. When / if there is, this seems a good candidate... -- Kevin On 9/18/2018 10:52 AM, Laurent Bourg?s wrote: > Please review the following bug fix in the MarlinFX renderer for > JavaFX 12: > https://bugs.openjdk.java.net/browse/JDK-8210386 > https://github.com/javafxports/openjdk-jfx/pull/206 > > PS: What is the process to backport this bug fix to OpenJFX 11 updates ? > This patch is small and can be applied directly to OpenJFX 11. > > Thanks, > Laurent > From johan at lodgon.com Mon Sep 24 20:01:41 2018 From: johan at lodgon.com (Johan Vos) Date: Mon, 24 Sep 2018 22:01:41 +0200 Subject: [12] RFR: JDK-8210386: Clipping problems with complex affine transforms In-Reply-To: References: Message-ID: I agree, this is something that can go in 11.1 -- pending review in develop branch of course. Op ma 24 sep. 2018 om 21:42 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > Hi Laurent, > > I see that the Java2D fix was just pushed to jdk/jdk. Now that the JDK > fix is in, I'll review it this week. It will need a second reviewer > (maybe Phil or Sergey?) > > There isn't an openjfx-11 updates repo available. When / if there is, > this seems a good candidate... > > -- Kevin > > > On 9/18/2018 10:52 AM, Laurent Bourg?s wrote: > > Please review the following bug fix in the MarlinFX renderer for > > JavaFX 12: > > https://bugs.openjdk.java.net/browse/JDK-8210386 > > https://github.com/javafxports/openjdk-jfx/pull/206 > > > > PS: What is the process to backport this bug fix to OpenJFX 11 updates ? > > This patch is small and can be applied directly to OpenJFX 11. > > > > Thanks, > > Laurent > > > > From bourges.laurent at gmail.com Mon Sep 24 20:49:52 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 24 Sep 2018 22:49:52 +0200 Subject: [12] RFR: JDK-8210386: Clipping problems with complex affine transforms In-Reply-To: References: Message-ID: Sounds good. Cheers, Laurent Le lun. 24 sept. 2018 ? 22:01, Johan Vos a ?crit : > I agree, this is something that can go in 11.1 -- pending review in > develop branch of course. > > Op ma 24 sep. 2018 om 21:42 schreef Kevin Rushforth < > kevin.rushforth at oracle.com>: > >> Hi Laurent, >> >> I see that the Java2D fix was just pushed to jdk/jdk. Now that the JDK >> fix is in, I'll review it this week. It will need a second reviewer >> (maybe Phil or Sergey?) >> >> There isn't an openjfx-11 updates repo available. When / if there is, >> this seems a good candidate... >> >> -- Kevin >> >> >> On 9/18/2018 10:52 AM, Laurent Bourg?s wrote: >> > Please review the following bug fix in the MarlinFX renderer for >> > JavaFX 12: >> > https://bugs.openjdk.java.net/browse/JDK-8210386 >> > https://github.com/javafxports/openjdk-jfx/pull/206 >> > >> > PS: What is the process to backport this bug fix to OpenJFX 11 updates ? >> > This patch is small and can be applied directly to OpenJFX 11. >> > >> > Thanks, >> > Laurent >> > >> >> From prasanta.sadhukhan at oracle.com Tue Sep 25 08:41:43 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 25 Sep 2018 14:11:43 +0530 Subject: [12] RFR: JDK-8210092: Remove old javafx.swing implementation In-Reply-To: References: Message-ID: Hi Kevin, Removal looks ok but one thing, do we still need to keep the enhanced-for loop in InterOpFactory.java#getInstance now that we have only 1 factory? I guess we can probably remove the whole reflection thing also and instantiate InteropFactoryN directly, no? Regards Prasanta On 22-Sep-18 5:23 AM, Kevin Rushforth wrote: > Please review the following on GitHub: > > https://bugs.openjdk.java.net/browse/JDK-8210092 > https://github.com/javafxports/openjdk-jfx/pull/207 > https://github.com/javafxports/openjdk-jfx/pull/207/files > > This will remove the old JDK-10-based implementation of FX / Swing > interop and cleanup the build to remove the legacy qualified exports > and the logic that optionally excludes the new implementation. It also > changes the dependency that javafx.swing has on > jdk.unsupported.desktop from "requires static" (optional) to > "requires", which will fix an existing bug with jlinked images that > include javafx.swing. > > -- Kevin > From kevin.rushforth at oracle.com Tue Sep 25 12:33:27 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 25 Sep 2018 05:33:27 -0700 Subject: [12] RFR: JDK-8210092: Remove old javafx.swing implementation In-Reply-To: References: Message-ID: <04dc0b44-4a92-af32-6af0-269fa78a3097@oracle.com> Yes, that seems like a good bit of additional cleanup. I'll do that. -- Kevin On 9/25/2018 1:41 AM, Prasanta Sadhukhan wrote: > > Hi Kevin, > > Removal looks ok but one thing, do we still need to keep the > enhanced-for loop in InterOpFactory.java#getInstance now that we have > only 1 factory? I guess we can probably remove the whole reflection > thing also and instantiate InteropFactoryN directly, no? > > Regards > Prasanta > On 22-Sep-18 5:23 AM, Kevin Rushforth wrote: >> Please review the following on GitHub: >> >> https://bugs.openjdk.java.net/browse/JDK-8210092 >> https://github.com/javafxports/openjdk-jfx/pull/207 >> https://github.com/javafxports/openjdk-jfx/pull/207/files >> >> This will remove the old JDK-10-based implementation of FX / Swing >> interop and cleanup the build to remove the legacy qualified exports >> and the logic that optionally excludes the new implementation. It >> also changes the dependency that javafx.swing has on >> jdk.unsupported.desktop from "requires static" (optional) to >> "requires", which will fix an existing bug with jlinked images that >> include javafx.swing. >> >> -- Kevin >> > From nlisker at gmail.com Tue Sep 25 21:17:31 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 26 Sep 2018 00:17:31 +0300 Subject: State of maven artifacts Message-ID: Hi, I haven't kept up with all of the Maven artifacts discussion. The website mentioned in 2 places that there are maven artifacts, but does not mention their ID's, group etc. These are the downloads page [1] and the getting started page [2] (later you can see an example pom, but that doesn't count). I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it finds the artifacts. It should be written in the above pages if this is correct. On the usability side it's worse. I'm using Eclipse and during compilation I'm getting error messages that JavaFX classes like BooleanProperty can't be found. Is it a JavaFX problem, Eclipse problem, or me problem? If I use the SDKs, can I point Gradle and Maven to them if it will solve the problem? - Nir [1] https://gluonhq.com/products/javafx/ [2] https://openjfx.io/openjfx-docs/#introduction From sam.carlberg at gmail.com Tue Sep 25 23:37:35 2018 From: sam.carlberg at gmail.com (Sam Carlberg) Date: Tue, 25 Sep 2018 19:37:35 -0400 Subject: State of maven artifacts In-Reply-To: References: Message-ID: The libraries are in artifacts with platform-specific classifiers. The artifacts with no classifiers that you currently depend on are completely empty. You need to depend on "org.openjfx:javafx-base:11:$platform", where the platform is one of "win", "mac", or "linux". On Tue, Sep 25, 2018, 5:18 PM Nir Lisker wrote: > Hi, > > I haven't kept up with all of the Maven artifacts discussion. The website > mentioned in 2 places that there are maven artifacts, but does not mention > their ID's, group etc. These are the downloads page [1] and the getting > started page [2] (later you can see an example pom, but that doesn't > count). > > I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it finds > the artifacts. It should be written in the above pages if this is correct. > > On the usability side it's worse. I'm using Eclipse and during compilation > I'm getting error messages that JavaFX classes like BooleanProperty can't > be found. Is it a JavaFX problem, Eclipse problem, or me problem? > > If I use the SDKs, can I point Gradle and Maven to them if it will solve > the problem? > > - Nir > > [1] https://gluonhq.com/products/javafx/ > [2] https://openjfx.io/openjfx-docs/#introduction > From nlisker at gmail.com Wed Sep 26 03:45:27 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 26 Sep 2018 06:45:27 +0300 Subject: State of maven artifacts In-Reply-To: References: Message-ID: Thanks Sam, that solved it. For some reason I was thinking that if you don't specify the platform it downloads a version with all native dependencies for cross compilation. On Wed, Sep 26, 2018 at 2:37 AM Sam Carlberg wrote: > The libraries are in artifacts with platform-specific classifiers. The > artifacts with no classifiers that you currently depend on are completely > empty. > > You need to depend on "org.openjfx:javafx-base:11:$platform", where the > platform is one of "win", "mac", or "linux". > > On Tue, Sep 25, 2018, 5:18 PM Nir Lisker wrote: > >> Hi, >> >> I haven't kept up with all of the Maven artifacts discussion. The website >> mentioned in 2 places that there are maven artifacts, but does not mention >> their ID's, group etc. These are the downloads page [1] and the getting >> started page [2] (later you can see an example pom, but that doesn't >> count). >> >> I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it finds >> the artifacts. It should be written in the above pages if this is correct. >> >> On the usability side it's worse. I'm using Eclipse and during compilation >> I'm getting error messages that JavaFX classes like BooleanProperty can't >> be found. Is it a JavaFX problem, Eclipse problem, or me problem? >> >> If I use the SDKs, can I point Gradle and Maven to them if it will solve >> the problem? >> >> - Nir >> >> [1] https://gluonhq.com/products/javafx/ >> [2] https://openjfx.io/openjfx-docs/#introduction >> > From youngty1997 at gmail.com Wed Sep 26 06:27:31 2018 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 26 Sep 2018 01:27:31 -0500 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 In-Reply-To: References: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> <3c90e7b3-51d9-5c1a-3446-129846aa7338@oracle.com> Message-ID: <78b82c43-12c7-1bb9-42ee-008b12387b31@gmail.com> On 9/24/18 2:12 AM, Johan Vos wrote: > > > > And it's only going to get worse as time goes on. Would it not be > > possible to support up until the last JDK LTS(Starting at 11) > release > > for building JavaFX? I feel like maybe that would be more > reasonable. > > This is a good question, and maybe in the future we might not be so > quick to do this...or maybe we will.? We should discuss this > before we > get to this point for JavaFX 13, a little less than six months > from now. > The choices for the model are: > > 1. Allow building JavaFX N with either JDK N-1 or JDK N. > 2. Allow building JavaFX N with the most recent LTS or later. > > Choice #1 will allow JavaFX to better keep pace with JDK features > (API > or language features). Choice #2 will allow JavaFX to build and > run with > the most current, stable JDK LTS at the cost of not being able to use > newer JDK features. > > > One of the reasons Java is moving to a fast release cadence is because > today, this is required to stay relevant in a fast-changing landscape. > I think we need to do the same with JavaFX. We should be able to > leverage the latest and greatest advances in the JDK, since this will > allow JavaFX to move fast as well, which is required to stay relevant. > Maybe it's because I don't work for a large corporation, but I don't see this supposed "fast-changing" landscape. To me, it just looks like Java is trying to appeal to all the people from Python/C++/other languages who can't or have a hard time writing object oriented code by introducing a more lazy "functional" and "concise" way of programming. The amount of actual meaningful updates to the language in 10 and 11 in my eyes is fairly small, which is somewhat expected with the faster release cycles. If there was actually a "fast-changing" landscape, I would think that there would more meaningful and useful updates rather than the 50/50 "functional and/or concise"/other misc updates that has been the case for JDK 10 and 11. Personally, whatever was updated that resulted in Netbeans properly using the OS's Look and Feel was the only worthwhile update of the entire JDK 11 release IMO, but I digress. To be clear, I'm not that concerned about breaking compatibility with older versions of the JDK because of API updates/introductions/removals or new, better tools being introduced. I'm more concerned about backwards compatibility being broken for stupid reasons like new lazy language updates that have no actual value or can be done with older compatible ways just because people want to be lazy, "functional", and "concise" which has become a bit of a hot trend lately. > If you want to run on the latest stable JDK LTS, the logical > consequence seems to me you use the latest stable JavaFX LTS. There is > LTS support available for both Java and JavaFX 11 and they are pretty > well aligned. > That's all fine and dandy except for the fact that you can't guarantee what JRE is being run if you haven't moved to Java 9 modules. What do you do, wait a few months after a new LTS is out and then update your application with new JDK/JavaFX features and say "tough luck" to anyone who is still using a previous LTS? What if a user has a newer JRE installed with a feature that exists on the previous LTS removed but not their newer JRE that JavaFX LTS depends on? I've never tried it, but I guess you could prompt the user to download a compatible JRE via a Swing GUI and use that to launch the application via a launcher... but that's just awful for so many different reasons. > Having said that, there is no point in moving forward just for the fun > of it. We also have to distinguish between changes in the VM or in the > core Java API's. > My opinion is that if a new feature is added to JDK N, we can really > take advantage of it in JavaFX (N+1). > In some cases, there won't be new features relevant to OpenJFX. But > even then, I don't think we can't change our rules on a per-release > case (e.g. JavaFX 14 works with Java 13 and Java 14, and even Java 12; > but JavaFX 15 works with Java 14 and Java 15 and not with Java 13). > > In general, I think developers updating from JavaFX 11-12-13 are also > capable of updating the JDK from 11-12-13, so I prefer the coupling > > 1. Allow building JavaFX N with either JDK N-1 or JDK N. > > - Johan > From youngty1997 at gmail.com Wed Sep 26 07:17:51 2018 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 26 Sep 2018 02:17:51 -0500 Subject: BUG: zip file in sdk lib folder causes bugged JDK build In-Reply-To: References: <527442d0-2554-61a1-93e9-1a27a1eea338@gmail.com> Message-ID: On 9/22/18 9:01 AM, Kevin Rushforth wrote: > I have never seen this problem. As for including src.zip in the "lib" > directory, that matches what the JDK has done for years. It may have > something to do with how you are building your JDK? No, I compile JavaFX the same everytime - remove -Werror from the Linux gradle file and ignore all web tests via -x :web:test. Maybe something was changed on the JDK side of things(an exclude list maybe)? I don't remember having this issue before either compiling the pre-release versions of JDK11 and JavaFX either. I used both the JDK11 and JavaFX 11 release branch for the source code. > In any case, as mentioned in a previous email, I do not recommend > using a boot JDK with JavaFX modules to build FX. This is no longer > the expected way to build FX and will quite likely stop working at > some point. > > -- Kevin > Why exactly does having the modules in the JDK matter? Worse case scenario they just aren't used, right? Even if it isn't the "expected" way to build JavaFX, it still has advantages over using the standalone SDK and IMO should still be supported. I'm having a hard time understanding why people at Oracle(or Oracle itself) seems to just want to drop features/tools/options and replace them with completely inferior, incomplete, or not as good replacements, like jLink(though the reduced file size is useful). You all must realize that by doing this that you are breaking projects that utilized these features/tools/options(like JPackager) and increasing the amount of work for IDE developers as they have to support whatever feature that is supported on JDK release X but not on release Y(they have to do this anyway for new language features, but why complicate more?). To add salt to the wound, non LTS releases are only supported until the next JDK so you need to adapt your project for every few releases because of this. Netbeans *still* doesn't have a way to convert a non modular JavaFX application(where JPackager would've been used) to a modular one easily, and modules were released with *Java 9* and many third party libraries still haven't moved to modules yet either(not that I use them, I've just read elsewhere that they haven't). I literally have a non modular JavaFX program that used to use jPackager that doesn't even compile anymore because Apache Netbeans 9 still hasn't added any code to remove jPackager from the ant scripts(or whatever). The project isn't worth anything but that isn't the point. Why break support for it if it isn't hurting anything? Why introduce something and then abort it like it's an unwanted baby? Isn't developing these features/tools/options and dropping them so fast costing time and money? If there is a completely legitimate reason like is the case with Swing interop(as stated before) then that's understandable, but some minor bug(like above) that could probably easily be fixed is just kicking yourselves. No one wants to utilize a feature/tool/option only for it to be pulled from under them all of a sudden for no good reason or a *PROPER* AND *COMPLETE* replacement. It happens so often you can't depend on any new feature/tool/option since you have no idea if it isn't just going to get removed a few JDK releases later. And no, a standalone SDK isn't a replacement for a JDK that has built in support for JavaFX. Does it continue to allow you to compile the project? Maybe? At what cost? HDD space, memory(see below), convenience, and reproducibility(multiple JavaFX versions potentially being used). I didn't even know about it until I compiled and tested it, but a "client" build of the JDK uses less memory than a "server" variant regardless of the application itself. Without being able to build JDK with JavaFX support baked in, my application would be unnecessarily allocating more memory than it needs to. Most JDK/JRE builds are "server" builds and not "client" builds and use around 250MB which is insane and will cause people to complain. If there is no other *PROPER* AND *COMPLETE* way to reduce the insanely high memory usage of "server" JDK/JRE builds, is that use case not enough reason to support it? (Side note: A "client" build of the JDK fails to finish a JavaFX test because it runs out of heap space. Guess I'll need to build a server and client variants from now on.) > > On 9/18/2018 7:30 PM, Ty Young wrote: >> The zip file "src.zip" located in rt/build/sdk/lib/ after building >> JavaFX from source causes a bugged build of OpenJDK with JavaFX >> integrated into it. The build itself completes just fine, it's just >> that resulting build has issues. >> >> Because a zip file isn't a supported module format, Netbeans spits >> out an error saying as such when attempting to compile a JavaFX >> application(unsure if the project being modular matters here or not, >> but it is.). It also seems to cause any attempt to build a new build >> of OpenJDK to segmentation fault using that same bugged JDK as the >> boot jdk. >> >> >> Is there somekind of special exception for unsupported module formats >> for the standalone SDK or is it just manually removed after it's done >> being compiled? >> >> >> Not sure if it's worth creating a bug report for this since this >> seems to be some minor mishap. Including a zipped file of the source >> code in a lib file doesn't make a whole lot of sense to me... I would >> think it should be in the parent directory(rt/buid/sdk), next to the >> legal and lib folders. >> >> > From johan at lodgon.com Wed Sep 26 07:30:55 2018 From: johan at lodgon.com (Johan Vos) Date: Wed, 26 Sep 2018 09:30:55 +0200 Subject: State of maven artifacts In-Reply-To: References: Message-ID: The problem with that is that there is no cross-platform version of the jars itself. The windows-jar for the graphics module contains different Java classes than the linux jar, for example. The top-level API's are the same of course, hence the logical Java module is the same, but different physical jars are really needed. I realise this may be strange at compile time, where you only care about the top-level API's. Therefore, people added nice "tricks" to both a pom.xml and build.gradle system to automatically detect the current (host) operating system, and making sure the correct artifacts are then used. What I really wanted to avoid is that developers had to manually add their platform (e.g. "win") in the build files, as this would break cross-platform development (imagine you're in a team with a win and a linux user, and they constantly change the pom.xml or build.gradle file for this...). I think the current solution deals pretty well with the current situations, where there are different concepts in gradle/maven/sonatype and in the Java module system. - Johan Op wo 26 sep. 2018 om 05:46 schreef Nir Lisker : > Thanks Sam, that solved it. For some reason I was thinking that if you > don't specify the platform it downloads a version with all native > dependencies for cross compilation. > > On Wed, Sep 26, 2018 at 2:37 AM Sam Carlberg > wrote: > > > The libraries are in artifacts with platform-specific classifiers. The > > artifacts with no classifiers that you currently depend on are completely > > empty. > > > > You need to depend on "org.openjfx:javafx-base:11:$platform", where the > > platform is one of "win", "mac", or "linux". > > > > On Tue, Sep 25, 2018, 5:18 PM Nir Lisker wrote: > > > >> Hi, > >> > >> I haven't kept up with all of the Maven artifacts discussion. The > website > >> mentioned in 2 places that there are maven artifacts, but does not > mention > >> their ID's, group etc. These are the downloads page [1] and the getting > >> started page [2] (later you can see an example pom, but that doesn't > >> count). > >> > >> I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it finds > >> the artifacts. It should be written in the above pages if this is > correct. > >> > >> On the usability side it's worse. I'm using Eclipse and during > compilation > >> I'm getting error messages that JavaFX classes like BooleanProperty > can't > >> be found. Is it a JavaFX problem, Eclipse problem, or me problem? > >> > >> If I use the SDKs, can I point Gradle and Maven to them if it will solve > >> the problem? > >> > >> - Nir > >> > >> [1] https://gluonhq.com/products/javafx/ > >> [2] https://openjfx.io/openjfx-docs/#introduction > >> > > > From mike.ennen at gmail.com Wed Sep 26 10:19:03 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 26 Sep 2018 03:19:03 -0700 Subject: State of maven artifacts In-Reply-To: References: Message-ID: And just to reiterate and confirm for anyone trying to get a handle on using the Maven artifacts - it is *NOT* necessary to manually specify the platform classifier when using maven or gradle (nor add the automatic tricks to your own project) because the JavaFX artifacts will automatically detect the platform you are building on and pull in the correct artifacts, right? Thanks for your work in this area Johan. On Wed, Sep 26, 2018 at 12:31 AM Johan Vos wrote: > The problem with that is that there is no cross-platform version of the > jars itself. The windows-jar for the graphics module contains different > Java classes than the linux jar, for example. > The top-level API's are the same of course, hence the logical Java module > is the same, but different physical jars are really needed. > I realise this may be strange at compile time, where you only care about > the top-level API's. Therefore, people added nice "tricks" to both a > pom.xml and build.gradle system to automatically detect the current (host) > operating system, and making sure the correct artifacts are then used. > > What I really wanted to avoid is that developers had to manually add their > platform (e.g. "win") in the build files, as this would break > cross-platform development (imagine you're in a team with a win and a linux > user, and they constantly change the pom.xml or build.gradle file for > this...). > > I think the current solution deals pretty well with the current situations, > where there are different concepts in gradle/maven/sonatype and in the Java > module system. > > - Johan > > > > Op wo 26 sep. 2018 om 05:46 schreef Nir Lisker : > > > Thanks Sam, that solved it. For some reason I was thinking that if you > > don't specify the platform it downloads a version with all native > > dependencies for cross compilation. > > > > On Wed, Sep 26, 2018 at 2:37 AM Sam Carlberg > > wrote: > > > > > The libraries are in artifacts with platform-specific classifiers. The > > > artifacts with no classifiers that you currently depend on are > completely > > > empty. > > > > > > You need to depend on "org.openjfx:javafx-base:11:$platform", where the > > > platform is one of "win", "mac", or "linux". > > > > > > On Tue, Sep 25, 2018, 5:18 PM Nir Lisker wrote: > > > > > >> Hi, > > >> > > >> I haven't kept up with all of the Maven artifacts discussion. The > > website > > >> mentioned in 2 places that there are maven artifacts, but does not > > mention > > >> their ID's, group etc. These are the downloads page [1] and the > getting > > >> started page [2] (later you can see an example pom, but that doesn't > > >> count). > > >> > > >> I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it > finds > > >> the artifacts. It should be written in the above pages if this is > > correct. > > >> > > >> On the usability side it's worse. I'm using Eclipse and during > > compilation > > >> I'm getting error messages that JavaFX classes like BooleanProperty > > can't > > >> be found. Is it a JavaFX problem, Eclipse problem, or me problem? > > >> > > >> If I use the SDKs, can I point Gradle and Maven to them if it will > solve > > >> the problem? > > >> > > >> - Nir > > >> > > >> [1] https://gluonhq.com/products/javafx/ > > >> [2] https://openjfx.io/openjfx-docs/#introduction > > >> > > > > > > -- Michael Ennen From marcel.au at web.de Wed Sep 26 11:20:28 2018 From: marcel.au at web.de (marcel Austenfeld) Date: Wed, 26 Sep 2018 13:20:28 +0200 Subject: "Toolkit already initialized" error with OpenJDK 11 Message-ID: From marcel.au at web.de Wed Sep 26 11:22:49 2018 From: marcel.au at web.de (marcel Austenfeld) Date: Wed, 26 Sep 2018 13:22:49 +0200 Subject: "Toolkit already initialized" error with OpenJDK 11 Message-ID: First of all congratulation to the new release and thank you for the hard work on JavaFX. ? ? I have a problem with JavaFX which in my case is embedded in a Rich Client Platform of Eclipse. ? I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT replacement) into my app. ? This works fine in Java 8 which my current release depends on. ? However in Java 11 after the second panel is initialized at startup I get the following error: ? "Caused by: java.lang.IllegalStateException: Toolkit already initialized" ? Is there a new option available to avoid a new initialization of the toolkit if several FXCanvas are embedded in an application? Or do you now any changes since Java 8 which could the cause of such an exception? ? ? Thanks in advance for any help. From kevin.rushforth at oracle.com Wed Sep 26 12:09:02 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 26 Sep 2018 05:09:02 -0700 Subject: "Toolkit already initialized" error with OpenJDK 11 In-Reply-To: References: Message-ID: I'm' not aware of anything that intentionally changed between FX in JDK 8 and FX 11, but my guess is that the FX runtime is being shutdown after your first FXCanvas exits. Try making the following call (only needed one time) before creating your first FXCanvas: ??? Platform.setImplicitExit(false); -- Kevin On 9/26/2018 4:22 AM, marcel Austenfeld wrote: > First of all congratulation to the new release and thank you for the hard work on JavaFX. > > > I have a problem with JavaFX which in my case is embedded in a Rich Client Platform of Eclipse. > > I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT replacement) into my app. > > This works fine in Java 8 which my current release depends on. > > However in Java 11 after the second panel is initialized at startup I get the following error: > > "Caused by: java.lang.IllegalStateException: Toolkit already initialized" > > Is there a new option available to avoid a new initialization of the toolkit if several FXCanvas are embedded in an application? > Or do you now any changes since Java 8 which could the cause of such an exception? > > > Thanks in advance for any help. From marcel.au at web.de Wed Sep 26 13:31:10 2018 From: marcel.au at web.de (marcel Austenfeld) Date: Wed, 26 Sep 2018 15:31:10 +0200 Subject: "Toolkit already initialized" error with OpenJDK 11 Message-ID: Hello Kevin, I already use Platform.setImplicitExit(false) at startup so this can't be the problem. All SWT FXCanvas are not closed (at least at startup). Could it be that the initialisation of the SWT FXCanvas is different and could cause the problem. At the moment I use as java arguments: --module-path C:\javafx-sdk-11\lib --add-modules javafx.controls,javafx.swing,javafx.swt The javafx.swt module is accepted but I have to add the javafx-swt.jar to my classpath to get at least an embedded canvas working. Without the *.jar it won't work at all. Is there a better or recommended option to include the javafx-swt.jar classes at startup in the --add-modules option? The --add-modules javafx.swt doesn't seem to work. From kevin.rushforth at oracle.com Wed Sep 26 15:22:57 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 26 Sep 2018 08:22:57 -0700 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 In-Reply-To: <3017d185-5314-bec8-0cf2-0f305da5fab2@bestsolution.at> References: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> <3c90e7b3-51d9-5c1a-3446-129846aa7338@oracle.com> <498052a2-6acf-757d-e457-7decca2865da@oracle.com> <3017d185-5314-bec8-0cf2-0f305da5fab2@bestsolution.at> Message-ID: <15a9002d-5ffb-9d9f-afd6-f8c29fe4e361@oracle.com> > So I think we should official define the JDK N-1 and JDK N but don't pro > actively break JDK N-2, ... if there's no real value. Perhaps your suggestion is a good compromise: if we choose this approach, then we would still claim support for only JDK N-1 and JDK N, but wouldn't go out of our way to stop it from running on JDK N-2 unless/until there was a feature or bug fix that required something from JDK N-1. Given that it could break -- either because we need something from JDK N-2 or because of a bug that gets introduced and we no longer test with JDK N-2 -- application vendors wouldn't be able to rely on FX N working with JDK N-2. Johan: what do you think? -- Kevin On 9/24/2018 12:14 PM, Tom Schindl wrote: > Hi, > > As a general rule I'm fine with that but as outlined in another reply we > should only break building with older JDKs in case it really adds value. > > So I think we should official define the JDK N-1 and JDK N but don't pro > actively break JDK N-2, ... if there's no real value. > > Tom > > On 24.09.18 16:40, Kevin Rushforth wrote: >>> In general, I think developers updating from JavaFX 11-12-13 are also >>> capable of updating the JDK from 11-12-13, so I prefer the coupling >>> >>> 1. Allow building JavaFX N with either JDK N-1 or JDK N. >>> >> This is also my preference. >> >> -- Kevin >> >> >> On 9/24/2018 12:12 AM, Johan Vos wrote: >>> >>> ??? > And it's only going to get worse as time goes on. Would it not be >>> ??? > possible to support up until the last JDK LTS(Starting at 11) >>> ??? release >>> ??? > for building JavaFX? I feel like maybe that would be more >>> ??? reasonable. >>> >>> ??? This is a good question, and maybe in the future we might not be so >>> ??? quick to do this...or maybe we will.? We should discuss this >>> ??? before we >>> ??? get to this point for JavaFX 13, a little less than six months >>> ??? from now. >>> ??? The choices for the model are: >>> >>> ??? 1. Allow building JavaFX N with either JDK N-1 or JDK N. >>> ??? 2. Allow building JavaFX N with the most recent LTS or later. >>> >>> ??? Choice #1 will allow JavaFX to better keep pace with JDK features >>> ??? (API >>> ??? or language features). Choice #2 will allow JavaFX to build and >>> ??? run with >>> ??? the most current, stable JDK LTS at the cost of not being able to use >>> ??? newer JDK features. >>> >>> >>> One of the reasons Java is moving to a fast release cadence is because >>> today, this is required to stay relevant in a fast-changing landscape. >>> I think we need to do the same with JavaFX. We should be able to >>> leverage the latest and greatest advances in the JDK, since this will >>> allow JavaFX to move fast as well, which is required to stay relevant. >>> >>> If you want to run on the latest stable JDK LTS, the logical >>> consequence seems to me you use the latest stable JavaFX LTS. There is >>> LTS support available for both Java and JavaFX 11 and they are pretty >>> well aligned. >>> >>> Having said that, there is no point in moving forward just for the fun >>> of it. We also have to distinguish between changes in the VM or in the >>> core Java API's. >>> My opinion is that if a new feature is added to JDK N, we can really >>> take advantage of it in JavaFX (N+1). >>> In some cases, there won't be new features relevant to OpenJFX. But >>> even then, I don't think we can't change our rules on a per-release >>> case (e.g. JavaFX 14 works with Java 13 and Java 14, and even Java 12; >>> but JavaFX 15 works with Java 14 and Java 15 and not with Java 13). >>> >>> In general, I think developers updating from JavaFX 11-12-13 are also >>> capable of updating the JDK from 11-12-13, so I prefer the coupling >>> >>> 1. Allow building JavaFX N with either JDK N-1 or JDK N. >>> >>> - Johan >>> >>> >>> From john at status6.com Wed Sep 26 17:46:43 2018 From: john at status6.com (John Neffenger) Date: Wed, 26 Sep 2018 10:46:43 -0700 Subject: HTTPS download location or checksum available? Message-ID: <5a671270-1637-c52f-f70b-bddd24693e2d@status6.com> Is it possible to change the following page either to download the files over HTTPS or provide their checksums on an HTTPS page (as Oracle does for the JDK)? JavaFX - Gluon https://gluonhq.com/products/javafx/ The page redirects to an insecure HTTP connection when downloading the Linux files, for example: JavaFX Linux SDK http://gluonhq.com/download/javafx-11-sdk-linux/ --> Location: https://gluonhq.com/download/javafx-11-sdk-linux/ --> Location: http://download2.gluonhq.com/openjfx/11/openjfx-11_linux-x64_bin-sdk.zip JavaFX Linux jmods https://gluonhq.com/download/javafx-11-jmods-linux/ --> Location: http://download2.gluonhq.com/openjfx/11/openjfx-11_linux-x64_bin-jmods.zip Is that the official download page outside of the Maven repositories? Thank you, John From sverre.moe at gmail.com Wed Sep 26 18:50:17 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 26 Sep 2018 20:50:17 +0200 Subject: Filling the Packager gap In-Reply-To: References: Message-ID: I have tried this jpackager a bit. It is working fine packaging a Java modular project. However it fails to package a none modular project. I modified my project and removed the modularization and tried again to see if it would work to package our legacy Java 8 project (though now built with JDK 11 and with dependencies on openjfx 11). I was under the impression that the jpackager should also work to package non-modular projects. The Gradle distribution task produces an tar archive with all the dependencies and my own JAR, which I am using as input to the jpackager. This produces the RPM for the modular project: sverre at mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib> ~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir --verbose --echo-mode --module-path . --module no.smeaworks.movies/no.smeaworks.movies.MoviesApplication Using the jpackager to package non modular project: sverre at mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT> ~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output outputDir --verbose --echo-mode --class no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar ECHO-MODE: Running [rpmbuild, --version] "Adding modules: [] to runtime image." ECHO-MODE: Running jlink [ --output = /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime --module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods] --add-modules = [] --limit-modules = [] --exclude-files = .*\.diz --strip-native-commands = false ] /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException: jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing for java.base module Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use them to customize package. Exception in thread "main" jdk.packager.internal.PackagerException: Error: Bundler "RPM Bundle" (rpm) failed to produce a bundle. at jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642) at jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582) at jdk.packager/jdk.packager.Main.run(Main.java:71) at jdk.packager/jdk.packager.Main.main(Main.java:47) Is my presumption wrong that it should package also non modular projects, or am I missing some runtime flags to jpackager? Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I reckon that Gluon has yet to modularize SceneBuilder? Can you provide some insight how you use jpackage to build the project? I could not find anything on it in the Gluon SceneBuilder GitHub repository. /Sverre Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos : > Hi, > > As promised, we looked into an interim solution for the packager-gap. Work > for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. > We backported the required changes to an OpenJDK 11 mirror: > https://github.com/johanvos/openjdk-mobile11/tree/packager > > With this, we created modified OpenJDK 11 builds that contain the packager > (wrapper/exe + module including native library). They can be downloaded and > tested/used at > > http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip > > For Windows, you have to unzip the bundle in the same directory as the JDK, > as the packager wrapper expect to find the java binary at the same level. > > Note that these are not products. We use them internally to create > installers (e.g. we're using them for Scene Builder 11 and that works > fine), and they do what we expect them to do, but there are no guarantees > of course so at least for now I recommend using them in development only > (or even better, look at the changes and contribute to > https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) > > - Johan > From kevin.rushforth at oracle.com Wed Sep 26 19:44:31 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 26 Sep 2018 12:44:31 -0700 Subject: Filling the Packager gap In-Reply-To: References: Message-ID: <21473946-e701-9a78-520f-5faedfacaee2@oracle.com> jpackager should work for non-modular applications as well as modular ones. We've tested it for simple applications with or without FX. In the latter case, the testing I've done has been done by first using jlink to create a Java runtime with the needed JDK modules + the openjfx11 modules (using the jomds). Andy might have additional comments. -- Kevin On 9/26/2018 11:50 AM, Sverre Moe wrote: > I have tried this jpackager a bit. It is working fine packaging a Java > modular project. > However it fails to package a none modular project. I modified my project > and removed the modularization and tried again to see if it would work to > package our legacy Java 8 project (though now built with JDK 11 and with > dependencies on openjfx 11). > > I was under the impression that the jpackager should also work to package > non-modular projects. > > The Gradle distribution task produces an tar archive with all the > dependencies and my own JAR, which I am using as input to the jpackager. > > This produces the RPM for the modular project: > sverre at mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib> > ~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir > --verbose --echo-mode --module-path . --module > no.smeaworks.movies/no.smeaworks.movies.MoviesApplication > > Using the jpackager to package non modular project: > sverre at mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT> > ~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output > outputDir --verbose --echo-mode --class > no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar > > > ECHO-MODE: Running [rpmbuild, --version] > > "Adding modules: [] to runtime image." > > ECHO-MODE: Running jlink [ > --output = > /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime > --module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods] > --add-modules = [] > --limit-modules = [] > --exclude-files = .*\.diz > --strip-native-commands = false > ] > /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime > Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException: > jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing > for java.base module > Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use > them to customize package. > Exception in thread "main" jdk.packager.internal.PackagerException: Error: > Bundler "RPM Bundle" (rpm) failed to produce a bundle. > at > jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642) > > at > jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582) > > at jdk.packager/jdk.packager.Main.run(Main.java:71) > at jdk.packager/jdk.packager.Main.main(Main.java:47) > > > Is my presumption wrong that it should package also non modular projects, > or am I missing some runtime flags to jpackager? > > Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I > reckon that Gluon has yet to modularize SceneBuilder? Can you provide some > insight how you use jpackage to build the project? I could not find > anything on it in the Gluon SceneBuilder GitHub repository. > > /Sverre > > Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos : > >> Hi, >> >> As promised, we looked into an interim solution for the packager-gap. Work >> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. >> We backported the required changes to an OpenJDK 11 mirror: >> https://github.com/johanvos/openjdk-mobile11/tree/packager >> >> With this, we created modified OpenJDK 11 builds that contain the packager >> (wrapper/exe + module including native library). They can be downloaded and >> tested/used at >> >> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip >> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip >> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip >> >> For Windows, you have to unzip the bundle in the same directory as the JDK, >> as the packager wrapper expect to find the java binary at the same level. >> >> Note that these are not products. We use them internally to create >> installers (e.g. we're using them for Scene Builder 11 and that works >> fine), and they do what we expect them to do, but there are no guarantees >> of course so at least for now I recommend using them in development only >> (or even better, look at the changes and contribute to >> https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) >> >> - Johan >> From johan.vos at gluonhq.com Wed Sep 26 19:45:11 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 26 Sep 2018 21:45:11 +0200 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 In-Reply-To: <15a9002d-5ffb-9d9f-afd6-f8c29fe4e361@oracle.com> References: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> <3c90e7b3-51d9-5c1a-3446-129846aa7338@oracle.com> <498052a2-6acf-757d-e457-7decca2865da@oracle.com> <3017d185-5314-bec8-0cf2-0f305da5fab2@bestsolution.at> <15a9002d-5ffb-9d9f-afd6-f8c29fe4e361@oracle.com> Message-ID: I agree with the idea of not actively breaking things if not needed, on the other hand I like predictability (instead of remembering that JavaFX 19 works with Java 17 but JavaFX 20 doens't work with Java 18 etc). But from a pragmatic point, I'm ok with it. The main difficulty in the whole minimum boot JDK is probably the classfile format. If we now compile with JDK 11 and produce bytecode with version 55, it won't run on JDK 10 VM's, even though there might be no API's or VM specs that are specific to 11. I agree that if there is no reason to make use of new API's or VM functionality, there is no reason to make it not work on previous JDK's. - Johan On Wed, Sep 26, 2018 at 8:53 PM Kevin Rushforth wrote: > > > So I think we should official define the JDK N-1 and JDK N but don't pro > > actively break JDK N-2, ... if there's no real value. > > Perhaps your suggestion is a good compromise: if we choose this > approach, then we would still claim support for only JDK N-1 and JDK N, > but wouldn't go out of our way to stop it from running on JDK N-2 > unless/until there was a feature or bug fix that required something from > JDK N-1. Given that it could break -- either because we need something > from JDK N-2 or because of a bug that gets introduced and we no longer > test with JDK N-2 -- application vendors wouldn't be able to rely on FX > N working with JDK N-2. > > Johan: what do you think? > > -- Kevin > > > On 9/24/2018 12:14 PM, Tom Schindl wrote: > > Hi, > > > > As a general rule I'm fine with that but as outlined in another reply we > > should only break building with older JDKs in case it really adds value. > > > > So I think we should official define the JDK N-1 and JDK N but don't pro > > actively break JDK N-2, ... if there's no real value. > > > > Tom > > > > On 24.09.18 16:40, Kevin Rushforth wrote: > >>> In general, I think developers updating from JavaFX 11-12-13 are also > >>> capable of updating the JDK from 11-12-13, so I prefer the coupling > >>> > >>> 1. Allow building JavaFX N with either JDK N-1 or JDK N. > >>> > >> This is also my preference. > >> > >> -- Kevin > >> > >> > >> On 9/24/2018 12:12 AM, Johan Vos wrote: > >>> > >>> > And it's only going to get worse as time goes on. Would it not > be > >>> > possible to support up until the last JDK LTS(Starting at 11) > >>> release > >>> > for building JavaFX? I feel like maybe that would be more > >>> reasonable. > >>> > >>> This is a good question, and maybe in the future we might not be > so > >>> quick to do this...or maybe we will. We should discuss this > >>> before we > >>> get to this point for JavaFX 13, a little less than six months > >>> from now. > >>> The choices for the model are: > >>> > >>> 1. Allow building JavaFX N with either JDK N-1 or JDK N. > >>> 2. Allow building JavaFX N with the most recent LTS or later. > >>> > >>> Choice #1 will allow JavaFX to better keep pace with JDK features > >>> (API > >>> or language features). Choice #2 will allow JavaFX to build and > >>> run with > >>> the most current, stable JDK LTS at the cost of not being able to > use > >>> newer JDK features. > >>> > >>> > >>> One of the reasons Java is moving to a fast release cadence is because > >>> today, this is required to stay relevant in a fast-changing landscape. > >>> I think we need to do the same with JavaFX. We should be able to > >>> leverage the latest and greatest advances in the JDK, since this will > >>> allow JavaFX to move fast as well, which is required to stay relevant. > >>> > >>> If you want to run on the latest stable JDK LTS, the logical > >>> consequence seems to me you use the latest stable JavaFX LTS. There is > >>> LTS support available for both Java and JavaFX 11 and they are pretty > >>> well aligned. > >>> > >>> Having said that, there is no point in moving forward just for the fun > >>> of it. We also have to distinguish between changes in the VM or in the > >>> core Java API's. > >>> My opinion is that if a new feature is added to JDK N, we can really > >>> take advantage of it in JavaFX (N+1). > >>> In some cases, there won't be new features relevant to OpenJFX. But > >>> even then, I don't think we can't change our rules on a per-release > >>> case (e.g. JavaFX 14 works with Java 13 and Java 14, and even Java 12; > >>> but JavaFX 15 works with Java 14 and Java 15 and not with Java 13). > >>> > >>> In general, I think developers updating from JavaFX 11-12-13 are also > >>> capable of updating the JDK from 11-12-13, so I prefer the coupling > >>> > >>> 1. Allow building JavaFX N with either JDK N-1 or JDK N. > >>> > >>> - Johan > >>> > >>> > >>> > > From jose.rodriguez at cenpalab.cu Wed Sep 26 21:26:41 2018 From: jose.rodriguez at cenpalab.cu (=?UTF-8?Q?Jos=c3=a9_J._Rodriguez?=) Date: Wed, 26 Sep 2018 17:26:41 -0400 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 In-Reply-To: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> References: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> Message-ID: <29eb63eb-d13c-5c11-8cf1-26f4cc651458@cenpalab.cu> Ty Young wrote: > > And it's only going to get worse as time goes on. Would it not be > possible to support up until the last JDK LTS(Starting at 11) release > for building JavaFX? I feel like maybe that would be more reasonable. > FWIW, I would prefer it if jfx only followed the LTS jdk releases. Regards, Joe1962 From swpalmer at gmail.com Wed Sep 26 22:23:40 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 26 Sep 2018 18:23:40 -0400 Subject: Filling the Packager gap In-Reply-To: <21473946-e701-9a78-520f-5faedfacaee2@oracle.com> References: <21473946-e701-9a78-520f-5faedfacaee2@oracle.com> Message-ID: <8D57F8CD-AD30-4E6F-81EC-9FACF919EAC8@gmail.com> Does jlink work for non-modular stuff? The last time I tried it complained to me too. I guess it gives up because it can?t automatically figure out module dependencies. The error below shows jlink is what is complaining. Scott > On Sep 26, 2018, at 3:44 PM, Kevin Rushforth wrote: > > jpackager should work for non-modular applications as well as modular ones. We've tested it for simple applications with or without FX. In the latter case, the testing I've done has been done by first using jlink to create a Java runtime with the needed JDK modules + the openjfx11 modules (using the jomds). > > Andy might have additional comments. > > -- Kevin > > > On 9/26/2018 11:50 AM, Sverre Moe wrote: >> I have tried this jpackager a bit. It is working fine packaging a Java >> modular project. >> However it fails to package a none modular project. I modified my project >> and removed the modularization and tried again to see if it would work to >> package our legacy Java 8 project (though now built with JDK 11 and with >> dependencies on openjfx 11). >> >> I was under the impression that the jpackager should also work to package >> non-modular projects. >> >> The Gradle distribution task produces an tar archive with all the >> dependencies and my own JAR, which I am using as input to the jpackager. >> >> This produces the RPM for the modular project: >> sverre at mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib> >> ~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir >> --verbose --echo-mode --module-path . --module >> no.smeaworks.movies/no.smeaworks.movies.MoviesApplication >> >> Using the jpackager to package non modular project: >> sverre at mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT> >> ~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output >> outputDir --verbose --echo-mode --class >> no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar >> >> >> ECHO-MODE: Running [rpmbuild, --version] >> >> "Adding modules: [] to runtime image." >> >> ECHO-MODE: Running jlink [ >> --output = >> /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime >> --module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods] >> --add-modules = [] >> --limit-modules = [] >> --exclude-files = .*\.diz >> --strip-native-commands = false >> ] >> /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime >> Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException: >> jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing >> for java.base module >> Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use >> them to customize package. >> Exception in thread "main" jdk.packager.internal.PackagerException: Error: >> Bundler "RPM Bundle" (rpm) failed to produce a bundle. >> at >> jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642) >> >> at >> jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582) >> >> at jdk.packager/jdk.packager.Main.run(Main.java:71) >> at jdk.packager/jdk.packager.Main.main(Main.java:47) >> >> >> Is my presumption wrong that it should package also non modular projects, >> or am I missing some runtime flags to jpackager? >> >> Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I >> reckon that Gluon has yet to modularize SceneBuilder? Can you provide some >> insight how you use jpackage to build the project? I could not find >> anything on it in the Gluon SceneBuilder GitHub repository. >> >> /Sverre >> >> Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos : >> >>> Hi, >>> >>> As promised, we looked into an interim solution for the packager-gap. Work >>> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. >>> We backported the required changes to an OpenJDK 11 mirror: >>> https://github.com/johanvos/openjdk-mobile11/tree/packager >>> >>> With this, we created modified OpenJDK 11 builds that contain the packager >>> (wrapper/exe + module including native library). They can be downloaded and >>> tested/used at >>> >>> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip >>> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip >>> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip >>> >>> For Windows, you have to unzip the bundle in the same directory as the JDK, >>> as the packager wrapper expect to find the java binary at the same level. >>> >>> Note that these are not products. We use them internally to create >>> installers (e.g. we're using them for Scene Builder 11 and that works >>> fine), and they do what we expect them to do, but there are no guarantees >>> of course so at least for now I recommend using them in development only >>> (or even better, look at the changes and contribute to >>> https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) >>> >>> - Johan >>> > From kevin.rushforth at oracle.com Wed Sep 26 22:49:45 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 26 Sep 2018 15:49:45 -0700 Subject: Filling the Packager gap In-Reply-To: <8D57F8CD-AD30-4E6F-81EC-9FACF919EAC8@gmail.com> References: <21473946-e701-9a78-520f-5faedfacaee2@oracle.com> <8D57F8CD-AD30-4E6F-81EC-9FACF919EAC8@gmail.com> Message-ID: <032f8884-ff36-fa13-37c3-d1187b49ce45@oracle.com> No, jlink won't link in a non-modular application. So the steps are: 1) Run jlink to create a Java runtime image, possibly stripped down, and include the javafx.* modules you need 2) Run jpackager to package your non-modular application with the above Java runtime image. -- Kevin On 9/26/2018 3:23 PM, Scott Palmer wrote: > Does jlink work for non-modular stuff? The last time I tried it complained to me too. I guess it gives up because it can?t automatically figure out module dependencies. The error below shows jlink is what is complaining. > > Scott > > >> On Sep 26, 2018, at 3:44 PM, Kevin Rushforth wrote: >> >> jpackager should work for non-modular applications as well as modular ones. We've tested it for simple applications with or without FX. In the latter case, the testing I've done has been done by first using jlink to create a Java runtime with the needed JDK modules + the openjfx11 modules (using the jomds). >> >> Andy might have additional comments. >> >> -- Kevin >> >> >> On 9/26/2018 11:50 AM, Sverre Moe wrote: >>> I have tried this jpackager a bit. It is working fine packaging a Java >>> modular project. >>> However it fails to package a none modular project. I modified my project >>> and removed the modularization and tried again to see if it would work to >>> package our legacy Java 8 project (though now built with JDK 11 and with >>> dependencies on openjfx 11). >>> >>> I was under the impression that the jpackager should also work to package >>> non-modular projects. >>> >>> The Gradle distribution task produces an tar archive with all the >>> dependencies and my own JAR, which I am using as input to the jpackager. >>> >>> This produces the RPM for the modular project: >>> sverre at mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib> >>> ~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir >>> --verbose --echo-mode --module-path . --module >>> no.smeaworks.movies/no.smeaworks.movies.MoviesApplication >>> >>> Using the jpackager to package non modular project: >>> sverre at mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT> >>> ~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output >>> outputDir --verbose --echo-mode --class >>> no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar >>> >>> >>> ECHO-MODE: Running [rpmbuild, --version] >>> >>> "Adding modules: [] to runtime image." >>> >>> ECHO-MODE: Running jlink [ >>> --output = >>> /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime >>> --module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods] >>> --add-modules = [] >>> --limit-modules = [] >>> --exclude-files = .*\.diz >>> --strip-native-commands = false >>> ] >>> /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime >>> Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException: >>> jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing >>> for java.base module >>> Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use >>> them to customize package. >>> Exception in thread "main" jdk.packager.internal.PackagerException: Error: >>> Bundler "RPM Bundle" (rpm) failed to produce a bundle. >>> at >>> jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642) >>> >>> at >>> jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582) >>> >>> at jdk.packager/jdk.packager.Main.run(Main.java:71) >>> at jdk.packager/jdk.packager.Main.main(Main.java:47) >>> >>> >>> Is my presumption wrong that it should package also non modular projects, >>> or am I missing some runtime flags to jpackager? >>> >>> Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I >>> reckon that Gluon has yet to modularize SceneBuilder? Can you provide some >>> insight how you use jpackage to build the project? I could not find >>> anything on it in the Gluon SceneBuilder GitHub repository. >>> >>> /Sverre >>> >>> Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos : >>> >>>> Hi, >>>> >>>> As promised, we looked into an interim solution for the packager-gap. Work >>>> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. >>>> We backported the required changes to an OpenJDK 11 mirror: >>>> https://github.com/johanvos/openjdk-mobile11/tree/packager >>>> >>>> With this, we created modified OpenJDK 11 builds that contain the packager >>>> (wrapper/exe + module including native library). They can be downloaded and >>>> tested/used at >>>> >>>> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip >>>> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip >>>> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip >>>> >>>> For Windows, you have to unzip the bundle in the same directory as the JDK, >>>> as the packager wrapper expect to find the java binary at the same level. >>>> >>>> Note that these are not products. We use them internally to create >>>> installers (e.g. we're using them for Scene Builder 11 and that works >>>> fine), and they do what we expect them to do, but there are no guarantees >>>> of course so at least for now I recommend using them in development only >>>> (or even better, look at the changes and contribute to >>>> https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) >>>> >>>> - Johan >>>> From nlisker at gmail.com Thu Sep 27 00:38:29 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 27 Sep 2018 03:38:29 +0300 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 In-Reply-To: <29eb63eb-d13c-5c11-8cf1-26f4cc651458@cenpalab.cu> References: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> <29eb63eb-d13c-5c11-8cf1-26f4cc651458@cenpalab.cu> Message-ID: > > but wouldn't go out of our way to stop it from running on JDK N-2 > unless/until there was a feature or bug fix that required something from > JDK N-1. > I would be surprised if there will be a release without a language change, as I don't recall any release without one, and Amber (and friends) keeps providing. Now, we can discuss what is "required". Java 11 added 'var' for Lambdas. Is it something worth bumping the minimum version for? Isn't it enough that it's used once in the codebase to make it incompatible with pre-11 JDK's? And if so, we'll have to document what contributors are allowed to use and what not when working on JavaFX. We will have to have this discussion every release to determine if we bump the minimum version or not. On Thu, Sep 27, 2018 at 12:27 AM Jos? J. Rodriguez < jose.rodriguez at cenpalab.cu> wrote: > Ty Young wrote: > > > > And it's only going to get worse as time goes on. Would it not be > > possible to support up until the last JDK LTS(Starting at 11) release > > for building JavaFX? I feel like maybe that would be more reasonable. > > > > > FWIW, I would prefer it if jfx only followed the LTS jdk releases. > > Regards, > Joe1962 > From youngty1997 at gmail.com Thu Sep 27 02:03:53 2018 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 26 Sep 2018 21:03:53 -0500 Subject: Filling the Packager gap In-Reply-To: References: Message-ID: <0e66d63a-f87d-396c-1b48-123a707c92ca@gmail.com> On 9/19/18 3:55 AM, Johan Vos wrote: > Hi, > > As promised, we looked into an interim solution for the packager-gap. Work > for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. > We backported the required changes to an OpenJDK 11 mirror: > https://github.com/johanvos/openjdk-mobile11/tree/packager > > With this, we created modified OpenJDK 11 builds that contain the packager > (wrapper/exe + module including native library). They can be downloaded and > tested/used at > > http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip > > For Windows, you have to unzip the bundle in the same directory as the JDK, > as the packager wrapper expect to find the java binary at the same level. > > Note that these are not products. We use them internally to create > installers (e.g. we're using them for Scene Builder 11 and that works > fine), and they do what we expect them to do, but there are no guarantees > of course so at least for now I recommend using them in development only > (or even better, look at the changes and contribute to > https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) > > - Johan The JDK source fails to compile due to a duplicate qualified export. Removing the export from openjdk-mobile11-packager/src/jdk.jlink/share/classes/module-info.java fixes it. By the way, how does one use this with jLink generated by Netbeans? I used the jLink build as the input and it just dumped it into the "app" folder when making the image which doesn't work. From johan.vos at gluonhq.com Thu Sep 27 06:44:33 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 27 Sep 2018 08:44:33 +0200 Subject: Filling the Packager gap In-Reply-To: <0e66d63a-f87d-396c-1b48-123a707c92ca@gmail.com> References: <0e66d63a-f87d-396c-1b48-123a707c92ca@gmail.com> Message-ID: Hi Ty, Apart om jdk.jlink, who else is exporting jdk.tools.jlink.internal.packager ? If that is the case, there must be something wrong. The 12-sandbox version also exports that package: http://hg.openjdk.java.net/jdk/sandbox/file/6972c0e75e23/src/jdk.jlink/share/classes/module-info.java - Johan On Thu, Sep 27, 2018 at 4:14 AM Ty Young wrote: > > On 9/19/18 3:55 AM, Johan Vos wrote: > > Hi, > > > > As promised, we looked into an interim solution for the packager-gap. > Work > > for the new Java Packager (12?) is being done in the OpenJDK sandbox > repo. > > We backported the required changes to an OpenJDK 11 mirror: > > https://github.com/johanvos/openjdk-mobile11/tree/packager > > > > With this, we created modified OpenJDK 11 builds that contain the > packager > > (wrapper/exe + module including native library). They can be downloaded > and > > tested/used at > > > > http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip > > http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip > > http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip > > > > For Windows, you have to unzip the bundle in the same directory as the > JDK, > > as the packager wrapper expect to find the java binary at the same level. > > > > Note that these are not products. We use them internally to create > > installers (e.g. we're using them for Scene Builder 11 and that works > > fine), and they do what we expect them to do, but there are no guarantees > > of course so at least for now I recommend using them in development only > > (or even better, look at the changes and contribute to > > https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) > > > > - Johan > > > The JDK source fails to compile due to a duplicate qualified export. > Removing the export from > openjdk-mobile11-packager/src/jdk.jlink/share/classes/module-info.java > fixes it. > > > By the way, how does one use this with jLink generated by Netbeans? I > used the jLink build as the input and it just dumped it into the "app" > folder when making the image which doesn't work. > > > > From johan.vos at gluonhq.com Thu Sep 27 06:52:04 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 27 Sep 2018 08:52:04 +0200 Subject: [12] RFR: JDK-8209966: Update minimum boot JDK to 11 In-Reply-To: References: <1af2e424-0248-b6d8-5dea-be28642efd59@gmail.com> <29eb63eb-d13c-5c11-8cf1-26f4cc651458@cenpalab.cu> Message-ID: Historically, there was a no-go for default interface methods in the 8-tree a long time ago, as those would break the android port (thanks Stephen Northover for imposing that). Hence, I was happy with the restrictions not to use new language features. Android is a special case though, as that is the only environment I know about where the JavaFX applications (and jars) are not running on controllable JRE's. If JavaFX applications are packaged and bundled with JRE's, I don't see reasons why moving to new JDK versions can be a problem. However, if there are more cases like Android, where the developer doesn't control the version at runtime, we have to consider being more conservative. - Johan On Thu, Sep 27, 2018 at 2:49 AM Nir Lisker wrote: > > > > but wouldn't go out of our way to stop it from running on JDK N-2 > > unless/until there was a feature or bug fix that required something from > > JDK N-1. > > > > I would be surprised if there will be a release without a language change, > as I don't recall any release without one, and Amber (and friends) keeps > providing. > Now, we can discuss what is "required". Java 11 added 'var' for Lambdas. Is > it something worth bumping the minimum version for? Isn't it enough that > it's used once in the codebase to make it incompatible with pre-11 JDK's? > And if so, we'll have to document what contributors are allowed to use and > what not when working on JavaFX. > > We will have to have this discussion every release to determine if we bump > the minimum version or not. > > On Thu, Sep 27, 2018 at 12:27 AM Jos? J. Rodriguez < > jose.rodriguez at cenpalab.cu> wrote: > > > Ty Young wrote: > > > > > > And it's only going to get worse as time goes on. Would it not be > > > possible to support up until the last JDK LTS(Starting at 11) release > > > for building JavaFX? I feel like maybe that would be more reasonable. > > > > > > > > > FWIW, I would prefer it if jfx only followed the LTS jdk releases. > > > > Regards, > > Joe1962 > > > From sverre.moe at gmail.com Thu Sep 27 08:42:36 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 27 Sep 2018 10:42:36 +0200 Subject: Filling the Packager gap In-Reply-To: <032f8884-ff36-fa13-37c3-d1187b49ce45@oracle.com> References: <21473946-e701-9a78-520f-5faedfacaee2@oracle.com> <8D57F8CD-AD30-4E6F-81EC-9FACF919EAC8@gmail.com> <032f8884-ff36-fa13-37c3-d1187b49ce45@oracle.com> Message-ID: Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth < kevin.rushforth at oracle.com>: > No, jlink won't link in a non-modular application. So the steps are: > > 1) Run jlink to create a Java runtime image, possibly stripped down, and > include the javafx.* modules you need > 2) Run jpackager to package your non-modular application with the above > Java runtime image. > > -- Kevin > So we have to create the image with the jlink first before we use jpackager, and we have to link in with the javafx modules. We cannot use the javafx dependencies in the project? jlink --add-modules=ALL-SYSTEM --output image Error: Module ALL-SYSTEM not found The just to make sure we have everything we need I add the actual modules jlink --add-modules=java.base --add-modules=java.desktop --add-modules=java.net.http --add-modules=java.xml --add-modules=java.prefs --add-modules=java.logging --output image Linking in with the JavaFX jmods from Gluon: jlink --add-modules=java.base --add-modules=java.desktop --add-modules=java.net.http --add-modules=java.xml --add-modules=java.prefs --add-modules=java.logging --module-path /usr/java/javafx-jmods-11/ --add-modules=javafx.base --add-modules=javafx.controls --add-modules=javafx.fxml --add-modules=javafx.graphics --add-modules=javafx.web --add-modules=javafx.media --add-modules=javafx.swing --output image I managed to build our Java 8 project with Java 11, using the JavaFX dependencies. Then using jpackager with the runtime image from jlink /usr/java/jpackager/jpackager create-installer --input build/distributions/application-1.0.0-SNAPSHOT/lib/ --output outputDir --runtime-image image/ --verbose --echo-mode --main-jar application-1.0.0-SNAPSHOT.jar Running the application image from jpackager First try: I thought I had added all necessary modules to the runtime image, but I needed one more, java.management. Second try: InteropFactory: cannot load com.sun.javafx.embed.swing.newimpl.InteropFactoryN Exception in thread "GUIBuilderWorker" java.lang.IllegalAccessError: class com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module javafx.swing) cannot access class sun.swing.JLightweightFrame (in module java.desktop) because module java.desktop does not export sun.swing to module javafx.swing at javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.(SwingNodeInteropO.java:71) at javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42) at javafx.swing/javafx.embed.swing.SwingNode.(SwingNode.java:271) at no.company.application.fx.MySwingComponent.initNode( MySwingComponent.java:155) The module java.desktop should include the AWT/Swing. At least I now have been able to create an native application using both jlink and the new jpackager. /Sverre From prasanta.sadhukhan at oracle.com Thu Sep 27 14:29:48 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 27 Sep 2018 19:59:48 +0530 Subject: [12] RFR: JDK-8210092: Remove old javafx.swing implementation In-Reply-To: <04dc0b44-4a92-af32-6af0-269fa78a3097@oracle.com> References: <04dc0b44-4a92-af32-6af0-269fa78a3097@oracle.com> Message-ID: <2ccf5fb5-296e-8fe2-2d31-97581dbaa6b8@oracle.com> +1 with the additional refactoring done. Regards Prasanta On 25-Sep-18 6:03 PM, Kevin Rushforth wrote: > Yes, that seems like a good bit of additional cleanup. I'll do that. > > -- Kevin > > > On 9/25/2018 1:41 AM, Prasanta Sadhukhan wrote: >> >> Hi Kevin, >> >> Removal looks ok but one thing, do we still need to keep the >> enhanced-for loop in InterOpFactory.java#getInstance now that we have >> only 1 factory? I guess we can probably remove the whole reflection >> thing also and instantiate InteropFactoryN directly, no? >> >> Regards >> Prasanta >> On 22-Sep-18 5:23 AM, Kevin Rushforth wrote: >>> Please review the following on GitHub: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8210092 >>> https://github.com/javafxports/openjdk-jfx/pull/207 >>> https://github.com/javafxports/openjdk-jfx/pull/207/files >>> >>> This will remove the old JDK-10-based implementation of FX / Swing >>> interop and cleanup the build to remove the legacy qualified exports >>> and the logic that optionally excludes the new implementation. It >>> also changes the dependency that javafx.swing has on >>> jdk.unsupported.desktop from "requires static" (optional) to >>> "requires", which will fix an existing bug with jlinked images that >>> include javafx.swing. >>> >>> -- Kevin >>> >> > From cenbe at kolabnow.com Thu Sep 27 14:39:24 2018 From: cenbe at kolabnow.com (Glenn Holmer) Date: Thu, 27 Sep 2018 09:39:24 -0500 Subject: tutorial Message-ID: On https://openjfx.io/openjfx-docs/ I don't see any content, just buttons and links that don't seem to do anything. Tried both Firefox and Chrome. Is it just me? -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." From nlisker at gmail.com Thu Sep 27 14:43:44 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 27 Sep 2018 17:43:44 +0300 Subject: tutorial In-Reply-To: References: Message-ID: Works for me on Vivaldi. On Thu, Sep 27, 2018 at 5:39 PM Glenn Holmer wrote: > On https://openjfx.io/openjfx-docs/ I don't see any content, just > buttons and links that don't seem to do anything. Tried both Firefox and > Chrome. Is it just me? > > -- > Glenn Holmer (Linux registered user #16682) > "After the vintage season came the aftermath -- and Cenbe." > From jose.rodriguez at cenpalab.cu Thu Sep 27 14:44:23 2018 From: jose.rodriguez at cenpalab.cu (=?UTF-8?Q?Jos=c3=a9_J._Rodriguez?=) Date: Thu, 27 Sep 2018 10:44:23 -0400 Subject: tutorial In-Reply-To: References: Message-ID: Glenn Holmer wrote: > On https://openjfx.io/openjfx-docs/ I don't see any content, just > buttons and links that don't seem to do anything. Tried both Firefox and > Chrome. Is it just me? > Works for me on SeaMonkey. Regards, Joe1962 From sverre.moe at gmail.com Thu Sep 27 16:03:56 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 27 Sep 2018 18:03:56 +0200 Subject: Filling the Packager gap In-Reply-To: References: <21473946-e701-9a78-520f-5faedfacaee2@oracle.com> <8D57F8CD-AD30-4E6F-81EC-9FACF919EAC8@gmail.com> <032f8884-ff36-fa13-37c3-d1187b49ce45@oracle.com> Message-ID: Without the reliance on javafx-swing I was able to create an image, package and execute my test application. Is the Swing problem a known bug in JavaFX 11? The jlink runtime image I reckon now also contains the JavaFX modules? Seems unnecessary when they already are dependencies. /Sverre Den tor. 27. sep. 2018 kl. 10:42 skrev Sverre Moe : > Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth < > kevin.rushforth at oracle.com>: > >> No, jlink won't link in a non-modular application. So the steps are: >> >> 1) Run jlink to create a Java runtime image, possibly stripped down, and >> include the javafx.* modules you need >> 2) Run jpackager to package your non-modular application with the above >> Java runtime image. >> >> -- Kevin >> > > So we have to create the image with the jlink first before we use > jpackager, and we have to link in with the javafx modules. We cannot use > the javafx dependencies in the project? > > jlink --add-modules=ALL-SYSTEM --output image > Error: Module ALL-SYSTEM not found > > The just to make sure we have everything we need I add the actual modules > jlink --add-modules=java.base --add-modules=java.desktop > --add-modules=java.net.http --add-modules=java.xml > --add-modules=java.prefs --add-modules=java.logging --output image > > Linking in with the JavaFX jmods from Gluon: > jlink --add-modules=java.base --add-modules=java.desktop > --add-modules=java.net.http --add-modules=java.xml > --add-modules=java.prefs --add-modules=java.logging --module-path > /usr/java/javafx-jmods-11/ --add-modules=javafx.base > --add-modules=javafx.controls --add-modules=javafx.fxml > --add-modules=javafx.graphics --add-modules=javafx.web > --add-modules=javafx.media --add-modules=javafx.swing --output image > > I managed to build our Java 8 project with Java 11, using the JavaFX > dependencies. > Then using jpackager with the runtime image from jlink > /usr/java/jpackager/jpackager create-installer --input > build/distributions/application-1.0.0-SNAPSHOT/lib/ --output outputDir > --runtime-image image/ --verbose --echo-mode --main-jar > application-1.0.0-SNAPSHOT.jar > > Running the application image from jpackager > First try: > I thought I had added all necessary modules to the runtime image, but I > needed one more, java.management. > > Second try: > InteropFactory: cannot load > com.sun.javafx.embed.swing.newimpl.InteropFactoryN > Exception in thread "GUIBuilderWorker" java.lang.IllegalAccessError: class > com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module > javafx.swing) cannot access class sun.swing.JLightweightFrame (in module > java.desktop) because module java.desktop does not export sun.swing to > module javafx.swing > at > javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.(SwingNodeInteropO.java:71) > > at > javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42) > > at > javafx.swing/javafx.embed.swing.SwingNode.(SwingNode.java:271) > at no.company.application.fx.MySwingComponent.initNode( > MySwingComponent.java:155) > > The module java.desktop should include the AWT/Swing. > > At least I now have been able to create an native application using both > jlink and the new jpackager. > > /Sverre > From kevin.rushforth at oracle.com Thu Sep 27 16:18:48 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 27 Sep 2018 09:18:48 -0700 Subject: Filling the Packager gap In-Reply-To: References: <21473946-e701-9a78-520f-5faedfacaee2@oracle.com> <8D57F8CD-AD30-4E6F-81EC-9FACF919EAC8@gmail.com> <032f8884-ff36-fa13-37c3-d1187b49ce45@oracle.com> Message-ID: <8a9652a2-0bf5-51b4-66f0-2a20a691963e@oracle.com> I missed seeing the swing exception in your earlier message. Yes, the Swing issue is a known problem in openjfx11, JDK-8210759 [1], and is documented in the release notes [2]. It will be fixed in openjfx12 just as soon as I push the fix for JDK-8210092 [3] later today (the review was just finished earlier this morning). This was one of the bugs waiting until the fix requiring JDK 11 for openjfx 12 was pushed. As for your other question, yes, if you add the javafx.* modules to your Java runtime image, then that runtime image contains the javafx.* modules. If your application were modularized, then the Java runtime image would contain your application, too. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8210759 [2] https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#known-issues [3] https://bugs.openjdk.java.net/browse/JDK-8210092 On 9/27/2018 9:03 AM, Sverre Moe wrote: > Without the reliance on javafx-swing I was able to create an image, > package and execute my test application. > Is the Swing problem a known bug in JavaFX 11? > > The jlink runtime image I reckon now also contains the JavaFX modules? > Seems unnecessary when they already are dependencies. > > /Sverre > > Den tor. 27. sep. 2018 kl. 10:42 skrev Sverre Moe > >: > > Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth > >: > > No, jlink won't link in a non-modular application. So the > steps are: > > 1) Run jlink to create a Java runtime image, possibly stripped > down, and > include the javafx.* modules you need > 2) Run jpackager to package your non-modular application with > the above > Java runtime image. > > -- Kevin > > > So we have to create the image with the jlink first before we use > jpackager, and we have to link in with the javafx modules. We > cannot use the javafx dependencies in the project? > > jlink --add-modules=ALL-SYSTEM --output image > Error: Module ALL-SYSTEM not found > > The just to make sure we have everything we need I add the actual > modules > jlink --add-modules=java.base --add-modules=java.desktop > --add-modules=java.net.http --add-modules=java.xml > --add-modules=java.prefs --add-modules=java.logging --output image > > Linking in with the JavaFX jmods from Gluon: > jlink --add-modules=java.base --add-modules=java.desktop > --add-modules=java.net.http --add-modules=java.xml > --add-modules=java.prefs --add-modules=java.logging --module-path > /usr/java/javafx-jmods-11/ --add-modules=javafx.base > --add-modules=javafx.controls --add-modules=javafx.fxml > --add-modules=javafx.graphics --add-modules=javafx.web > --add-modules=javafx.media --add-modules=javafx.swing --output image > > I managed to build our Java 8 project with Java 11, using the > JavaFX dependencies. > Then using jpackager with the runtime image from jlink > /usr/java/jpackager/jpackager create-installer --input > build/distributions/application-1.0.0-SNAPSHOT/lib/ --output > outputDir --runtime-image image/ --verbose --echo-mode --main-jar > application-1.0.0-SNAPSHOT.jar > > Running the application image from jpackager > First try: > I thought I had added all necessary modules to the runtime image, > but I needed one more, java.management. > > Second try: > InteropFactory: cannot load > com.sun.javafx.embed.swing.newimpl.InteropFactoryN > Exception in thread "GUIBuilderWorker" > java.lang.IllegalAccessError: class > com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module > javafx.swing) cannot access class sun.swing.JLightweightFrame (in > module java.desktop) because module java.desktop does not export > sun.swing to module javafx.swing > ???????at > javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.(SwingNodeInteropO.java:71) > ???????at > javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42) > ???????at > javafx.swing/javafx.embed.swing.SwingNode.(SwingNode.java:271) > ???????at > no.company.application.fx.MySwingComponent.initNode(MySwingComponent.java:155) > > The module java.desktop should include the AWT/Swing. > > At least I now have been able to create an native application > using both jlink and the new jpackager. > > /Sverre > From sverre.moe at gmail.com Thu Sep 27 16:27:33 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 27 Sep 2018 18:27:33 +0200 Subject: Filling the Packager gap In-Reply-To: <8a9652a2-0bf5-51b4-66f0-2a20a691963e@oracle.com> References: <21473946-e701-9a78-520f-5faedfacaee2@oracle.com> <8D57F8CD-AD30-4E6F-81EC-9FACF919EAC8@gmail.com> <032f8884-ff36-fa13-37c3-d1187b49ce45@oracle.com> <8a9652a2-0bf5-51b4-66f0-2a20a691963e@oracle.com> Message-ID: Any chance of getting the fix for JDK-8210759 backported to JDK 11? I remember reading the OpenJDK will be patched up to 2023 (while Oracle JDK will be patched up to 2026). We deliver software that our customers could be running for a decade or more. The LTS is the version we will then target when we move away from Java 8. /Sverre Den tor. 27. sep. 2018 kl. 18:18 skrev Kevin Rushforth < kevin.rushforth at oracle.com>: > I missed seeing the swing exception in your earlier message. Yes, the > Swing issue is a known problem in openjfx11, JDK-8210759 [1], and is > documented in the release notes [2]. > > It will be fixed in openjfx12 just as soon as I push the fix for > JDK-8210092 [3] later today (the review was just finished earlier this > morning). This was one of the bugs waiting until the fix requiring JDK 11 > for openjfx 12 was pushed. > > As for your other question, yes, if you add the javafx.* modules to your > Java runtime image, then that runtime image contains the javafx.* modules. > If your application were modularized, then the Java runtime image would > contain your application, too. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8210759 > [2] > https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#known-issues > [3] https://bugs.openjdk.java.net/browse/JDK-8210092 > > > On 9/27/2018 9:03 AM, Sverre Moe wrote: > > Without the reliance on javafx-swing I was able to create an image, > package and execute my test application. > Is the Swing problem a known bug in JavaFX 11? > > The jlink runtime image I reckon now also contains the JavaFX modules? > Seems unnecessary when they already are dependencies. > > /Sverre > > Den tor. 27. sep. 2018 kl. 10:42 skrev Sverre Moe : > >> Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth < >> kevin.rushforth at oracle.com>: >> >>> No, jlink won't link in a non-modular application. So the steps are: >>> >>> 1) Run jlink to create a Java runtime image, possibly stripped down, and >>> include the javafx.* modules you need >>> 2) Run jpackager to package your non-modular application with the above >>> Java runtime image. >>> >>> -- Kevin >>> >> >> So we have to create the image with the jlink first before we use >> jpackager, and we have to link in with the javafx modules. We cannot use >> the javafx dependencies in the project? >> >> jlink --add-modules=ALL-SYSTEM --output image >> Error: Module ALL-SYSTEM not found >> >> The just to make sure we have everything we need I add the actual modules >> jlink --add-modules=java.base --add-modules=java.desktop >> --add-modules=java.net.http --add-modules=java.xml >> --add-modules=java.prefs --add-modules=java.logging --output image >> >> Linking in with the JavaFX jmods from Gluon: >> jlink --add-modules=java.base --add-modules=java.desktop >> --add-modules=java.net.http --add-modules=java.xml >> --add-modules=java.prefs --add-modules=java.logging --module-path >> /usr/java/javafx-jmods-11/ --add-modules=javafx.base >> --add-modules=javafx.controls --add-modules=javafx.fxml >> --add-modules=javafx.graphics --add-modules=javafx.web >> --add-modules=javafx.media --add-modules=javafx.swing --output image >> >> I managed to build our Java 8 project with Java 11, using the JavaFX >> dependencies. >> Then using jpackager with the runtime image from jlink >> /usr/java/jpackager/jpackager create-installer --input >> build/distributions/application-1.0.0-SNAPSHOT/lib/ --output outputDir >> --runtime-image image/ --verbose --echo-mode --main-jar >> application-1.0.0-SNAPSHOT.jar >> >> Running the application image from jpackager >> First try: >> I thought I had added all necessary modules to the runtime image, but I >> needed one more, java.management. >> >> Second try: >> InteropFactory: cannot load >> com.sun.javafx.embed.swing.newimpl.InteropFactoryN >> Exception in thread "GUIBuilderWorker" java.lang.IllegalAccessError: >> class com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module >> javafx.swing) cannot access class sun.swing.JLightweightFrame (in module >> java.desktop) because module java.desktop does not export sun.swing to >> module javafx.swing >> at >> javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.(SwingNodeInteropO.java:71) >> at >> javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42) >> at >> javafx.swing/javafx.embed.swing.SwingNode.(SwingNode.java:271) >> at no.company.application.fx.MySwingComponent.initNode( >> MySwingComponent.java:155) >> >> The module java.desktop should include the AWT/Swing. >> >> At least I now have been able to create an native application using both >> jlink and the new jpackager. >> >> /Sverre >> > > From kevin.rushforth at oracle.com Thu Sep 27 16:50:28 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 27 Sep 2018 09:50:28 -0700 Subject: Filling the Packager gap In-Reply-To: References: <21473946-e701-9a78-520f-5faedfacaee2@oracle.com> <8D57F8CD-AD30-4E6F-81EC-9FACF919EAC8@gmail.com> <032f8884-ff36-fa13-37c3-d1187b49ce45@oracle.com> <8a9652a2-0bf5-51b4-66f0-2a20a691963e@oracle.com> Message-ID: <324d513f-b60f-e12f-6243-c75466872630@oracle.com> You mean openjfx11, not JDK 11, right? Backporting this fix would mean an openjfx 11.x update release would stop building or running with JDK 10. Not something that would be done lightly, since it would break the "FX N runs with JDK N-1" policy we have been discussing lately. There is an easy workaround for that bug that needs to be done when running "jlink" to create your image. It's documented in the release notes. -- Kevin On 9/27/2018 9:27 AM, Sverre Moe wrote: > Any chance of getting the fix for JDK-8210759 backported to JDK 11? I > remember reading the OpenJDK will be patched up to 2023 (while Oracle > JDK will be patched up to 2026). > We deliver software that our customers could be running for a decade > or more. The LTS is the version we will then target when we move away > from Java 8. > > /Sverre > > Den tor. 27. sep. 2018 kl. 18:18 skrev Kevin Rushforth > >: > > I missed seeing the swing exception in your earlier message. Yes, > the Swing issue is a known problem in openjfx11, JDK-8210759 [1], > and is documented in the release notes [2]. > > It will be fixed in openjfx12 just as soon as I push the fix for > JDK-8210092 [3] later today (the review was just finished earlier > this morning). This was one of the bugs waiting until the fix > requiring JDK 11 for openjfx 12 was pushed. > > As for your other question, yes, if you add the javafx.* modules > to your Java runtime image, then that runtime image contains the > javafx.* modules. If your application were modularized, then the > Java runtime image would contain your application, too. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8210759 > [2] > https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#known-issues > [3] https://bugs.openjdk.java.net/browse/JDK-8210092 > > > On 9/27/2018 9:03 AM, Sverre Moe wrote: >> Without the reliance on javafx-swing I was able to create an >> image, package and execute my test application. >> Is the Swing problem a known bug in JavaFX 11? >> >> The jlink runtime image I reckon now also contains the JavaFX >> modules? Seems unnecessary when they already are dependencies. >> >> /Sverre >> >> Den tor. 27. sep. 2018 kl. 10:42 skrev Sverre Moe >> >: >> >> Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth >> >: >> >> No, jlink won't link in a non-modular application. So the >> steps are: >> >> 1) Run jlink to create a Java runtime image, possibly >> stripped down, and >> include the javafx.* modules you need >> 2) Run jpackager to package your non-modular application >> with the above >> Java runtime image. >> >> -- Kevin >> >> >> So we have to create the image with the jlink first before we >> use jpackager, and we have to link in with the javafx >> modules. We cannot use the javafx dependencies in the project? >> >> jlink --add-modules=ALL-SYSTEM --output image >> Error: Module ALL-SYSTEM not found >> >> The just to make sure we have everything we need I add the >> actual modules >> jlink --add-modules=java.base --add-modules=java.desktop >> --add-modules=java.net.http --add-modules=java.xml >> --add-modules=java.prefs --add-modules=java.logging --output >> image >> >> Linking in with the JavaFX jmods from Gluon: >> jlink --add-modules=java.base --add-modules=java.desktop >> --add-modules=java.net.http --add-modules=java.xml >> --add-modules=java.prefs --add-modules=java.logging >> --module-path /usr/java/javafx-jmods-11/ >> --add-modules=javafx.base --add-modules=javafx.controls >> --add-modules=javafx.fxml --add-modules=javafx.graphics >> --add-modules=javafx.web --add-modules=javafx.media >> --add-modules=javafx.swing --output image >> >> I managed to build our Java 8 project with Java 11, using the >> JavaFX dependencies. >> Then using jpackager with the runtime image from jlink >> /usr/java/jpackager/jpackager create-installer --input >> build/distributions/application-1.0.0-SNAPSHOT/lib/ --output >> outputDir --runtime-image image/ --verbose --echo-mode >> --main-jar application-1.0.0-SNAPSHOT.jar >> >> Running the application image from jpackager >> First try: >> I thought I had added all necessary modules to the runtime >> image, but I needed one more, java.management. >> >> Second try: >> InteropFactory: cannot load >> com.sun.javafx.embed.swing.newimpl.InteropFactoryN >> Exception in thread "GUIBuilderWorker" >> java.lang.IllegalAccessError: class >> com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in >> module javafx.swing) cannot access class >> sun.swing.JLightweightFrame (in module java.desktop) because >> module java.desktop does not export sun.swing to module >> javafx.swing >> ???????at >> javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.(SwingNodeInteropO.java:71) >> ???????at >> javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42) >> ???????at >> javafx.swing/javafx.embed.swing.SwingNode.(SwingNode.java:271) >> ???????at >> no.company.application.fx.MySwingComponent.initNode(MySwingComponent.java:155) >> >> The module java.desktop should include the AWT/Swing. >> >> At least I now have been able to create an native application >> using both jlink and the new jpackager. >> >> /Sverre >> > From sverre.moe at gmail.com Thu Sep 27 17:05:48 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 27 Sep 2018 19:05:48 +0200 Subject: Filling the Packager gap In-Reply-To: <324d513f-b60f-e12f-6243-c75466872630@oracle.com> References: <21473946-e701-9a78-520f-5faedfacaee2@oracle.com> <8D57F8CD-AD30-4E6F-81EC-9FACF919EAC8@gmail.com> <032f8884-ff36-fa13-37c3-d1187b49ce45@oracle.com> <8a9652a2-0bf5-51b4-66f0-2a20a691963e@oracle.com> <324d513f-b60f-e12f-6243-c75466872630@oracle.com> Message-ID: Den tor. 27. sep. 2018 kl. 18:50 skrev Kevin Rushforth < kevin.rushforth at oracle.com>: > You mean openjfx11, not JDK 11, right? Backporting this fix would mean an > openjfx 11.x update release would stop building or running with JDK 10. Not > something that would be done lightly, since it would break the "FX N runs > with JDK N-1" policy we have been discussing lately. There is an easy > workaround for that bug that needs to be done when running "jlink" to > create your image. It's documented in the release notes. > > -- Kevin > Yes, I meant OpenJFX 11. I will take a look at the release notes to find the workaround. /Sverre From sverre.moe at gmail.com Thu Sep 27 17:16:59 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 27 Sep 2018 19:16:59 +0200 Subject: Later OpenJFX Compatibilty with JDK 11 LTS Message-ID: On tor. 27. sep. 2018 kl. 18:18 wrote Kevin Rushforth < kevin.rushforth at oracle.com>: > > I missed seeing the swing exception in your earlier message. Yes, the Swing issue is a known problem in openjfx11, JDK-8210759 [1], and is documented in the release notes [2]. > > It will be fixed in openjfx12 just as soon as I push the fix for JDK-8210092 [3] later today (the review was just finished earlier this morning). This was one of the bugs waiting until the fix requiring JDK 11 for openjfx 12 was pushed. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8210759 > [2] https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#known-issues > [3] https://bugs.openjdk.java.net/browse/JDK-8210092 > On tor. 27. sep. 2018 kl. 18:50 wrote Kevin Rushforth < kevin.rushforth at oracle.com>: > > Backporting this fix would mean an openjfx 11.x update release would stop building or running with JDK 10. Not something that would be done lightly, since it would break the "FX N runs with JDK N-1" policy we have been discussing lately. There is an easy workaround for that bug that needs to be done when running "jlink" to create your image. It's documented in the release notes. > > -- Kevin How can we continue to upgrade to newer OpenJFX as time goes by. Will the later OpenJFX 13+ work with JDK 11 or is it just "FX N run JDK N-1" (one version backward support)? We would probably target the Java 11 because it is LTS. Changes to JDK will be backported up to september 2023 by the community. If we are interested in getting updates on OpenJFX also we would then need to always upgrade it. I reckon there will not be a OpenJFX 11 LTS. /Sverre From johan.vos at gluonhq.com Thu Sep 27 18:06:27 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 27 Sep 2018 20:06:27 +0200 Subject: Later OpenJFX Compatibilty with JDK 11 LTS In-Reply-To: References: Message-ID: > > How can we continue to upgrade to newer OpenJFX as time goes by. Will the > later OpenJFX 13+ work with JDK 11 or is it just "FX N run JDK N-1" (one > version backward support)? > There is a separate thread about this: http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022527.html It seems we are moving to a consensus where we use existing JDK versions as long as there are no new API's/VM changes that really benefit JavaFX, however the "guaranteed" required version for JavaFX N would be Java N or Java N-1. > We would probably target the Java 11 because it is LTS. Changes to JDK will > be backported up to september 2023 by the community. If we are interested > in getting updates on OpenJFX also we would then need to always upgrade it. > I reckon there will not be a OpenJFX 11 LTS. > Actually, there is. See https://gluonhq.com/javafx-11-release-and-support-plans/ for commercial support for JavaFX 11 LTS. Basically, you have 3 options: 1. Move along with the latest and greatest JavaFX releases (free) 2. Stick with a given release (free, unsupported) 3. Stick with an LTS release and get commercial support to get updates - Johan From kevin.rushforth at oracle.com Thu Sep 27 18:06:45 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 27 Sep 2018 11:06:45 -0700 Subject: Later OpenJFX Compatibilty with JDK 11 LTS In-Reply-To: References: Message-ID: This was discussed on the list earlier this week, and the current proposal is to support OpenJFX N on JDK N-1 or later [1]. As part of a follow-on discussion, it was suggested that we might avoid eagerly breaking JDK N-2 unless/until there is something we need from JDK N-1 that makes breaking it necessary. Requiring later versions of FX to run on JDK 11 LTS would mean, for example, that OpenJFX 14 wouldn't be able to use language features from JDK 12 or JDK 13, which seems a bit restrictive. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022538.html On 9/27/2018 10:16 AM, Sverre Moe wrote: > How can we continue to upgrade to newer OpenJFX as time goes by. Will the > later OpenJFX 13+ work with JDK 11 or is it just "FX N run JDK N-1" (one > version backward support)? > > We would probably target the Java 11 because it is LTS. Changes to JDK will > be backported up to september 2023 by the community. If we are interested > in getting updates on OpenJFX also we would then need to always upgrade it. > I reckon there will not be a OpenJFX 11 LTS. > > /Sverre From sverre.moe at gmail.com Thu Sep 27 18:35:50 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 27 Sep 2018 20:35:50 +0200 Subject: Later OpenJFX Compatibilty with JDK 11 LTS In-Reply-To: References: Message-ID: Den tor. 27. sep. 2018 kl. 20:06 skrev Johan Vos : > We would probably target the Java 11 because it is LTS. Changes to JDK will >> be backported up to september 2023 by the community. If we are interested >> in getting updates on OpenJFX also we would then need to always upgrade >> it. >> I reckon there will not be a OpenJFX 11 LTS. >> > > Actually, there is. See > https://gluonhq.com/javafx-11-release-and-support-plans/ for commercial > support for JavaFX 11 LTS. > > Basically, you have 3 options: > 1. Move along with the latest and greatest JavaFX releases (free) > 2. Stick with a given release (free, unsupported) > 3. Stick with an LTS release and get commercial support to get updates > > - Johan > Thanks. Option 3 looks very interesting. It would allow us to deliver a stable application on the current LTS while the same time get updates on JavaFX. I have not seen Oracle offering an JavaFX 11 LTS, just the JDK 11 LTS. Is Gluon the only one with a JavaFX 11 LTS? /Sverre From j.tosovsky at email.cz Thu Sep 27 20:38:10 2018 From: j.tosovsky at email.cz (Jan Tosovsky) Date: Thu, 27 Sep 2018 22:38:10 +0200 Subject: Later OpenJFX Compatibilty with JDK 11 LTS In-Reply-To: References: Message-ID: <00a101d456a2$0271f360$0755da20$@email.cz> On 2018-09-27 Sverre Moe wrote: > Den tor. 27. sep. 2018 kl. 20:06 skrev Johan Vos : > > > > We would probably target the Java 11 because it is LTS. Changes to JDK > > > will be backported up to september 2023 by the community. If we are > > > interested in getting updates on OpenJFX also we would then need to > > > always upgrade it. > > > I reckon there will not be a OpenJFX 11 LTS. > > > > Actually, there is. See > > https://gluonhq.com/javafx-11-release-and-support-plans/ for commercial > > support for JavaFX 11 LTS. > > > > Basically, you have 3 options: > > 1. Move along with the latest and greatest JavaFX releases (free) > > 2. Stick with a given release (free, unsupported) > > 3. Stick with an LTS release and get commercial support to get updates > > > Thanks. Option 3 looks very interesting. It would allow us to deliver a > stable application on the current LTS while the same time get updates on > JavaFX. If I understand correctly, there will be 4th option in near future: 4. Bundle module based app with JDK modules you need >From that moment you are becoming independent on any future FX and JDK releases. Especially handy if your app doesn't evolve much and it is distributed in controlled environment (several users within company). Unless your app becomes famous, I don't think it will attract attackers to employ any vulnerabilities found in those older versions as time goes. Jan From sverre.moe at gmail.com Thu Sep 27 22:26:29 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Fri, 28 Sep 2018 00:26:29 +0200 Subject: Later OpenJFX Compatibilty with JDK 11 LTS In-Reply-To: <00a101d456a2$0271f360$0755da20$@email.cz> References: <00a101d456a2$0271f360$0755da20$@email.cz> Message-ID: Den tor. 27. sep. 2018 kl. 22:38 skrev Jan Tosovsky : > On 2018-09-27 Sverre Moe wrote: > > Den tor. 27. sep. 2018 kl. 20:06 skrev Johan Vos >: > > > > > 3. Stick with an LTS release and get commercial support to get updates > > > > > Thanks. Option 3 looks very interesting. It would allow us to deliver a > > stable application on the current LTS while the same time get updates on > > JavaFX. > > If I understand correctly, there will be 4th option in near future: > 4. Bundle module based app with JDK modules you need > > From that moment you are becoming independent on any future FX and JDK > releases. Especially handy if your app doesn't evolve much and it is > distributed in controlled environment (several users within company). > Unless your app becomes famous, I don't think it will attract attackers to > employ any vulnerabilities found in those older versions as time goes. > > Jan > > Being a SCADA application, keeping it stable and secure is very important, even though our application is not famous or known beyond the industry we deliver it to. /Sverre From youngty1997 at gmail.com Fri Sep 28 07:53:55 2018 From: youngty1997 at gmail.com (Ty Young) Date: Fri, 28 Sep 2018 02:53:55 -0500 Subject: Filling the Packager gap In-Reply-To: References: <0e66d63a-f87d-396c-1b48-123a707c92ca@gmail.com> Message-ID: <34c29678-24a0-c94f-5321-b4dfa6d96c33@gmail.com> On 9/27/18 1:44 AM, Johan Vos wrote: > Hi Ty, > > Apart om jdk.jlink, who else is > exporting?jdk.tools.jlink.internal.packager ? > If that is the case, there must be something wrong. > The 12-sandbox version also exports that package: > http://hg.openjdk.java.net/jdk/sandbox/file/6972c0e75e23/src/jdk.jlink/share/classes/module-info.java > > - Johan JavaFX itself is: rt/apps/performance/JavaFX/src/jdk.jlink/classes(It's just an app) module-info.java.extra from /rt/dependencies/jdk.jlink module-info.java.extra from /rt/build/modular-sdk/modules_src/jdk.jlink I don't know what the .extra is all about. I found those by searching for all the module-info files from in JavaFX and seeing if there was any matches to jdk.tools.jlink.internal.packager. > > On Thu, Sep 27, 2018 at 4:14 AM Ty Young > wrote: > > > On 9/19/18 3:55 AM, Johan Vos wrote: > > Hi, > > > > As promised, we looked into an interim solution for the > packager-gap. Work > > for the new Java Packager (12?) is being done in the OpenJDK > sandbox repo. > > We backported the required changes to an OpenJDK 11 mirror: > > https://github.com/johanvos/openjdk-mobile11/tree/packager > > > > With this, we created modified OpenJDK 11 builds that contain > the packager > > (wrapper/exe + module including native library). They can be > downloaded and > > tested/used at > > > > http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip > > http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip > > http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip > > > > For Windows, you have to unzip the bundle in the same directory > as the JDK, > > as the packager wrapper expect to find the java binary at the > same level. > > > > Note that these are not products. We use them internally to create > > installers (e.g. we're using them for Scene Builder 11 and that > works > > fine), and they do what we expect them to do, but there are no > guarantees > > of course so at least for now I recommend using them in > development only > > (or even better, look at the changes and contribute to > > https://bugs.openjdk.java.net/browse/JDK-8200758 or to this > backport) > > > > - Johan > > > The JDK source fails to compile due to a duplicate qualified export. > Removing the export from > openjdk-mobile11-packager/src/jdk.jlink/share/classes/module-info.java > > fixes it. > > > By the way, how does one use this with jLink generated by Netbeans? I > used the jLink build as the input and it just dumped it into the > "app" > folder when making the image which doesn't work. > > > From john at status6.com Sun Sep 30 19:03:00 2018 From: john at status6.com (John Neffenger) Date: Sun, 30 Sep 2018 12:03:00 -0700 Subject: Setting the FreeType LCD filter Message-ID: <24d59238-b959-2b5e-5772-618cda2519c4@status6.com> I think I found the cause of the text rendering problem I have always seen in JavaFX applications on Linux: Reduce color fringes in FreeType subpixel rendering https://github.com/javafxports/openjdk-jfx/issues/229 I'm finally seeing the fonts as they were intended! I used the Oracle bug report outline as a template for the GitHub issue to make it easy to copy to the Java Bug Database. Do I need a Java Bug ID before I submit a pull request? Thanks, John P.S.: For background information, there is a great demonstration of LCD filtering algorithms by Felipe Heidrich at 1:02:47 into the video "JavaFX Text Rendering" . The link takes you directly to the two-minute segment showing the text rendered by FreeType, first with no filter, and then with its various filter options. (Note: the audio is a bit loud.) From philip.race at oracle.com Sun Sep 30 21:03:58 2018 From: philip.race at oracle.com (Philip Race) Date: Sun, 30 Sep 2018 14:03:58 -0700 Subject: Setting the FreeType LCD filter In-Reply-To: <24d59238-b959-2b5e-5772-618cda2519c4@status6.com> References: <24d59238-b959-2b5e-5772-618cda2519c4@status6.com> Message-ID: <5BB13A3E.1000909@oracle.com> Hi, Your explanation makes sense. Compile time linking is probably best so long as we can verify that the function is available on all the platforms we need to build & run on .. notably older versions of OEL&RHEL. Failing that, then as well as adding ".6" we should initialise jint rc =-1; instead of to zero .. so that failure to find the function isn't confused as failure *of* the function, which in a nutshell, seems to be the bug here. And I suppose we have the same bug on "older" systems where the freetype library is found but lack the symbol. Is there no JBS bug id already open on this ? If one was closed as not reproducible, we can re-open it. Better than creating a new one. -phil. On 9/30/18, 12:03 PM, John Neffenger wrote: > I think I found the cause of the text rendering problem I have always > seen in JavaFX applications on Linux: > > Reduce color fringes in FreeType subpixel rendering > https://github.com/javafxports/openjdk-jfx/issues/229 > > I'm finally seeing the fonts as they were intended! I used the Oracle > bug report outline as a template for the GitHub issue to make it easy > to copy to the Java Bug Database. Do I need a Java Bug ID before I > submit a pull request? > > Thanks, > John > > P.S.: For background information, there is a great demonstration of > LCD filtering algorithms by Felipe Heidrich at 1:02:47 into the video > "JavaFX Text Rendering" . The > link takes you directly to the two-minute segment showing the text > rendered by FreeType, first with no filter, and then with its various > filter options. (Note: the audio is a bit loud.) From swpalmer at gmail.com Sun Sep 30 21:19:18 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 30 Sep 2018 17:19:18 -0400 Subject: State of maven artifacts In-Reply-To: References: Message-ID: <0ED45382-7510-4276-AF12-90F058C98ECD@gmail.com> I thought he was saying the exact opposite. You must specify the platform by using some mechanism in Maven (profiles?) or Gradle. That?s what worked for me anyway. Scott > On Sep 26, 2018, at 6:19 AM, Michael Ennen wrote: > > And just to reiterate and confirm for anyone trying to get a handle on using > the Maven artifacts - it is *NOT* necessary to manually specify the platform > classifier when using maven or gradle (nor add the automatic tricks to your > own project) because the JavaFX artifacts will automatically detect the > platform you are building on and pull in the correct artifacts, right? > > Thanks for your work in this area Johan. > > On Wed, Sep 26, 2018 at 12:31 AM Johan Vos wrote: > >> The problem with that is that there is no cross-platform version of the >> jars itself. The windows-jar for the graphics module contains different >> Java classes than the linux jar, for example. >> The top-level API's are the same of course, hence the logical Java module >> is the same, but different physical jars are really needed. >> I realise this may be strange at compile time, where you only care about >> the top-level API's. Therefore, people added nice "tricks" to both a >> pom.xml and build.gradle system to automatically detect the current (host) >> operating system, and making sure the correct artifacts are then used. >> >> What I really wanted to avoid is that developers had to manually add their >> platform (e.g. "win") in the build files, as this would break >> cross-platform development (imagine you're in a team with a win and a linux >> user, and they constantly change the pom.xml or build.gradle file for >> this...). >> >> I think the current solution deals pretty well with the current situations, >> where there are different concepts in gradle/maven/sonatype and in the Java >> module system. >> >> - Johan >> >> >> >> Op wo 26 sep. 2018 om 05:46 schreef Nir Lisker : >> >>> Thanks Sam, that solved it. For some reason I was thinking that if you >>> don't specify the platform it downloads a version with all native >>> dependencies for cross compilation. >>> >>> On Wed, Sep 26, 2018 at 2:37 AM Sam Carlberg >>> wrote: >>> >>>> The libraries are in artifacts with platform-specific classifiers. The >>>> artifacts with no classifiers that you currently depend on are >> completely >>>> empty. >>>> >>>> You need to depend on "org.openjfx:javafx-base:11:$platform", where the >>>> platform is one of "win", "mac", or "linux". >>>> >>>> On Tue, Sep 25, 2018, 5:18 PM Nir Lisker wrote: >>>> >>>>> Hi, >>>>> >>>>> I haven't kept up with all of the Maven artifacts discussion. The >>> website >>>>> mentioned in 2 places that there are maven artifacts, but does not >>> mention >>>>> their ID's, group etc. These are the downloads page [1] and the >> getting >>>>> started page [2] (later you can see an example pom, but that doesn't >>>>> count). >>>>> >>>>> I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it >> finds >>>>> the artifacts. It should be written in the above pages if this is >>> correct. >>>>> >>>>> On the usability side it's worse. I'm using Eclipse and during >>> compilation >>>>> I'm getting error messages that JavaFX classes like BooleanProperty >>> can't >>>>> be found. Is it a JavaFX problem, Eclipse problem, or me problem? >>>>> >>>>> If I use the SDKs, can I point Gradle and Maven to them if it will >> solve >>>>> the problem? >>>>> >>>>> - Nir >>>>> >>>>> [1] https://gluonhq.com/products/javafx/ >>>>> [2] https://openjfx.io/openjfx-docs/#introduction >>>>> >>>> >>> >> > > > -- > Michael Ennen From mike.ennen at gmail.com Sun Sep 30 23:01:01 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Sun, 30 Sep 2018 16:01:01 -0700 Subject: State of maven artifacts In-Reply-To: <0ED45382-7510-4276-AF12-90F058C98ECD@gmail.com> References: <0ED45382-7510-4276-AF12-90F058C98ECD@gmail.com> Message-ID: Scott, It seems that, for me at least, specifying the platform manually is not necessary on Maven but is necessary on Gradle. Looking at the POMs themselves it seems that the javafx-graphics, javafx-controls, etc. modules declare a dependency on the platform specific artifacts: org.openjfx javafx-base 11 ${javafx.platform} and declare as their parent: org.openjfx javafx 11 and the POM for that parent has the platform-specific Maven profiles built-in. So in other words the logic is already built in to the Maven POM and therefore works out of the box with Maven but Gradle does not re-use the Maven profile logic in the POM. Regards, Michael Ennen On Sun, Sep 30, 2018 at 2:19 PM Scott Palmer wrote: > I thought he was saying the exact opposite. > You must specify the platform by using some mechanism in Maven (profiles?) > or Gradle. > > That?s what worked for me anyway. > > Scott > > > On Sep 26, 2018, at 6:19 AM, Michael Ennen wrote: > > > > And just to reiterate and confirm for anyone trying to get a handle on > using > > the Maven artifacts - it is *NOT* necessary to manually specify the > platform > > classifier when using maven or gradle (nor add the automatic tricks to > your > > own project) because the JavaFX artifacts will automatically detect the > > platform you are building on and pull in the correct artifacts, right? > > > > Thanks for your work in this area Johan. > > > > On Wed, Sep 26, 2018 at 12:31 AM Johan Vos wrote: > > > >> The problem with that is that there is no cross-platform version of the > >> jars itself. The windows-jar for the graphics module contains different > >> Java classes than the linux jar, for example. > >> The top-level API's are the same of course, hence the logical Java > module > >> is the same, but different physical jars are really needed. > >> I realise this may be strange at compile time, where you only care about > >> the top-level API's. Therefore, people added nice "tricks" to both a > >> pom.xml and build.gradle system to automatically detect the current > (host) > >> operating system, and making sure the correct artifacts are then used. > >> > >> What I really wanted to avoid is that developers had to manually add > their > >> platform (e.g. "win") in the build files, as this would break > >> cross-platform development (imagine you're in a team with a win and a > linux > >> user, and they constantly change the pom.xml or build.gradle file for > >> this...). > >> > >> I think the current solution deals pretty well with the current > situations, > >> where there are different concepts in gradle/maven/sonatype and in the > Java > >> module system. > >> > >> - Johan > >> > >> > >> > >> Op wo 26 sep. 2018 om 05:46 schreef Nir Lisker : > >> > >>> Thanks Sam, that solved it. For some reason I was thinking that if you > >>> don't specify the platform it downloads a version with all native > >>> dependencies for cross compilation. > >>> > >>> On Wed, Sep 26, 2018 at 2:37 AM Sam Carlberg > >>> wrote: > >>> > >>>> The libraries are in artifacts with platform-specific classifiers. The > >>>> artifacts with no classifiers that you currently depend on are > >> completely > >>>> empty. > >>>> > >>>> You need to depend on "org.openjfx:javafx-base:11:$platform", where > the > >>>> platform is one of "win", "mac", or "linux". > >>>> > >>>> On Tue, Sep 25, 2018, 5:18 PM Nir Lisker wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> I haven't kept up with all of the Maven artifacts discussion. The > >>> website > >>>>> mentioned in 2 places that there are maven artifacts, but does not > >>> mention > >>>>> their ID's, group etc. These are the downloads page [1] and the > >> getting > >>>>> started page [2] (later you can see an example pom, but that doesn't > >>>>> count). > >>>>> > >>>>> I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it > >> finds > >>>>> the artifacts. It should be written in the above pages if this is > >>> correct. > >>>>> > >>>>> On the usability side it's worse. I'm using Eclipse and during > >>> compilation > >>>>> I'm getting error messages that JavaFX classes like BooleanProperty > >>> can't > >>>>> be found. Is it a JavaFX problem, Eclipse problem, or me problem? > >>>>> > >>>>> If I use the SDKs, can I point Gradle and Maven to them if it will > >> solve > >>>>> the problem? > >>>>> > >>>>> - Nir > >>>>> > >>>>> [1] https://gluonhq.com/products/javafx/ > >>>>> [2] https://openjfx.io/openjfx-docs/#introduction > >>>>> > >>>> > >>> > >> > > > > > > -- > > Michael Ennen > >