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.
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.
I tried to create some file in the IDE with umlauts and it worked in NB 7.0
(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.
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.
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.
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.
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; }
Thanks, I will fix it
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
Maybe P1; should be considered for backport.
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).
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
True, probably candidate for backport. Btw. 41da22186fa5 looks more systematic than the original attempt to fix this problem.
Thanks, Alexander. I think we should prepare patch from http://hg.netbeans.org/cnd-main/rev/41da22186fa5 and backport it.
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.
integrated into releases/release692 with: http://hg.netbeans.org/releases/rev/ae97738cf156
do we need to change spec versions?
(In reply to comment #16) > do we need to change spec versions? Egor, yes. Please do so. Thanks in advance.
spec versions updated in: http://hg.netbeans.org/releases/rev/2135de304d83
(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.
Isn't it required to increase spec versions in the whole chain up to kit?
(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.
cool! Reverted unneeded spec updates: http://hg.netbeans.org/releases/rev/5c899d7999f9
verified in patch 3, attached file can be part of project, can be edited and is visible in projects view.
NetBeans 6.9/.1 Patch 3 has just been released. Please update your installation to get this issue fixed in your NB installation.