- This greatly reduces the memory footprint during analysis,
addressing part of the issues raised ay #185
- Rendering is still done to a single String which is then either printed
to STDOUT or a file, this stiill needs refactoring.
- SourceCodeProcessor now consistently calls rule sets start / end
if cache is not up to date
- Both Mono and MultiThread Processors rely on PmdRunnable, just using
different execution strategies
- This also fixes https://sourceforge.net/p/pmd/bugs/1511/
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 ?
- Move shared code to pmd-core
- Allow search methods to stop searching when they want to
- If we are looking for a variable declaration, just search among those and not all name declarations
- This is roughtly another 10% improvement on symbol table performance
- We stick to ConstantsInInterface since it covers all scenarios the other one did,
and allows greater configuration.
- The existing test cases were already covered, so we can safely drop them.
- It's just a bunch of static methods with no state on a URLClassLoader
- We should probably review if this class makes sense at all, or should
be replaced with helper methods on top of PMDASMClassLoader
- RuleSet is now immutable
- RuleSets are created through a RuleSetBuilder
- RuleSetBuilder is accessed solely from RuleSetFactory
- RuleSetFactory can now either parse XMLs for rule set creation,
or create single rule rulesets
- It's just a bunch of static methods with no state on a URLClassLoader
- We should probably review if this class makes sense at all, or should
be replaced with helper methods on top of PMDASMClassLoader
- Types are now attempted to be resolved as inner classes if public attempt fails
- ClassScope offers a `resolveType` method that qualifies the name as per local rules
before resolution
