Re: Remove JavaFX JPMS enforcement

[Abhinay Agarwal]

Hi Ty Young,

I am trying to identify which part of the documentation changed after JavaFX 
13. The JVM arguments that you have specified are required since JavaFX 11. 
Alternatively, user doesn't need to pass these arguments if they are using 
javafx-maven-plugin to build and run the application.

I might be missing something here. Can you be kind enough to point me to the 
specific issue and the related section in docs so that it can be fixed?

Thanks in advance.

-- Abhinay

From: openjfx-dev  on behalf of Ty Young 

Sent: Monday, April 20, 2020 10:07 PM
To: openjfx-dev@openjdk.java.net 
Subject: Re: Remove JavaFX JPMS enforcement


On 4/20/20 11:36 AM, Ty Young wrote:
>
> On 4/20/20 10:47 AM, Mark Raynsford wrote:
>> Am I missing something here? What absurd arguments are required for
>> Maven projects?
>>
>> I have multiple applications here running in full module-path mode (the
>> applications are modularized, and JavaFX is on the module path), using
>> plain Maven builds with no special arguments, and IDEA as the IDE.
>> This is on JDK 13, with the 13.0.2 JavaFX release from Central.
>>
>
> From the second warning on this page:
>
>
> https://openjfx.io/openjfx-docs/
>
>
> That's the absurd part. JavaFX 14 now requires this as a JVM runtime
> argument:
>
>
> --module-path /path/to/javafx-sdk-12/lib --add-modules
> javafx.controls,javafx.fxml
>
>
> Which wasn't required before. Not only is this a PITA and confusing
> but it also prevents Maven from just handling everything. Netbeans
> uses a custom file for runtime arguments, which the above is added to.
>

Also, it gives JavaFX 12 as an example, which is wrong. It should be 14.

Re: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi

[Alexander Scherbatiy]

On Fri, 24 Apr 2020 01:27:42 GMT, John Neffenger 
 wrote:

>> Wow, this is going to take some getting used to. 😃 Below is a photograph of 
>> the button and text with two changes:
>> 
>> 1. the code from this pull request, and
>> 2. the `javafx.platform.properties` file moved to its parent directory.
>> 
>> ![withfix](https://user-images.githubusercontent.com/1413266/80160191-d344d380-8581-11ea-8fd4-09023ad30610.jpg)
>> 
>> The native screen on this platform returns 167 for its DPI. In general, the 
>> devices I'm testing have pixel densities of
>> either 167 or 300 pixels per inch.
>
> I got out my trusty C-Thru Ruler (GA-96), and the type now measures 12 
> points, just as intended.
> 
> **PrismFontFactory.getSystemFontSize**
>   } else if (isEmbedded) {
>   try {
>   int screenDPI = Screen.getMainScreen().getResolutionY();
>   systemFontSize = ((float) screenDPI) / 6f; // 12 points
>   } catch (NullPointerException npe) {
>   // if no screen is defined
>   systemFontSize = 13f; // same as desktop Linux
>   }
>   } else {
>   systemFontSize = 13f; // Gnome uses 13.
>   }
> 
> Without the platform properties file, I've been running (for years!) with a 
> default font size of 13 pixels, which on
> this device is very small: (13 px ÷ 167 px/in) × 72 points/in = 5.60 points.
> Now JavaFX is setting `isEmbedded` to `true`, picking up the correct screen 
> DPI, and I'm finally getting a good default
> font size: ((167 px/in ÷ 6 per in) ÷ 167 px/in) × 72 points/in = 12.0 points. 
> Amazing.

> @AlexanderScherbatiy Did you move the _javafx.platform.properties_ file to 
> its parent directory manually, as I just did?

I used the full version of jdk 14.0.1 on Raspberry Pi where JavaFX is included 
in jdk so the file
_javafx.platform.properties_ is already in jdk-14.0.1-full/lib directory.

