crunch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Owen (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CRUNCH-520) Fix minor potential bugs, minor cleanup from second Coverity Scan
Date Wed, 20 May 2015 08:13:01 GMT
Sean Owen created CRUNCH-520:
--------------------------------

             Summary: Fix minor potential bugs, minor cleanup from second Coverity Scan
                 Key: CRUNCH-520
                 URL: https://issues.apache.org/jira/browse/CRUNCH-520
             Project: Crunch
          Issue Type: Bug
          Components: Core
    Affects Versions: 0.11.0
            Reporter: Sean Owen
            Assignee: Josh Wills
            Priority: Minor


As mentioned on the mailing list, I ran a Coverity scan (https://scan.coverity.com/projects/1983?tab=overview)
again and it turned up a reasonable number of little things to fix or touch up in the code.
See previous work in https://issues.apache.org/jira/browse/CRUNCH-380

Cross-cutting minor touch-ups are:

- Replace use of old junit.framework.* with org.unit.* for consistency
- Remove some unused imports
- String.getBytes() -> String.getBytes(Charset) to avoid platform dependence
- Remove a few dead stores
- Replace one Map.keySet() + many get()s with Map.entrySet() iteration
- Remove a few @Nullable on method args that can't be (immediately dereferenced)
- Closing some objects in a finally block that are Closable
- Math.abs is technically a bad idea for something that can == Integer.MIN_VALUE


There are a few changes that might be minor bug fixes:

Aggregators:1059
"maxInputLength > 0 && next.length() > maxInputLength" also needs a check for
next != null, but doesn't the second clause also need parentheses?

TupleWritable:337
The call to skip() doesn't check that the expected number of bytes were skipped.

OrcWritable
Missing hashCode for equals

WritableGroupedTableType:97
options is checked for null but is always dereferenced at the end

CrunchOutputs:201
baseContext can't be null at this point because of line 192

SparkRuntime:342
Not a bug but redundant I think since this occurs inside a block also guarded by "if (t instance
MapReduceTarget) {"




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message