New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SPARK-36362][CORE][SQL][TESTS] Omnibus Java code static analyzer warning fixes #33594
Conversation
- Unnecessarily non-static inner classes - Some tests "catch (AssertionError)" and do nothing - Manual array iteration vs very slightly faster/simpler foreach - Incorrect generic types that just happen to not cause a runtime error - Missed opportunities for try-close - Mutable enums - .. and a few other minor things
@@ -130,7 +130,7 @@ String getParentIndexName(String indexName) { | |||
Class<?> getType(); | |||
} | |||
|
|||
private class FieldAccessor implements Accessor { | |||
private static class FieldAccessor implements Accessor { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
static is better for inner classes that need no reference to the outer class. While I don't think it comes up -- those hidden references can cause GC or serialization issues in theory. Just cleaner.
@@ -150,7 +150,7 @@ private ByteBuf doWrite(MessageWithHeader msg, int minExpectedWrites) throws Exc | |||
|
|||
@Override | |||
public long count() { | |||
return 8 * writeCount; | |||
return 8L * writeCount; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea here is that 8 * writeCount is int * int, which could overflow, even though the result is meant to be long. Cast before the multiply. Probably not actually a bug in practice but who knows.
@@ -217,19 +217,6 @@ public void setAndRetrieveAKey() { | |||
Assert.assertArrayEquals(valueData, | |||
getByteArray(loc.getValueBase(), loc.getValueOffset(), recordLengthBytes)); | |||
|
|||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test has the same problem as the above, but, is actually further just 'wrong' since a long time ago, when putNewValue was replaced by append. It is no longer expected to assert, or that's what I work out from the commit log.
try { | ||
batch.getKeyRow(-1); | ||
Assert.fail("Should not be able to get row -1"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same problem -- if it 'failed' it would still pass as the fail() is caught by the catch block
@@ -1548,7 +1548,7 @@ public void test() { | |||
A("www.elgoog.com"), | |||
B("www.google.com"); | |||
|
|||
private String url; | |||
private final String url; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Enums shouldn't be mutable!
@@ -547,7 +547,7 @@ public void testPairMap2() { // Maps pair -> single | |||
JavaPairDStream<String, Integer> pairStream = JavaPairDStream.fromJavaDStream(stream); | |||
JavaDStream<Integer> reversed = pairStream.map(Tuple2::_2); | |||
JavaTestUtils.attachTestOutputStream(reversed); | |||
List<List<Tuple2<Integer, String>>> result = JavaTestUtils.runStreams(ssc, 2, 2); | |||
List<List<Integer>> result = JavaTestUtils.runStreams(ssc, 2, 2); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The generic types were just wrong. It happens to work because of erasure.
Kubernetes integration test starting |
Kubernetes integration test status success |
Test build #141907 has finished for PR 33594 at commit
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, LGTM. Thank you, @srowen .
It seems that the pattern of AssertionError
are easily slipped during review.
Merged to master for Apache Spark 3.3.0 only. |
Oh, there are linter errors.
|
I'll make a follow-up. |
Here is the PR. |
### What changes were proposed in this pull request? This is a follow-up of #33594 to fix the Java linter error. ### Why are the changes needed? To recover GitHub Action. ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? Pass the GitHub Action. Closes #33601 from dongjoon-hyun/SPARK-36362. Authored-by: Dongjoon Hyun <dongjoon@apache.org> Signed-off-by: Hyukjin Kwon <gurwls223@apache.org>
…ning fixes Fix up some minor Java issues: - Some int*int multiplications that widen to long maybe could overflow - Unnecessarily non-static inner classes - Some tests "catch (AssertionError)" and do nothing - Manual array iteration vs very slightly faster/simpler foreach - Incorrect generic types that just happen to not cause a runtime error - Missed opportunities for try-close - Mutable enums - .. and a few other minor things Some are minor but clear fixes; some may have a marginal perf impact or avoid a bug later. Also: maybe avoid future PRs to address these one by one. No. Existing tests Closes #33594 from srowen/SPARK-36362. Authored-by: Sean Owen <srowen@gmail.com> Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
### What changes were proposed in this pull request? This is a follow-up of #33594 to fix the Java linter error. ### Why are the changes needed? To recover GitHub Action. ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? Pass the GitHub Action. Closes #33601 from dongjoon-hyun/SPARK-36362. Authored-by: Dongjoon Hyun <dongjoon@apache.org> Signed-off-by: Hyukjin Kwon <gurwls223@apache.org>
What changes were proposed in this pull request?
Fix up some minor Java issues:
Why are the changes needed?
Some are minor but clear fixes; some may have a marginal perf impact or avoid a bug later. Also: maybe avoid future PRs to address these one by one.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Existing tests