Community
Participate
Working Groups
RC2 1. have this folder structure: src // src folder |- encoding // package - encoding set to UTF-8 |- LATIN1Class.java // java source file, encoding: ISO-8859-1 (Latin1) Containing this code: ==================== package encoding; public class LATIN1Class { /* (non-Javadoc) * @see java.lang.Object#toString() */ public String toString ( ) { // TODO Auto-generated method stub return "הצ�: " + הצ�(); } /** * @return */ private String הצ� ( ) { // TODO Auto-generated method stub return "הצ�"; } } =========================== 2. Refactor -> Rename the class to LATIN1Class2 Expected: class is renamed, keeps encoding ISO-8859-1, file content the same but for the class name Actual: class is renamed, keeps encoding ISO-8859-1, file content changed to UTF-8 encoding. Note: - When Refactor->Copying a class the file gets properly copied and saved in the folder's encoding (UTF-8). - Rename is probably a special case of 'Move': a new file is created, with the inherited encoding. When renaming, the encoding should be kept.
JDT/UI calls ICompilationUnit.rename to do the actual rename. Moving to JDT/Core. Refactor->Copy uses a different change. So this isn't related.
I cannot reproduce your problem... My experience is that reftacor->rename is ok but problem occurs while copying the class... Here's the fully described scenario for Linux-GTK: 1- Create project b66898 2- Create package encoding 3- Add following line to org.eclipse.core.resources.prefs file in .settings directory using Resource perspective: "encoding//encoding=ISO-8859-1" 4- Outside eclipse, copy existing LATIN1Class.java to <wksp dir>/b66898/encoding 5- Refresh project => class is displayed in package explorer 6- Edit file => I can see הצ�'s and class has no error (encoding for this file: "Default (inherited from container: ISO-8859-1)") 7- Refactor->Rename class to "Test" => class is renamed and still have no error! 8- Copy class and paste to "CopyOfTest" => I cannot see הצ�'s in CopyOfTest and class has 3 compile errors (one on each הצ�...) Back to JDT/UI as problem is located while writing file and JDT/Core does not write source file (only .class)... Note that similar problem occurs also on WinXP, you just have to change specific and default encodings...
The steps in comment 2 describe a different setting: a Latin1 file within a Latin1 folder. Comment 0 says that the folder has UTF-8 encoding, but the file's encoding set to Latin1. Renaming then picks up the container's encoding instead of keeping the original one.
Frederic, the copy case is covered by the bug 66479. JDT/Core does write source files. The method ICompilationUnit#rename changes the class name inside the CU as well (e.g. changes "class LATIN1Class" two "class LATIN2Class") and updates constructor names if there are any. I double checked and JDT/UI isn't touching the content of the file in this scenario. May be bug 66480 can give some more insights. The problem seems to be different on Sun and IBM VM. I tested this using IBM VM java version "1.4.1" J9 - VM for the Java(TM) platform (build 2.1) IBM J9SE VM (build 2.1, J2RE 1.4.1 IBM J9 build 20040510 (JIT enabled)) Moving back to JDT/Core to invetigate if the class name & constructor update can caused the problem.
Dirk, You're right. For rename and move the problem comes from JDT/Core... We're losing encoding while executing RenameResourceElementsOperation...
Created attachment 12191 [details] Fix for both move and rename issue
I see we were using the target encoding instead of the source one.
Dirk approved fixing it for RC3. Change reviewed, pls release it for integration.
Fixed. Now rename and move operation keep file encoding. [jdt-core-internal] Change done in method processCompilationUnitResource(ICompilationUnit, IPackageFragment) of CopyResourceElementsOperation. Test case added to EncodingTests
We should undo this fix once bug 67606 is addressed.
Reopen as we still need to do something here for 3.0: 1) Undo fix if bug 67606 is fixed 2) explicitely set encoding for destination file if bug is not fixed
Warning, in case of 2), we had to use getCharset(false) in order to know whether source file has a specific encoding (returned value would be not null) and then set charset only in this case...
We should also check that the charset is available then immediately for further queries in subsequent actions of batched operation. Imagine that someone has wrapped in a runnable a copy operation (now made consistent) and a file read, would the copied resource read ok ? i.e. would the charset we hammered be taken into account at this stage, or is its update also queued until notification has occurred ?
We should release the full workaround, and may reconsider it for a subsequent service release, when platform issue is solved. Please enter a separate defect for remembering to reconsider it, and make this new one dependent on platform bug.
I've opened bug 67823 to address bug 67606 dependency...
Created attachment 12488 [details] Complete workaround for this problem 1) Get encoding from source file using getCharset(false) => is null if no specific encoding was set on file. 2) Set encoding on destination file only if there's one specific on source file 3) Back to initial implementation: get encoding from destination file and write contents using this encoding As 1)+2) is done before 3), we're sure that destination file encoding will be ok. Furthermore, it will be easier to remove it (ie. fix bug 67823) when bug 67606 will be fixed...
Created attachment 12490 [details] Additional test added to EncodingTests This additional test verify that setCharset is applied immediately by executing copy/move/rename operations in a runnable...
Reviewed change. Pls release.
Fixed and released in HEAD.
*** Bug 110576 has been marked as a duplicate of this bug. ***
