On Apr 3, 2013, at 11:00 PM, Jeroen Frijters <jer...@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
