Character encoding annoyance - eclipse

I am suddenly getting a character encoding error when trying to run ant build-all. I have been in the properties for my project, and choose UTF-8 under resource. Still I'm getting the following error (actually there are more than 100 encoding errors) when trying to build-all:
error: unmappable character for encoding UTF8
[javac] // nedenfor inden f�rste angreb, s� total = 41 = tur 21
I cannot commit my project because of this error. Any idea how to fix this? And it just all of a sudden started complaining about encoding

Sounds like you need to specify the encoding argument on your Ant javac task:
<javac encoding="UTF-8" ...
Ant tasks do not know about Eclipse project properties.

Related

Netbeans Ant build.compiler.emacs

The default ant settings in Netbeans has the property build.compiler.emacs set to true. What does this mean? The ant documentation just says
Enable emacs-compatible error messages.
I understand emacs is an editor, though I have not used it. What is the effect of setting this property to true or false?
You might not have noticed that that part of the ant documentation describing the javac task is in the "Jikes notes". It's a setting that modifies the result message format of a compilation while using the jikes compiler in a way that when ant is invoked by the Emacs editor (e.g. while using the JDEE environment), the editor can parse the result messages and jump at correct positions in the files related to the messages.
It is indeed a bit weird that NB includes such a setting for a compiler that is not the standard one and seems abandoned for almost a decade.
Given the following ant build.xml file
<project name="mini" basedir="." default="compile">
<property name="build.compiler.emacs" value="off"/>
<property name="build.compiler" value="jikes"/><!-- invoke jikes instead of javac-->
<target name="compile">
<javac srcdir="." destdir="" classpath="." includeantruntime="false">
</javac>
</target>
</project>
The compilation of a simple class comporting a syntax error gives that output:
Buildfile: /Users/seb/projets/java/ant/build.xml
compile:
[javac] Compiling 1 source file to /Users/seb/projets/java/ant
[javac]
[javac] Found 1 semantic error compiling "Hello.java":
[javac]
[javac] 5. System.out.println("Hello, World!"+foo);
[javac] ^-^
[javac] *** Semantic Error: No accessible field named "foo" was found in type "Hello".
BUILD FAILED
/Users/seb/projets/java/ant/build.xml:5: Compile failed; see the compiler error output for details.
Total time: 1 second
While you have this output by changing build.compiler.emacs property to on:
Buildfile: /Users/seb/projets/java/ant/build.xml
compile:
[javac] Compiling 1 source file to /Users/seb/projets/java/ant
[javac] Hello.java:5:52:5:54: Semantic Error: No accessible field named "foo" was found in type "Hello".
BUILD FAILED
/Users/seb/projets/java/ant/build.xml:5: Compile failed; see the compiler error output for details.
Total time: 1 second
In the latter version, the messages are less fancy and Emacs is more capable of parsing them.

Can't make Ant write proper version info with unicode (c) character

After upgrading ant from 1.6 to 1.8.3 version info resources of Windows .dlls that are built with Ant became corrupted.
Previously this value was properly saved to the version-info resource:
product.copyright=\u00a9 Copyright 20xx-20xx yyyyyyyyyy \u2122 (so (c) and TM symbols were properly displayed).
After upgrading Ant default encoding was changed to UTF-8 which is expected, but currently Copyright string looks like this:
© Copyright 20xx-20xx yyyyyy ™
This is not a console issue - I checked with hex editor and File Properties dialog - both display it incorrectly.
Looking at file's hexdump I see that following (obviously incorrect) mapping occurs
\u00a9 -> 0x00c2 0x00a9
\u2122 -> 0x00e2 0x201e 0x00a2
The problem here is that Ant encodes UTF-8 bytes (not Unicode string) into 16-bit characters and writes it to version-info.
Although this looks like a bug in ant, I would ask if anyone managed to find any workarounds for this or similar problems.
Here are some snippets from the script:
Project properties file:
...
product.copyright=(c) Copyright 2005-2012 Clarabridge
....
Files included into build.xml:
<versioninfo id="current-version" if="is-windows"
fileversion="${product.version}"
productversion="${product.version}"
compatibilityversion="1"
legalcopyright="${product.copyright}"
companyname="${product.company}"
filedescription="${ant.project.name}"
productname="${ant.project.name}"
/>
...
<cc objdir="${target.dir}/${target.platform}/obj"
outfile="${target.dir}/${target.platform}/${ant.project.name}"
subsystem="other"
failonerror="true"
incremental="false"
outtype="shared"
runtime="dynamic"
>
<versioninfo refid="current-version" />
<compiler refid="compiler-shared-${target.platform}" />
<compiler refid="rc-compiler" />
<linker extends="linker-${target.platform}">
<libset dir="${target.dir}/${target.platform}/lib" libs="${lib.list}" />
</linker>
<fileset dir="${src.dir}" casesensitive="false">
<include name="*.cpp"/>
</fileset>
</cc>
Your bug is that something is misinterpreting the UTF-8 characters as 8-bit ones!!!
BTW, Java doesn’t use 16-bit characters; that would be UCS-2. Java uses UTF-16, which is just as much a variable-width encoding as UTF-8 is. Distressing how many Java programmers screw this up!
UTF-8 has 8-bit code units where UTF-16 has 16-bit code units; neither one supports an “8-bit character” or a “16-bit character”. If you catch yourself writing code that thinks they do, you’ve just written buggy code.
Your output is the result of erroneously displaying UTF-8 as though it were in Latin1, which does use 8-bit characters. You, however, do not.

