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.
Could NB be changed please so that .class files have a very different icon/badge to the .java files. When source and target directories are the same, the .java & .class files cannot be easily distinguished from each other. On some projects I use a different target directory for compiling and then NB displays a different badge for .class files. Could the icon/badge used when target directory set please be used throughout for .class files. Kind regards Emmanuel
moving to java module
Sorry - I don't understand this. When classes are placed in the same directory as sources (target dir not set), they should not be displayed at all. Class files are "consumed" by their .java siblings' objects so you shouldn't be able to seen them. Can you clarify it a bit ?
Hello Svatopuk, I have several 'calling and worker' classes, each in one .java file. Once these are compiled, several .class files are created from each .java file and these are visible in the explorer filesystem view. These orphaned .class files originated this request. Hope this clarifies my request. Kind regards Emmanuel
Yes, it's clear now. a) the class objects already have different (grayscale) icon than java ones. Class Elements, however, have just the same one. b) the orphaned classes are not recognized as coming from those java sources, otherwise they would be "consumed" underneath them. If you want to enable such recognition, go to Tools -> Options -> Object Types -> Java Sources and turn "Parse class files" on. The IDE will try harder to pair class files with their java counterparts then. The option is off by default, because it slows down processing in the IDE. If b) is what you wanted, then please close the bug, since it is designed to work this way. BTW if you can avoid more than one top-level class in a source, please do so. It's just the same as creating a static inner class and only pollutes package namespace - besides that, tools which are attempting to find a source for such class may fail, because - if they don't parse the .class file - they don't have a clue what it was and eventually slows down compilation.
Hello Svatopuk, Thank you for all your feedback and assistance. It worked as descibed. One further point though, I noticed that this option (and many others) are not available at project level. Is this intended? When I experiment I'd have multiple classes in one .java source file and therefore in such a project I could set the option, whereas in other 'production related' projects I would then have this option off. Please advise. Kind regards Emmanuel
I haven't even thought about having the option varied per-project yet :-) It always seemed more like configuration parameter of the IDE, rather than project thing; we've though about this option in the same way as an installed module, or a recognized extension setting.
It would have added advantages if 'per project'.
Target milestone -> 3.3.1.
Cleaning up before 4.0 planning
Described behavior is as disigned.
Target milestone was changed from not determined to TBD