Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Build Identifier: M20090917-0800 I have a workspace with UTF-8 as default encoding. And I have a normal Java project which some string constants using this encoding. When I start the JUnit tests which rely on the correct encoding they are green. But when I convert the project into an AspectJ project and start the JUnit tests again, they fail. Could it be that the AspectJ compiler ignores the encoding settings in the workspace? With Linux this problem does not appear but there the OS enviroment uses UTF-8 as default encoding. Reproducible: Always Steps to Reproduce: 1. Switch the text file encoding in the preferences to "UTF-8" (General > Workspace > Text file encoding) 2. Import the attached Java project 3. Start the JUnit tests (should be ok) 4. Convert to AspectJ Project 5. Start the JUnit tests again (now one test will fail)
Created attachment 148271 [details] Java project with UTF-8 encoding it was originally created under Linux and imported under MacOS-X
*** Bug 254557 has been marked as a duplicate of this bug. ***
Move to the 2.0.2 release.
Try to solve for 2.1.0.
Determining what will be tackled for 2.1.1 release.
I can reproduce this issue with AJDT 2.1.2.e36x-20101113-1400, eclipse 3.6.1 and MacOS X 10.6.5. This issue cause some of our unittests to fail when running them in eclipse. Is there any hope to get this issue fixed in the 2.1.2 release?
Didn't make the 2.1.2 release, but taking a real look now as more users have been hitting this. If we are to properly support encodings specified by the eclipse workspace there are several things we need to do. It is possible to specify a workspace-wide encoding and it is also possible to set encodings on a per-resource basis. This is stored in the project settings. AJC does not have any concept of the eclipse workspace, so it would need to use a callback into AJDT to get the encodings of all files. There are two ways I can see implementing this: 1. before each build, AJC asks AJDT for the default encoding as well as all resources that do not use the default encoding. The benefit of this is that it will likely be more efficient since there is only one callback per project rather than callbacks for each file (especially when most files use the default encoding). 2. Callback for each file when AJC is about to read the file. The benefit here is that it is much simpler to implement. I'll go have a peek at how JDT does this and see if it makes sense for us to do something similar.
Another reasonable possibility is to simply ignore all but the default project encoding. Ie- AJDT passes to AJC the project's encoding only (or the workspace's if the project uses the default encoding). This would obviously mean that users can't specify individual encodings for files, but I think that's a reasonable restriction.
I extended the ICompilerConfiguration to support passing encoding across. Used Olivers test program to check it works. Committed that into AJDT for 3.6 and 3.7. It does not handle per-file encoding.
Committed appropriate fixes into AJDT. Test project now passes. Issue is now fixed.
