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: regression - Unable to open java source files when project encoding is set to non UTF-8 encoding | ||
---|---|---|---|
Product: | platform | Reporter: | watanabe-fumika |
Component: | Text | Assignee: | David Strupl <dstrupl> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | Ervis_Tusha, jtulach, masaki, mmirilovic, vv159170 |
Priority: | P1 | Keywords: | I18N, REGRESSION |
Version: | 7.0 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | sample projects with several encoding |
Description
watanabe-fumika
2010-12-16 05:24:56 UTC
Set priority to P2. It's still happen in the latest trunk. Product Version: NetBeans IDE Dev (Build 201101140000) Java: 1.6.0_23; Java HotSpot(TM) Client VM 19.0-b09 System: SunOS version 5.11 running on x86; UTF-8; en (nb) I'm seeing this issue on both Solaris and Windows. 1. Create a Java project with default main.java 2. Set project encoding to UTF-8 3. Close the project and open it again, then open main.java on the editor => works fine. 4. Set project encoding to non UTF-8 encoding e.g. windows-31j, EUC-JP, Big5... 5. Close the project and open it again, then open main.java on the editor => NetBeans shows "The document XXXX.java could not be locaded." on the dialog. The same exception happens in the log file. Created attachment 105020 [details]
sample projects with several encoding
Try to open these projects on the latest trunk, then try to open Java source file.
If possible, please fix it for Beta 2, but this is definitely stopper for FCS. Vladimir, any comment on that? *** Bug 193980 has been marked as a duplicate of this bug. *** David, I will have a look David. looks like we've faced with issue Jan asked about before: "did someone check what will hapen if a multibyte character will span across the first 1024 bytes boundary?" check only buffer with 1024 bytes is not enough. Right approach is to load file completely. Workaround could be to add extra catch for such situations: if (len > 0) { try { decoder.decode(ByteBuffer.wrap(buffer, 0, len)); } catch (CharacterCodingException e) { ERR.log(Level.FINE, "Encoding problem using " + charset, e); // NOI18N return false; } catch (IllegalStateException e) { ERR.log(Level.FINE, "Encoding problem using " + charset, e); // NOI18N if (!e.getMessage().contains("CODING_END")) { return false; } } } I will add the catch now. Ok? The Problem confirmed the correction by build 201102010000. (In reply to comment #10) > The Problem confirmed the correction by build 201102010000. Is there a usage of the comment? |