To debug the JavaFX on Raspberry Pi I built  armv6hf-sdk and just copied the 
file  _javafx.platform.properties_ from
the full jdk version with JavaFX to jdk-14.0.1/lib directory of jdk without 
JavaFX which I used to run my java
application with JavaFX modules from armv6hf-sdk/lib.

-

PR: https://git.openjdk.java.net/jfx/pull/193

Re: Remove JavaFX JPMS enforcement

[Ty Young]

On 4/24/20 2:14 AM, Abhinay Agarwal wrote:

Hi Ty Young,

I am trying to identify which part of the documentation changed after 
JavaFX 13. The JVM arguments that you have specified are required 
since JavaFX 11. Alternatively, user doesn't need to pass these 
arguments if they are using javafx-maven-plugin to build and run the 
application.


I might be missing something here. Can you be kind enough to point me 
to the specific issue and the related section in docs so that it can 
be fixed?



Right, so I think I got the issue sorted out.



TL;DR, you HAVE to use the archtype. Netbeans WILL NOT adjust its own 
runtime "nbactions.xml" file if you decided to create a barebones 
project and add JavaFX later, which is why runtime components are 
missing and following the advice for Ant will fix the issue.



In Netbeans 12.3 Beta(what I'm using now) everything works.



In other words, as of Netbeans 12-3, **don't do this**:



New Project -> Java with Maven -> Java Application -> add JavaFX from 
maven central




do this:



New Project -> Java with Maven -> Simple JavaFX Application Archtype(Gluon)



They changed the UI in Netbeans 12-3 beta, so the documentation will 
need to be updated for it.






Thanks in advance.

-- Abhinay

*From:* openjfx-dev  on behalf 
of Ty Young 

*Sent:* Monday, April 20, 2020 10:07 PM
*To:* openjfx-dev@openjdk.java.net 
*Subject:* Re: Remove JavaFX JPMS enforcement

On 4/20/20 11:36 AM, Ty Young wrote:
>
> On 4/20/20 10:47 AM, Mark Raynsford wrote:
>> Am I missing something here? What absurd arguments are required for
>> Maven projects?
>>
>> I have multiple applications here running in full module-path mode (the
>> applications are modularized, and JavaFX is on the module path), using
>> plain Maven builds with no special arguments, and IDEA as the IDE.
>> This is on JDK 13, with the 13.0.2 JavaFX release from Central.
>>
>
> From the second warning on this page:
>
>
> https://openjfx.io/openjfx-docs/
>
>
> That's the absurd part. JavaFX 14 now requires this as a JVM runtime
> argument:
>
>
> --module-path /path/to/javafx-sdk-12/lib --add-modules
> javafx.controls,javafx.fxml
>
>
> Which wasn't required before. Not only is this a PITA and confusing
> but it also prevents Maven from just handling everything. Netbeans
> uses a custom file for runtime arguments, which the above is added to.
>

Also, it gives JavaFX 12 as an example, which is wrong. It should be 14.

Re: Remove JavaFX JPMS enforcement

[Abhinay Agarwal]

Hi Ty Young,

Thank you for reverting back.

Basic documentation has not changed since JavaFX 11.

Since it is difficult to keep up with the ever changing IDEs, we added a 
disclaimer on the top of each IDE section denoting the JavaFX and IDE version 
used for the tutorial.

And as always, in case you feel something can be improved, feel free to raise a 
PR [1].

-- Abhinay

[1] https://github.com/openjfx/openjfx-docs/
[https://avatars1.githubusercontent.com/u/43116912?s=400&v=4]
GitHub - openjfx/openjfx-docs: Getting started guide for JavaFX 
11
Getting started guide for JavaFX 11. Contribute to openjfx/openjfx-docs 
development by creating an account on GitHub.
github.com


From: openjfx-dev  on behalf of Ty Young 

Sent: Friday, April 24, 2020 5:50 PM
To: openjfx-dev@openjdk.java.net 
Subject: Re: Remove JavaFX JPMS enforcement


On 4/24/20 2:14 AM, Abhinay Agarwal wrote:
> Hi Ty Young,
>
> I am trying to identify which part of the documentation changed after
> JavaFX 13. The JVM arguments that you have specified are required
> since JavaFX 11. Alternatively, user doesn't need to pass these
> arguments if they are using javafx-maven-plugin to build and run the
> application.
>
> I might be missing something here. Can you be kind enough to point me
> to the specific issue and the related section in docs so that it can
> be fixed?


Right, so I think I got the issue sorted out.



TL;DR, you HAVE to use the archtype. Netbeans WILL NOT adjust its own
runtime "nbactions.xml" file if you decided to create a barebones
project and add JavaFX later, which is why runtime components are
missing and following the advice for Ant will fix the issue.


In Netbeans 12.3 Beta(what I'm using now) everything works.



In other words, as of Netbeans 12-3, **don't do this**:



New Project -> Java with Maven -> Java Application -> add JavaFX from
maven central



do this:



New Project -> Java with Maven -> Simple JavaFX Application Archtype(Gluon)



They changed the UI in Netbeans 12-3 beta, so the documentation will
need to be updated for it.



>
> Thanks in advance.
>
> -- Abhinay
> 
> *From:* openjfx-dev  on behalf
> of Ty Young 
> *Sent:* Monday, April 20, 2020 10:07 PM
> *To:* openjfx-dev@openjdk.java.net 
> *Subject:* Re: Remove JavaFX JPMS enforcement
>
> On 4/20/20 11:36 AM, Ty Young wrote:
> >
> > On 4/20/20 10:47 AM, Mark Raynsford wrote:
> >> Am I missing something here? What absurd arguments are required for
> >> Maven projects?
> >>
> >> I have multiple applications here running in full module-path mode (the
> >> applications are modularized, and JavaFX is on the module path), using
> >> plain Maven builds with no special arguments, and IDEA as the IDE.
> >> This is on JDK 13, with the 13.0.2 JavaFX release from Central.
> >>
> >
> > From the second warning on this page:
> >
> >
> > https://openjfx.io/openjfx-docs/
> >
> >
> > That's the absurd part. JavaFX 14 now requires this as a JVM runtime
> > argument:
> >
> >
> > --module-path /path/to/javafx-sdk-12/lib --add-modules
> > javafx.controls,javafx.fxml
> >
> >
> > Which wasn't required before. Not only is this a PITA and confusing
> > but it also prevents Maven from just handling everything. Netbeans
> > uses a custom file for runtime arguments, which the above is added to.
> >
>
> Also, it gives JavaFX 12 as an example, which is wrong. It should be 14.
>

Re: RFR: 8087555: [ChoiceBox] uncontained value not shown

[Ambarish Rapte]

On Tue, 21 Apr 2020 12:16:57 GMT, Kevin Rushforth  wrote:

>> The issue is that ChoiceBoxSkin
>> a) doesn't update the text of the label if the value is not contained in the 
>> items
>> b) doesn't respect converter for label text
>> 
>> Fixed by
>> - listening to value changes to update the label
>> - removing ad-hoc updates (not needed), added update on converter change
>> - passing all label updates through converter
>> 
>> Added test for text updates that failed before the fix and pass after (note: 
>> there were no tests for the display text,
>> so for coveragy, contains also tests that passed before as well as after)
>
> @aghaisas @arapte can you review?

I have not reviewed the code but have only tested it.
The value of index is not defined when an uncontained item is selected.
With the current implementation (with and without this PR change) there is a 
difference of behavior when an uncontained
item is selected Vs when an existing item is selected, in scenarios as below,

=> clearSelection()
a) scenario 1
1. Select/set an uncontained item. `selectedIndex` would be -1.
2. call `clearSelection()`, Does NOT clear the selected item to null
b) scenario 2
1. Select an item at index 2, `selectedIndex` would be 2.
2. Select/set an uncontained item. `selectedIndex` would remain 2.
3. call `clearSelection()`, => clears the selected item to null  and selected 
index to -1

