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.
To reproduce, open https://ndvis.svn.sourceforge.net/svnroot/ndvis/trunk/NDVisCore/src/com/visitrend/ndvis/actions/FitToWindowAction.java in the editor. It is incorrectly marked as erroneous (F9 works to compile). The AP calls processingEnv.getFiler().getResource(StandardLocation.CLASS_PATH, "", "path/to/icon.gif") but this throws an exception even though the referenced icon in fact exists. Inspecting the sources I see two problems: 1. CachingFileManager.getFileForInput calls findFile, which can only return a JavaFileObject, whereas I would expect to get some other kind of FileObject here since this is not a Java class. 2. CachingArchive.getFiles is given a folderName with a leading slash ("/path/to") whereas folders uses non-leading-slash keys ("path/to"). #1 might be a problem for various reasons, but #2 is easily corrected and seems to fix the symptom: diff --git a/java.source/src/org/netbeans/modules/java/source/parsing/CachingArchive.java b/java.source/src/org/netbeans/modules/java/source/parsing/CachingArchive.java --- a/java.source/src/org/netbeans/modules/java/source/parsing/CachingArchive.java +++ b/java.source/src/org/netbeans/modules/java/source/parsing/CachingArchive.java @@ -95,6 +95,10 @@ public Iterable<JavaFileObject> getFiles( String folderName, ClassPath.Entry entry, Set<JavaFileObject.Kind> kinds, JavaFileFilterImplementation filter ) throws IOException { Map<String, Folder> folders = doInit(); Folder files = folders.get( folderName ); + if (files == null && folderName.startsWith("/")) { + folderName = folderName.substring(1); + files = folders.get(folderName); + } if (files == null) { return Collections.<JavaFileObject>emptyList(); }
No sure why #1 should be a problem - Kind.OTHER shall be used for files that are not a Java source code, class file or HTML file. I would personally prefer to solve #2 in the FileObjects.getRelativePath(String, String), where the package name and relative path are appended - when the package name is empty, there is nothing to append and the relative path itself is the result. Tomas, what do you think? Thanks.
Created attachment 107337 [details] Patch for FileObjects Patch I forgot to attach previously.
(In reply to comment #1) > Kind.OTHER shall be used for files that > are not a Java source code, class file or HTML file. OK. Just the API name "JavaFileObject" seemed wrong, but maybe this is working as expected. (In reply to comment #2) > Created an attachment (id=107337) [details] > Patch for FileObjects Looks like a better patch. Did you already test it on my sample case, or do you need me to verify?
>1) whereas I would expect to get some other kind of FileObject here since this is not a Java class The JavaFileObject is a subclass of FileObject. Returning JFO is OK. >2) The patch in to FileObjects.getRelativePath is OK. It prevents '/' to be prepended.
I have tested it on the Jesse's testcase and it seems to work fine: http://hg.netbeans.org/jet-main/rev/451b9268c762 Whether or not this should be transplanted to 7.0 is up to QE: I think that the patch quite safe. I would recommend testing resolution of default-package references. I tested that, and it still seems to work OK, but independent test would be useful.
I agree with integration into release70 after proper verification from us (QE). Jara, please take a look - thanks in advance.
Integrated into 'main-golden', will be available in build *201103290400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/451b9268c762 User: Jan Lahoda <jlahoda@netbeans.org> Log: #197104: making Filer.getResource work correctly when packageName == "".
Verified in the following build: Product Version: NetBeans IDE Dev (Build jet-main-3797-on-20110329) Java: 1.6.0_24; Java HotSpot(TM) Client VM 19.1-b02 System: Linux version 2.6.35-22-generic running on i386; UTF-8; en_US (nb) I agree with integration to 7.0.
Confirmed that it works on my original test case.
Transplated to 7.0: http://hg.netbeans.org/releases/rev/c09c9bf18d7e
Verified in the following nb70 build: Product Version: NetBeans IDE 7.0 RC2 (Build 201103310000) Java: 1.6.0_24; Java HotSpot(TM) Client VM 19.1-b02 System: Windows 7 version 6.1 running on x86; Cp1250; cs_CZ (nb)