| RE: [smila-dev] RE: encoding during compilation |
|
Hi, extracting such
strings into resource files is not a problem and another valid solution, we can
set this as a guide. I just looked into
our dev guide http://wiki.eclipse.org/SMILA/Development_Guidelines#How_to_set_up_the_development_environment
and either I was mistaken that we said to have our IDE use UTF-8 as default
encoding or it just isn’t recorded there. However, leaving this
point undefined could lead to bugs that are very hard to track and find
especially when working in a distributed environment and with diff. systems
underneath (that use diff. default encodings). Hence, I strongly
suggest to define the IDE and javac encoding to be UTF-8. Note also, that the
encoding that u have chosen to write your (source) files to the disc, also
affects how it will be put into SVN. If we leave all developers to decide what
encoding they are using, then this will lead to problems left and right. PS: I had it already
in a project where some Russians committed code to an SVN and when I checked it
out, I couldn’t read it in my eclipse due to diff. encodings on the respective
dev. machines. Well, it is up to the
PLs to decide the matter Thomas
Menzel @ IT-Solutions GmbH From: smila-dev-bounces@xxxxxxxxxxx
[mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel.Stucky@xxxxxxxxxxx Hi, I would also prefer
to have test data with special encodings not hard coded in the code, but in
separate files. Bye, Daniel Von: smila-dev-bounces@xxxxxxxxxxx
[mailto:smila-dev-bounces@xxxxxxxxxxx] Im Auftrag von Igor.Novakovic@xxxxxxxxxxx Hi Thomas, Generally speaking, I
have nothing against instructing javac to interpret our source files as UTF-8
encoded. But would not be
better to stay by ASCII in our code and to keep all non ASCII characters
(constants) in some resource file that would be filled and interpreted in
UTF-8? This is actually the
way how the localization of messages would be usually done, right? Cheers Igor Von:
smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Thomas Menzel Hi, i found out how the
javac encoding can be set for PDE build. I have tested this for
my build and it works, so far but don’t know if there are any side effects
(yet) See: http://www.eclipse.org/forums/index.php?&t=msg&th=18436 http://dev.eclipse.org/newslists/news.eclipse.platform.pde/msg00488.html Thomas
Menzel @ IT-Solutions GmbH From: smila-dev-bounces@xxxxxxxxxxx
[mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Menzel Hi folks, This mail intends to a)
share a subtle encoding issue b)
start a discussion on how we
want to treat the matter in SMILA. Here goes the description of the encoding
issue I ran into: The scenario is the writing of a test case
with a converter pipelet; but that is just the setting where it happened
to me and might happen again elsewhere to s.o. else. The expected result for the extracted item
is “Microsoft® Office PowerPoint® 2007” (note the (R) char!) As with tests, I hard coded this value in
source code as it is sufficiently short and as soon as the converter worked the
unit test (UT) was green – in the IDE!! When I built from the command line the
junit test would fail complaining that expected and actual value weren’t the
same. After some time of debugging and not
getting anywhere, I switched the default encoding from my IDE to my system’s
(cp1252, and it similarly works when setting the project’s encoding for the
test bundle). Having done this, eclipse recompiled the
(whole) workspace – et voi là - the UT failed the same as it did on the
console. Vica versa I was also able to get it green
on the console by setting this env var: set JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 (note that u need the UTF-8 and not UTF8 as
I have seen on a webpage) Reason: The source file is written by the IDE in
the encoding that is set. However, javac uses the encoding that is determined by
the environment; in the IDE this is the same as for writing the files -- on the
console this might be different since javac doesn’t know the encoding I have in
the IDE. Usually this isn’t a problem as we seldom use special / non-ascii
chars in our java code, but in this case it happened for a god reason and as a
consequence it mattered with which encoding the compiler reads the source
files. In the light of this and our recommendation
to use UTF-8 in our IDE as default encoding, I suggest that we do our builds
also in UTF-8. Any thoughts and comments on your end? If we agree on this: where will we write
this down for fellow developers? |