Annotation for fine-tuning access control

Comrades,

In some of my (team-based) projects, I've found the need for more fine-grained method access control: I know that the access modifiers already address this concern, though what I'm looking for is for the compiler/IDE togracefully inform the developer that a certain method is meant only to be accessed by ThisAndThatClass but not ThatClass - similar to how @Override informs the user if the annotated method isn't overridden.

Eg, something similar to:

@LimitAccess({This.class, That.class})

protectedvoid someMethod()

{

System.out.println("yo.");

}

I've browsed the web for some example annotations providing similar functionality, but, so far, haven't found anything but the most rudimentary in terms of tutorials - though, correct me if I am wrong, I think it should be possible with annotations - any pointers to good resources would be gratefully received.

Respectfully,

Adrian

[1167 byte] By [blackraxora] at [2007-11-27 0:38:45]
# 1

> Comrades,

>

> In some of my (team-based) projects, I've found the

> need for more fine-grained method access control: I

> know that the access modifiers already address this

> concern, though what I'm looking for is for the

> compiler/IDE to gracefully inform the

> developer that a certain method is meant only to be

> accessed by ThisAndThatClass but not ThatClass -

> similar to how @Override informs the user if the

> annotated method isn't overridden.

This is a job for a modules system. Work is underway on that problem for the JDK (JSRs 277 and 294); NetBeans also has a modules system and Eclipse supports OSGi.

j.d.darcya at 2007-7-11 22:49:56 > top of Java-index,Core,Core APIs...
# 2
Ah, bummer. Well, JSR-294, for the most part, address my problem. JSR-277 and OSGI appear to be more concerned with distribution than ongoing team development.
blackraxora at 2007-7-11 22:49:56 > top of Java-index,Core,Core APIs...
# 3

A custom AnnotationProcessor can provide checks for some class relationships and output compile-time notes, warnings, or errors (halting compilation). IsA and HasA can be checked, but "uses" and "used by" cannot. However, you should be able to enforce the granularity with interfaces...

interface FooCallable {

void foo();

}

interface BarCallable {

void bar();

}

class Foo implements FooCallable {

void foo() { System.out.println( "foo" ); }

}

class Bar implements BarCallable {

void bar() { System.out.println( "bar" ); }

}

class FooBar implements FooCallable, BarCallable {

void foo() { System.out.println( "foo" ); }

void bar() { System.out.println( "bar" ); }

}

class ShazBot implements BarCallable {

// I aint no Foo

void bar() { System.out.println( "yapple dapple" );

}

class FineGrainAccess {

void fizzle( FooCallable fc ) { fc.foo(); }

BarCallable wuzzle() { return new ShazBot(); }

}

FineGrainAccess.fizzle can be passed a Foo instance or a FooBar instance, but inside the object must be accessed as a FooCallable, foo only

FineGrainAccess.wuzzle can return a Bar instance or a ShazBot instance, but outside the object must be accessed as a BarCallable, bar only

All constraints would be compiler-checked.

developer_jbsa at 2007-7-11 22:49:56 > top of Java-index,Core,Core APIs...