Java 7 introduced java.nio.charset.StandardCharsets, which negates the
need for our CharEncoding method. Additionally, the constants in the
class now point to the constants defined in Java 7.
Fixes: LANG-1334
Previous implementation was causing an endless loop by calling
'super.appendDetail' rather than 'super.reflectionAppendArrayDetail'
when it encountered an array type.
Fixes: LANG-1319
As discussed on the ML, we need more time to figure out the design of
this annotations. So I'm removing them in order to get the next release
out of the door.
In order to provide patch for LANG-1110, required dependency on JMH lib.
Current commit add benchmark profile and ability to run JMH based benchmark by
executing "mvn test -P benchmark" command, moreover it's also possible to
specify exact benchmark name by running "mvn test -P benchmark
-Dbenchmark=benchmark.full.class.name".
Since the project defines a JDK 7 source compatibility, it's safe to use JDK 5's features.
This patch replaces usages of String#indexOf with String#contains where possible to make the code easier to read and maintain.
This patch copies the FindBugs configuration in pom.xml from the
reporting section to the build section so findbugs can be used as part
of the build process (by using the maven goal findbugs:check).
It then adds this goal to the Travis CI build so that FindBugs
becomes part of the CI, and new patches would be prevented from
introducing new FindBugs errors.
FastDatePrinter#appendFullDigits uses a switch case without break
statements.
SF_SWITCH_NO_DEFAULT unfortunately cannot recognize this pattern, and
leave us with no choice but to suppress it.
FastDateParser#simpleQuote uses a switch case that actually has a
default branch in it, but doesn't use break statements.
SF_SWITCH_NO_DEFAULT unfortunately cannot recognize this pattern, and
leave us with no choice but to suppress it.
Exclude ES_COMPARING_PARAMETER_STRING_WITH_EQ FindBugs warnings from
StringUtils methods compare(String, String, boolean) and
compareIgnoreCase(String, String, boolean).
The usages of the == operator seem to be intentional optimizations
similar to the usage in indexOfDifference. If this reasoning is ever
overruled, this suppression should be removed.