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.
After fix of issue #120837, the parser uses project encoding to read files while building caches. But, the caches are not updated when the project encoding is changed. The problem is twofold: -the caches do not record the encoding from which they were created, and do not listen on the changes -the provisional patch from issue #120837 asks for encoding for a given source root only once per session
what user cases are affected here ? what problems or errors could happen from user view ? I just want to understand so can add to relnotes or wiki faq if needed and also to see if this should be fixed for nb6, so the feq/encoding functionality is complete ? ken.frank@sun.com
The problem is as follows: -consider a source root containing files encoded in non-system encoding -when a project is created, it uses an encoding - but this may be different from the encoding of the sources -> the Java caches are created incorrectly (due to encoding problems, the files may look like garbage for the parser) -when the user sets the correct encoding in the project, the files can be opened and are presented correctly in the editor, but the Java caches are not updated automatically, which may lead into various problems, like false error reports in the editor, false error badges in the projects tab, incorrect code completion proposals. The workaround is to force Java caches update. The safest way to do this is to stop the IDE after changing the encoding and delete ${userdir}/var/cache/index directory and start the IDE again. I will try to come up with a simpler workaround. The most important difficulty in fixing this is that we will need a textual representation of the encoding used to decode source files in the given source root. Charset.name() cannot be used, AFAIK, as the actual Charset returned from the FEQ is always a ProxyCharset, which name() is not guaranteed to correspond to the name of the actual decoder used to decode the file.
moving opened issues from TM <= 6.1 to TM=Dev
can this/should this be fixed for 6.5 ? ken.frank@sun.com
Not duplicates => not critical. If time permits it can be fixed in NB 6.5 but I am afraid it will need an API change.
Overtake.
can some sample project with some not english/utf8 encoding be attached to the issue (with problems if encoding mismatch with defualt system, i.e. with some special characters).
Reassigning all moonko's java/source bugs to myself.
too old, without any changes and no plan for next 2 releases - WONTFIX