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.
Summary: | I18N - Rebuild Java caches when project encoding changes | ||
---|---|---|---|
Product: | java | Reporter: | Jan Lahoda <jlahoda> |
Component: | Source | Assignee: | Jan Lahoda <jlahoda> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | kfrank, mmirilovic, tzezula |
Priority: | P3 | Keywords: | I18N |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Jan Lahoda
2007-11-12 13:04:49 UTC
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 |