Proper support for INVOKEDYNAMIC about spotbugs HOT 17 OPEN

The warning are still there in 3.1.12 on 03.2019.

Added example project to reproduce:
https://github.com/ati90ati/bugreport-spotbugs-gradle-plugin-logging

#527

Maybe you can find a solution to fix this problem.

from spotbugs.

we should do a scan of other INVOKES and see what shows up, for instance
DismantleBytecode.isMethodCall() ignores invoke dynamic which would seem wrong.

from spotbugs.

With Java 17.0.4.1 and Gradle 7.5.1 and Spotbugs 4.7.2 (5.0.12 gradle plugin) I get the following when running spotbugs on the Desktop project github.com/pcnge/pcgen

Task :spotbugsMain
The following classes needed for analysis were missing:
makeConcatWithConstants
test
accept
run
newThread
equals
toString
hashCode
apply
applyAsInt
handleEvent
get
getAsInt
stateChanged
compare
execute
handle
processStatus
actionPerformed
allow
referenceChanged
changed
propertyChange
applyAsDouble
variableChanged
itemStateChanged
valueChanged

from spotbugs.

i know one of the detectors has FP because of INVOKEDYNAMIC, one of the useless variables one,... i'll have to find it.

from spotbugs.

@mebigfatguy do you mean UnreadFields?

I believe that one suffers the same issue described in #20, where even if detected, the priority is increased until it's discarded. This is taken from UnredFields

                if (getThisClass().isPrivate() || getMethod().isPrivate()) {
                    priority++;
                }
                if (getClassName().indexOf('$') != -1 || BCELUtil.isSynthetic(getMethod()) || f.isSynthetic()
                        || f.getName().indexOf('$') >= 0) {
                    priority++;
                }

Lambda bodies are moved to a private static synthetic or private synthetic method (depending on if it's capturing the instance reference or not). Being private AND being synthetic increases the priority from low (2) to experimental (4).

The thing is, there is no definite way of identifying a lambda. They are private static? synthetic, but they don't need to be the only ones (specially if the bytecode is being manipulated by tools such as AspectJ's compiler or RetroLambda).

The method names "conventionally" include the word "lambda", but there is no formal requirement for this on the Java spec, so I would advise against this method.

Therefore, lambda detection is limited to checking if a method is private synthetic, and this may produce FPs.

Thankfully, there will be no FPs with accessor methods, since those are always package-private.

from spotbugs.

@jsotuyod @mebigfatguy Do we have known problem in this topic? Can we release RC1 without closing this issue?

from spotbugs.

@KengoTODA I'm ok. This was more of an umbrella issue, the particular cases we were able to identify were fixed. Actually the changes in #21 probably resolved several related issues.

We can probably close this and just open particular issues as needed.

from spotbugs.

I think it's useless variables or something. You create a collection and then don't do anything with it. But you do use it with an invoke dynamic

from spotbugs.

@mebigfatguy good thinking!

from spotbugs.

What is the status of this issue? Can we release 3.1.0 without this?

from spotbugs.

i'm fine with releasing as is.

from spotbugs.

I guess SpotBugs itself cannot do anything about this, but I thought I'd mention it here for reference or if you actually can do something about it: find-sec-bugs/find-sec-bugs#332

from spotbugs.

Found another place, this time in SpotBugs itself edu.umd.cs.findbugs.ba.Hierarchy#resolveMethodCallTargets(org.apache.bcel.generic.InvokeInstruction, edu.umd.cs.findbugs.ba.type.TypeFrame, org.apache.bcel.generic.ConstantPoolGen) calls typeFrame.getInstanceStackLocation(invokeInstruction, cpg) which returns -1. typeFrame.getStackValue(instanceStackLocation) then of course throws an Error generating derefs for ... edu.umd.cs.findbugs.ba.DataflowAnalysisException: can't get position -1 of stack.

I can reproduce this with the following file:

import java.io.File;
import java.util.ArrayList;
import java.util.List;

public class Test
{
   public static void main(String[] args) throws Exception
   {
      List<String> notOkList = new ArrayList<>();
      for (String fileName : new File("").list()) { }
      notOkList.forEach(notOk -> System.out.println(notOk));
   }
}

from spotbugs.

What's the progress on this?

I'm still getting errors in 2018 with 3.1.7:

The following classes needed for analysis were missing:
  accept
  handle
  get
  apply
  handleConnection
  handleUserCheck

from spotbugs.

Still getting these warnings in 3.1.10

from spotbugs.

Hello everyone,

It is possible to know if this issue could be leading to False Positives detection?

SpotBug in combination with FindSecBug, generates different results depending on the Java bytecode version.

Using a Java version greater than 8 to generate the bytecode, the number of False positives increases considerably.

from spotbugs.

I remember one false positive when I upgraded from Java 8 to Java 11 (actually it wasn't a false positive).

I think it was in try with resources and auto closeable Java feature.

With Java 8 I didn't get the warning from Spotbugs, but with Java 11 I got some warnings in try with resources.

I investigated the bytecode generated in Java 8 vs bytecode of Java 11 and actually it was different.

If you decompile the class files you can see that there is a real issue in there and not a false positive and Spotbugs highlighted that issue from the generated bytecode.

Because I couldn't fix the generated bytecode I decided to suppress those warnings in Spotbugs.

from spotbugs.