Re: Windows Installation Instructions, All DLL Files Missing

[Michael Paus]

Hi Christopher,
I do not know what your specific problem is but maybe you just have to 
shift your goals a little bit.
Continuing like you did in the Java 8 days is not a good idea for 
various reasons. The current trend
for distributing desktop software with Java is to build a platform 
specific installer. The tools for that
are all there. Just give it a try. Together with Dirk Lemmermann I have 
set up a working example
and tutorial on GitHub. It uses the latest Java/JavaFX and works on Mac 
and Windows (should also work
on Linux but I haven't tested it.) 

The nice thing about this approach is that your customer does not have 
to have anything installed on his
own machine. He can just install your software like he would install any 
other piece of software.

Michael

Am 18.04.20 um 20:18 schrieb Christopher Miles:

Yep, that's where I downloaded it from.

> PS C:\Users\cmiles\source\repos\xmltool> java --version
> openjdk 14.0.1 2020-04-14
> OpenJDK Runtime Environment (build 14.0.1+7)
> OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

When I look at the "bin" directory that came with the JavaFX SDK and 
compare it to the "bin" directory that comes with OpenJDK there are 
things in the JavaFX distribution that aren't present in the OpenJDK 
distribution. These three caught my attention:


  + prism_common.dll
  + prism_d3d.dll
  + prism_sw.dll

I suspect missing these DLL's is what is causing the exception when I 
try to launch my application.


I took a look at "JDK-8207015" and I don't think that is my problem, 
yet. It could be that if the "prism_xxx.dll" files were present, I 
might run into this issue.


I changed my `jlink` command to point at the "mods" as this seems like 
the correct way to do this. Still, the app refuses to launch with the 
same error message.


> Graphics Device initialization failed for :  d3d, sw
> Error initializing QuantumRenderer: no suitable pipeline found
> java.lang.RuntimeException: java.lang.RuntimeException: Error 
initializing QuantumRenderer: no suitable pipeline found


I would very much like to avoid adding switches to a `java` invocation 
in order to run the application. In your example, I would need to have 
customer installed the JavaFX JDK to a specific location in order for 
that to work. I'd also need to have some kind of wrapper to handle 
other operating systems, like Linux or OS X. My goal is to distribute 
one package with custom launching scripts (i.e. one for batch, 
Powershell, and Linux/OS X shell) as I did under Java 8. This makes me 
think that using `jlink` with the mods is the way to go, as long as I 
can figure out why that is not working.


Thank you for your help with this. :-)

Kevin Rushforth wrote on 4/17/2020 17:34:
 From where are you getting your OpenJDK build? 
https://jdk.java.net/14 ? Somewhere else?


-- Kevin


On 4/17/2020 2:16 PM, Christopher Miles wrote:
Yeah, I've tried it with both. The instructions on the JavaFX page 
tell you to add the "lib" directory to the `javac` path and the 
"mods" to the `jlink` path. I figured, since nothing is working, why 
not try them the other way around? In all cases the results are the 
same.


I'm using OpenJDK, wouldn't that project have the same issue 
distributing these DLL files? I would bet they would, since they are 
also an open source project. I can run Swing projects, however, 
without these DLL files.


I can give the Oracle JDK a try. I had been shying away from it 
since OpenJDK is getting to be so popular. If that works, I will let 
the list know.


As an aside, the JavaFX home page recommends using OpenJDK right now:

  https://openjfx.io/openjfx-docs/#install-java

Thank you!

Kevin Rushforth wrote on 4/17/2020 16:51:
Where are you getting JDK 14.0.1 from? Does it include the 
Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There 
are 45 of them (40 of them are of the form api-ms-win-*.dll). The 
JavaFX 14.0.1 sdk includes them, but the jmods do not. See 
JDK-8207015 [1] for why not. If the JDK has them, then there should 
be no problem running a jlinked app.


