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.
Observed in release31 as of Nov 25 '00. Had a class extending org.apache.tools.ant.Task. Had already successfully generated parser database for Ant library (it is normally in modules classloader, modules/ext/ant.jar - NOT in Filesystems). Asked to override methods, expecting to be offered e.g. execute() from Task, but in Override Methods dialog, only Object had any methods; Task displayed none.
As far as I can tell information from parser database is used only in editor. To see methods from org.apache.tools.ant.Task, ant.jar must be mounted.
Tomas is right, Java module does not see Editor's parser database at all (which is a pity anyway, we would be able to provide at least some cross-referencing support :-( )
Is it not a bug that the Task class was not recognized and its methods displayed? As I said, it was present in the modules classloader--shouldn't that suffice, even if not in Filesystems? E.g. ClassElement.forName hopefully would have parsed it.
It should, sorry - at least with Clazz module using reflection APIs. We'll evaluate the bug again.
Jesse, I think we have another classpath problem. The implementation of class lookup is implemented in openide, which does not (and should not) use execution class loader; the problem is that openide even does not find a class so it cannot be passed to the class module to inspect & produce hierarchy data.
ClassElement.java line 985 calls Class.forName(name)--should it be e.g. Class.forName(name,true,TopManager.getDefault().systemClassLoader())? I don't see what problem there would be with that...
The problem is roughly the same as having NB modules on compiler's classpath -- the parser should not (IMHO) be allowed to see module classes unless it is (somehow) configured so.
It is an analogous question, although little harm is done if the IDE finds a class in its own module list that you did not really care about--at worst, the Inherit dialog works, or something like this. Compared to the compiler, where someone's application could be screwed up because they did not realize what they were compiling against.
Done; ClassElement.forName() is now using TopManager.systemClassLoader() to locate the Class object.
[010221_2] Bug still lives
Version: 'Dev' -> 3.2
It should work now - ClassElement.forName() uses TopManager.currentClassLoader(), so it should be able to find all classes in installed modules, at least.
[release32-20] Verified
Target milestone -> 3.2
Resolved for 3.4.x or earlier, no new info since then -> closing.