Bug 197104 - Filer.getResource(CLASS_PATH, ...) does not work on JAR entry from inside AP
Filer.getResource(CLASS_PATH, ...) does not work on JAR entry from inside AP
Status: VERIFIED FIXED
Product: java
Classification: Unclassified
Component: Source
7.0
PC Linux
: P2 (vote)
: 7.0
Assigned To: Jan Lahoda
issues@java
: 70_HR_FIX
Depends on:
Blocks: 196933
  Show dependency treegraph
 
Reported: 2011-03-25 20:33 UTC by Jesse Glick
Modified: 2011-03-31 13:43 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Patch for FileObjects (660 bytes, patch)
2011-03-28 14:25 UTC, Jan Lahoda
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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)


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo