Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

[John Rose]

On Apr 3, 2013, at 11:00 PM, Jeroen Frijters <jeroen at sumatra.nl> wrote:

> Given the ability to create constructorless subclasses, it really should be combined with making the class final.
> 
> My current rules for @CallerID (which unlike @CallerSensitive is not just about semantics, but also about implementation strategy) allow it only to be used on static methods and instance methods in final classes (in theory constructors would also be allowed, but I didn't implement that since I didn't encounter any that were worthwhile).

Yes, making the class final fixes the interface problem, and in a portable way.

It doesn't fix the ACC_SYNTHETIC problem.

> An implicit rule is that a @CallerID instance methods may not implement an interface method.

Another way to skin that cat is to have the JVM refuse to populate an i-table (or non-HotSpot equivalent) with CallerID.  It could populate the table entry with the thing that throws an AME or ICCE when a signature fails to match.  In effect, there would be an extra signature match enforced on such calls.

> Another thought that occurred to me was that there should probably be a test that goes through rt.jar and makes sure no ACC_BRIDGE or ACC_SYNTHETIC methods call @CallerSensitive methods.

That's an excellent point.  Similar cat-skinning idea:  The check could be done at link time, and throw something like ICCE.

(These are all JVM-centric ideas; that's the biggest hammer in my own toolkit.)

— John