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 189988 - Netbeans IDE does not find source files with umlauts in class name
Summary: Netbeans IDE does not find source files with umlauts in class name
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P1 normal (vote)
Assignee: Vladimir Voskresensky
URL:
Keywords: I18N, REGRESSION
Depends on: 181684
Blocks: 187487
  Show dependency tree
 
Reported: 2010-08-30 13:26 UTC by rgarske
Modified: 2011-01-05 14:19 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Testcase, see my reply to Comment #1 (1.60 KB, text/java)
2010-10-14 15:54 UTC, rgarske
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rgarske 2010-08-30 13:26:50 UTC
I have a Java project with source file encoding UTF8, and I used german umlauts, like ä,ö,ü and ther uppercase counterparts in some (not many) classnames. While this is no problem with Java, which finds, compiles and runs these classes flawlessly, it is a big problem with Netbeans. The Netbeans ide does not show the source files (in neither the project nor files tree view) and flags the calls to these classes as error. I can remember working with previous versions of the ide,
(don#t know exactly which version) which didn't havew this problem.
Comment 1 Marian Mirilovic 2010-10-14 12:36:26 UTC
I tried to create some file in the IDE with umlauts and it worked in NB 7.0
Comment 2 rgarske 2010-10-14 15:45:30 UTC
(In reply to comment #1)
> I tried to create some file in the IDE with umlauts and it worked in NB 7.0

Which Version of the IDE did you use exactly? Is is already available for download. I downloaded latest DEV build today and still have the problem.

This is copied from the About page:

Product Version: NetBeans IDE Dev (Build 201010140000)
Java: 1.6.0_21; Java HotSpot(TM) Client VM 17.0-b17
System: Windows XP version 5.1 running on x86; Cp1252; de_DE (nb)
Userdir: C:\Documents and Settings\ingak\.netbeans\dev

I will upload an attachment, ProbenSchlüssel.java, you can try to add this file
to a project (in package "dea_proben.util") and try to import it, see what happens. I can not even open the file in Netbeans using the "Open file..." from the File menue. I can see the file from the browser, but on loading the filename gets misinterpreted by Netbeans (shown as "ProbenSchlürsel.java" and the file does not load.
Comment 3 rgarske 2010-10-14 15:54:28 UTC
Created attachment 102410 [details]
Testcase, see my reply to Comment #1

This file will not be seen as part of the project in Netbeans. You can find it with "Open file..." but you probably can't load it into Netbeans. If you try to import it into another class, it will be flagged as an error. But you can instantiate the class and call its's methods and the project will compile and run with no error. Since I created this File with an earlier Version of Netbeans, that I no longer have, this is an regression. The file should be in utf8 encoding, I hope it will upload that way.
Comment 4 Jaroslav Tulach 2010-11-04 04:54:40 UTC
Looks like masterfs problem. Try to create JavaSE project with following Main.java (and proper dependencies):

public class Main {
    public static void main(String[] args) throws Exception {
        File home = new File(System.getProperty("user.home"));
        for (File f : home.listFiles()) {
            if (f.getName().contains("robe")) {
                System.err.println("f: " + f);
            }
        }
        LocalFileSystem lfs = new LocalFileSystem();
        lfs.setRootDirectory(home);
        enlist(lfs.getRoot(), "localfs: ");
        final FileObject root = FileUtil.toFileObject(home);
        enlist(root, "masterfo: ");
    }

    private static void enlist(final FileObject root, String prefix) {
        for (FileObject fo : root.getChildren()) {
            if (fo.getName().contains("robe")) {
                System.err.println(prefix + fo);
            }
        }
    }

}

If you put the attached file into root directory, you'll get something like:

f: /home/jarda/probecouna.png
f: /home/jarda/ProbenSchlüssel.java
localfs: AbstractFileObject@18a7efd[probecouna.png]
localfs: AbstractFileObject@1971afc[ProbenSchlüssel.java]
masterfo: MasterFileObject[/home/jarda/probecouna.png@16d2633:50ca0c,valid=true]
BUILD SUCCESSFUL (total time: 2 seconds)

For some reason masterfs does not see the file with UTF characters.
Comment 5 Jaroslav Tulach 2010-11-04 05:05:38 UTC
The code

        final Set<FileNaming> cache = (lookupExisting) ? getExisting(false) : getNotExisting(false);
        if (cache.contains(fake)) {
            assert fake.lastEqual != null : "If cache contains the object, we set lastEqual"; // NOI18N
            assert fake.lastEqual.getName().equals(childName) : "childName: " + childName + " equals: " + fake.lastEqual;
            return fake.lastEqual;
        } else {
            return null;
        }

returns null in spite the cache contains the FileName object representing the file with strange character. The fileName.hashCode() is however different for some reason.
Comment 6 Jaroslav Tulach 2010-11-04 05:19:39 UTC
The behavior is regression caused by fix to bug 181684. If I stop using CharSequences, I'll get the proper result:

# This patch file was generated by NetBeans IDE
# It uses platform neutral UTF-8 encoding and \n newlines.
--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -62,7 +62,7 @@
 
     protected FileName(final FileNaming parent, final File file) {
         this.parent = parent;
-        this.name = CharSequences.create(parseName(parent, file));
+        this.name = parseName(parent, file);
         id = NamingFactory.createID(file);
         this.currentName = name;
     }
Comment 7 Vladimir Voskresensky 2010-11-04 07:17:39 UTC
Thanks,
I will fix it
Comment 8 Vladimir Voskresensky 2010-11-04 08:28:38 UTC
test + expensive impl
http://hg.netbeans.org/cnd-main/rev/3d7a991637ce
then reduced optimization to ascii table only to prevent problems with different 8-bit encodings as well
http://hg.netbeans.org/cnd-main/rev/9c6eb954811c
Comment 9 Jesse Glick 2010-11-04 14:20:05 UTC
Maybe P1; should be considered for backport.
Comment 10 Alexander Simon 2010-11-04 15:06:17 UTC
Additional fixes:
http://hg.netbeans.org/cnd-main/rev/295bbd7ce5fc
http://hg.netbeans.org/cnd-main/rev/41da22186fa5
So last change set fix original problem (change 0xFF -> 0xFFL).
Comment 11 Quality Engineering 2010-11-05 03:51:04 UTC
Integrated into 'main-golden', will be available in build *201011050000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/3d7a991637ce
User: Vladimir Voskresensky <vv159170@netbeans.org>
Log: fixed #189988 -  Netbeans IDE does not find source files with umlauts in class name
Comment 12 Jaroslav Tulach 2010-11-05 09:12:41 UTC
True, probably candidate for backport. Btw. 41da22186fa5 looks more systematic than the original attempt to fix this problem.
Comment 13 Vladimir Voskresensky 2010-11-05 09:49:27 UTC
Thanks, Alexander.
I think we should prepare patch from 
http://hg.netbeans.org/cnd-main/rev/41da22186fa5
and backport it.
Comment 14 Marian Mirilovic 2010-12-03 12:46:08 UTC
Vladimir, 
please transplant fix into clone releases / branch release692, see http://wiki.netbeans.org/NetBeansPatchesProcess#How_to_proceed_with_patch for details by Tuesday 7th of December 2010. Thanks in advance.
Comment 15 Egor Ushakov 2010-12-03 13:50:29 UTC
integrated into releases/release692 with:
http://hg.netbeans.org/releases/rev/ae97738cf156
Comment 16 Egor Ushakov 2010-12-03 13:50:49 UTC
do we need to change spec versions?
Comment 17 Marian Mirilovic 2010-12-03 18:39:48 UTC
(In reply to comment #16)
> do we need to change spec versions?

Egor, yes. Please do so. Thanks in advance.
Comment 18 Egor Ushakov 2010-12-06 18:52:26 UTC
spec versions updated in:
http://hg.netbeans.org/releases/rev/2135de304d83
Comment 19 Jesse Glick 2010-12-06 18:55:32 UTC
(In reply to comment #18)
> http://hg.netbeans.org/releases/rev/2135de304d83

The fix was in openide.util. Why did you update spec versions of o.n.core and core.kit, which were untouched? This is unnecessary and should be reverted.
Comment 20 Egor Ushakov 2010-12-06 19:27:53 UTC
Isn't it required to increase spec versions in the whole chain up to kit?
Comment 21 Jesse Glick 2010-12-06 20:05:50 UTC
(In reply to comment #20)
> Isn't it required to increase spec versions in the whole chain up to kit?

No, this was fixed in Plugin Manager in 6.8! See bug #141714.
Comment 22 Egor Ushakov 2010-12-06 20:31:14 UTC
cool!
Reverted unneeded spec updates:
http://hg.netbeans.org/releases/rev/5c899d7999f9
Comment 23 Tomas Danek 2010-12-10 12:49:28 UTC
verified in patch 3, attached file can be part of project, can be edited and is visible in projects view.
Comment 24 Marian Mirilovic 2010-12-14 10:04:01 UTC
NetBeans 6.9/.1 Patch 3 has just been released. Please update your installation to get this issue fixed in your NB installation.