and similarly the difference of behavior can be observed with `selectNext()`, 
`selectPrevious()`

This is not formally documented(nor decided), so we might need to decide on a 
value of index for an uncontained value.

-

PR: https://git.openjdk.java.net/jfx/pull/191

Re: RFR: 8087555: [ChoiceBox] uncontained value not shown

[Jeanette Winzenburg]

On Fri, 24 Apr 2020 14:05:27 GMT, Ambarish Rapte  wrote:

> I have not reviewed the code but have only tested it.

Thanks for taking an initial look :) Just keep in mind that this issue is 
focused on displaying of the box' value
reliably.

> The value of index is not defined when an uncontained item is selected.

yeah the spec is rather .. well, suboptimal at some crucial points (see also
[JDK-8088012](https://bugs.openjdk.java.net/browse/JDK-8088012)). To keep the 
state logically consistent, we need an
invariant like:

 assertEquals(getItems().indexOf(selectedItem), selectedIndex)

Which seems to be hinted at in a code comment in 
`SingleSelectionModel.select(item)`:

// if we are here, we did not find the item in the entire data model.
// Even still, we allow for this item to be set to the give object.
// We expect that in concrete subclasses of this class we observe the
// data model such that we check to see if the given item exists in it,
// whilst SelectedIndex == -1 && SelectedItem != null.

For ChoiceBox, that will be fixed in 
[JDK-8241999](https://bugs.openjdk.java.net/browse/JDK-8241999) (ready for push 
as
soon as this is integrated).

> With the current implementation (with and without this PR change) there is a 
> difference of behavior when an uncontained
> item is selected Vs when an existing item is selected, in scenarios as below,
> => clearSelection()
> a) scenario 1
> 
> 1. Select/set an uncontained item. `selectedIndex` would be -1.
> 
> 2. call `clearSelection()`, Does NOT clear the selected item to null

true, that's spec'ed in ComboBox only .. so by analogy I considered it being 
the same here. Hmm .. might need an update
of the doc?

>b) scenario 2
> 
> 3. Select an item at index 2, `selectedIndex` would be 2.
> 
> 4. Select/set an uncontained item. `selectedIndex` would remain 2.
> 

exactly that is [JDK-8241999](https://bugs.openjdk.java.net/browse/JDK-8241999)

> 5. call `clearSelection()`, => clears the selected item to null  and 
> selected index to -1
> 

interesting, hadn't noticed yet - will add a test to the other fix, thanks :)

> 
> and similarly the difference of behavior can be observed with `selectNext()`, 
> `selectPrevious()`
> 

yeah, that's another issue .. selection issues are a bottomless pit ..

> This is not formally documented(nor decided), so we might need to decide on a 
> value of index for an uncontained value.

see the "natural" constraint above - without we get into hell, IMO.

Good points all, thanks again!

-

PR: https://git.openjdk.java.net/jfx/pull/191

Re: Gradle support for getting :web:test working properly

[Jesper Skov]

Thanks, I will give it a shot.

Jesper


On Thu, Apr 23, 2020 at 7:45 PM Kevin Rushforth 
wrote:

> That's an interesting idea that might be worth pursuing. It would help
> mitigate what has been a long-standing pain point for developers who
> don't want to build media or web, but would like to run them. I would
> caution, though, that it is still not a substitute for building both
> media and WebKit yourself, since it will still not work reliably in the
> case where there is an interface change or some other mutually dependent
> change between the native media or web library and Java class files. In
> those cases you are stuck until a new EA build is available.
>
> If you do want to pursue this, then as long as the dependency on
> org.openjfx:javafx-web and org.openjfx:javafx-media is localized to the
> downloading and unpacking step you mentioned, this would be fine with
> me. Maybe others could help test it on Mac and Windows.
>
> As for the name of the new property, maybe STUB_RUNTIME_OPENJFX? The
> easiest way to implement this might be to set the value of
> `defaultStubRuntime` to the directory into which you unpack it
> (underneath either build or buildSrc/build).
>
> -- Kevin
>
>
> On 4/23/2020 1:14 AM, Jesper Skov wrote:
> > Hi
> >
> > I struggled somewhat to get :web:test running with -PSTUB_RUNTIME.
> >
> > The JVM kept crashing by what turned out to be missing media
> > libraries (the failure message was hidden).
> >
> > I tried building with -PCOMPILE_WEBKIT=true, but it takes a terrible
> > long time on my laptop. And did not in itself fix the problem.
> >
> > Frustrations and lost time was the only real outcome of this :)
> >
> >
> >
> >
> > So I would suggest adding logic to the build file to allow something
> > like:
> >
> >  gradlew -PSTUB_RUNTIME_USE=15-ea+4 all test
> >
> > This should download org.openjfx:javafx-web and
> > org.openjfx:javafx-media artifacts in the specified version.
> >
> > Then unpack the shared libraries to a build folder, and make them
> > availble via the STUB_RUNTIME logic.
> >
> >
> > Plus an addition to the CONTRIBUTING.md documenting this.
> >
> >
> > I would be happy to help make and/or test the changes, but am only
> > able to work on Linux.
> >
> >
> > Thanks,
> > Jesper
>

