Bug 201340

What is the relationship to the containership logic of a (non-SOURCE) ClassPath, i.e. binary CP includes/excludes? Sounds like there is some overlap.

JG01: The functionality is different from user point of view. When the class is excluded from the classpath it's not visible and marked as error (the project does not compile). When the classpath is black listed (not on white list) editor, code completion and task list just mark it as a warning (the project is compilable). It's not compile error it's only runtime restriction when the same app is deployed to different app server which has no restrictions the application should work. According to UI spec navigation to black listed class should work. 

Here is a part of UI Spec:
1) Whitelist violations are shown in editor  warnings and not errors.
2) These warnings are not shown in project logical view
3) In Tasks window whitelist violations have their own category. Ideally violations warnings in Tasks window have high priority so that they are shown at the top of the list just under compilation errors
4) Navigation on black listed element works
5) In code completion whitelist violations are shown  like deprecated with additional "yellow triangle" badge.

In addition to this UI difference there is also difference on granularity. The whitelist has to be able to disable only certain method(s) of the class not whole class. Originally it had to support also restriction of subclassing and overriding, the client was able to use the class but subclassing was restricted. This was removed from requirements but may return.

One possible use case would be to flag undeclared transitive dependencies from Maven NBM projects. (Maven automatically includes transitive dependencies in the classpath; there is a separate validation mojo run after compilation which checks the bytecode for references to API modules not in the direct dependency list, since these would not resolve in the NB module system.) But this means that the whitelist detector needs to understand implicit usages. For example,

package api1;
public interface Task {
  boolean succeeded();
}
package api2;
public class RunStuff {
  public static api1.Task start();
}
package client;
class Client {
  static boolean run() {
    return api2.RunStuff.start().succeeded();
  }
}

If client has an expressed dependency on api2 but not api1, the whitelist would include RunStuff but not Task. The editor must then show the call to succeeded() as a warning, even though the identifier "Task" never appears in Client.java.

It's possible.
The WhiteListImplementation.check gets ElementHandle for succeeded() and it can use  SourceUtil.getJVMSignature to get the [ClassBinaryName, methodName, methodVMSignature] and it can decide if the ClassBinaryName is allowed or not. It should not resolve the ElementHandle to Element as it's expensive and the WhiteList.check is called many times. Best way is to create a map of (allowed or forbidden) classes. I have a WhiteListImplementationBuilder which does it but it's not a part of this API review as it's currently very j2ee runtime specific. I will clean it up and send it for API review later on.

Fixed jet-main 3c2e3b50bbe8

Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/3c2e3b50bbe8
User: Tomas Zezula <tzezula@netbeans.org>
Log: #201340: API review of a friend white list API