Note: calling the static native method `String Console.encoding()` returns the current console encoding, even if `System.console()` is null because the console is not interactive (pipe or redirection).
- due to some rewriting without testing, the encoding property was not added to the renderer properties.
- better console encoding: use system property `sun.stdout.encoding` in interactive console, and `file.encoding` in piped or redirected output
Hi,
The writers in the Ant task's formatter uses the default platform's encoding (for instance cp1252 on Western Windows) and the XMLRenderer sets the default XML encoding to UTF-8. This may lead to incorrect XML encoding, detected for instance when the XML file is sent to a XSLT task.
This goes undetected as long as the characters in the XML file are in the ASCII subset, which is frequently the case with code, usually in plain Latin language. In my case, the issue was raised because of the localized formatting of some line numbers greater than 999, due to localized thousand separator 0xA0, which is out of the ASCII subset.
I modified the Formatter class to always use a charset for writers. When no encoding is specified, UTF-8 is used instead of the default platform's encoding.
I strongly recommend to *always set the encoding parameter* of the formatter element. It should be reflected as so in the Ant Task documentation.
```xml
<pmd encoding="cp1252"> <!-- source encoding -->
<formatter type="xml" toFile="pmd.xml">
<param name="encoding" value="UTF-8" /> <!-- report encoding -->
</formatter>
<fileset dir="src/main/java">
<include name="**/*.java"/>
</fileset>
</pmd>
```
Note: when digging into sourceforge issues for similar bugs, I found [Bug 877: Output with encoding CP1252](https://sourceforge.net/p/pmd/bugs/877/) . Not the same task, but the same symptoms, probably the same cause ?
- Avoid making calls within for loops, specially costly ones
such as `getQualifiedTypeNames`
- Don't create lists when they are empty.
- Create lists of proper size to avoid resizing / oversizing
- I'm seeing a ~5% improvement. We are reaching the point were noise
makes it hard to detect improvements. We should attack GC cycles soon.
- This was an excruciatingly slow rule, the slowest by far of all PMD
- We speed it up by:
* checking early if we are analyzing a `clone()` method to cut the AST tree
* making better use of type information available
* only performing additional checks when we know we can't rely on
available type information