Re: Community request to test 3D performance

[David Grieve]

Yes, windows. I can run on a Mac, but it's just a laptop with the standard 
Intel HD Graphics card. 

-Original Message-
From: openjfx-dev  On Behalf Of Kevin 
Rushforth
Sent: Thursday, April 23, 2020 5:59 PM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] Re: RE; Community request to test 3D performance

Thanks, David.

I presume you will be running Windows? Ideally we would get results on Windows 
and Mac.

Nir: I can upload the modified version of the benchmark, unless you have a 
working version.

-- Kevin


On 4/23/2020 2:41 PM, Nir Lisker wrote:
> I think so. The test is relatively simple, so it should be worth it. Thanks.
>
> On Fri, Apr 24, 2020 at 12:04 AM David Grieve 
> 
> wrote:
>
>> I have an NVIDIA Quadro P400. Will that help?
>>
>> -Original Message-
>> From: openjfx-dev  On Behalf Of 
>> Nir Lisker
>> Sent: Thursday, April 23, 2020 3:55 PM
>> To: openjfx-dev@openjdk.java.net Mailing 
>> 
>> Subject: [EXTERNAL] Community request to test 3D performance
>>
>> Hi all,
>>
>> My PR [1] for adding attenuation for PointLight is pending tests from 
>> setups with recent NVidia or AMD GPUs. If anyone has such a setup, it 
>> would greatly help to get tests results from it.
>>
>> Thanks,
>> Nir
>>
>> [1]
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>> hub.com%2Fopenjdk%2Fjfx%2Fpull%2F43&data=02%7C01%7CDavid.Grieve%4
>> 0microsoft.com%7Cc7e4abcf102f4a570f6208d7e7d1debc%7C72f988bf86f141af9
>> 1ab2d7cd011db47%7C1%7C0%7C637232760879569256&sdata=EF9g8h8jIL6Dzw
>> 7s4ZwFIBFIiYuiAgvLErCDQWVhyB4%3D&reserved=0
>>

Re: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi

[John Neffenger]

On Fri, 24 Apr 2020 08:20:02 GMT, Alexander Scherbatiy  
wrote:

> To debug the JavaFX on Raspberry Pi I built armv6hf-sdk and just copied the 
> file _javafx.platform.properties_ from the
> full jdk version with JavaFX to jdk-14.0.1/lib directory of jdk without 
> JavaFX which I used to run my java application
> with JavaFX modules from armv6hf-sdk/lib.

