Bug#866845: libidw-java FTBFS: PropertyMapImpl.java:383: error: unmappable character for encoding ASCII

[Emmanuel Bourg]

Le 4/07/2017 à 20:21, Markus Koschany a écrit :

> I understand what you intend to say. Even if UTF-8 was the default,
> libidw-java would require an override with ISO-8859-1 encoding. However
> we are talking about the general case. What is more likely that a Java
> project contains an UTF-8 encoded character or ISO-8859-1 character in
> 2017?

UTF-8 is certainly more prevalent in 2017, but the packages lacking a
build system and thus using jh_build are often old projects more likely
to have ASCII or ISO-8859-1 encoded source files.


> I hope tony will read this and find some better arguments
> because he is also in favor of UTF-8. :)

I wish I could find the right argument to spare you the trouble of
updating old packages for nothing, but if you think it's better go for
it. That would still be an opportunity to refresh old packages, migrate
them to Git, etc.


> By the way how are people supposed to override the JH_JAVAC_OPTS
> variable. I just tried
> 
> export JH_JAVAC_OPTS="-encoding UTF-8" in libidw-java but this doesn't
> really seem to work.

You are right, I misread the jh_build code sorry. The jh_build options
are either specified with the JH_BUILD_ARGS variable for the CDBS
packages (never used according to codesearch.debian.net), or by adding
the --javacopts option to dh_auto_build for DH packages (used by
osgi-core, libcds-moc-java and rdp-readseq to set the encoding).


> To be honest I didn't expect that much resistance against using UTF-8.

I'm not against UTF-8, I use and recommend UTF-8 everyday, whenever
possible. But here it isn't about using UTF-8, it is about selecting a
default encoding expected by the compiler to parse the source files. I'm
just arguing that the best choice is the one that works out of the box
for a majority of javahelper based packages. Changing the default in
javahelper will do nothing to spread the use of UTF-8.