4.8.0 PI_DO_NOT_REUSE_PUBLIC_IDENTIFIERS_CLASS_NAMES False positives

[josephearl]

Upgrading to 4.8.0 I get a lot of what I believe are false positives like:

PI | Class name ?>?1/1??? in source file ?>?2/1??? shadows the publicly available identifier from the Java Standard Library.
Bug type PI_DO_NOT_REUSE_PUBLIC_IDENTIFIERS_CLASS_NAMES
In class com.my.package.SomeException
At SomeException.java:[lines 9-19]

Where SomeException is a custom exception subclass.

And the class name and source in the message are weird characters instead of the actual class name and source (which is shown in the details)

[JuditKnoll]

Can you please provide a minimal, complete and verifiable example?

[josephearl]

This is the class it is complaining about as far as I can see:

package com.my.package;

import java.util.Map;

public class SomeException extends RuntimeException {
  private final Map<String, Object> data;

  public SomeException(String message, Map<String, Object> data, Throwable cause) {
    super(message, cause);
    this.data = data;
  }

  public SomeException(String message, Map<String, Object> data) {
    super(message);
    this.data = data;
  }

  public Map<String, Object> getData() {
    return data;
  }
}

[JuditKnoll]

@norbo03 As the author of #2511, can you please look into this issue?

[iloveeclipse]

We see also LOT of such meaningless warnings reported, also with broken ?>?1/1??? type names etc. Just tried 4.8.0 yesterday locally for the first time.

[uhafner]

I also can confirm that this happens at different places:
https://github.com/uhafner/codingstyle/pull/829/checks?check_run_id=17667365889

[gtoison]

That detector is looking for every single class name in the entire JDK.
Most of them are in internal packages (com.sun.* for instance) so IMO it is perfectly OK to use them.
For instance there are 6 instances of the Filter class name in the JDK, that one alone will surely produce false positives.

Also the detector reports the name of the top-level class when finding a problem with an inner class (it reports LineRangeList instead of Cursor here: https://github.com/uhafner/codingstyle/blob/main/src/main/java/edu/hm/hafner/util/LineRangeList.java)

[iloveeclipse]

This detector false positives rate is nearly 99%.
We should disable it by default, it is of academic interest only (beside that it's reporting is buggy).

[iloveeclipse]

@norbo03 As the author of #2511, can you please look into this issue?

Note, there are actually two issues:

1. The high rate of false positives ("fixed" by disabling detector by default). I doubt there is any other way to fix that, as the main idea of detector is questionable at least, so it is "broken by design".
2. Bugs during reporting of found problems. That is not fixed yet, so @norbo03 it would be nice if you could fix that properly, just in case someone wants enable the detector.

[norbo03]

Thank you for letting me know about the issues. I'll investigate to find out what's causing the detector problems. As for the strange messages, I think I know the cause of the problem.
I'm really sorry for the caused problems. I'll make sure to keep you updated on the progress.

[noorul]

Can we roll out a new release?

[JuditKnoll]

Can we roll out a new release?

AFAIK it's planned soon. Here is the discussion about it: #2674