May I then suggest one additional change to this pull request? It's a two-line 
fix:

--- a/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java
+++ b/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java
@@ -238,8 +238,7 @@ public class PlatformUtil {
 // Strip everything after the last "/" or "" to get rid of the jar 
filename
 int lastIndexOfSlash = Math.max(
 s.lastIndexOf('/'), s.lastIndexOf('\'));
-return new File(new URL(s.substring(0, lastIndexOfSlash + 
1)).getPath())
-.getParentFile();
+return new File(new URL(s.substring(0, lastIndexOfSlash + 
1)).getPath());
 } catch (MalformedURLException e) {
 return null;
 }

That change corrects the code to look for the `javafx.platform.properties` file 
in the same directory as the
`javafx.base.jar` file instead of looking for it in the parent directory of the 
JAR file. I just stepped through the
code with this change, and the method `PlatformUtil.loadProperties` now finds 
the properties file in the location where
it is packaged by the build in the SDK.

-

PR: https://git.openjdk.java.net/jfx/pull/193

Re: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi

[John Neffenger]

On Fri, 24 Apr 2020 16:39:07 GMT, John Neffenger 
 wrote:

>>> @AlexanderScherbatiy Did you move the _javafx.platform.properties_ file to 
>>> its parent directory manually, as I just did?
>> 
>> I used the full version of jdk 14.0.1 on Raspberry Pi where JavaFX is 
>> included in jdk so the file
>> _javafx.platform.properties_ is already in jdk-14.0.1-full/lib directory.
>> To debug the JavaFX on Raspberry Pi I built  armv6hf-sdk and just copied the 
>> file  _javafx.platform.properties_ from
>> the full jdk version with JavaFX to jdk-14.0.1/lib directory of jdk without 
>> JavaFX which I used to run my java
>> application with JavaFX modules from armv6hf-sdk/lib.
>
>> To debug the JavaFX on Raspberry Pi I built armv6hf-sdk and just copied the 
>> file _javafx.platform.properties_ from the
>> full jdk version with JavaFX to jdk-14.0.1/lib directory of jdk without 
>> JavaFX which I used to run my java application
>> with JavaFX modules from armv6hf-sdk/lib.
> 
> May I then suggest one additional change to this pull request? It's a 
> two-line fix:
> 
> --- a/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java
> +++ b/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java
> @@ -238,8 +238,7 @@ public class PlatformUtil {
>  // Strip everything after the last "/" or "" to get rid of the 
> jar filename
>  int lastIndexOfSlash = Math.max(
>  s.lastIndexOf('/'), s.lastIndexOf('\'));
> -return new File(new URL(s.substring(0, lastIndexOfSlash + 
> 1)).getPath())
> -.getParentFile();
> +return new File(new URL(s.substring(0, lastIndexOfSlash + 
> 1)).getPath());
>  } catch (MalformedURLException e) {
>  return null;
>  }
> 
> That change corrects the code to look for the `javafx.platform.properties` 
> file in the same directory as the
> `javafx.base.jar` file instead of looking for it in the parent directory of 
> the JAR file. I just stepped through the
> code with this change, and the method `PlatformUtil.loadProperties` now finds 
> the properties file in the location where
> it is packaged by the build in the SDK.

Related issues, including the original request for enhancement:

* [JDK-8100775](https://bugs.openjdk.java.net/browse/JDK-8100775): Means of 
bundling platform specific settings for
  glass/runtime
* [JDK-8115678](https://bugs.openjdk.java.net/browse/JDK-8115678): JavaFX 
preview on Raspberry Pi
  requires -Djavafx.platform=eglfb to be set
* [JDK-8117705](https://bugs.openjdk.java.net/browse/JDK-8117705): Embedded 
JavaFX can't find javafx.platform.properties

-

PR: https://git.openjdk.java.net/jfx/pull/193