False negatives on DMI_HARDCODED_ABSOLUTE_FILENAME
I found false negatives on DMI_HARDCODED_ABSOLUTE_FILENAME when using SpotBugs to analyze my history code.
This code constructs a File object using a hard coded to an absolute pathname (e.g., new File("/home/dannyc/workspace/j2ee/src/share/com/sun/enterprise/deployment");
void testDMI_HARDCODED_ABSOLUTE_FILENAME(File vfile){
File pipe = new File("/tmp/fswebcam-pipe-" + vfile.getName() + ".mjpeg");
}
According to the source code, SpotBugs should report DMI_HARDCODED_ABSOLUTE_FILENAME. As I guess, it does not support analysis on string join.
If you're using a parameter to assemble the filename, that doesn't sound like hardcoding. See https://github.com/spotbugs/spotbugs/blob/51e586bed98393e53559a38c1f9bd15f54514efa/spotbugs/src/main/java/edu/umd/cs/findbugs/detect/DumbMethodInvocations.java#L141
If you're using a parameter to assemble the filename, that doesn't sound like hardcoding. See
https://github.com/spotbugs/spotbugs/blob/51e586bed98393e53559a38c1f9bd15f54514efa/spotbugs/src/main/java/edu/umd/cs/findbugs/detect/DumbMethodInvocations.java#L141
void testDMI_HARDCODED_ABSOLUTE_FILENAME(){
String extension = ".mjpeg";
File pipe = new File("/tmp/fswebcam-pipe-" + extension);
}
Thank you for your immediate response @ThrawnCA :)
I removed the parameter vfile, but it still does not work.
Technically yes, that is a situation where the filename is hardcoded, but it's a bit contrived, assembling it from two pieces that are both literal strings.
If you would like to enhance the detector to pick up this case, feel free.