This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Assumne we have an abstract class 'afx' extending javafx.application.Application subclass, and several instanciable class extending this abstract 'afx' class. With netbeans 4 it became impossible to run (in any mode) these subclasses. It is also impossible to define them as Application class in the project properties, and thus to package the project. This is not clear: is it a Netbeans 7.4 limitation, or a problem to some new security features of the JDK ? We just know that all worked perfectly with netbeans 7.3.x and JDK 1.7.0.x (x small), but now with netbeans 7.4 and JDK 17.0.45, our work became useless. (This is quite annoying, because we made a lot of work on top of this architecture, and all this seems now unusable!). Thanks for your comments, help, corrections...
This is a known issue and it didn't work in NetBeans 7.3 as well. If you really need to set a class that extends Application class as an project's application class, you can do following as a temporary solution until the fix will be published: 1. In project's properties manually enter FQN of your class in the Application class field. 2. From Files view, open build.xml. 3. In navigator right-click on "jfxsa-run" target and select "Run target".
Ok, Roman, it works with the workaround that you described. However, we think that 7.3 was not showing this bug. And we would be happy to know when the fix will be available, because the workaround is not convenient for frequent use. Tnx, regards.
For more frequent use (until fix will be available), maybe the Ant target shortcut could help: 1. In navigator view for build.xml's ant targets, select "Create Shortcut..." instead of run target. 2. In dialog select "Add a Toolbar Button" and in the next step select "Run" category and enter name for custom button (e.g.: JFX Run) and finish wizard. 3. A button for this custom action is created right to the profile button in toolbar. Click this button. In case of JavaFX it will fail (because imported JavaFX build script jfx-impl.xml), so click on a link in output window which looks like: D:\jet-main\nbbuild\testuserdir\config\Actions\Build\jfx-impl-jfxsa-run.xml:4: The following error occurred while executing this line: Target "-init-project" does not exist in the project "jfx-impl". It is used from target "-check-clean-if-config-changed". 4. It will open XML editor, here replace "jfx-impl.xml" with "build-impl.xml". Now you can run project using this shortcut button. Same can be applied for debug. Hope it will help.
And I have forgotten to mention that after XML modification, saving of modified XML is required to take effect.
Indeed it helps a lot. It also shows probably that the bug correction should not be so far :-) Tnx Roman!
Reassigning to Java Source for evaluation, since ClassIndex#getElements is called for retrieving of suitable classes.
From the 'java.source' module's point of view, the ClassIndex works "as designed", in that it answers queries for immediate predecessors in the class hierarchy. Being able to quickly answer 'is type of' recursively (even for grandparent supertypes) would be nice to have and could be beneficial for other use-cases, too. This change requires thorough analysis because it brings possibly fragile information into the class index: just by reordering the classpath all dependent entries in the class index would have to be evicted or recomputed. Scheduling for the time being & changing to an enhancement. If the current behaviour implies some issues in e.g. FX support code, the JFX support should query the classindex recursively, as it is currently required by classindex design.
*** Bug 240001 has been marked as a duplicate of this bug. ***
Hi Svata I just want to underline that this "enhancement" (?I would rather say "bug") is still quite annoying for the kind of development that we run. Netbeans 7.4 patch 2 does not provide improvement on this (as far as we have seen). Can we expect this problem to be soled in netbeans 8 ? Or is it possible to patch the current version with a suitable correction? Or can we have a date for a planned correction? Best regards - tnx for the works achieved by your team! Philippe [ I understand from your tech comments that solving this may introduce some undesired side effects. Risk management, then... ]
I classified the issue as enh, because the index system was desinged other way, which - while it is very simple - supports many usecases well, and the others are at least possible. I agree that if you take the potential effects into account, absence of recursive isTypeOf pops up as a red flagged defect == an obvious candidate for future evolution. Sadly the implications seems quite big: right now, classindex metadata are not affected by classpath changes (library replacement, reordering etc); the data from individual 'levels' of type hierarchy are joined at runtime at the time of the query. This is not the case if we cache query result in an index - the data for type X needs to be at least invalidated not only when the source for the X itself, but for classes down/up the inheritance tree. This would be a BIG feature if implemented and even bigger if something like 'method override index' (even more tough) or 'method call index' (I don't think it's feasible) could be coded. Given the current backlog of issues, assignments (I am an employee) and time remaining to close 8.0 development, it's not possible (IMHO) to include this feature in 8.0. Experiments from the community are, however welcome; mere code review is a way quicker than thinking the whole complexity out and could be injected into my work queue. Sorry :-/
The ClassIndex does not track transitive dependencies and will never do it, the requirement is WONTFIX from java.source point of view. There are several reasons, here are two most important: 1st) Performance - The CI does is document based which minimise the time for it to be updated. 2nd) Correctness - In case of transitive dependencies it is not only expensive but also impossible to correctly update transitive dependencies regarding closed project, class path changes. The transitive model requires inference based on actual classpath, so it requires Elements model. The CI is lightway and cannot require Elements model. The correct fix is on the jfx side which should not use CI model but Elements model to resolve subtypes as several other IDE feature like refactoring, find usages, navigation are doing. Regarding the comment #10. >This would be a BIG feature if implemented and even bigger if something like 'method >override index' (even more tough) or 'method call index' (I don't think it's feasible) >could be coded. In fact it cannot be done in reasonable performance as classpath roots needs to be self included. One example suppose you open already scanned project which library changed a link in transitive graph, this will require full scan of such a root -> the IDE will nearly always have to do full scan rather than up to date check.
If you want feel free to reassign to me, I will fix it.
*** Bug 241554 has been marked as a duplicate of this bug. ***
Af far as I have seen, Netbeans 8.0 does not bring improvement on this bug (more than enhancement?!). Am I wrong? It is a big disappointment, because it makes generic development of javaFX families of application impossible or at least really not convenient. In our case, we want to develop an animation language based on a subclass of javafx.application.Application . Is there a chance to have it solved? Or should we leave the excellent Netbeans for that reason?
*** Bug 250996 has been marked as a duplicate of this bug. ***