#1169 Nullcheck and try-with-resources (jdk7)

[Baldurien]

The following code is getting me a RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE, but I can't do anything against it as it is "normal" : http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.20.3

try (FileChannel c = open(path, READ)) {
  final MappedByteBuffer mb = c.map(MapMode.READ_ONLY, 0L, c.size());
  ...
  return ...something...;
}

The problem lies with the JDK which rewrite such code to :

FileChannel c = null;
try {
  c = open(path, READ);
  final MappedByteBuffer mb = c.map(MapMode.READ_ONLY, 0L, c.size());
  ...
  return ...something...;
} finally {
  if (null != c) {try {c.close();} catch (Exception e) {...}}
}

A @Nullable on c make the error go away, but breaks with Eclipse 3.8 'nullcheck' analysis.

@SuppressFBWarnings("RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE") also works, but ... the annotation is quite long and break code formatting (but I can go with that).

[Baldurien]

Forgot to tell that I'm using Eclipse 3.8 + Findbugs Plugin 2.0.2.20121210 and that I do not encounter the same case in maven findbugs plugin 2.5.2 (2.0.1).

[William Pugh]

OK, I wasn't able to reproduce this exactly (see sfBugsNew.Bug1169 for my attempt), but I received a separate bug report that did show this problem, and committed a fix to HEAD to resolve it.

Can you check that the problem is resolved in HEAD, and if not, please submit a class file (preferred) or a full, compilable source file showing the problem.

[Baldurien]

I should apologize first, as I should've made a proper tests.

One correction on my previous post : I'm using Eclipse 4.2 (and not 3.8, but I use it at work) + FindBugs Feature 2.0.2.20121210.

Now, without not much any changes (except for using Findbugs configuration plugin for M2Eclipse/1.0.0.201303192141), I do not have the reported warning, but another : P_LOAD_OF_KNOWN_NULL_VALUE. note: before writing further, I tried with Findbugs Daily [2.0.3 2013.04.17] and it seems ok (I still gets them in maven, but the plugin is still using findbugs 2.0.1)

It comes on one of my tests :

:::java
  @Nonnull // <-- from findbugs maven artifact
  protected static <R> R executeEngine(@Nonnull final Engine<R> engine, @Nonnull final Path path) throws IOException {
    try (final FileChannel c = open(path, StandardOpenOption.READ)) {
      engine.reset();

      final MappedByteBuffer mb = c.map(MapMode.READ_ONLY, 0L, c.size());
      final int bufferLength = (int) KiloBytes.create(8).toBytes().getValue();
      final byte[] buffer = new byte[bufferLength];
      while (mb.hasRemaining()) {
        final int get = Math.min(mb.remaining(), bufferLength);
        mb.get(buffer, 0, get);
        engine.update(buffer, 0, get);
      }

      return engine.digest();
    }

  } <-- NP_LOAD_OF_KNOWN_NULL_VALUE

But in another code :

:::java
  @Override
  @Nonnull
  public <R> R execute(@Nonnull final Engine<R> engine, @Nonnull final Path path, @Nonnull final byte[] buffer)
      throws UnsupportedOperationException, IOException {

    try (FileChannel c = open(path, READ)) {
      engine.reset();
      final long size = c.size();

      long i = 0;
      while (i < size) {
        final MappedByteBuffer mb = c.map(MapMode.READ_ONLY, i, min(size - i, Integer.MAX_VALUE));
        final int bl = buffer.length;
        while (mb.hasRemaining()) {
          final int get = Math.min(mb.remaining(), bl);
          mb.get(buffer, 0, get);
          engine.update(buffer, 0, get);
          i += get;
        }
      }
      return engine.digest();
    } <-- nothing
  }

If you read the code, you would understand where the erratic part comes from : there are no warnings in that code, while it is almost the same.

[William Pugh]

Can you provide a class file that demonstrates the problem? I can't reproduce it.

[William Price]

I can confirm the original bug issue (RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE) with the following code in releases 2.0.1 and 2.0.2:

import java.io.*;

public class FindBugs1169 {

    public String reproduce() throws IOException {
        String str = "hi!";
        char[] buf = new char[str.length()];
        try (Reader reader = new StringReader(str)) {
            StringBuilder out = new StringBuilder();
            int bytes = reader.read(buf);
            while (bytes >= 0) {
                out.append(buf, 0, bytes);
                bytes = reader.read(buf);
            }
            return out.toString();
        }
        // workaround: move return outside of try-with-resources
        // return out.toString();
    }

}

For those hit by this bug, without adding annotations or other means to bypass the rule, a simple workaround is to move the return statement outside the try block if possible.

I built 2.0.3-SNAPSHOT from SVN trunk (specifically, revision 14771) and confirm that the issue is resolved for me. I don't know what the 2.0.3 release plan is, but may I please request that it be uploaded to Maven Central when ready? (2.0.2 never made it there.)

[William Pugh]

OK, I've added the last example to the regression test suite and all are fixed in HEAD.