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.