ANT Javac and special characters

I have an ANT task defined like so:
<javac source="1.5" target="1.5" srcdir="${src.dir}" destdir="${classes.dir}" deprecation="on" debug="on" classpathref="classpath" fork="true" memoryMaximumSize="512m" encoding="UTF-8">
<include name="${app.directory}/**/*.java"/>
</javac>
This works fine, but when I have classes with special characters in their names it gives me the following error:
[iosession] Compiling 131 source files to /C24/PUB/io-stds/trunk/standards/GSIT/build/test/deployment/build/classes
[iosession] javac: file not found: /C24/PUB/io-stds/trunk/standards/GSIT/build/test/deployment/src/java/biz/c24/io/minos/AléaChiffréClass.java
[iosession] Usage: javac <options> <source files>
[iosession] use -help for a list of possible options
[iosession] Target compile finished
[iosession]
[iosession] Building unsuccessful 2 seconds
When I remove the "fork=true" it works, but then it ignores the "memoryMaximumSize" setting. I also tried the nested approach, but to no avail.
Any ideas?
It's perhaps not the answer you expect but my advice would be to remove all non-ascii letters from the names of methods and classes. I'm French-speaking too, and I've never seen any company, even in France and using French as its development language, accept accented letters in class names and methods. It's just not good practice, simply because it would be very hard for a non French developer, without accents on his keyboard, to use these classes and methods.
If you use a good IDE, it should allow you to refactor your code easily.
Apache did confirm that the encoding attribute only applies to the file contents and not file names. I reverted back to using fork only when needed and kept encoding="UTF-8".

Error while connecting Eclipse IDE to run the Flex 4.5.1 SDK

I want to run the Flex SDK 4.5.1 on Eclipse IDE. I have followed this http://www.seanhsmith.com/2010/03/29/flex-for-free-setting-up-the-flex-4-sdk-with-eclipse-ide/
step by step and it was same as it was written.
But then when i first built my sample code and ran it, it gave me these errors. I cant figure out what the problem is:
This is the sample code:
and these are the ERRORS:
Loading configuration file C:\Mario's Files\STF\Flex SDK\flex_sdk_4.5.1.21328\frameworks\flex-config.xml
_application_Styles.as(24): col: 38 Error: Syntax error: expecting rightparen before s.
[Embed(_resolvedSource='C:/Mario's Files/STF/Flex SDK/flex_sdk_4.5.1.21328/frameworks/libs/framework.swc$Assets.swf', symbol='mx.skins.cursor.BusyCursor', source='C:/Mario's Files/STF/Flex SDK/flex_sdk_4.5.1.21328/frameworks/libs/framework.swc$Assets.swf', original='Assets.swf', _line='194', _pathsep='true', _file='C:/Mario's Files/STF/Flex SDK/flex_sdk_4.5.1.21328/frameworks/libs/framework.swc$defaults.css')]
^
Any solutions?
Do we have to get a compatible Eclipse-FlexSDK-Flash version??
The ' in "Mario's Files" throws off the parser, because it assumes the path ends there. Your folder names should not have a ' in it, ever. Call the folder "Marios Files" and you're fine.
Read up on String delimiters and escape characters, it's knowledge you will need anyway at some point.
This question might also be off-topic.

Eclipse: infinitest vs. JUnit: character encoding

I'm using infinitest in Eclipse and I have a strange phenomenon in connection with JUnit.
I have code that uses org.apache.http.HttpResponse.getEntity() and org.apache.http.entity.StringEntity. The JUnit test looks like this:
#Test
public void convertEncodedContentToString() throws UnsupportedEncodingException {
HttpResponse httpResponseMock = Mockito.mock(HttpResponse.class);
Mockito.when(httpResponseMock.getEntity()).thenReturn(new StringEntity("huiäöüß#€", HTTP.UTF_8));
Assert.assertEquals("huiäöüß#€", parser.convertContentToString(httpResponseMock));
}
All source files are stored in UTF-8.
If I let JUnit execute this method, it works fine.
However, if infinitest runs this test it complains that the assertion fails.
ComparisonFailure (expected:<hui[äöüß#€]> but was:<hui[äöüß#€]>) in ResponseBodyParserFactoryTest.convertEncodedContentToString
Obviously there is a character encoding problem.
As infinitest has close to no options I have no idea how to help infinitest to run this test properly. Can anyone please help me out here?
You need to say to infinitest that it must use the UTF-8 charset to run the tests.
Just add a file in your Eclipse project: "infinitest.args".
In this file, add the following:
-Dfile.encoding=UTF-8
And so, inifinitest will use UTF-8
User guide: http://infinitest.github.com/doc/user_guide.html specifically the 'Setting JVM Options' section