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.
Failing test: public void testI18N() throws IOException { TestUtilities.copyStringToFileObject(testFO, "public class Vecernicek {" + "}"); JavaSource javaSource = JavaSource.forFileObject(testFO); javaSource.runUserActionTask(new Task<CompilationController>() { public void run(CompilationController controller) throws IOException { controller.toPhase(JavaSource.Phase.ELEMENTS_RESOLVED); TypeElement typeElement = controller.getElements().getTypeElement("Vecernicek"); assertNotNull(typeElement); } }, true); TestUtilities.copyStringToFileObject(testFO, "public class Večerníček {" + "}"); javaSource = JavaSource.forFileObject(testFO); javaSource.runUserActionTask(new Task<CompilationController>() { public void run(CompilationController controller) throws IOException { controller.toPhase(JavaSource.Phase.ELEMENTS_RESOLVED); TypeElement typeElement = controller.getElements().getTypeElement("Večerníček"); assertNotNull(typeElement); } }, true); }
*** Issue 96927 has been marked as a duplicate of this issue. ***
I cannot fully evaluate the test, as I do not know what exactly does "TestUtilities.copyStringToFileObject", but if it is copy of our TestUtilities.copyStringToFile, it uses always UTF-8. And the file is (as far as can be told from the test case) being read using platform default encoding - unsuprisingly leading into problem with finding the class. I have committed the test into org.netbeans.api.java.source.ElementsTest. It worked for me fine (I use UTF-8 as the default encoding), and I moreover ensured that the file is being read with UTF-8 (I hope - I cannot test it). Could you please try to run the test? Thanks.
Changing to P3 as the original issue 96927 is P3. Your test in java/source is working fine for me, but I have steps to reproduce the problem on Mac: 1. New Java Application 2. New Java Class - name it Večerníček 3. After pressing ok, file is opened in editor for a moment and closed. After reopening there is error annotation saying: 'class Večerníček is public, should be declared in a file named Večerníček.java I also noticed warnings in console from j2ee/metadata: WARNING [org.netbeans.modules.j2ee.metadata.model.api.support.annotation.PersistentObjectManager]: typesAdded: type ElementHandle[kind=CLASS; sigs=javaapplication3.Ve?ern??ek ] has dissapeared WARNING [org.netbeans.modules.j2ee.metadata.model.api.support.annotation.PersistentObjectManager]: typesChanged: type ElementHandle[kind=CLASS; sigs=javaapplication3.Ve?ern??ek ] has dissapeared so I am adding also Andrei on cc.
I spoke about this with Tomas, and he remembers some problem on Mac OS X which caused problems when working with filenames with non-ASCII-7 characters. I will try to find out more, but we may be unable to fix/workaround this.
I used ja chars on Mac for the class name. It was opened ok and chars were shown correctly. Closed/reopened manually - looks ok.
The situation on MacOS X (not sure if it holds also for Japanese version) is quite strange. The sys calls work with UTF-8 encoded strings but the file systems stores them in MacRoman.
am removing incomplete keyword as it seems Martin provided more information. But am confused on how 96927, about multibyte in name of session bean is related to this issue and since this issue is about mac only, but 96927 was not platform specific. And also want to understand about this one to what project and file types it applies to, and what mac locales it might be seen in. Can someone explain about this, and should 96927 be reopened or filed as a new issue based on nb6.0 since original issue was on nb5.x ? ken.frank@sun.com
I have tested this on a Mac, and it seems like a JDK/Mac issue, not NB: -I have file "/tmp/Večerníček" -I have listed files in "/tmp", and checked their names - there is no "Večerníček", only "Vec?erni?c?ek" ('?' probably represent unprintable characters). I double checked that "Večerníček" (10 characters) != "Vec?erni?c?ek" (13 characters). Sorry, but I do not see anything we could do about this. Martin should probably comment on relationship with issue #96927.
could it be related to another comment mentioned here and in relation to feq and encoding The situation on MacOS X (not sure if it holds also for Japanese version) is quite strange. The sys calls work with UTF-8 encoded strings but the file systems stores them in MacRoman. - does it happen both when the project encoding property is both default utf-8 and then another separate project that has macroman as its project encoding property ? ken.frank@sun.com
Yes, the experiment confirms Tomas' comment. I do not think this is related to the FEQ or any encoding inside the IDE - I did the experiment in a plain J2SE project. It looks like the system and the JDK do not understand each other correctly.