-
Notifications
You must be signed in to change notification settings - Fork 133
/
rules-findbugs.xml
5425 lines (5360 loc) · 288 KB
/
rules-findbugs.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<rules><!-- This file is auto-generated. -->
<rule key='CNT_ROUGH_CONSTANT_VALUE' priority='MAJOR'>
<name>Bad practice - Rough value of known constant found</name>
<configKey>CNT_ROUGH_CONSTANT_VALUE</configKey>
<description><p>It's recommended to use the predefined library constant for code clarity and better precision.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='SKIPPED_CLASS_TOO_BIG' priority='INFO'>
<name>Experimental - Class too big for analysis</name>
<configKey>SKIPPED_CLASS_TOO_BIG</configKey>
<description><p>This class is bigger than can be effectively handled, and was not fully analyzed for errors.
</p></description>
<tag>experimental</tag>
</rule>
<rule key='DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE' priority='MAJOR'>
<name>Correctness - BigDecimal constructed from double that isn't represented precisely</name>
<configKey>DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE</configKey>
<description><p>
This code creates a BigDecimal from a double value that doesn't translate well to a
decimal number.
For example, one might assume that writing new BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with a scale of 1), but it is actually equal to 0.1000000000000000055511151231257827021181583404541015625.
You probably want to use the BigDecimal.valueOf(double d) method, which uses the String representation
of the double to create the BigDecimal (e.g., BigDecimal.valueOf(0.1) gives 0.1).
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='DMI_DOH' priority='MAJOR'>
<name>Correctness - D'oh! A nonsensical method invocation</name>
<configKey>DMI_DOH</configKey>
<description><p>
This partical method invocation doesn't make sense, for reasons that should be apparent from inspection.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='DMI_VACUOUS_CALL_TO_EASYMOCK_METHOD' priority='MAJOR'>
<name>Correctness - Useless/vacuous call to EasyMock method</name>
<configKey>DMI_VACUOUS_CALL_TO_EASYMOCK_METHOD</configKey>
<description><p>This call doesn't pass any objects to the EasyMock method, so the call doesn't do anything.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='DMI_SCHEDULED_THREAD_POOL_EXECUTOR_WITH_ZERO_CORE_THREADS' priority='MAJOR'>
<name>Correctness - Creation of ScheduledThreadPoolExecutor with zero core threads</name>
<configKey>DMI_SCHEDULED_THREAD_POOL_EXECUTOR_WITH_ZERO_CORE_THREADS</configKey>
<description><p>(<a href="http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html#ScheduledThreadPoolExecutor%28int%29">Javadoc</a>)
A ScheduledThreadPoolExecutor with zero core threads will never execute anything; changes to the max pool size are ignored.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='DMI_FUTILE_ATTEMPT_TO_CHANGE_MAXPOOL_SIZE_OF_SCHEDULED_THREAD_POOL_EXECUTOR' priority='MAJOR'>
<name>Correctness - Futile attempt to change max pool size of ScheduledThreadPoolExecutor</name>
<configKey>DMI_FUTILE_ATTEMPT_TO_CHANGE_MAXPOOL_SIZE_OF_SCHEDULED_THREAD_POOL_EXECUTOR</configKey>
<description><p>(<a href="http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html">Javadoc</a>)
While ScheduledThreadPoolExecutor inherits from ThreadPoolExecutor, a few of the inherited tuning methods are not useful for it. In particular, because it acts as a fixed-sized pool using corePoolSize threads and an unbounded queue, adjustments to maximumPoolSize have no useful effect.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='DMI_UNSUPPORTED_METHOD' priority='INFO'>
<name>Style - Call to unsupported method</name>
<configKey>DMI_UNSUPPORTED_METHOD</configKey>
<description><p>All targets of this method invocation throw an UnsupportedOperationException.
</p></description>
<tag>style</tag>
</rule>
<rule key='DMI_EMPTY_DB_PASSWORD' priority='MAJOR'>
<name>Security - Empty database password</name>
<configKey>DMI_EMPTY_DB_PASSWORD</configKey>
<description><p>This code creates a database connect using a blank or empty password. This indicates that the database is not protected by a password.
</p></description>
<tag>security</tag>
</rule>
<rule key='DMI_CONSTANT_DB_PASSWORD' priority='MAJOR'>
<name>Security - Hardcoded constant database password</name>
<configKey>DMI_CONSTANT_DB_PASSWORD</configKey>
<description><p>This code creates a database connect using a hardcoded, constant password. Anyone with access to either the source code or the compiled code can
easily learn the password.
</p></description>
<tag>security</tag>
</rule>
<rule key='HRS_REQUEST_PARAMETER_TO_COOKIE' priority='MAJOR'>
<name>Security - HTTP cookie formed from untrusted input</name>
<configKey>HRS_REQUEST_PARAMETER_TO_COOKIE</configKey>
<description><p>This code constructs an HTTP Cookie using an untrusted HTTP parameter. If this cookie is added to an HTTP response, it will allow a HTTP response splitting
vulnerability. See <a href="http://en.wikipedia.org/wiki/HTTP_response_splitting">http://en.wikipedia.org/wiki/HTTP_response_splitting</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of HTTP response splitting.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more
vulnerabilities that SpotBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p></description>
<tag>security</tag>
</rule>
<rule key='HRS_REQUEST_PARAMETER_TO_HTTP_HEADER' priority='MAJOR'>
<name>Security - HTTP Response splitting vulnerability</name>
<configKey>HRS_REQUEST_PARAMETER_TO_HTTP_HEADER</configKey>
<description><p>This code directly writes an HTTP parameter to an HTTP header, which allows for a HTTP response splitting
vulnerability. See <a href="http://en.wikipedia.org/wiki/HTTP_response_splitting">http://en.wikipedia.org/wiki/HTTP_response_splitting</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of HTTP response splitting.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more
vulnerabilities that SpotBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p></description>
<tag>security</tag>
</rule>
<rule key='PT_RELATIVE_PATH_TRAVERSAL' priority='MAJOR'>
<name>Security - Relative path traversal in servlet</name>
<configKey>PT_RELATIVE_PATH_TRAVERSAL</configKey>
<description><p>The software uses an HTTP request parameter to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.
See <a href="http://cwe.mitre.org/data/definitions/23.html">http://cwe.mitre.org/data/definitions/23.html</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of relative path traversal.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more
vulnerabilities that SpotBugs doesn't report. If you are concerned about relative path traversal, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p></description>
<tag>cwe</tag>
<tag>security</tag>
</rule>
<rule key='PT_ABSOLUTE_PATH_TRAVERSAL' priority='MAJOR'>
<name>Security - Absolute path traversal in servlet</name>
<configKey>PT_ABSOLUTE_PATH_TRAVERSAL</configKey>
<description><p>The software uses an HTTP request parameter to construct a pathname that should be within a restricted directory,
but it does not properly neutralize absolute path sequences such as "/abs/path" that can resolve to a location that is outside of that directory.
See <a href="http://cwe.mitre.org/data/definitions/36.html">http://cwe.mitre.org/data/definitions/36.html</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of absolute path traversal.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more
vulnerabilities that SpotBugs doesn't report. If you are concerned about absolute path traversal, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p></description>
<tag>cwe</tag>
<tag>security</tag>
</rule>
<rule key='XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER' priority='MAJOR'>
<name>Security - Servlet reflected cross site scripting vulnerability</name>
<configKey>XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER</configKey>
<description><p>This code directly writes an HTTP parameter to Servlet output, which allows for a reflected cross site scripting
vulnerability. See <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of cross site scripting.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more cross site scripting
vulnerabilities that SpotBugs doesn't report. If you are concerned about cross site scripting, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p></description>
<tag>owasp-a3</tag>
<tag>security</tag>
</rule>
<rule key='XSS_REQUEST_PARAMETER_TO_SEND_ERROR' priority='MAJOR'>
<name>Security - Servlet reflected cross site scripting vulnerability in error page</name>
<configKey>XSS_REQUEST_PARAMETER_TO_SEND_ERROR</configKey>
<description><p>This code directly writes an HTTP parameter to a Server error page (using HttpServletResponse.sendError). Echoing this untrusted input allows
for a reflected cross site scripting
vulnerability. See <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of cross site scripting.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more cross site scripting
vulnerabilities that SpotBugs doesn't report. If you are concerned about cross site scripting, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p></description>
<tag>owasp-a3</tag>
<tag>security</tag>
</rule>
<rule key='SW_SWING_METHODS_INVOKED_IN_SWING_THREAD' priority='MAJOR'>
<name>Bad practice - Certain swing methods needs to be invoked in Swing thread</name>
<configKey>SW_SWING_METHODS_INVOKED_IN_SWING_THREAD</configKey>
<description><p>(<a href="http://web.archive.org/web/20090526170426/http://java.sun.com/developer/JDCTechTips/2003/tt1208.html">From JDC Tech Tip</a>): The Swing methods
show(), setVisible(), and pack() will create the associated peer for the frame.
With the creation of the peer, the system creates the event dispatch thread.
This makes things problematic because the event dispatch thread could be notifying
listeners while pack and validate are still processing. This situation could result in
two threads going through the Swing component-based GUI -- it's a serious flaw that
could result in deadlocks or other related threading issues. A pack call causes
components to be realized. As they are being realized (that is, not necessarily
visible), they could trigger listener notification on the event dispatch thread.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='IL_INFINITE_LOOP' priority='MAJOR'>
<name>Correctness - An apparent infinite loop</name>
<configKey>IL_INFINITE_LOOP</configKey>
<description><p>This loop doesn't seem to have a way to terminate (other than by perhaps
throwing an exception).</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='IL_INFINITE_RECURSIVE_LOOP' priority='MAJOR'>
<name>Correctness - An apparent infinite recursive loop</name>
<configKey>IL_INFINITE_RECURSIVE_LOOP</configKey>
<description><p>This method unconditionally invokes itself. This would seem to indicate
an infinite recursive loop that will result in a stack overflow.</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='IL_CONTAINER_ADDED_TO_ITSELF' priority='MAJOR'>
<name>Correctness - A collection is added to itself</name>
<configKey>IL_CONTAINER_ADDED_TO_ITSELF</configKey>
<description><p>A collection is added to itself. As a result, computing the hashCode of this
set will throw a StackOverflowException.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='VO_VOLATILE_REFERENCE_TO_ARRAY' priority='MAJOR'>
<name>Multi-threading - A volatile reference to an array doesn't treat the array elements as volatile</name>
<configKey>VO_VOLATILE_REFERENCE_TO_ARRAY</configKey>
<description><p>This declares a volatile reference to an array, which might not be what
you want. With a volatile reference to an array, reads and writes of
the reference to the array are treated as volatile, but the array elements
are non-volatile. To get volatile array elements, you will need to use
one of the atomic array classes in java.util.concurrent (provided
in Java 5.0).</p></description>
<tag>multi-threading</tag>
<tag>bug</tag>
</rule>
<rule key='VO_VOLATILE_INCREMENT' priority='MAJOR'>
<name>Multi-threading - An increment to a volatile field isn't atomic</name>
<configKey>VO_VOLATILE_INCREMENT</configKey>
<description><p>This code increments a volatile field. Increments of volatile fields aren't
atomic. If more than one thread is incrementing the field at the same time,
increments could be lost.
</p></description>
<tag>multi-threading</tag>
<tag>bug</tag>
</rule>
<rule key='UI_INHERITANCE_UNSAFE_GETRESOURCE' priority='MAJOR'>
<name>Bad practice - Usage of GetResource may be unsafe if class is extended</name>
<configKey>UI_INHERITANCE_UNSAFE_GETRESOURCE</configKey>
<description><p>Calling <code>this.getClass().getResource(...)</code> could give
results other than expected if this class is extended by a class in
another package.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='NP_BOOLEAN_RETURN_NULL' priority='MAJOR'>
<name>Bad practice - Method with Boolean return type returns explicit null</name>
<configKey>NP_BOOLEAN_RETURN_NULL</configKey>
<description><p>
A method that returns either Boolean.TRUE, Boolean.FALSE or null is an accident waiting to happen.
This method can be invoked as though it returned a value of type boolean, and
the compiler will insert automatic unboxing of the Boolean value. If a null value is returned,
this will result in a NullPointerException.
</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='NP_OPTIONAL_RETURN_NULL' priority='MAJOR'>
<name>Correctness - Method with Optional return type returns explicit null</name>
<configKey>NP_OPTIONAL_RETURN_NULL</configKey>
<description><p>
The usage of Optional return type (java.util.Optional or com.google.common.base.Optional)
always means that explicit null returns were not desired by design.
Returning a null value in such case is a contract violation and will most likely break client code.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='NP_NONNULL_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR' priority='MAJOR'>
<name>Correctness - Non-null field is not initialized</name>
<configKey>NP_NONNULL_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR</configKey>
<description><p> The field is marked as non-null, but isn't written to by the constructor.
The field might be initialized elsewhere during constructor, or might always
be initialized before use.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='NP_SYNC_AND_NULL_CHECK_FIELD' priority='MAJOR'>
<name>Multi-threading - Synchronize and null check on the same field.</name>
<configKey>NP_SYNC_AND_NULL_CHECK_FIELD</configKey>
<description><p>Since the field is synchronized on, it seems not likely to be null.
If it is null and then synchronized on a NullPointerException will be
thrown and the check would be pointless. Better to synchronize on
another field.</p></description>
<tag>multi-threading</tag>
<tag>bug</tag>
</rule>
<rule key='RpC_REPEATED_CONDITIONAL_TEST' priority='MAJOR'>
<name>Correctness - Repeated conditional tests</name>
<configKey>RpC_REPEATED_CONDITIONAL_TEST</configKey>
<description><p>The code contains a conditional test is performed twice, one right after the other
(e.g., <code>x == 0 || x == 0</code>). Perhaps the second occurrence is intended to be something else
(e.g., <code>x == 0 || y == 0</code>).
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='AM_CREATES_EMPTY_ZIP_FILE_ENTRY' priority='MAJOR'>
<name>Bad practice - Creates an empty zip file entry</name>
<configKey>AM_CREATES_EMPTY_ZIP_FILE_ENTRY</configKey>
<description><p>The code calls <code>putNextEntry()</code>, immediately
followed by a call to <code>closeEntry()</code>. This results
in an empty ZipFile entry. The contents of the entry
should be written to the ZipFile between the calls to
<code>putNextEntry()</code> and
<code>closeEntry()</code>.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='AM_CREATES_EMPTY_JAR_FILE_ENTRY' priority='MAJOR'>
<name>Bad practice - Creates an empty jar file entry</name>
<configKey>AM_CREATES_EMPTY_JAR_FILE_ENTRY</configKey>
<description><p>The code calls <code>putNextEntry()</code>, immediately
followed by a call to <code>closeEntry()</code>. This results
in an empty JarFile entry. The contents of the entry
should be written to the JarFile between the calls to
<code>putNextEntry()</code> and
<code>closeEntry()</code>.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='IMSE_DONT_CATCH_IMSE' priority='MAJOR'>
<name>Bad practice - Dubious catching of IllegalMonitorStateException</name>
<configKey>IMSE_DONT_CATCH_IMSE</configKey>
<description><p>IllegalMonitorStateException is generally only
thrown in case of a design flaw in your code (calling wait or
notify on an object you do not hold a lock on).</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='FL_MATH_USING_FLOAT_PRECISION' priority='MAJOR'>
<name>Correctness - Method performs math using floating point precision</name>
<configKey>FL_MATH_USING_FLOAT_PRECISION</configKey>
<description><p>
The method performs math operations using floating point precision.
Floating point precision is very imprecise. For example,
16777216.0f + 1.0f = 16777216.0f. Consider using double math instead.</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='CAA_COVARIANT_ARRAY_FIELD' priority='INFO'>
<name>Style - Covariant array assignment to a field</name>
<configKey>CAA_COVARIANT_ARRAY_FIELD</configKey>
<description><p>Array of covariant type is assigned to a field. This is confusing and may lead to ArrayStoreException at runtime
if the reference of some other type will be stored in this array later like in the following code:
</p>
<pre><code>Number[] arr = new Integer[10];
arr[0] = 1.0;
</code></pre>
<p>Consider changing the type of created array or the field type.</p></description>
<tag>style</tag>
</rule>
<rule key='CAA_COVARIANT_ARRAY_LOCAL' priority='INFO'>
<name>Style - Covariant array assignment to a local variable</name>
<configKey>CAA_COVARIANT_ARRAY_LOCAL</configKey>
<description><p>Array of covariant type is assigned to a local variable. This is confusing and may lead to ArrayStoreException at runtime
if the reference of some other type will be stored in this array later like in the following code:
</p>
<pre><code>Number[] arr = new Integer[10];
arr[0] = 1.0;
</code></pre>
<p>Consider changing the type of created array or the local variable type.</p></description>
<tag>style</tag>
</rule>
<rule key='CAA_COVARIANT_ARRAY_RETURN' priority='INFO'>
<name>Style - Covariant array is returned from the method</name>
<configKey>CAA_COVARIANT_ARRAY_RETURN</configKey>
<description><p>Array of covariant type is returned from the method. This is confusing and may lead to ArrayStoreException at runtime
if the calling code will try to store the reference of some other type in the returned array.
</p>
<p>Consider changing the type of created array or the method return type.</p></description>
<tag>style</tag>
</rule>
<rule key='CAA_COVARIANT_ARRAY_ELEMENT_STORE' priority='MAJOR'>
<name>Correctness - Possibly incompatible element is stored in covariant array</name>
<configKey>CAA_COVARIANT_ARRAY_ELEMENT_STORE</configKey>
<description><p>Value is stored into the array and the value type doesn't match the array type.
It's known from the analysis that actual array type is narrower than the declared type of its variable or field
and this assignment doesn't satisfy the original array type. This assignment may cause ArrayStoreException
at runtime.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='CN_IDIOM' priority='MAJOR'>
<name>Bad practice - Class implements Cloneable but does not define or use clone method</name>
<configKey>CN_IDIOM</configKey>
<description><p>
Class implements Cloneable but does not define or
use the clone method.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE' priority='MAJOR'>
<name>Bad practice - Class defines clone() but doesn't implement Cloneable</name>
<configKey>CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE</configKey>
<description><p> This class defines a clone() method but the class doesn't implement Cloneable.
There are some situations in which this is OK (e.g., you want to control how subclasses
can clone themselves), but just make sure that this is what you intended.
</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='CN_IDIOM_NO_SUPER_CALL' priority='MAJOR'>
<name>Bad practice - clone method does not call super.clone()</name>
<configKey>CN_IDIOM_NO_SUPER_CALL</configKey>
<description><p> This non-final class defines a clone() method that does not call super.clone().
If this class ("<i>A</i>") is extended by a subclass ("<i>B</i>"),
and the subclass <i>B</i> calls super.clone(), then it is likely that
<i>B</i>'s clone() method will return an object of type <i>A</i>,
which violates the standard contract for clone().</p>
<p> If all clone() methods call super.clone(), then they are guaranteed
to use Object.clone(), which always returns an object of the correct type.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='NM_FUTURE_KEYWORD_USED_AS_IDENTIFIER' priority='MAJOR'>
<name>Bad practice - Use of identifier that is a keyword in later versions of Java</name>
<configKey>NM_FUTURE_KEYWORD_USED_AS_IDENTIFIER</configKey>
<description><p>The identifier is a word that is reserved as a keyword in later versions of Java, and your code will need to be changed
in order to compile it in later versions of Java.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='NM_FUTURE_KEYWORD_USED_AS_MEMBER_IDENTIFIER' priority='MAJOR'>
<name>Bad practice - Use of identifier that is a keyword in later versions of Java</name>
<configKey>NM_FUTURE_KEYWORD_USED_AS_MEMBER_IDENTIFIER</configKey>
<description><p>This identifier is used as a keyword in later versions of Java. This code, and
any code that references this API,
will need to be changed in order to compile it in later versions of Java.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='DE_MIGHT_DROP' priority='MAJOR'>
<name>Bad practice - Method might drop exception</name>
<configKey>DE_MIGHT_DROP</configKey>
<description><p> This method might drop an exception.&nbsp; In general, exceptions
should be handled or reported in some way, or they should be thrown
out of the method.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='DE_MIGHT_IGNORE' priority='MAJOR'>
<name>Bad practice - Method might ignore exception</name>
<configKey>DE_MIGHT_IGNORE</configKey>
<description><p> This method might ignore an exception.&nbsp; In general, exceptions
should be handled or reported in some way, or they should be thrown
out of the method.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='DP_DO_INSIDE_DO_PRIVILEGED' priority='INFO'>
<name>Malicious code - Method invoked that should be only be invoked inside a doPrivileged block</name>
<configKey>DP_DO_INSIDE_DO_PRIVILEGED</configKey>
<description><p> This code invokes a method that requires a security permission check.
If this code will be granted security permissions, but might be invoked by code that does not
have security permissions, then the invocation needs to occur inside a doPrivileged block.</p></description>
<tag>malicious-code</tag>
</rule>
<rule key='DP_DO_INSIDE_DO_PRIVILEDGED' priority='INFO'>
<name>Experimental - Method invoked that should be only be invoked inside a doPrivileged block</name>
<configKey>DP_DO_INSIDE_DO_PRIVILEDGED</configKey>
<description><p> This code invokes a method that requires a security permission check.
If this code will be granted security permissions, but might be invoked by code that does not
have security permissions, then the invocation needs to occur inside a doPrivileged block.</p></description>
<tag>experimental</tag>
</rule>
<rule key='DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED' priority='INFO'>
<name>Malicious code - Classloaders should only be created inside doPrivileged block</name>
<configKey>DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED</configKey>
<description><p> This code creates a classloader, which needs permission if a security manage is installed.
If this code might be invoked by code that does not
have security permissions, then the classloader creation needs to occur inside a doPrivileged block.</p></description>
<tag>malicious-code</tag>
</rule>
<rule key='JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS' priority='MAJOR'>
<name>Bad practice - Fields of immutable classes should be final</name>
<configKey>JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS</configKey>
<description><p> The class is annotated with net.jcip.annotations.Immutable or javax.annotation.concurrent.Immutable,
and the rules for those annotations require that all fields are final.
.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED' priority='INFO'>
<name>Style - Thread passed where Runnable expected</name>
<configKey>DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED</configKey>
<description><p> A Thread object is passed as a parameter to a method where
a Runnable is expected. This is rather unusual, and may indicate a logic error
or cause unexpected behavior.
</p></description>
<tag>style</tag>
</rule>
<rule key='DMI_COLLECTION_OF_URLS' priority='MAJOR'>
<name>Performance - Maps and sets of URLs can be performance hogs</name>
<configKey>DMI_COLLECTION_OF_URLS</configKey>
<description><p> This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See <a href="http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html">http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html</a> for more information.
Consider using <code>java.net.URI</code> instead.
</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DMI_BLOCKING_METHODS_ON_URL' priority='MAJOR'>
<name>Performance - The equals and hashCode methods of URL are blocking</name>
<configKey>DMI_BLOCKING_METHODS_ON_URL</configKey>
<description><p> The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See <a href="http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html">http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html</a> for more information.
Consider using <code>java.net.URI</code> instead.
</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION' priority='MAJOR'>
<name>Correctness - Can't use reflection to check for presence of annotation without runtime retention</name>
<configKey>DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION</configKey>
<description><p> Unless an annotation has itself been annotated with @Retention(RetentionPolicy.RUNTIME), the annotation can't be observed using reflection
(e.g., by using the isAnnotationPresent method).
.</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='DM_EXIT' priority='MAJOR'>
<name>Bad practice - Method invokes System.exit(...)</name>
<configKey>DM_EXIT</configKey>
<description><p> Invoking System.exit shuts down the entire Java virtual machine. This
should only been done when it is appropriate. Such calls make it
hard or impossible for your code to be invoked by other code.
Consider throwing a RuntimeException instead.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='DM_RUN_FINALIZERS_ON_EXIT' priority='MAJOR'>
<name>Bad practice - Method invokes dangerous method runFinalizersOnExit</name>
<configKey>DM_RUN_FINALIZERS_ON_EXIT</configKey>
<description><p> <em>Never call System.runFinalizersOnExit
or Runtime.runFinalizersOnExit for any reason: they are among the most
dangerous methods in the Java libraries.</em> -- Joshua Bloch</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='DM_STRING_CTOR' priority='MAJOR'>
<name>Performance - Method invokes inefficient new String(String) constructor</name>
<configKey>DM_STRING_CTOR</configKey>
<description><p> Using the <code>java.lang.String(String)</code> constructor wastes memory
because the object so constructed will be functionally indistinguishable
from the <code>String</code> passed as a parameter.&nbsp; Just use the
argument <code>String</code> directly.</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DM_STRING_VOID_CTOR' priority='MAJOR'>
<name>Performance - Method invokes inefficient new String() constructor</name>
<configKey>DM_STRING_VOID_CTOR</configKey>
<description><p> Creating a new <code>java.lang.String</code> object using the
no-argument constructor wastes memory because the object so created will
be functionally indistinguishable from the empty string constant
<code>""</code>.&nbsp; Java guarantees that identical string constants
will be represented by the same <code>String</code> object.&nbsp; Therefore,
you should just use the empty string constant directly.</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DM_STRING_TOSTRING' priority='MAJOR'>
<name>Performance - Method invokes toString() method on a String</name>
<configKey>DM_STRING_TOSTRING</configKey>
<description><p> Calling <code>String.toString()</code> is just a redundant operation.
Just use the String.</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DM_GC' priority='MAJOR'>
<name>Performance - Explicit garbage collection; extremely dubious except in benchmarking code</name>
<configKey>DM_GC</configKey>
<description><p> Code explicitly invokes garbage collection.
Except for specific use in benchmarking, this is very dubious.</p>
<p>In the past, situations where people have explicitly invoked
the garbage collector in routines such as close or finalize methods
has led to huge performance black holes. Garbage collection
can be expensive. Any situation that forces hundreds or thousands
of garbage collections will bring the machine to a crawl.</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DM_BOOLEAN_CTOR' priority='MAJOR'>
<name>Performance - Method invokes inefficient Boolean constructor; use Boolean.valueOf(...) instead</name>
<configKey>DM_BOOLEAN_CTOR</configKey>
<description><p> Creating new instances of <code>java.lang.Boolean</code> wastes
memory, since <code>Boolean</code> objects are immutable and there are
only two useful values of this type.&nbsp; Use the <code>Boolean.valueOf()</code>
method (or Java 1.5 autoboxing) to create <code>Boolean</code> objects instead.</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DM_NUMBER_CTOR' priority='MAJOR'>
<name>Performance - Method invokes inefficient Number constructor; use static valueOf instead</name>
<configKey>DM_NUMBER_CTOR</configKey>
<description><p>
Using <code>new Integer(int)</code> is guaranteed to always result in a new object whereas
<code>Integer.valueOf(int)</code> allows caching of values to be done by the compiler, class library, or JVM.
Using of cached values avoids object allocation and the code will be faster.
</p>
<p>
Values between -128 and 127 are guaranteed to have corresponding cached instances
and using <code>valueOf</code> is approximately 3.5 times faster than using constructor.
For values outside the constant range the performance of both styles is the same.
</p>
<p>
Unless the class must be compatible with JVMs predating Java 1.5,
use either autoboxing or the <code>valueOf()</code> method when creating instances of
<code>Long</code>, <code>Integer</code>, <code>Short</code>, <code>Character</code>, and <code>Byte</code>.
</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DM_FP_NUMBER_CTOR' priority='MAJOR'>
<name>Performance - Method invokes inefficient floating-point Number constructor; use static valueOf instead</name>
<configKey>DM_FP_NUMBER_CTOR</configKey>
<description><p>
Using <code>new Double(double)</code> is guaranteed to always result in a new object whereas
<code>Double.valueOf(double)</code> allows caching of values to be done by the compiler, class library, or JVM.
Using of cached values avoids object allocation and the code will be faster.
</p>
<p>
Unless the class must be compatible with JVMs predating Java 1.5,
use either autoboxing or the <code>valueOf()</code> method when creating instances of <code>Double</code> and <code>Float</code>.
</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DM_CONVERT_CASE' priority='INFO'>
<name>I18n - Consider using Locale parameterized version of invoked method</name>
<configKey>DM_CONVERT_CASE</configKey>
<description><p> A String is being converted to upper or lowercase, using the platform's default encoding. This may
result in improper conversions when used with international characters. Use the </p>
<ul>
<li>String.toUpperCase( Locale l )</li>
<li>String.toLowerCase( Locale l )</li>
</ul>
<p>versions instead.</p></description>
<tag>i18n</tag>
</rule>
<rule key='BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR' priority='MAJOR'>
<name>Performance - Primitive value is unboxed and coerced for ternary operator</name>
<configKey>BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR</configKey>
<description><p>A wrapped primitive value is unboxed and converted to another primitive type as part of the
evaluation of a conditional ternary operator (the <code> b ? e1 : e2</code> operator). The
semantics of Java mandate that if <code>e1</code> and <code>e2</code> are wrapped
numeric values, the values are unboxed and converted/coerced to their common type (e.g,
if <code>e1</code> is of type <code>Integer</code>
and <code>e2</code> is of type <code>Float</code>, then <code>e1</code> is unboxed,
converted to a floating point value, and boxed. See JLS Section 15.25.
</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='BX_BOXING_IMMEDIATELY_UNBOXED' priority='MAJOR'>
<name>Performance - Primitive value is boxed and then immediately unboxed</name>
<configKey>BX_BOXING_IMMEDIATELY_UNBOXED</configKey>
<description><p>A primitive is boxed, and then immediately unboxed. This probably is due to a manual
boxing in a place where an unboxed value is required, thus forcing the compiler
to immediately undo the work of the boxing.
</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='BX_UNBOXING_IMMEDIATELY_REBOXED' priority='MAJOR'>
<name>Performance - Boxed value is unboxed and then immediately reboxed</name>
<configKey>BX_UNBOXING_IMMEDIATELY_REBOXED</configKey>
<description><p>A boxed value is unboxed and then immediately reboxed.
</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION' priority='MAJOR'>
<name>Performance - Primitive value is boxed then unboxed to perform primitive coercion</name>
<configKey>BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION</configKey>
<description><p>A primitive boxed value constructed and then immediately converted into a different primitive type
(e.g., <code>new Double(d).intValue()</code>). Just perform direct primitive coercion (e.g., <code>(int) d</code>).</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DM_BOXED_PRIMITIVE_TOSTRING' priority='MAJOR'>
<name>Performance - Method allocates a boxed primitive just to call toString</name>
<configKey>DM_BOXED_PRIMITIVE_TOSTRING</configKey>
<description><p>A boxed primitive is allocated just to call toString(). It is more effective to just use the static
form of toString which takes the primitive value. So,</p>
<table>
<tr><th>Replace...</th><th>With this...</th></tr>
<tr><td>new Integer(1).toString()</td><td>Integer.toString(1)</td></tr>
<tr><td>new Long(1).toString()</td><td>Long.toString(1)</td></tr>
<tr><td>new Float(1.0).toString()</td><td>Float.toString(1.0)</td></tr>
<tr><td>new Double(1.0).toString()</td><td>Double.toString(1.0)</td></tr>
<tr><td>new Byte(1).toString()</td><td>Byte.toString(1)</td></tr>
<tr><td>new Short(1).toString()</td><td>Short.toString(1)</td></tr>
<tr><td>new Boolean(true).toString()</td><td>Boolean.toString(true)</td></tr>
</table></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DM_BOXED_PRIMITIVE_FOR_PARSING' priority='MAJOR'>
<name>Performance - Boxing/unboxing to parse a primitive</name>
<configKey>DM_BOXED_PRIMITIVE_FOR_PARSING</configKey>
<description><p>A boxed primitive is created from a String, just to extract the unboxed primitive value.
It is more efficient to just call the static parseXXX method.</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DM_BOXED_PRIMITIVE_FOR_COMPARE' priority='MAJOR'>
<name>Performance - Boxing a primitive to compare</name>
<configKey>DM_BOXED_PRIMITIVE_FOR_COMPARE</configKey>
<description><p>A boxed primitive is created just to call compareTo method. It's more efficient to use static compare method
(for double and float since Java 1.4, for other primitive types since Java 1.7) which works on primitives directly.
</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DM_NEW_FOR_GETCLASS' priority='MAJOR'>
<name>Performance - Method allocates an object, only to get the class object</name>
<configKey>DM_NEW_FOR_GETCLASS</configKey>
<description><p>This method allocates an object just to call getClass() on it, in order to
retrieve the Class object for it. It is simpler to just access the .class property of the class.</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='DM_MONITOR_WAIT_ON_CONDITION' priority='MAJOR'>
<name>Multi-threading - Monitor wait() called on Condition</name>
<configKey>DM_MONITOR_WAIT_ON_CONDITION</configKey>
<description><p>
This method calls <code>wait()</code> on a
<code>java.util.concurrent.locks.Condition</code> object.&nbsp;
Waiting for a <code>Condition</code> should be done using one of the <code>await()</code>
methods defined by the <code>Condition</code> interface.
</p></description>
<tag>multi-threading</tag>
<tag>bug</tag>
</rule>
<rule key='RV_01_TO_INT' priority='MAJOR'>
<name>Correctness - Random value from 0 to 1 is coerced to the integer 0</name>
<configKey>RV_01_TO_INT</configKey>
<description><p>A random value from 0 to 1 is being coerced to the integer value 0. You probably
want to multiply the random value by something else before coercing it to an integer, or use the <code>Random.nextInt(n)</code> method.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='DM_INVALID_MIN_MAX' priority='MAJOR'>
<name>Correctness - Incorrect combination of Math.max and Math.min</name>
<configKey>DM_INVALID_MIN_MAX</configKey>
<description><p>This code tries to limit the value bounds using the construct like Math.min(0, Math.max(100, value)). However the order of
the constants is incorrect: it should be Math.min(100, Math.max(0, value)). As the result this code always produces the same result
(or NaN if the value is NaN).</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='DM_NEXTINT_VIA_NEXTDOUBLE' priority='MAJOR'>
<name>Performance - Use the nextInt method of Random rather than nextDouble to generate a random integer</name>
<configKey>DM_NEXTINT_VIA_NEXTDOUBLE</configKey>
<description><p>If <code>r</code> is a <code>java.util.Random</code>, you can generate a random number from <code>0</code> to <code>n-1</code>
using <code>r.nextInt(n)</code>, rather than using <code>(int)(r.nextDouble() * n)</code>.
</p>
<p>The argument to nextInt must be positive. If, for example, you want to generate a random
value from -99 to 0, use <code>-r.nextInt(100)</code>.
</p></description>
<tag>performance</tag>
<tag>bug</tag>
</rule>
<rule key='SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE' priority='MAJOR'>
<name>Security - Nonconstant string passed to execute or addBatch method on an SQL statement</name>
<configKey>SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE</configKey>
<description><p>The method invokes the execute or addBatch method on an SQL statement with a String that seems
to be dynamically generated. Consider using
a prepared statement instead. It is more efficient and less vulnerable to
SQL injection attacks.
</p></description>
<tag>owasp-a1</tag>
<tag>injection</tag>
<tag>security</tag>
</rule>
<rule key='SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING' priority='MAJOR'>
<name>Security - A prepared statement is generated from a nonconstant String</name>
<configKey>SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING</configKey>
<description><p>The code creates an SQL prepared statement from a nonconstant String.
If unchecked, tainted data from a user is used in building this String, SQL injection could
be used to make the prepared statement do something unexpected and undesirable.
</p></description>
<tag>owasp-a1</tag>
<tag>injection</tag>
<tag>security</tag>
</rule>
<rule key='DM_USELESS_THREAD' priority='MAJOR'>
<name>Multi-threading - A thread was created using the default empty run method</name>
<configKey>DM_USELESS_THREAD</configKey>
<description><p>This method creates a thread without specifying a run method either by deriving from the Thread class, or
by passing a Runnable object. This thread, then, does nothing but waste time.
</p></description>
<tag>multi-threading</tag>
<tag>bug</tag>
</rule>
<rule key='DC_DOUBLECHECK' priority='MAJOR'>
<name>Multi-threading - Possible double check of field</name>
<configKey>DC_DOUBLECHECK</configKey>
<description><p> This method may contain an instance of double-checked locking.&nbsp;
This idiom is not correct according to the semantics of the Java memory
model.&nbsp; For more information, see the web page
<a href="http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html"
>http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html</a>.</p></description>
<tag>multi-threading</tag>
<tag>bug</tag>
</rule>
<rule key='DC_PARTIALLY_CONSTRUCTED' priority='MAJOR'>
<name>Multi-threading - Possible exposure of partially initialized object</name>
<configKey>DC_PARTIALLY_CONSTRUCTED</configKey>
<description><p>Looks like this method uses lazy field initialization with double-checked locking.
While the field is correctly declared as volatile, it's possible that the internal structure of
the object is changed after the field assignment, thus another thread may see the partially initialized object.</p>
<p>To fix this problem consider storing the object into the local variable first
and save it to the volatile field only after it's fully constructed.
</p></description>
<tag>multi-threading</tag>
<tag>bug</tag>
</rule>
<rule key='FI_FINALIZER_NULLS_FIELDS' priority='MAJOR'>
<name>Bad practice - Finalizer nulls fields</name>
<configKey>FI_FINALIZER_NULLS_FIELDS</configKey>
<description><p> This finalizer nulls out fields. This is usually an error, as it does not aid garbage collection,
and the object is going to be garbage collected anyway.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='FI_FINALIZER_ONLY_NULLS_FIELDS' priority='MAJOR'>
<name>Bad practice - Finalizer only nulls fields</name>
<configKey>FI_FINALIZER_ONLY_NULLS_FIELDS</configKey>
<description><p> This finalizer does nothing except null out fields. This is completely pointless, and requires that
the object be garbage collected, finalized, and then garbage collected again. You should just remove the finalize
method.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='FI_PUBLIC_SHOULD_BE_PROTECTED' priority='INFO'>
<name>Malicious code - Finalizer should be protected, not public</name>
<configKey>FI_PUBLIC_SHOULD_BE_PROTECTED</configKey>
<description><p> A class's <code>finalize()</code> method should have protected access,
not public.</p></description>
<tag>malicious-code</tag>
</rule>
<rule key='FI_EMPTY' priority='MAJOR'>
<name>Bad practice - Empty finalizer should be deleted</name>
<configKey>FI_EMPTY</configKey>
<description><p> Empty <code>finalize()</code> methods are useless, so they should
be deleted.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='FI_NULLIFY_SUPER' priority='MAJOR'>
<name>Bad practice - Finalizer nullifies superclass finalizer</name>
<configKey>FI_NULLIFY_SUPER</configKey>
<description><p> This empty <code>finalize()</code> method explicitly negates the
effect of any finalizer defined by its superclass.&nbsp; Any finalizer
actions defined for the superclass will not be performed.&nbsp;
Unless this is intended, delete this method.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='FI_USELESS' priority='MAJOR'>
<name>Bad practice - Finalizer does nothing but call superclass finalizer</name>
<configKey>FI_USELESS</configKey>
<description><p> The only thing this <code>finalize()</code> method does is call
the superclass's <code>finalize()</code> method, making it
redundant.&nbsp; Delete it.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='FI_MISSING_SUPER_CALL' priority='MAJOR'>
<name>Bad practice - Finalizer does not call superclass finalizer</name>
<configKey>FI_MISSING_SUPER_CALL</configKey>
<description><p> This <code>finalize()</code> method does not make a call to its
superclass's <code>finalize()</code> method.&nbsp; So, any finalizer
actions defined for the superclass will not be performed.&nbsp;
Add a call to <code>super.finalize()</code>.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='FI_EXPLICIT_INVOCATION' priority='MAJOR'>
<name>Bad practice - Explicit invocation of finalizer</name>
<configKey>FI_EXPLICIT_INVOCATION</configKey>
<description><p> This method contains an explicit invocation of the <code>finalize()</code>
method on an object.&nbsp; Because finalizer methods are supposed to be
executed once, and only by the VM, this is a bad idea.</p>
<p>If a connected set of objects beings finalizable, then the VM will invoke the
finalize method on all the finalizable object, possibly at the same time in different threads.
Thus, it is a particularly bad idea, in the finalize method for a class X, invoke finalize
on objects referenced by X, because they may already be getting finalized in a separate thread.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS' priority='MAJOR'>
<name>Bad practice - Equals checks for incompatible operand</name>
<configKey>EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS</configKey>
<description><p> This equals method is checking to see if the argument is some incompatible type
(i.e., a class that is neither a supertype nor subtype of the class that defines
the equals method). For example, the Foo class might have an equals method
that looks like:
</p>
<pre><code>public boolean equals(Object o) {
if (o instanceof Foo)
return name.equals(((Foo)o).name);
else if (o instanceof String)
return name.equals(o);
else return false;
}
</code></pre>
<p>This is considered bad practice, as it makes it very hard to implement an equals method that
is symmetric and transitive. Without those properties, very unexpected behaviors are possible.
</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='EQ_DONT_DEFINE_EQUALS_FOR_ENUM' priority='MAJOR'>
<name>Correctness - Covariant equals() method defined for enum</name>
<configKey>EQ_DONT_DEFINE_EQUALS_FOR_ENUM</configKey>
<description><p> This class defines an enumeration, and equality on enumerations are defined
using object identity. Defining a covariant equals method for an enumeration
value is exceptionally bad practice, since it would likely result
in having two different enumeration values that compare as equals using
the covariant enum method, and as not equal when compared normally.
Don't do it.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='EQ_SELF_USE_OBJECT' priority='MAJOR'>
<name>Correctness - Covariant equals() method defined, Object.equals(Object) inherited</name>
<configKey>EQ_SELF_USE_OBJECT</configKey>
<description><p> This class defines a covariant version of the <code>equals()</code>
method, but inherits the normal <code>equals(Object)</code> method
defined in the base <code>java.lang.Object</code> class.&nbsp;
The class should probably define a <code>boolean equals(Object)</code> method.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='EQ_OTHER_USE_OBJECT' priority='MAJOR'>
<name>Correctness - equals() method defined that doesn't override Object.equals(Object)</name>
<configKey>EQ_OTHER_USE_OBJECT</configKey>
<description><p> This class defines an <code>equals()</code>
method, that doesn't override the normal <code>equals(Object)</code> method
defined in the base <code>java.lang.Object</code> class.&nbsp;
The class should probably define a <code>boolean equals(Object)</code> method.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='EQ_OTHER_NO_OBJECT' priority='MAJOR'>
<name>Correctness - equals() method defined that doesn't override equals(Object)</name>
<configKey>EQ_OTHER_NO_OBJECT</configKey>
<description><p> This class defines an <code>equals()</code>
method, that doesn't override the normal <code>equals(Object)</code> method
defined in the base <code>java.lang.Object</code> class.&nbsp; Instead, it
inherits an <code>equals(Object)</code> method from a superclass.
The class should probably define a <code>boolean equals(Object)</code> method.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='EQ_DOESNT_OVERRIDE_EQUALS' priority='INFO'>
<name>Style - Class doesn't override equals in superclass</name>
<configKey>EQ_DOESNT_OVERRIDE_EQUALS</configKey>
<description><p> This class extends a class that defines an equals method and adds fields, but doesn't
define an equals method itself. Thus, equality on instances of this class will
ignore the identity of the subclass and the added fields. Be sure this is what is intended,
and that you don't need to override the equals method. Even if you don't need to override
the equals method, consider overriding it anyway to document the fact
that the equals method for the subclass just return the result of
invoking super.equals(o).
</p></description>
<tag>style</tag>
</rule>
<rule key='EQ_SELF_NO_OBJECT' priority='MAJOR'>
<name>Bad practice - Covariant equals() method defined</name>
<configKey>EQ_SELF_NO_OBJECT</configKey>
<description><p> This class defines a covariant version of <code>equals()</code>.&nbsp;
To correctly override the <code>equals()</code> method in
<code>java.lang.Object</code>, the parameter of <code>equals()</code>
must have type <code>java.lang.Object</code>.</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC' priority='MAJOR'>
<name>Correctness - equals method overrides equals in superclass and may not be symmetric</name>
<configKey>EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC</configKey>
<description><p> This class defines an equals method that overrides an equals method in a superclass. Both equals methods
methods use <code>instanceof</code> in the determination of whether two objects are equal. This is fraught with peril,
since it is important that the equals method is symmetrical (in other words, <code>a.equals(b) == b.equals(a)</code>).
If B is a subtype of A, and A's equals method checks that the argument is an instanceof A, and B's equals method
checks that the argument is an instanceof B, it is quite likely that the equivalence relation defined by these
methods is not symmetric.
</p></description>
<tag>correctness</tag>
<tag>bug</tag>
</rule>
<rule key='EQ_GETCLASS_AND_CLASS_CONSTANT' priority='MAJOR'>
<name>Bad practice - equals method fails for subtypes</name>
<configKey>EQ_GETCLASS_AND_CLASS_CONSTANT</configKey>
<description><p> This class has an equals method that will be broken if it is inherited by subclasses.
It compares a class literal with the class of the argument (e.g., in class <code>Foo</code>
it might check if <code>Foo.class == o.getClass()</code>).
It is better to check if <code>this.getClass() == o.getClass()</code>.
</p></description>
<tag>bad-practice</tag>
</rule>
<rule key='EQ_UNUSUAL' priority='INFO'>
<name>Style - Unusual equals method </name>
<configKey>EQ_UNUSUAL</configKey>
<description><p> This class doesn't do any of the patterns we recognize for checking that the type of the argument
is compatible with the type of the <code>this</code> object. There might not be anything wrong with
this code, but it is worth reviewing.
</p></description>
<tag>style</tag>
</rule>
<rule key='EQ_COMPARING_CLASS_NAMES' priority='MAJOR'>
<name>Correctness - equals method compares class names rather than class objects</name>
<configKey>EQ_COMPARING_CLASS_NAMES</configKey>
<description><p> This method checks to see if two objects are the same class by checking to see if the names