Forum Stats

  • 3,837,110 Users
  • 2,262,228 Discussions
  • 7,900,205 Comments

Discussions

JavaFX TableView Issues Moving from Swing

digidan
digidan Member Posts: 2
edited Apr 28, 2017 4:14AM in JavaFX 2.0 and Later

We are currently migrating a swing application to JavaFX. The application makes heavy use of TableViews. We have 17 table views that are updated constantly many times a second each.

Users can scroll, and select as the table views are being updated.

In JavaFX we have the following blockers:

  1. Very slow ui behaviour when these tables are being updated. We have had to slow down the rate of updates to the table views as otherwise the whole ui slows to a crawl.
  2. Single Cell selection flickers every time a row is added to a table view which looks very unprofessional - http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8177945
  3. If you scroll down a table view and let go of the mouse, every additional row to the table view causes the table to scroll slightly. This makes the table view appear as if it is slowly scrolling when new rows are being added when it should be completely still. http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8178297
  4. The JavaFX table view does not provide the drag selection behaviour of the swing table view out of the box.

We have been forced to use a java agent with a ClassFileTransformer to intercept class loading to replace the VirtualFlow class with our modified version but this is less than ideal.

More details to the above bullet points:

  1. It seems that JavaFX calls layoutChildren every time a row is added, whether that row is within the view port or not which seems excessive when you have multiple table views being dynamically updated.
  2. We have raised a bug but has been given very low priority P3 targeted for v10 so don’t imagine this being fixed quickly. We have temporarily fixed this by doing a Toolkit.getToolkit().firePulse(); at the end of VirtualFlow.layoutChildren.
  3. We have raised a bug but has been given very low priority P3 targeted for v10 so don’t imagine this being fixed quickly. This seems to be caused by the code in VirtualFlow starting at 1159 where the function adjustPixelAmount is being called with floating point values. Take a look at the firstCellOffset and viewportTopToCellTop double variables. We have temporarily fixed this by rounding these values to integers.
  4. Our customers are used to being able to drag square selections in table views and to extend these selections by dragging outside of the boundary of the tableView. We have tried to implement a similar but incomplete behaviour by overriding TableColumn cellFactories and intercepting dragEntered events for table cells. But it is near impossible to mirror the dragging outside of the table view to extend the selection behaviour of the Swing table view.

My questions are:

Are these issues likely to be fixed? it doesn’t seem that JavaFX TableViews have been tested with tables that are being dynamically updated.

Is there a better way to patch issue 2 and 3 other than replacing the VirtualFlow class at class load time using a Java Agent?

Thanks

Danny

Answers

  • jsmith
    jsmith Member Posts: 2,856
    edited Apr 26, 2017 12:43PM

    The following are just my opinions and hold little value.  I am not associated with Oracle.

    > Are these issues likely to be fixed?

    Perhaps.  If you want to be sure you should get in touch with Jonathan Giles, the lead controls developer and see what you can do to get it prioritized.  To get any prioritized work done which assists you quicker than the standard Java 10 delivery timeframe may require some kind of support contract with Oracle, I don't know, but I'm sure somebody at Oracle could help you if you asked through the appropriate channel (I don't know what that is, this Oracle JavaFX forum is not it).  You can try doing the work yourself with patches to the JDK as you have been attempting thus far, but, as you have discovered, a home-built the route for this kind of stuff, is not easy.

    > It doesn’t seem that JavaFX TableViews have been tested with tables that are being dynamically updated.

    I'm sure it's been tested.  But probably not to the extent which exhibits the issues as much as your particular use-case.  I've added and removed rows to TableViews and not really noticed any severe issues, but I probably don't do it as often as you are doing.  So the testing, as far as it went, probably deemed the current implementation good enough.

    > Is there a better way to patch issue 2 and 3 other than replacing the VirtualFlow class at class load time using a Java Agent?

    Wow, that is such an ugly way to patch, I have never heard of anybody doing that before.  Depending on how your app is bundled, you might have other options.

    1. For instance if it is a self-contained application, then you could run a post-install script which replaces the jfxrt.jar with a custom built jar which you create that includes your patched VirtualFlow implementation OR

    2. JavaFX loads from the <span class="pun" style="color: #303336;"><</span><span class="pln" style="color: #303336;">JRE_HOME</span><span class="pun" style="color: #303336;">>/</span><span class="pln" style="color: #303336;">lib</span><span class="pun" style="color: #303336;">/</span><span class="pln" style="color: #303336;">ext</span><span class="pun" style="color: #303336;">/</span><span class="pln" style="color: #303336;">jfxrt</span><span class="pun" style="color: #303336;">.</span><span class="pln" style="color: #303336;">jar</span> which places it on the Java bootclasspath.  If you can get your patch classes ahead of the jfxrt.jar in the boot class path loading, then the JVM should load them instead of the ones in jfxrt.jar.  The might be done by placing a patch jar called apatch.jar on the lib/ext directory (I think this will work because as far as I know Java loads jar files from this directory alphabetically).  Alternatively using a java runtime command line switch to add your patches to the bootclasspath might work if the java launcher loads them before jfxrt.jar.  This will only work if you know exactly the version or the JRE you are running with (for example when you create a self-contained application).

    Just some thoughts or you could just keep on doing the strange thing you are doing with the Java Agent.

    If you want to get in touch with the developers and the rest of the JavaFX team, try the openjfx-dev mailing list:

    openjfx-dev Info Page

  • bouye-JavaNet
    bouye-JavaNet Member Posts: 394 Silver Badge
    edited Apr 26, 2017 5:36PM

    Fixes will certainly not come to JDK9 (initial release) as everything appears to be currently frozen in preparation for the last phase before release in July. After that, their priority is JDK10 developments + backports for JDK9 post-release updates. It also quite likely that backports to JDK8 will not be a priority anymore (or may even be completely dropped).

    As said by jsmith only paying customers with a maintenance contracts with Oracle get priority treatment and even those sometimes have to wait for several years/major releases for some bugs to be fixed (judging the initial submit date found on the bug tracking system for some of the things fixed in JDK9).

  • digidan
    digidan Member Posts: 2
    edited Apr 28, 2017 4:14AM

    Thanks for the reply and the suggestion to get in contact with Jonathan Giles. I did send him an email and he was very helpful with his reply. He mirrored your comments regarding the Java 10 delivery time frame.

    Thanks also for your alternative suggestions for patching in the file.

    Danny

This discussion has been closed.