Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

“This method compares an expression such as `((event.detail & SWT.SELECTED) > 0)`

. Using bit arithmetic and then comparing with the greater than operator can lead to unexpected results (of course depending on the value of SWT.SELECTED). If SWT.SELECTED is a negative number, this is a candidate for a bug. Even when SWT.SELECTED is not negative, it seems good practice to use '!= 0' instead of '> 0'. – *Boris Bokowski*, 2013-10-31”

When using bit arithmetic, it is impossible to get a negative number as a result. Therefore, all x > 0 expressions should be transformed into a x != 0 expression. This is more concise and will reduce confusion. In general (if comparing with another number than 0) the greater than operator is also unusual but possible in my opinion, stated the bit arithmetic is applied to bigger numbers.

if ((x & y) > 0) ...

If one of the values that are input to the & operator is statically known to be negative at this point (e.g. a constant, or guarded before by a test for being <0), then the above should be marked as an **ERROR**. Otherwise it should be *WARNED* that this might be an error and *SUGGESTED* (quick-fix) that an explicit != comparison would be easier to understand.

if ((x & y) > 3) ...

If the comparison is to a constant bigger than 0 (or to a statically unknown value) no error or waring must be produced.

if ((x & y) != 0) { }

I doubt the numbers below are correct and rather guess the author did not understand the notions of precision and recall.

Benchmark project | Time | # Hits | Precision | Recall | |||||
---|---|---|---|---|---|---|---|---|---|

FB | JT | FB | JT | Delta | FB | JT | Delta | ||

Apache Tomcat | < 1s | 0 | 0 | 100% | 100% | 0 | 100% | 100% | 0 |

Argo UML | < 1s | 0 | 18 | 100% | 100% | 0 | 100% | 0% | 100 |

AWT | < 1s | 0 | 1 | 100% | 100% | 0 | 100% | 0% | 100 |

Jakarta | < 1s | 0 | 0 | 100% | 100% | 0 | 100% | 100% | 0 |

Java IO | < 1s | 0 | 0 | 100% | 100% | 0 | 100% | 100% | 0 |

JHotDraw | < 1s | 0 | 0 | 100% | 100% | 0 | 100% | 100% | 0 |

jrefactory | < 1s | 0 | 2 | 100% | 100% | 0 | 100% | 0% | 100 |

JServlet | < 1s | 0 | 0 | 100% | 100% | 0 | 100% | 100% | 0 |

JUnit | < 1s | 0 | 0 | 100% | 100% | 0 | 100% | 100% | 0 |

Lexi | < 1s | 0 | 0 | 100% | 100% | 0 | 100% | 100% | 0 |

Mapper XML | < 1s | 0 | 0 | 100% | 100% | 0 | 100% | 100% | 0 |

nutch | < 1s | 0 | 0 | 100% | 100% | 0 | 100% | 100% | 0 |

PMD | < 1s | 0 | 13 | 100% | 100% | 0 | 100% | 0% | 100 |

quickuml | < 1s | 0 | 0 | 100% | 100% | 0 | 100% | 100% | 0 |

FB = FindBugs, JT = JTransformer, Delta = JTransformer - FindBug

All measurements were taken on a machine with the following properties:

- JT Version: 4.0.0
- Eclipse Kepler
- Windows 8.1
- i5 2,30Ghz
- 8 GB Main Memory
- SSD Hardrive

teaching/labs/mdse/2013/bug_descriptions/jt-bug-cor10.txt · Last modified: 2019/06/28 19:31 by Günter Kniesel

SEWiki, © 2019