Community
Participate
Working Groups
My OS's default encoding is GBK, while my java project "HelloWorldPrj"'s encoding is UTF-8 which uses one lib named "terasoluna-thin-server.jar". This lib's source attachment "terasoluna-server4jweb-src_2.0.1.0.zip"'s source code's encoding is Shift-JIS. There is only one way to view this lib's source properly: Windows -> Preferences -> General -> Workspace, set "Text file encoding" to "Shift-JIS". Set either my project, or "terasoluna-thin-server.jar", or "terasoluna-server4jweb-src_2.0.1.0.zip", or all above's property "Text file encoding" to "Shift-JIS" has no effect. How to view all soucre attachement properly when add a soucre attachement's encoding is "Big5"'s lib? Hope this is reported to a right place!
Created attachment 181323 [details] Proposed patch This patch takes care the following scenarios: 1. The source attachment is a Zip file from the workspace. In this scenario, the encoding that is set for the Zip file is used for displaying the source. In the absence of encoding for the ZIP, inherited encoding from the project is used. 2. The source attachment is a source folder from the workspace. Here, the encoding set for the specific source file (java etc.) is used. If there is no encoding set for the individual file explicitly, then the inherited encoding is applied. For instance, if ProjectA uses a folder or a ZIP from ProjectB as a source attachment, then in the absence of encoding for the source file/ZIP, ProjectB's encoding will be used. 3. The source attachment is an external folder or a archive - the encoding used will be that of the project (explicit or inherited) that contains the library concerned. Regressions tests to be added.
Created attachment 181364 [details] Updated patch Same patch with minor changes and tests. The tests need some changes to one of the test projects, which I will be attaching.
Created attachment 181365 [details] Modified test project This ZIP to extracted to \org.eclipse.jdt.core.tests.model\workspace. The project files need to be overwritten.
Srikanth, can you review this for 3.7M3 please?
(In reply to comment #1) 1. and 2. look good but 3. is not OK: the encoding for external libraries must be taken from the workspace because it is not deterministic which project resolves e.g. the rt.jar (the first one wins).
(In reply to comment #5) > (In reply to comment #1) > 1. and 2. look good but 3. is not OK: the encoding for external libraries must > be taken from the workspace because it is not deterministic which project > resolves e.g. the rt.jar (the first one wins). Well, I thought it would allow the user to use a different encoding at a project level, if he/she wants to, for external source attachments. Of course, if it doesn't have to be different, one can simply do nothing, as the inherited encoding from the workspace will be used. With this, we can address scenarios where the user generally wants UTF-8 for the workspace, but one particular external source attachment requires a different encoding, say Shift-JIS. I agree it's unlikely that the user would want to use different encoding in different projects for the same ZIP file. However, the advantage is the user doesn't have to touch the workspace encoding when the external archive is used in only one project. Let me know if I have overlooked something here.
Shared external JARs, like rt.jar, are attached to a single project (its parent). This parent is not guaranteed to be the same all the time and there is no clear indication in the UI which project this is. Therefore it's not possible to use the project encoding for external JARs.
I agree with Dani that the workspace encoding should be used for external source attachments. > With this, we can address scenarios > where the user generally wants UTF-8 for the workspace, but one particular > external source attachment requires a different encoding, say Shift-JIS. In that case, the user can either copy the source into the workspace, or he can create a link to the external source and set the encoding on the link.
Created attachment 181399 [details] Updated patch Agreed on the points raised by Dani and Markus. I have removed the code that looks for the project's encoding. Now, in the case of external resources, the workspace's default encoding is used. Tests have been modified to reflect this.
Looks good to me.
Created attachment 181484 [details] Updated patch Same fix with one more test added as per Srikanth's suggestion.
Released in HEAD for 3.7M3.
This causes JUnit failures in the latest build. Please fix for the next one.
Created attachment 181601 [details] Fixes for tests The failures were caused by weird '\r' in the an archive used by the tests. The tests have been fixed now with this patch.
(In reply to comment #14) > Created an attachment (id=181601) [details] > Fixes for tests > > The failures were caused by weird '\r' in the an archive used by the tests. The > tests have been fixed now with this patch. Between, the tests were all passing on my local machine before commit. Something went wrong with the CVS commit that caused the '\r' problem. Now I am removing all '\r' in the tests themselves in order to have a reliable comparison of sources.
Verified for 3.7M3 using I20101025-1602 (4.1 build)
For external libraries, could it be possible to add an extra attribute to the classpath entry? If not present, use the workspace encoding and if present, use it. This would make it possible to point to external libraries using different encodings.
(In reply to comment #17) > For external libraries, could it be possible to add an extra attribute to the > classpath entry? > If not present, use the workspace encoding and if present, use it. > This would make it possible to point to external libraries using different > encodings. We could do that if someone really reports that the currently solution is not sufficient.
*** Bug 361356 has been marked as a duplicate of this bug. ***
