To get a trial key
fill out the form below
Team License (standard version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Request our prices
New License
License Renewal
--Select currency--
USD
EUR
GBP
RUB
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
>
Top-10 Bugs in Java Projects in 2020

Top-10 Bugs in Java Projects in 2020

Dec. 28, 2020

The New Year is steadily approaching, therefore it's time to sum everything up. Continuing the tradition, we thought back to our articles about checking Java projects from the open-source world for this year and rated the top 10 most exciting bugs.

0788_Top_10_Java_bugs_2020/image1.png

In 2020 we (the PVS-Studio's Java team) have reviewed errors from five open-source projects and also touched upon our inner workings in our articles:

First, we suggest that readers get to know these articles and make their personal rankings, then compare them with ours, and say if we are wrong :).

N10. Tricky equality

Source: Big / Bug Data: Analyzing the Apache Flink Source Code

V6001 There are identical sub-expressions 'processedData' to the left and to the right of the '==' operator. CheckpointStatistics.java(229)

@Override
public boolean equals(Object o) 
{
  ....
  CheckpointStatistics that = (CheckpointStatistics) o;
  return id == that.id &&
    savepoint == that.savepoint &&
    triggerTimestamp == that.triggerTimestamp &&
    latestAckTimestamp == that.latestAckTimestamp &&
    stateSize == that.stateSize &&
    duration == that.duration &&
    alignmentBuffered == that.alignmentBuffered &&
    processedData == processedData &&                // <=
    persistedData == that.persistedData &&
    numSubtasks == that.numSubtasks &&
    numAckSubtasks == that.numAckSubtasks &&
    status == that.status &&
    Objects.equals(checkpointType, that.checkpointType) &&
    Objects.equals(
      checkpointStatisticsPerTask, 
      that.checkpointStatisticsPerTask);
}

Here's an example of a simple and very disappointing mistake which occurred due to inattention: the processedData field is compared to itself. Because of this mistake, comparison of the CheckpointStatistics type objects will sometimes give a false positive result. But the main danger of this typo lies in the fact that equals is very actively used in collections, and incorrect implementation of this method can lead to very strange behavior, which will take a huge amount of time to debug.

For the record, it is common for developers to make mistakes in comparison functions. My colleague even wrote a whole article "The Evil within the Comparison Functions" with lots of examples and explanations.

N9. Unreachable code

Source: Unicorns on Guard for Your Safety: Exploring the Bouncy Castle Code.

V6019 Unreachable code detected. It is possible that an error is present. XMSSTest.java(170)

public void testSignSHA256CompleteEvenHeight2() {
    ....
    int height = 10;
    ....
    for (int i = 0; i < (1 << height); i++) {
        byte[] signature = xmss.sign(new byte[1024]);
        switch (i) {
            case 0x005b:
                assertEquals(signatures[0], Hex.toHexString(signature));
                break;
            case 0x0822:
                assertEquals(signatures[1], Hex.toHexString(signature));
                break;
            ....
        }
    }
}

The switch branch for the value i == 0x0822(2082) happens to be unreachable. How on earth did that happen?

If you pay attention to the 1 << height loop condition where height is always equal to 10, then everything immediately falls into place. According to the loop condition, the counter i in the for loop can't be greater than 1024 (1 << 10). Obviously, the execution of the switch branch in question will never happen.

N8. Annotated method

Source: Under the Hood of PVS-Studio for Java: How We Develop Diagnostics.

V6009 Collection is empty. The call of the 'clear' function is senseless. MetricRepositoryRule.java(90)

protected void after()
{
  this.metricsById.clear();
  this.metricsById.clear();
}

Some of our diagnostics rely heavily on the method annotation mechanism. Annotations provide additional information to the analyzer about the methods used. For example, they show:

  • If a method is pure,
  • What restrictions are posed on arguments,
  • Returned result,
  • ... and things like that.

Some annotations are derived by the analyzer itself from the source code, and some are added manually (for example, for the standard library methods). The story of this error began with the fact that we did not fully annotate the Map#clear method. After we noticed and fixed it, new warnings (including our peculiar case) appeared on our test projects.

At first glance, re-clearing a dictionary is not an error. And we would even think that this is a randomly duplicated string if we did not pay attention to class fields:

private final Map<String, Metric> metricsByKey = new HashMap<>();
private final Map<Long, Metric> metricsById = new HashMap<>();

The class has two fields with similar names metricsByld and metricsByKey. This got us thinking that the author wanted to clear both dictionaries but ... that did not happen. Thus, two dictionaries that store related data will be put out of sync after calling after.

N7. Expectation / reality

Source: Checking WildFly, a JavaEE Application Server.

V6058 The 'equals' function compares objects of incompatible types: String, ModelNode. JaxrsIntegrationProcessor.java(563)

// Send value to RESTEasy only if it's not null, empty string, or the 
// default value.
private boolean isTransmittable(AttributeDefinition attribute,
                                ModelNode modelNode) {
  if (modelNode == null || ModelType
      .UNDEFINED.equals(modelNode.getType())) {
    return false;
  }
  String value = modelNode.asString();
  if ("".equals(value.trim())) {
    return false;
  }
  return !value.equals(attribute.getDefaultValue());        // <=
}

According to the comment before the method, we can expect the method to return true, if:

  • modelNode is not null,
  • the string representation of modelNode is not empty,
  • modelNode is not the default value.

Despite the author's comment and the logic that seems correct at first glimpse, the method's behavior will be different. The reason for this is the modelNode check for equality with the default value in the method's last line.

The modelNode string representation is compared to an object of ModelNode type, and as you might guess, such a comparison will always return a negative result due to type incompatibility.

Error consequences are as follows: an unexpected permission to send the modelNode value when it is equal to the default value (attribute.getDefaultValue()).

N6. Copy-paste-oriented programming

Source: Checking the Code of XMage, and Why You Won't Be Able to Get the Special Rare Cards of the Dragon's Maze Collection.

V6072 Two similar code fragments were found. Perhaps, this is a typo and 'playerB' variable should be used instead of 'playerA'. SubTypeChangingEffectsTest.java(162), SubTypeChangingEffectsTest.java(158), SubTypeChangingEffectsTest.java(156), SubTypeChangingEffectsTest.java(160)

@Test
public void testArcaneAdaptationGiveType() {
    addCard(Zone.HAND, playerA, "Arcane Adaptation", 1);
    addCard(Zone.BATTLEFIELD, playerA, "Island", 3);

    addCard(Zone.HAND, playerA, "Silvercoat Lion");
    addCard(Zone.BATTLEFIELD, playerA, "Silvercoat Lion");
    addCard(Zone.GRAVEYARD, playerA, "Silvercoat Lion");   // <=

    addCard(Zone.HAND, playerB, "Silvercoat Lion");
    addCard(Zone.BATTLEFIELD, playerB, "Silvercoat Lion");
    addCard(Zone.GRAVEYARD, playerA, "Silvercoat Lion");   // <=

    ....

    for (Card card : playerB.getGraveyard().getCards(currentGame)) {
        if (card.isCreature()) {
            Assert.assertEquals(card.getName() + " should not have ORC type",
                    false, card.getSubtype(currentGame).contains(SubType.ORC));
            Assert.assertEquals(card.getName() + " should have CAT type",
                    true, card.getSubtype(currentGame).contains(SubType.CAT));
        }
    }
}

A cool copy-paste error from the V6072 diagnostic rule earns a place in the top 10 of this year. The same happened in 2019 (Top 10 errors for 2019).

The error's nature is as follows. When the developer needs to do similar actions for different variables, they copy the code, faithfully written previously, and change the variable's name. But they do this quite negligently and forget to modify the variables in some places.

That's exactly what happened in this code snippet. The test's author simulated the game between the players, scattering the same cards between them in the game zones, but because of the copy-paste, the playerA got the same card twice. Due to this, the game zone Zone.GRAVEYARD of the playerB was left without testing. A detailed description of the error can be found in the article itself.

N5. Non-normal distribution

Source: Big / Bug Data: Analyzing the Apache Flink Source Code

V6048 This expression can be simplified. Operand 'index' in the operation equals 0. CollectionUtil.java(76)

public static <T> 
Collection<List<T>> partition(Collection<T> elements, int numBuckets) 
{
  Map<Integer, List<T>> buckets = new HashMap<>(numBuckets);
  
  int initialCapacity = elements.size() / numBuckets;

  int index = 0;
  for (T element : elements) 
  {
    int bucket = index % numBuckets;                                 // <=
    buckets.computeIfAbsent(bucket, 
                            key -> new ArrayList<>(initialCapacity))

           .add(element); 
  }

  return buckets.values();
}

The error was found in the partition utility method, which splits the elements collection into numBuckets of collections. The essence of the error is that the bucket collection's index, in which each element in question is going to be placed, has a constant value (0). The reason for this is that the developer forgot to increment the index variable at each iteration of the loop.

As a result, the partition method will always return the elements collection wrapped in another collection. And this is hardly the intended behavior.

N4. A time bomb

Source: NSA, Ghidra, and Unicorns.

V6008 Null dereference of 'selectedNode' in function 'setViewPanel'. OptionsPanel.java(266)


private void processSelection(OptionsTreeNode selectedNode) {
  if (selectedNode == null) {
    setViewPanel(defaultPanel, selectedNode); // <=
    return;
  }
  ....
}
private void setViewPanel(JComponent component, OptionsTreeNode selectedNode) {
  ....
  setHelpLocation(component, selectedNode);
  ....
}
private void setHelpLocation(JComponent component, OptionsTreeNode node) {
  Options options = node.getOptions();
  ....
}

The above code snippet is certainly messed up. If you follow selectedNode from processSelection(), when selectedNode == null, you will immediately find that with this outcome, NullPointerException inevitably awaits us. This is exactly what the analyzer warns us about.

But after studying the code a little, the author of the article concluded that the program execution will never meet NullPointerException, since the processSelection() method is called in only two places, before calling which, selectedNode is explicitly checked for the null.

Despite this, such code is a time bomb, because another developer may notice that the method explicitly handles the case of selectedNode == null, and decide that this is a valid value, which will then result in the application crash.

N3. Always false

Source: Checking the Code of XMage, and Why You Won't Be Able to Get the Special Rare Cards of the Dragon's Maze Collection.

V6007 Expression 'filter.getMessage().toLowerCase(Locale.ENGLISH).startsWith("Each ")' is always false. SetPowerToughnessAllEffect.java(107)

@Override
public String getText(Mode mode) {
  StringBuilder sb = new StringBuilder();
  ....
  if (filter.getMessage().toLowerCase(Locale.ENGLISH).startsWith("Each ")) {
    sb.append(" has base power and toughness ");
  } else {
    sb.append(" have base power and toughness ");
  }
  ....
  return sb.toString();
}

Who compares a lowercase string to a string that starts with a capital letter? Hence, we've got an always false result of the message's check.

The defect's result is not critical, but nasty as well: a poorly written text will appear somewhere.

N2. 2-in-1

Source: NSA, Ghidra, and Unicorns.

V6007 Expression 'index >= 0' is always true. ExternalNamesTableModel.java(105)

V6019 Unreachable code detected. It is possible that an error is present. ExternalNamesTableModel.java(109)

public void setValueAt(Object aValue, int row, int column) {
  ....
  int index = indexOf(newName);
  if (index >= 0) {                  // <=
    Window window = tool.getActiveWindow();
    Msg.showInfo(getClass(), window, "Duplicate Name",
                 "Name already exists: " + newName);
    return;
  }

  ExternalPath path = paths.get(row); // <=
  ....
}

private int indexOf(String name) {
  for (int i = 0; i < paths.size(); i++) {
    ExternalPath path = paths.get(i);
    if (path.getName().equals(name)) {
      return i;
    }
  }
  return 0;
}

The indexOf method always returns a non-negative number. This is due to the fact that the method's author returns 0 instead of -1 by mistake in case newName is absent in the collection. This error results in the program's execution flow always entering the then-branch of the if (index >= 0) conditional statement, in which it will generate the message about the existing newName and successfully exit the method, even though in reality newName was not found.

But it's not the end of the story. Since the then-branch of the conditional statement exits the method, the execution flow won't reach the code after the conditional statement.

This is exactly what the analyzer warns us about.

N1. Did we check the right one?

Source: Under the Hood of PVS-Studio for Java: How We Develop Diagnostics.

V6080 Consider checking for misprints. It's possible that an assigned variable should be checked in the next condition. Menu.java(40)

public class Menu
{
  private Map<String, List<String>> menus = new HashMap<String, List<String>>();

  public void putMenuItem(String menu, String item)
  {
    List<String> items = menus.get(menu);
    if (item == null)                      // <=
    {
      items = new ArrayList<String>();
      menus.put(menu, items);
    }
    items.add(item);
  }
  ....
}

According to the author's idea, this method was supposed to create a collection using the menu key, if there was not one yet. But a wrong variable check ruined the whole idea, cutting a loophole for NullPointerException. The method will throw the exception when the menu key is absent in the dictionary, and the item value that we wanted to add will not be null.

Conclusion

Each year PVS-Studio checks of open-source projects prove that such stage of protection as static code analysis must necessarily take place in development. No matter how skilled you are, mistakes will always find a loophole in your project, and there are many reasons for this: you may get tired, swamped with work, or even be distracted by cats. And if you work in a team, the number of possibilities for errors to get in the code increases proportionately to the number of colleagues.

If you enjoyed our review, then don't wait for the next year's end. Articles about checks will come out immediately at the beginning of 2021, but if you can't wait, feel free to download the analyzer and check open-source projects by yourself.

Popular related articles
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: 10.22.2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
The Ultimate Question of Programming, Refactoring, and Everything

Date: 04.14.2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
PVS-Studio for Java

Date: 01.17.2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
The way static analyzers fight against false positives, and why they do it

Date: 03.20.2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
The Evil within the Comparison Functions

Date: 05.19.2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
Free PVS-Studio for those who develops open source projects

Date: 12.22.2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
PVS-Studio ROI

Date: 01.30.2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: 07.31.2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
Static analysis as part of the development process in Unreal Engine

Date: 06.27.2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
The Last Line Effect

Date: 05.31.2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…

Comments (0)

Next comments

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept