imagine something like this:
import class B.*;
interface A supports A.testSum
{
int sum( int a , int b ) access from B.calculator;
testSum() { Assert(sum(1,1)==2); }
........
class B ...
{
void calculator() { A.sum(3,5); //ok }
void someOtherMethod() { A.sum(0,3); //compile error }
the idea of the "supports" is secondary but relevant since the test applies to the interface in this case (so the language would discriminate between an interface test, which all implementations must pass and a implementation test, which is specific to the implementation privates
but the important idea i want to convey here is the access control semantics; notice that A.sum with "access from" keyword can only be called from the method B.calculator. Anything else is detected as a compile time error. The idea here is to enforce architectural constraints in a more granular way. If you didn't add an "access from" or just added "access from *" it would mean the default behavior of allowing the method to be called from anywhere. What sort of architectural constraints? well, the kind that are manually enforced when doing a layered design: Layer A(lowest level) is used from layer B(intermediate level), which is in turn used from layer C(high level). But layer B is not accessible from layer A, and layer C is not accesible from neither A or B, but it is public otherwise (it might be what the end user will have direct access)
question: do you know any language (including source-to-source intermediate languages) that support the above semantics? extra points for discussing if this kind of semantics would be counterproductive, dangerous or just encouraging bad design
Update: there is another really important use case for this sort of restriction:
event-driven programming: Usually the problem with event is that events tend to do too much, and the understanding the chain of dependencies for events can get tricky
so for instance, one could define that a event handler has only certain set of visible classes it can interact to (or conversely, a certain set of objects it cannot touch)
Java supports something pretty much the same thing.
First of all, visibility of fields and methods are enforced at runtime, it is not possible for unprivileged code to bypass this.
You can also make your own privileges, and grant them to certain parts of code. For example, to open a file, the code that wants to access a file needs FilePermission for that file. You can make any kind of permission you wish though, it's possible to make a permission called SumPermission which Calculator checks before summing, and only grant it to whatever classes you want. Protection domains span across classes, not individual methods in the classes, because a whole class is generally obtained from a single source. The model in fact goes deeper that what you proposed. Every class on the stack (including the history of thread creations) leading up to a security check must have the permission, so if some untrusted code calls your code that has SumPermission, it will fail the security check. Of course this is only default, whenever you do anything that needs permissions, you can use a doPrivileged block, to tell the upcoming check to only check your permissions instead of both yours and your callers.
However, the current default security scheme in Java has many limitations. For one, untrusted code can't subdivide its permissions or define its own permissions for nested untrusted code. Also, it's a pain to guard against untrusted code that blocks.
You may want to check out E. In particular, it follows the Object-Capability Model. It is made for mutually untrusted code to interact securely, and has language level constructs to prevent deadlocking issues.
It's perfectly possible and feasible to implement robust behavior between mutually untrusted code in Java, but E will probably make your job much easier, and runs on the JVM so you should still be able to use Java libraries and libraries from any other languages that use the JVM.