Bug 201340 - API review of a friend white list API
API review of a friend white list API
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Source
7.1
All All
: P2 (vote)
: 7.1
Assigned To: Tomas Zezula
issues@java
: API, API_REVIEW_FAST
Depends on: 201762
Blocks: 201453
  Show dependency treegraph
 
Reported: 2011-08-25 21:59 UTC by Tomas Zezula
Modified: 2011-09-07 16:18 UTC (History)
2 users (show)

See Also:
Issue Type: TASK
:


Attachments
Diff file (61.56 KB, patch)
2011-08-25 21:59 UTC, Tomas Zezula
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Zezula 2011-08-25 21:59:58 UTC
Created attachment 110224 [details]
Diff file

Added white list API to check violations of runtime restrictions. The project types supporting a runtime
with class usage restriction implement the WhiteListQueryImplementationto provide a white list of allowed types (methods). The API is friend and under development as the use cases may change in the future.

Original usecases:
Allow restriction of method call, type usage, overriding of method, subclassing.

The original usecases were simplified to restriction of method call, type usage.

The API and SPI is designed in such a way that adding the support for restriction of overriding of method and subclassing will be compatible change.
Comment 1 Jesse Glick 2011-08-25 23:45:06 UTC
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.
Comment 2 Tomas Zezula 2011-08-26 05:52:09 UTC
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.
Comment 3 Jesse Glick 2011-08-26 14:33:15 UTC
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.
Comment 4 Tomas Zezula 2011-08-29 08:13:26 UTC
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.
Comment 5 Tomas Zezula 2011-08-29 09:41:17 UTC
Fixed jet-main 3c2e3b50bbe8
Comment 6 Quality Engineering 2011-09-01 14:21:58 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo