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.

Bug 237644 - ClassIndex should support isTypeOf queries
Summary: ClassIndex should support isTypeOf queries
Status: NEW
Alias: None
Product: javafx
Classification: Unclassified
Component: Project (show other bugs)
Version: 7.4
Hardware: PC Linux
: P1 normal with 1 vote (vote)
Assignee: Tomas Zezula
: 240001 241554 250996 (view as bug list)
Depends on:
Reported: 2013-10-25 06:50 UTC by
Modified: 2015-03-09 10:19 UTC (History)
7 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description 2013-10-25 06:50:27 UTC
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...
Comment 1 Roman Svitanic 2013-10-29 15:55:20 UTC
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".
Comment 2 2013-10-31 07:52:00 UTC
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.
Comment 3 Roman Svitanic 2013-10-31 10:22:55 UTC
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.
Comment 4 Roman Svitanic 2013-10-31 10:25:19 UTC
And I have forgotten to mention that after XML modification, saving of modified XML is required to take effect.
Comment 5 2013-10-31 14:52:56 UTC
Indeed it helps a lot.
It also shows probably that the bug correction should not be so far :-)
Tnx Roman!
Comment 6 Roman Svitanic 2013-11-25 15:01:43 UTC
Reassigning to Java Source for evaluation, since ClassIndex#getElements is called for retrieving of suitable classes.
Comment 7 Svata Dedic 2013-12-13 13:15:39 UTC
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.
Comment 8 Roman Svitanic 2014-01-05 15:46:34 UTC
*** Bug 240001 has been marked as a duplicate of this bug. ***
Comment 9 2014-01-19 17:34:08 UTC
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!


[ I understand from your tech comments that solving this may introduce some undesired side effects. Risk management, then... ]
Comment 10 Svata Dedic 2014-01-19 20:20:37 UTC
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 :-/
Comment 11 Tomas Zezula 2014-01-20 09:04:26 UTC
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.
Comment 12 Tomas Zezula 2014-01-20 09:16:07 UTC
If you want feel free to reassign to me, I will fix it.
Comment 13 Roman Svitanic 2014-02-10 08:17:23 UTC
*** Bug 241554 has been marked as a duplicate of this bug. ***
Comment 14 2014-03-28 13:24:25 UTC
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?
Comment 15 Roman Svitanic 2015-03-09 10:19:10 UTC
*** Bug 250996 has been marked as a duplicate of this bug. ***