One possible problem is that your jlink line is wrong. You should 
not point to the SDK at all when running jlink. Use the jmods with 
jlink (don't use the sdk). Use the sdk with javac and java 
--module-path (don't use the jmods at all).


Btw, even if you are running a JDK that for some reason doesn't 
have the Microsoft DLLs, you should still be able to run using the 
SDK (directly, not via jlink, which requires the jmods) as follows:


java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" 
--add-modules 
javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web 
MyApplication


If this doesn't work without you putting javafx-sdk-14/bin in your 
PATH then something else is wrong.


-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8207015

On 4/17/2020 1:18 PM, Christopher Miles wrote:
I have 

Re: Windows Installation Instructions, All DLL Files Missing

[Christopher Miles]

Yep, that's where I downloaded it from.

> PS C:\Users\cmiles\source\repos\xmltool> java --version
> openjdk 14.0.1 2020-04-14
> OpenJDK Runtime Environment (build 14.0.1+7)
> OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

When I look at the "bin" directory that came with the JavaFX SDK and 
compare it to the "bin" directory that comes with OpenJDK there are 
things in the JavaFX distribution that aren't present in the OpenJDK 
distribution. These three caught my attention:


  + prism_common.dll
  + prism_d3d.dll
  + prism_sw.dll

I suspect missing these DLL's is what is causing the exception when I 
try to launch my application.


I took a look at "JDK-8207015" and I don't think that is my problem, 
yet. It could be that if the "prism_xxx.dll" files were present, I might 
run into this issue.


I changed my `jlink` command to point at the "mods" as this seems like 
the correct way to do this. Still, the app refuses to launch with the 
same error message.


> Graphics Device initialization failed for :  d3d, sw
> Error initializing QuantumRenderer: no suitable pipeline found
> java.lang.RuntimeException: java.lang.RuntimeException: Error 
initializing QuantumRenderer: no suitable pipeline found


I would very much like to avoid adding switches to a `java` invocation 
in order to run the application. In your example, I would need to have 
customer installed the JavaFX JDK to a specific location in order for 
that to work. I'd also need to have some kind of wrapper to handle other 
operating systems, like Linux or OS X. My goal is to distribute one 
package with custom launching scripts (i.e. one for batch, Powershell, 
and Linux/OS X shell) as I did under Java 8. This makes me think that 
using `jlink` with the mods is the way to go, as long as I can figure 
out why that is not working.


Thank you for your help with this. :-)

Kevin Rushforth wrote on 4/17/2020 17:34:
 From where are you getting your OpenJDK build? https://jdk.java.net/14 
? Somewhere else?


-- Kevin


On 4/17/2020 2:16 PM, Christopher Miles wrote:
Yeah, I've tried it with both. The instructions on the JavaFX page 
tell you to add the "lib" directory to the `javac` path and the "mods" 
to the `jlink` path. I figured, since nothing is working, why not try 
them the other way around? In all cases the results are the same.


I'm using OpenJDK, wouldn't that project have the same issue 
distributing these DLL files? I would bet they would, since they are 
also an open source project. I can run Swing projects, however, 
without these DLL files.


I can give the Oracle JDK a try. I had been shying away from it since 
OpenJDK is getting to be so popular. If that works, I will let the 
list know.


As an aside, the JavaFX home page recommends using OpenJDK right now:

  https://openjfx.io/openjfx-docs/#install-java

Thank you!

Kevin Rushforth wrote on 4/17/2020 16:51:
Where are you getting JDK 14.0.1 from? Does it include the Microsoft 
VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There are 45 of 
them (40 of them are of the form api-ms-win-*.dll). The JavaFX 14.0.1 
sdk includes them, but the jmods do not. See JDK-8207015 [1] for why 
not. If the JDK has them, then there should be no problem running a 
jlinked app.


One possible problem is that your jlink line is wrong. You should not 
point to the SDK at all when running jlink. Use the jmods with jlink 
(don't use the sdk). Use the sdk with javac and java --module-path 
(don't use the jmods at all).


Btw, even if you are running a JDK that for some reason doesn't have 
the Microsoft DLLs, you should still be able to run using the SDK 
(directly, not via jlink, which requires the jmods) as follows:


java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" 
--add-modules 
javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web 
MyApplication


If this doesn't work without you putting javafx-sdk-14/bin in your 
PATH then something else is wrong.


-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8207015

On 4/17/2020 1:18 PM, Christopher Miles wrote:
I have downloaded both the "mods" and the SDK. I put them alongside 
the JDK on my workstation.


  C:\Program Files\Java\jdk-14.0.1
  C:\Program Files\Java\javafx-sdk-14
  C:\Program Files\Java\javafx-jmods-14.0.1

If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and 
point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` path...


jlink --module-path "C:\Program 
Files\Java\javafx-sdk-14\lib;C:\Program Files\Java\jdk-14.0.1/jmods" 
--add-modules 
javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base 
--output C:\Users\cmiles\source\repos\xmltool\target/jlink 
--strip-debug --no-man-pages --no-header-files --compress=2


...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my 
global path, the application builds. When I try to run the 
application I see the following error.


  Graphics 

Re: FYI: 8243112: Skip failing test SVGTest.testSVGRenderingWithPattern

[Kevin Rushforth]

On Sat, 18 Apr 2020 17:38:17 GMT, Arun Joseph  wrote:

> SVGTest.testSVGRenderingWithPattern is failing frequently due to
> [JDK-8243110](https://bugs.openjdk.java.net/browse/JDK-8243110). We should 
> skip this test until it is fixed.

Marked as reviewed by kcr (Lead).

-

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

FYI: 8243112: Skip failing test SVGTest.testSVGRenderingWithPattern

[Arun Joseph]

SVGTest.testSVGRenderingWithPattern is failing frequently due to
[JDK-8243110](https://bugs.openjdk.java.net/browse/JDK-8243110). We should skip 
this test until it is fixed.

-

Commit messages:
 - 8243112: Skip failing test SVGTest.testSVGRenderingWithPattern

Changes: https://git.openjdk.java.net/jfx/pull/188/files
 Webrev: https://webrevs.openjdk.java.net/jfx/188/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243112
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/188.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/188/head:pull/188

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

Re: [Rev 01] RFR: 8185886: Improve scrolling performance of TableView and TreeTableView

[yosbits]

On Fri, 3 Apr 2020 03:55:37 GMT, yosbits 
 wrote:

>> Hi,
>> I couldn't find you listed at 
>> https://www.oracle.com/technetwork/community/oca-486395.html . Please send 
>> me an e-mail
>> at dalibor.to...@oracle.com with information about your OCA, so that I can 
>> look it up.
>
> My name is "Naohiro Yoshimoto"
> I have received an approved email on 2019-8-3.

19fabf2eafcb02b519d39a1b0a9dad5b9209db64

* The constructor creates a cell, but the
 If the fixedCellSize is not initialized, the
Fixed a wasteful process of creating all cells and deleting cells out of the 
display range.
* Reduce the load on ExpressionHelper.removeListener by removing cells outside 
of the display range from the back of the
  scrolling operation.

-

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

Re: Remove JavaFX JPMS enforcement

[Glenn Holmer]

On 4/18/20 5:01 AM, Michael Paus wrote:
> Getting started with JavaFX is made overly complicated by the fact
> that the use of the module system is enforced by some code in the
> JDK. Especially for beginners, who just want to get some small
> program running, this is almost always a big source of frustration. 

> I'd now like to have some feedback of the community about this.

Making it easy for beginners is the job of an IDE. NetBeans 12.0 beta3
can already create modular JavaFX projects using Maven in which "run
project" and "debug project" work out of the box. Look for the addition
of out-of-box profiling support in beta 4 (hopefully the last before
12.0 releases).

-- 
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

Re: [Rev 01] RFR: 8185886: Improve scrolling performance of TableView and TreeTableView

[yosbits]

> If there are many columns, the current TableView will stall scrolling. 
> Resolving this performance issue requires column
> virtualization. Virtualization mode is enabled when the row height is fixed 
> by the following method.
> `tableView.setFixedCellSize(height)`
> 
> This proposal includes a fix because the current code does not correctly 
> implement column virtualization.
> 
> The improvement of this proposal can be seen in the following test program.
> 
>  Java
> import javafx.animation.AnimationTimer;
> import javafx.application.Application;
> import javafx.beans.property.SimpleStringProperty;
> import javafx.collections.ObservableList;
> import javafx.scene.Scene;
> import javafx.scene.control.TableColumn;
> import javafx.scene.control.TableView;
> import javafx.scene.layout.BorderPane;
> import javafx.stage.Stage;
> 
> public class BigTableViewTest2 extends Application {
> 
>   private static final boolean USE_WIDTH_FIXED_SIZE = true;
>   private static final boolean USE_HEIGHT_FIXED_SIZE = true;
> //private static final int COL_COUNT=300;
>   private static final int COL_COUNT=600;
> //private static final int COL_COUNT=1000;
>   private static final int ROW_COUNT=1000;
> 
>   @Override
>   public void start(Stage primaryStage) throws Exception {
>   final TableView tableView = new TableView<>();
> 
>   final ObservableList> columns = 
> tableView.getColumns();
>   for(int i=0; i   TableColumn column = new 
> TableColumn<>("Col"+i);
>   final int colIndex=i;
>   column.setCellValueFactory((cell)->new 
> SimpleStringProperty(cell.getValue()[colIndex]));
>   columns.add(column);
>   if(USE_WIDTH_FIXED_SIZE) {
>   column.setPrefWidth(60);
>   column.setMaxWidth(60);
>   column.setMinWidth(60);
>   }
>   }
> 
>   ObservableList items = tableView.getItems();
>   for(int i=0; i   String[] rec = new String[COL_COUNT];
>   for(int j=0; j   rec[j] = i+":"+j;
>   }
>   items.add(rec);
>   }
>   BorderPane root = new BorderPane(tableView);
>   if(USE_HEIGHT_FIXED_SIZE) {
>   tableView.setFixedCellSize(24);
>   }
> 
>   Scene scene = new Scene(root, 800, 800);
>   primaryStage.setScene(scene);
>   primaryStage.show();
>   prepareTimeline(scene);
> 
>   }
> 
>   public static void main(String[] args) {
>   Application.launch(args);
>   }
> 
> private void prepareTimeline(Scene scene) {
> new AnimationTimer() {
> @Override public void handle(long now) {
> double fps =  
> com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS();
> ((Stage)scene.getWindow()).setTitle("FPS:"+(int)fps);
> }
> }.start();
> }
> 
> }

yosbits has updated the pull request incrementally with one additional commit 
since the last revision:

  8185886: Fix scroll performance of TableView with many columns

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/125/files
  - new: https://git.openjdk.java.net/jfx/pull/125/files/04951abf..19fabf2e

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/125/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/125/webrev.00-01

  Stats: 48 lines in 1 file changed: 24 ins; 19 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/125.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/125/head:pull/125

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

RE: Remove JavaFX JPMS enforcement

[Mohammad Saleem Yusuf]

Michael,
I completely agree with you. I am Professor at a community college (NHTI) and 
teach entry level courses to students who have just graduated from high school.
About a year ago (JDK 8 to 11), I started including Java FX in my Java course, 
but after that I had to remove it (JDK > 11.03) as the Oracle examples on web 
stopped working. I noticed that the textbook I use (Java, The Complete 
Reference 11 ed, Oracle Press) also took Java FX out.

I really like JavaFX and I also teach Microsoft and Google (Android) courses. 
For GUI, they also use similar technologies in WPF, UWP and Android 
Development. It would be very helpful to make Java FX use easy again, so 
students start using Java FX again. I tried for a while but gave as I don't 
have to time to do all the research and install additional software.

M. Saleem Yusuf



-Original Message-
From: openjfx-dev  On Behalf Of Michael 
Paus
Sent: Saturday, April 18, 2020 6:01 AM
To: OpenJFX 
Subject: Remove JavaFX JPMS enforcement

Getting started with JavaFX is made overly complicated by the fact that the use 
of the module system is enforced by some code in the JDK. Especially for 
beginners, who just want to get some small program running, this is almost 
always a big source of frustration.
It is not very good marketing for JavaFX to make these initial steps such a 
pain. If you need some evidence for this statement, then just follow JavaFX on 
Stackoverflow or similar sites (and also this mailing list). Almost every day 
you can read frustrated posts from helpless people who would just like to get 
some JavaFX project running but are failing because they get lost in the module 
system jungle.

In order to make JavaFX more easily accessible, especially for beginners, I'd 
like to start a discussion here about the possibility to unconditionally remove 
the JavaFX JPMS enforcement. IMHO this enforcement is simply not necessary and 
is just the root for a lot of frustration with JavaFX. It should just be 
possible to put all the JavaFX jars on the classpath (instead of the module 
path) like you would do with any other external dependency in a non-modular 
setup.

With a not very intuitive hack you can circumvent this problem already now.
Just add a line like this to the file which contains your main class extending 
Application (MyApp).

class MyAppLauncher {public static void main(String[] args) {MyApp.main(args);}}

Because of this launcher it is now possible to put all dependencies and all 
JavaFX jars on the classpath and to completely forget the module system with 
all its intricacies and pitfalls.
But why should people be forced to use such dirty tricks? The better 
alternative would be to just lift the current constraint.

I am using this trick for a long time now, even on bigger projects, and I have 
never ever experienced any problem resulting from this. Even in theory I don't 
know anything that could prevent a formally correct module jar to also work on 
the classpath (which is of course not true the other way round). Therefore I 
say that this constraint is just not necessary and only does a lot of damage to 
JavaFXs reputation.

I'd now like to have some feedback of the community about this.

Michael

Re: Remove JavaFX JPMS enforcement

[Tom Eugelink]

I'm in the process of porting an app from Java 8 to Java 11. Just getting it to 
run in classpath mode is not that hard anymore; upgrade a bunch of libraries 
and you're set.

As an experiment I'm now activating JPMS. Right! What a lot of work! Do you 
have any idea how many fairly common libraries not even include an automatic 
module name in the manifest? Let alone being full fledged modules. It seems 
modules is a threshold a lot of projects see no need to cross. So I figure most 
JavaFX projects also run in classic classpath mode, hence that would be the 
main usage of the library. Just sayin'

Tom


On 18-4-2020 16:56, Weiqi Gao wrote:

I have built both non-modular and modular JavaFX apps in the past five years, 
and I agree that bootstrapping a modular Hello World JavaFX application is not 
as trivial as bootstrapping a non-modular one.

The big challenges are related to the JPMS. These challenges are not unique to 
JavaFX. They are present in almost all libraries that are going through the 
modularization process. (JAXB for example.)

The good news in this regard is that with a combination of tools like Gradle 
and its JavaFX plugin and Java Modularity plugin, bootstrapping a modular 
JavaFX application has become a non-event that can be done in minutes.

And after that initial setup, further development of the application is almost 
the same as for non-modular JavaFX applications, with the occasional need to 
add an exports or an opens line to the module-info.java file to allow FXML (or 
the dependency injector of your choice, I used Juice and Micronaut in two 
different projects to good effect) reflective access to your controller classes.

My IDE of choice, IntelliJ IDEA, works happily with JavaFX.

—
Weiqi Gao

Sent from my iPhone


On Apr 18, 2020, at 7:43 AM, Michael Paus  wrote:

Hi,
I would just like to add that many of the problems you have cited would just 
vanish if the JPMS
enforcement would be removed from the JDK. There would be no "JavaFX requiring 
absurd
runtime module VM arguments" anymore and the IDE integration would just be 
straight forward.
JavaFX would become just one more dependency whithout the need for any special 
treatment.

I did, however, not say that JavaFX should be de-modularized. For an expert 
user who wants
to use the JPMS nothing would change at all.

Michael


Am 18.04.20 um 12:58 schrieb Ty Young:


On 4/18/20 5:01 AM, Michael Paus wrote:
Getting started with JavaFX is made overly complicated by the fact that the use 
of the
module system is enforced by some code in the JDK. Especially for beginners, 
who just
want to get some small program running, this is almost always a big source of 
frustration.
It is not very good marketing for JavaFX to make these initial steps such a 
pain. If you
need some evidence for this statement, then just follow JavaFX on Stackoverflow 
or similar
sites (and also this mailing list). Almost every day you can read frustrated 
posts from
helpless people who would just like to get some JavaFX project running but are 
failing
because they get lost in the module system jungle.


Speaking as a long time JavaFX user(literally since Java 8), I have mostly 
disagree that the JPMS is hurting JavaFX.


That said, I don't think the frustration is misplaced. What you say is 
true(Netbeans mailing list is fill of JavaFX issues) and the end user is *NOT* 
to be blamed here.


Rather, I think what's to blame is poor documentation, JavaFX requiring absurd 
runtime module VM arguments, and  poor/buggy IDE support.


Starting with documentation, JavaFX uses reflection for things like 
TableView(everyone's favorite) and CSS style sheets. While this may be obvious 
for people who are more experienced, those who are not may be very confused 
when they get an onslaught of error messages regarding reflection. Better 
documentation on what requires reflection, why, and how to enable it would be 
useful.


Likewise, the notice about having to include javafx.graphics to the runtime 
module arguments here:


https://openjfx.io/openjfx-docs/#IDE-NetBeans


Apply to Maven as well, but it's under Ant for some reason. I don't know what 
was changed in JavaFX 14 that now suddenly requires a runtime VM argument, but 
it's a PITA and BS. End users are going to struggle with this, and it prevents 
JavaFX runtime from being purely managed by Maven. No other JavaFX version 
requires this, so it's mind boggling that all of a sudden JavaFX needs this.


Poor/buggy IDE support is really the big one here. I don't know about other IDEs but Netbeans DOES 
NOT provide a project template for creating a JavaFX application with setup dependencies. Netbeans, 
when setup with a Maven project, allows you to select an entire project(pom) rather than the 
individual dependencies(jar) which doesn't work. What you search for also matters: if you search 
for "JavaFX" you will get the wrong search results. You need to search for 
"openjfx" which can be confusing.


Anyway, yeah, 

Re: RFR: 8242490: Upgrade to gcc 9.2 on Linux

[Kevin Rushforth]

On Sat, 18 Apr 2020 15:52:36 GMT, Johan Vos  wrote:

>> This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 
>> 9.2. This will match a recent upgrade done
>> for JDK 15 -- see 
>> [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721).
>> On a related note, using the gcc 9 compiler produces many (harmless) 
>> warnings that will be addressed by
>> [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR 
>> #150.
>> I have run a full build and test using this new compiler.
>
> Works on my development system (didn't test on our build system yet)

I won't integrate this until Monday anyway. If you run into a problem with the 
actual builds using this compiler, let
me know and I'll hold off further (it's been well-tested on my end).

-

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

Re: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles()

[Kevin Rushforth]

On Thu, 9 Apr 2020 09:58:27 GMT, Jesper Skov 
 wrote:

> Make the two ways of associating a ToggleButton with a ToggleGroup interact 
> correctly.
> 
> This fixes https://bugs.openjdk.java.net/browse/JDK-8198402

The fix looks correct to me. Have you run all tests to ensure no regressions?

I left a couple inline comments.

modules/javafx.controls/src/main/java/javafx/scene/control/ToggleButton.java 
line 196:

> 195: private ObjectProperty toggleGroup;
> 196: @Override
> 197: public final void setToggleGroup(ToggleGroup value) {

This is unrelated to the fix. The changes in this file should be reverted.

modules/javafx.controls/src/test/java/test/javafx/scene/control/ToggleButtonTest.java
 line 270:

> 269: } catch (InterruptedException e) {
> 270:System.err.println("InterruptedException occurred during 
> Thread.sleep()");
> 271: }

An exception here should cause the test to fail. You can use `Assert.fail` or 
else re-throw the exception as an
`AssertionFailedError`.

modules/javafx.controls/src/main/java/javafx/scene/control/ToggleGroup.java 
line 74:

> 73: while (c.next()) {
> 74: List addedToggles = c.getAddedSubList();
> 75:

This can be declared as final.

-

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

Re: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles()

[Kevin Rushforth]

On Thu, 9 Apr 2020 10:00:49 GMT, Jesper Skov 
 wrote:

>> Make the two ways of associating a ToggleButton with a ToggleGroup interact 
>> correctly.
>> 
>> This fixes https://bugs.openjdk.java.net/browse/JDK-8198402
>
> /signed

@arapte can you also review?

-

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

Re: RFR: 8242490: Upgrade to gcc 9.2 on Linux

[Johan Vos]

On Mon, 13 Apr 2020 16:12:38 GMT, Kevin Rushforth  wrote:

> This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 
> 9.2. This will match a recent upgrade done
> for JDK 15 -- see 
> [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721).
> On a related note, using the gcc 9 compiler produces many (harmless) warnings 
> that will be addressed by
> [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR 
> #150.
> I have run a full build and test using this new compiler.

Works on my development system (didn't test on our build system yet)

-

Marked as reviewed by jvos (Reviewer).

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

Re: [Rev 03] RFR: 8217472: Add attenuation for PointLight

[Kevin Rushforth]

On Fri, 17 Apr 2020 16:02:12 GMT, Nir Lisker  wrote:

>> Conclusion: The new shaders that support attenuation don't seem to have much 
>> of a performance impact on machines with
>> an Intel HD, but on systems with a graphics accelerator, it is a significant 
>> slowdown.
>> So we are left with the two choices of doubling the number of shaders (that 
>> is, a set of shaders with attenuation and a
>> set without) or living with the performance hit (which will only be a 
>> problem on machines with a dedicated graphics
>> accelerator for highly fill-limited scenes). The only way we can justify a 
>> 2x drop in performance is if we are fairly
>> certain that this is a corner case, and thus unlikely to hit real 
>> applications.  If we do end up deciding to replicate
>> the shaders, I don't think it is all that much work. I'm more worried about 
>> how well it would scale to subsequent
>> improvements, although we could easily decide that for, say, spotlights 
>> attenuation is so common that you wouldn't
>> create a version that doesn't do that.  In the D3D HLSL shaders, ifdefs are 
>> used, so the work would be to restore the
>> original code and add the new code under an ifdef. Then double the number of 
>> lines of gradle (at that point, I'd do it
>> in a for-each loop), then modify the logic that loads the shaders to pick 
>> the right one.  For GLSL, the different parts
>> of the shader are in different files, so it's a matter of creating new 
>> versions of each of the three lighting shaders
>> that handle attenuation and choosing the right one at runtime.
>
> I discussed this with a graphics engineer. He said that a couple of branches 
> do not have any real performance impact
> even on modern mobile devices, and that, e.g., on iOS 7 using half floats 
> instead of floats was improving shader
> execution dramatically. Desktops with NVIDIA or AMD and even Intel modern 
> cards can process dozens of branches with no
> significant performance degradation.  He suggested actually to have all the 
> light types in a single shader file
> (looking ahead here). He also suggested not to permute on shaders based on 
> the number of lights and just pass in a
> uniform for that number and loop over it. The permutations on the bump, 
> specular and self illuminations components are
> correct (not sure we are not doing that for the diffuse component). If we add 
> later shadows, which is not on my near
> to-do list, then we should permute there.  It also depends on our target 
> hardware. If we take into account hardware
> from, say, 2005 then maybe branching will cause significant performance loss, 
> but that hinders our ability to increase
> performance for newer hardware. What is the policy here?  I have a Win10 
> laptop with a GeForce 610M that I will test
> this weekend to see if the mobile NVidia cards have some issue.

I think most of those are good suggestions going forward. As for the 
performance drop, the only place we've seen it so
far is on graphics accelerators that are a few years old by now. Integrated 
graphics chipsets (such as Intel HD) either
old or new seem largely unaffected by the shader changes. What we are missing 
is performance metrics from newer
graphics accelerators on Mac and Windows.

Even with the performance drop on older graphics devices, I'm leaning towards 
not having the shaders to be shaders to
be doubled, since this is an artificial stress test with huge quads. If we 
could get performance data from a couple
more recent graphics accelerators that would be best.

-

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

Re: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set

[Kevin Rushforth]

On Fri, 17 Apr 2020 10:42:30 GMT, Jeanette Winzenburg  
wrote:

>> I think, selection and scrolling are two separate operations. Here we use 
>> these two operations to achieve the desired
>> result for ComboBox. It is nice to have behavior and I am OK with the fix.
>>>  Also, I believe JDK-8196037 is a duplicate of this issue.
>> 
>> Please Note that - JDK-8196037 is not a duplicate of this issue as described 
>> in PR description.
>> 
>> I have a minor comment regarding test.
>
> repeating my comment from the [previous pull 
> request](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086):
> I don't think this is yet ready for a technical review - there are some more 
> basic questions that are not yet answered
> :)

This will need two reviewers. As part of this review, the questions raised by 
@kleopatra in [this message from the
original PR](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086) 
need to be answered.

-

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

Re: Remove JavaFX JPMS enforcement

[Weiqi Gao]

I have built both non-modular and modular JavaFX apps in the past five years, 
and I agree that bootstrapping a modular Hello World JavaFX application is not 
as trivial as bootstrapping a non-modular one.

The big challenges are related to the JPMS. These challenges are not unique to 
JavaFX. They are present in almost all libraries that are going through the 
modularization process. (JAXB for example.)

The good news in this regard is that with a combination of tools like Gradle 
and its JavaFX plugin and Java Modularity plugin, bootstrapping a modular 
JavaFX application has become a non-event that can be done in minutes.

And after that initial setup, further development of the application is almost 
the same as for non-modular JavaFX applications, with the occasional need to 
add an exports or an opens line to the module-info.java file to allow FXML (or 
the dependency injector of your choice, I used Juice and Micronaut in two 
different projects to good effect) reflective access to your controller classes.

My IDE of choice, IntelliJ IDEA, works happily with JavaFX.

—
Weiqi Gao

Sent from my iPhone

> On Apr 18, 2020, at 7:43 AM, Michael Paus  wrote:
> 
> Hi,
> I would just like to add that many of the problems you have cited would just 
> vanish if the JPMS
> enforcement would be removed from the JDK. There would be no "JavaFX 
> requiring absurd
> runtime module VM arguments" anymore and the IDE integration would just be 
> straight forward.
> JavaFX would become just one more dependency whithout the need for any 
> special treatment.
> 
> I did, however, not say that JavaFX should be de-modularized. For an expert 
> user who wants
> to use the JPMS nothing would change at all.
> 
> Michael
> 
>> Am 18.04.20 um 12:58 schrieb Ty Young:
>> 
>>> On 4/18/20 5:01 AM, Michael Paus wrote:
>>> Getting started with JavaFX is made overly complicated by the fact that the 
>>> use of the
>>> module system is enforced by some code in the JDK. Especially for 
>>> beginners, who just
>>> want to get some small program running, this is almost always a big source 
>>> of frustration.
>>> It is not very good marketing for JavaFX to make these initial steps such a 
>>> pain. If you
>>> need some evidence for this statement, then just follow JavaFX on 
>>> Stackoverflow or similar
>>> sites (and also this mailing list). Almost every day you can read 
>>> frustrated posts from
>>> helpless people who would just like to get some JavaFX project running but 
>>> are failing
>>> because they get lost in the module system jungle.
>> 
>> 
>> Speaking as a long time JavaFX user(literally since Java 8), I have mostly 
>> disagree that the JPMS is hurting JavaFX.
>> 
>> 
>> That said, I don't think the frustration is misplaced. What you say is 
>> true(Netbeans mailing list is fill of JavaFX issues) and the end user is 
>> *NOT* to be blamed here.
>> 
>> 
>> Rather, I think what's to blame is poor documentation, JavaFX requiring 
>> absurd runtime module VM arguments, and  poor/buggy IDE support.
>> 
>> 
>> Starting with documentation, JavaFX uses reflection for things like 
>> TableView(everyone's favorite) and CSS style sheets. While this may be 
>> obvious for people who are more experienced, those who are not may be very 
>> confused when they get an onslaught of error messages regarding reflection. 
>> Better documentation on what requires reflection, why, and how to enable it 
>> would be useful.
>> 
>> 
>> Likewise, the notice about having to include javafx.graphics to the runtime 
>> module arguments here:
>> 
>> 
>> https://openjfx.io/openjfx-docs/#IDE-NetBeans
>> 
>> 
>> Apply to Maven as well, but it's under Ant for some reason. I don't know 
>> what was changed in JavaFX 14 that now suddenly requires a runtime VM 
>> argument, but it's a PITA and BS. End users are going to struggle with this, 
>> and it prevents JavaFX runtime from being purely managed by Maven. No other 
>> JavaFX version requires this, so it's mind boggling that all of a sudden 
>> JavaFX needs this.
>> 
>> 
>> Poor/buggy IDE support is really the big one here. I don't know about other 
>> IDEs but Netbeans DOES NOT provide a project template for creating a JavaFX 
>> application with setup dependencies. Netbeans, when setup with a Maven 
>> project, allows you to select an entire project(pom) rather than the 
>> individual dependencies(jar) which doesn't work. What you search for also 
>> matters: if you search for "JavaFX" you will get the wrong search results. 
>> You need to search for "openjfx" which can be confusing.
>> 
>> 
>> Anyway, yeah, it's a PITA. There is also an issue with Ant based projects 
>> and Netbeans because JavaFX puts its src.zip in a folder that is supposed to 
>> only include the runtime library that has existed for years(literally a 1 
>> line fix too). No one really uses Ant anymore so it's probably not a big 
>> deal now but yeah, getting JavaFX working hasn't been "include and done" 
>> when it could potentially 

Re: Remove JavaFX JPMS enforcement

[Michael Paus]

Hi,
I would just like to add that many of the problems you have cited would 
just vanish if the JPMS
enforcement would be removed from the JDK. There would be no "JavaFX 
requiring absurd
runtime module VM arguments" anymore and the IDE integration would just 
be straight forward.
JavaFX would become just one more dependency whithout the need for any 
special treatment.


I did, however, not say that JavaFX should be de-modularized. For an 
expert user who wants

to use the JPMS nothing would change at all.

Michael

Am 18.04.20 um 12:58 schrieb Ty Young:


On 4/18/20 5:01 AM, Michael Paus wrote:
Getting started with JavaFX is made overly complicated by the fact 
that the use of the
module system is enforced by some code in the JDK. Especially for 
beginners, who just
want to get some small program running, this is almost always a big 
source of frustration.
It is not very good marketing for JavaFX to make these initial steps 
such a pain. If you
need some evidence for this statement, then just follow JavaFX on 
Stackoverflow or similar
sites (and also this mailing list). Almost every day you can read 
frustrated posts from
helpless people who would just like to get some JavaFX project 
running but are failing

because they get lost in the module system jungle.



Speaking as a long time JavaFX user(literally since Java 8), I have 
mostly disagree that the JPMS is hurting JavaFX.



That said, I don't think the frustration is misplaced. What you say is 
true(Netbeans mailing list is fill of JavaFX issues) and the end user 
is *NOT* to be blamed here.



Rather, I think what's to blame is poor documentation, JavaFX 
requiring absurd runtime module VM arguments, and  poor/buggy IDE 
support.



Starting with documentation, JavaFX uses reflection for things like 
TableView(everyone's favorite) and CSS style sheets. While this may be 
obvious for people who are more experienced, those who are not may be 
very confused when they get an onslaught of error messages regarding 
reflection. Better documentation on what requires reflection, why, and 
how to enable it would be useful.



Likewise, the notice about having to include javafx.graphics to the 
runtime module arguments here:



https://openjfx.io/openjfx-docs/#IDE-NetBeans


Apply to Maven as well, but it's under Ant for some reason. I don't 
know what was changed in JavaFX 14 that now suddenly requires a 
runtime VM argument, but it's a PITA and BS. End users are going to 
struggle with this, and it prevents JavaFX runtime from being purely 
managed by Maven. No other JavaFX version requires this, so it's mind 
boggling that all of a sudden JavaFX needs this.



Poor/buggy IDE support is really the big one here. I don't know about 
other IDEs but Netbeans DOES NOT provide a project template for 
creating a JavaFX application with setup dependencies. Netbeans, when 
setup with a Maven project, allows you to select an entire 
project(pom) rather than the individual dependencies(jar) which 
doesn't work. What you search for also matters: if you search for 
"JavaFX" you will get the wrong search results. You need to search for 
"openjfx" which can be confusing.



Anyway, yeah, it's a PITA. There is also an issue with Ant based 
projects and Netbeans because JavaFX puts its src.zip in a folder that 
is supposed to only include the runtime library that has existed for 
years(literally a 1 line fix too). No one really uses Ant anymore so 
it's probably not a big deal now but yeah, getting JavaFX working 
hasn't been "include and done" when it could potentially be that way.

Re: Remove JavaFX JPMS enforcement

[Ty Young]

On 4/18/20 5:01 AM, Michael Paus wrote:
Getting started with JavaFX is made overly complicated by the fact 
that the use of the
module system is enforced by some code in the JDK. Especially for 
beginners, who just
want to get some small program running, this is almost always a big 
source of frustration.
It is not very good marketing for JavaFX to make these initial steps 
such a pain. If you
need some evidence for this statement, then just follow JavaFX on 
Stackoverflow or similar
sites (and also this mailing list). Almost every day you can read 
frustrated posts from
helpless people who would just like to get some JavaFX project running 
but are failing

because they get lost in the module system jungle.



Speaking as a long time JavaFX user(literally since Java 8), I have 
mostly disagree that the JPMS is hurting JavaFX.



That said, I don't think the frustration is misplaced. What you say is 
true(Netbeans mailing list is fill of JavaFX issues) and the end user is 
*NOT* to be blamed here.



Rather, I think what's to blame is poor documentation, JavaFX requiring 
absurd runtime module VM arguments, and  poor/buggy IDE support.



Starting with documentation, JavaFX uses reflection for things like 
TableView(everyone's favorite) and CSS style sheets. While this may be 
obvious for people who are more experienced, those who are not may be 
very confused when they get an onslaught of error messages regarding 
reflection. Better documentation on what requires reflection, why, and 
how to enable it would be useful.



Likewise, the notice about having to include javafx.graphics to the 
runtime module arguments here:



https://openjfx.io/openjfx-docs/#IDE-NetBeans


Apply to Maven as well, but it's under Ant for some reason. I don't know 
what was changed in JavaFX 14 that now suddenly requires a runtime VM 
argument, but it's a PITA and BS. End users are going to struggle with 
this, and it prevents JavaFX runtime from being purely managed by Maven. 
No other JavaFX version requires this, so it's mind boggling that all of 
a sudden JavaFX needs this.



Poor/buggy IDE support is really the big one here. I don't know about 
other IDEs but Netbeans DOES NOT provide a project template for creating 
a JavaFX application with setup dependencies. Netbeans, when setup with 
a Maven project, allows you to select an entire project(pom) rather than 
the individual dependencies(jar) which doesn't work. What you search for 
also matters: if you search for "JavaFX" you will get the wrong search 
results. You need to search for "openjfx" which can be confusing.



Anyway, yeah, it's a PITA. There is also an issue with Ant based 
projects and Netbeans because JavaFX puts its src.zip in a folder that 
is supposed to only include the runtime library that has existed for 
years(literally a 1 line fix too). No one really uses Ant anymore so 
it's probably not a big deal now but yeah, getting JavaFX working hasn't 
been "include and done" when it could potentially be that way.

Remove JavaFX JPMS enforcement

[Michael Paus]

Getting started with JavaFX is made overly complicated by the fact that 
the use of the
module system is enforced by some code in the JDK. Especially for 
beginners, who just
want to get some small program running, this is almost always a big 
source of frustration.
It is not very good marketing for JavaFX to make these initial steps 
such a pain. If you
need some evidence for this statement, then just follow JavaFX on 
Stackoverflow or similar
sites (and also this mailing list). Almost every day you can read 
frustrated posts from
helpless people who would just like to get some JavaFX project running 
but are failing

because they get lost in the module system jungle.

In order to make JavaFX more easily accessible, especially for 
beginners, I'd like to start
a discussion here about the possibility to unconditionally remove the 
JavaFX JPMS
enforcement. IMHO this enforcement is simply not necessary and is just 
the root for a lot
of frustration with JavaFX. It should just be possible to put all the 
JavaFX jars on the
classpath (instead of the module path) like you would do with any other 
external dependency

in a non-modular setup.

With a not very intuitive hack you can circumvent this problem already now.
Just add a line like this to the file which contains your main class 
extending

Application (MyApp).

class MyAppLauncher {public static void main(String[] args) 
{MyApp.main(args);}}


Because of this launcher it is now possible to put all dependencies and 
all JavaFX jars
on the classpath and to completely forget the module system with all its 
intricacies and pitfalls.
But why should people be forced to use such dirty tricks? The better 
alternative would be to just

lift the current constraint.

I am using this trick for a long time now, even on bigger projects, and 
I have never ever
experienced any problem resulting from this. Even in theory I don't know 
anything that
could prevent a formally correct module jar to also work on the 
classpath (which is of
course not true the other way round). Therefore I say that this 
constraint is just not

necessary and only does a lot of damage to JavaFXs reputation.

I'd now like to have some feedback of the community about this.

Michael

Re: [Rev 01] RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set

[Craig Cavanaugh]

On Fri, 17 Apr 2020 10:38:06 GMT, Ajit Ghaisas  wrote:

>> Craig Cavanaugh has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Update unit test for JDK_8129123 to check midpoint of the list
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java
>  line 2097:
> 
>> 2096: first <= index  && index <= last);
>> 2097:
>> 2098: index = LIST_SIZE - 1;
> 
> You have tested first and last index selection.
> It will be nice to have a case where we select index = LIST_SIZE/2

Agreed, mid point test added

-

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

Re: [Rev 01] RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set

[Craig Cavanaugh]

> https://bugs.openjdk.java.net/browse/JDK-8129123
> 
> This pull request fixes JDK-8129123. This bug also effects Windows and Linux 
> platforms.
> Also, I believe JDK-8196037 is a duplicate of this issue.
> 
> I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and 
> Windows 10.
> 
> Thanks!

Craig Cavanaugh has updated the pull request incrementally with one additional 
commit since the last revision:

  Update unit test for JDK_8129123 to check midpoint of the list

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/166/files
  - new: https://git.openjdk.java.net/jfx/pull/166/files/28b25370..0b6683dd

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/166/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/166/webrev.00-01

  Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/166.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/166/head:pull/166

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