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 197104

Summary:	Filer.getResource(CLASS_PATH, ...) does not work on JAR entry from inside AP
Product:	java	Reporter:	Jesse Glick <jglick>
Component:	Source	Assignee:	Jan Lahoda <jlahoda>
Status:	VERIFIED FIXED
Severity:	normal	CC:	geertjan, juhrik, mmirilovic, tzezula
Priority:	P2
Version:	7.0
Hardware:	PC
OS:	Linux
Issue Type:	DEFECT	Exception Reporter:
Bug Depends on:
Bug Blocks:	196933
Attachments:	Patch for FileObjects

Description Jesse Glick 2011-03-25 20:33:32 UTC

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();
         }

Comment 1 Jan Lahoda 2011-03-26 21:44:18 UTC

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.

Comment 2 Jan Lahoda 2011-03-28 14:25:59 UTC

Created attachment 107337 [details]
Patch for FileObjects

Patch I forgot to attach previously.

Comment 3 Jesse Glick 2011-03-28 14:47:52 UTC

(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?

Comment 4 Tomas Zezula 2011-03-28 15:03:43 UTC

>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.

Comment 5 Jan Lahoda 2011-03-28 17:26:55 UTC

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.

Comment 6 Marian Mirilovic 2011-03-29 00:48:15 UTC

I agree with integration into release70 after proper verification from us (QE). Jara, please take a look - thanks in advance.

Comment 7 Quality Engineering 2011-03-29 08:43:50 UTC

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 == "".

Comment 8 Jaromir Uhrik 2011-03-29 16:43:34 UTC

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.

Comment 9 Jesse Glick 2011-03-29 17:18:53 UTC

Confirmed that it works on my original test case.

Comment 10 Jan Lahoda 2011-03-30 05:00:00 UTC

Transplated to 7.0:
http://hg.netbeans.org/releases/rev/c09c9bf18d7e

Comment 11 Jaromir Uhrik 2011-03-31 13:43:14 UTC

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)