> On 21 May 2015, at 22:20, Andreas Delmelle <andreas.delme...@telenet.be> 
> wrote:
> <snip />
> FWIW - Those 17 'high' priority "Reliance on default encoding" warnings are 
> definitely worth checking out. So far, I think the handful that I already 
> looked at can be safely added to the exclusions list, but this is *exactly* 
> the type of bug that can lead to issues at runtime that are a real pain to 
> track down, if they do arise.

Some follow-up:
In the meantime, I had a look at each of those 17, and the suggestion here 
would be a temporary blanket exclusion of the pattern for now.
Note - This should be replaced with an explicit set of approved exclusions, so 
that future warnings in new code would not go unnoticed due to the exclusion of 
the entire bug pattern.

Only one occurrence seemed suspicious, and would be easy to resolve, but not 
really an issue - 
Strictly speaking, RtfHandler.startDocument should be using explicit US-ASCII 
encoding for the stream. No priority to fix, since the RTF library already 
contains code that automatically escapes any character outside of the US-ASCII 

The remainder can be divided in following groups:

1) The actual source encoding seems out of FOP's control (?) - 5 warnings
This is the case for the warnings in the o.a.f.fonts package and the one 
o.a.f.render.ps package. 
The binary data here comes from FontBox classes. 
Not sure how to resolve those. I have to defer to the experts here. Should we 
assume that constructing Strings from the byte arrays using default encoding is 
always going to work here?

3) Default encoding is used as a fallback/last resort - 3 warnings
The developer in question added this in a catch-block for an 
UnsupportedEncodingException, so the choice is either to terminate or try the 
default, which should always work... 
Strictly speaking, if an explicit encoding is expected, I would say that the 
safer bet is to terminate, rather than silently revert to the default, but I am 
not going to insist. 

2) Reads from/writes to the console (System.in/System.out) - 3 warnings
Using the default encoding is OK in this case.

4) Private methods where byte-to-string and string-to-byte conversions are 
guaranteed to always happen on the same platform - 1 warning
No problem to use default encoding here.

5) Classes used by the build or from the command line - 4 warnings
Should be cleaned up over time, but no priority now.



Reply via email to