Bug ID: JDK-8122052 [Regression] As of b115 ListView of SceneBuilder Import dialog is broken

Type: Bug
Component: javafx
Sub-Component: controls
Affected Version: 8

Priority: P2
Status: Resolved
Resolution: Not an Issue

Submitted: 2013-11-15
Updated: 2015-06-17
Resolved: 2013-11-21

JDK 8
8Resolved

See attached snapshots, same SceneBuilder code over FX 8 b114 and b115.
The content of the ListView is not visible with 115 (nor with 116).

The callback as defined below is not called using b115, it is with b114:

                    final Callback<ImportRow, ObservableValue<Boolean>> importRequired
                            = new Callback<ImportRow, ObservableValue<Boolean>>() {
                                @Override
                                public BooleanProperty call(ImportRow row) {
                                    System.out.println("CALLED");
                                    return row.importRequired();
                                }
                            };
                    importList.setCellFactory(CheckBoxListCell.forListView(importRequired));

This part of the SceneBuilder code is quite isolated from the rest and didn't evolve at all for weeks now.
I spent a given amount of time writing from scratch an app to isolate the issue, without success.

Done: RT-34472
25-11-2013
Can you file a follow-on Tweak then?
22-11-2013
I agree, it's definitely just a nice-to-have warning/error report at compile-time to prevent developer bugs.
22-11-2013
Seems risky for FX 8. Since this is just to prevent future problems it seems that it could be done early in an update release, right?
22-11-2013
Shouldn't be hard to implement it. However, I don't know how hard is to adjust the build system so something can be added to META-INF/services
22-11-2013
If the new annotation processor is safe and easy, I would support that. This was a subtle issue. Do we know, has the behaviour changed since 2.2?
22-11-2013
We could add an annotation processor that would report an error at compile time if an @FXML annotation is used incorrectly.
22-11-2013
Glad this is solved. Wow. The final thing seems quite bad and something that might easily kill people in future. Thoughts? Did this used to "work" for 2.2 and now we have changed it for 8.0?
21-11-2013
I confirm removal of the final modifier did the trick. Thanks a lot.
21-11-2013
I narrowed it down to a single "if" clause that checks if the controller fields is not "final". We don't inject to final fields since this is generally a bad idea to do. A JIT optimization might rely on the fact that the fields is final for example. To fix the issue, remove final modifier from controller fields.
21-11-2013
I verified that it's due to RT-23622. Trying to find what part of the code is the cause.
21-11-2013
Adding extra snapshots: for both I run over FX 8 b114 + scrum 1921. The noCSS one is a try where all CSS defined for the ListView is commented out. The bgcolorCSS one is a try where I set chartreuse color for the background of the listview: .list-view { -fx-background-color: chartreuse; } Adding to CSS file a bg color for cell doesn't have a visible impact: .list-view { -fx-background-color: chartreuse; } .list-cell { -fx-background-color: pink; }
21-11-2013
The current likely culprits are now down to RT-23622 and RT-33984. Given this, and the current position of the sun, I've added Martin as a watcher to this issue, and would appreciate if he can take a look today or at least drive this for a few hours until I get back into work tomorrow.
21-11-2013
You found the proper way for doing an import: simply in place of selecting an FXML file select a jar containing custom controls (something like jfxtras is perfect). Or you can simply drag the jar from native file browser and drop it directly onto the Library panel.
21-11-2013
I cloned Scene Builder 2.0, but unfortunately I don't know how to bring up the import dialog. The only mention of the term 'import' that I can find is in the menu that appears when clicking on the arrow to the right of the 'Library' area (it says "Import JAR/FXML File"). However, this just opens a file chooser dialog, and selecting an FXML file doesn't seem to bring up the dialog either. Can you clarify how I should bring this dialog up?
21-11-2013
Thanks for the screenshots. From looking at them it's unfortunately not possible to say whether the ListView is being rendered at all or not, as it appears custom CSS is being used to set a gray background. Are you able to change the listView CSS so that it is a different colour to clarify whether the ListView is being rendered (but empty), or whether it is not being rendered at all? From looking through the changes that happened between b114 and b115, my feeling is that the issue is likely related to one of the following eight changes (some are more likely than others based on gut feel, so I've ordered in terms of their likelihood from most likely to least likely): RT-31123 http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6054bd8a3a5a (Change to handle TreeTableView issue in VirtualFlow) RT-33949 http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/853673edfc9f (Change to fix scroll bar thumbs in VirtualFlow on touch interfaces) RT-32009 http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/004595ed0b8f (Change to GridPane code - you said in an earlier revision of the description you are using GridPane, correct?) RT-33947 http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b9b072992e27 (Change to how CSS styles are applied) RT-28692 http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ed14640dd11c (Another big CSS change) RT-32704 http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/76c7f1bbfbd3 (Change to layout code for horizontal and vertical bias) RT-33028 http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6af0f4099136 (Scene repainting issue with dirty opts - have you tried running Scene Builder with dirty opts disabled?) RT-33984 http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a630648b31c2 (Change to PopupWindow to only apply CSS when the owner scene is not null) As we get nearer the bottom of this list the likelihood that it is the cause of the regression becomes less and less likely, so for now we'll focus on the first few changes. What I'll do now is try to spin up some intermediate builds that you can use to test with.
20-11-2013
I will look into this further today and may bring Martin into it this evening if necessary.
20-11-2013
Simon says: "We believe this is a regression occuring inb115, which we did not notice right away because we had pretty much skipped b155 since it had other blockers for us. We noticed the problem in b116 and tracked it back to b115. We have tried to work around the problem with no luck. We have spent some time trying to reproduce on a simple test case, but did not succeed. We are at a point where I think further investigation of which platform change might have caused the regression is needed. Luckily there is no API change impacting us between b114 and now, so we can pretty easily test any custom build if that can help narrowing down the problem -- to a certain extent, SB should be considered a test case and we can assist here." Jonathan, this is bad for SB. We need to debug this with them. Perhaps Martin can engage?
20-11-2013
I've rephrased the issue and added snapshots to make it clearer. I already spent a significant time to construct a small app with no success and I won't rewite the whole SceneBuilder. On your side did you list all FX changes in the arena made precisely in b115 ? I can help by trying some ad-hoc FX b115 where one or more fixes would be stripped out in order to dig out the root cause.
20-11-2013
Please reopen if you can still reproduce the issue and can provide further information / a test case.
19-11-2013
I am unable to reproduce this issue, and from the comments it sounds like even in your testing you can't easily reproduce it either. Are you able to provide further information and / or a test case that may shed more light onto this issue?
17-11-2013