access permissions for a method.

[peter cooke]

Hi;
Hoping new annotations will help me do what I want to do.

I have 2 classes (Foo and Bar) in 2 different packages

Foo does not/cannot inherit from Bar.


Foo needs to call a method on bar.
The problem is the method need to allow access only to it from a call from the class Foo or Bar. Preferably hide it all together from other classes.

Any thoughts???

[Ulf Dittmer]

The clean approach would be to put them together into the same package and have no other classes in that package. And then make the method protected or package protected.

If that's not an option somehow, the dirty (and comparatively slow) approach might be to check the stack trace that the calling method or class is what you want it to be.

[Winston Gutkowski]

peter cooke wrote:The problem is the method need to allow access only to it from a call from the class Foo or Bar. Preferably hide it all together from other classes.
Any thoughts???

Yes: why do you need to do this? It sounds very arcane.

However, if the reason for calling the method is to get a result of some kind, one possibility would be to add a proxy class in Bar's package that can call this method on behalf of a Foo, and update the Foo with its result. Alternatively, you could prevent any other class from calling it by supplying an object that can ONLY be created by a Foo. Either way, if you set it up right, no other class would ever be able to see the result.

But it's incredibly tortuous, so my advice would be to back up and work out WHY you want to do this. Don't leap to the HOW until you understand that.

Winston

[Winston Gutkowski]

Winston Gutkowski wrote:Alternatively, you could prevent any other class from calling it by supplying an object that can ONLY be created by a Foo.

Actually, you could do it directly:

public class Foo {
   public static final class Carrier {
      private Result result;
      private Carrier() {
      }
      public final void setResult(Result r) {
         result = r;
      }
   }

   ...

   private void runProtectedMethod(Bar b, whatever) {
      Carrier c = new Carrier();
      b.protectedMethod(c, whatever);
      // do whatever you need to do with the Result
   }
}

// and then in Bar's package:

public class Bar {
   ...

   public final void protectedMethod(Foo.Carrier carrier, whatever) {
      if (carrier == null)
         throw new IllegalArgumentException(
            "you must supply a Carrier");
      Result r;
      // do whatever needs to be done
      carrier.setResult(r);
   }
}

but, like I say, incredibly tortuous.

Winston

[Henry Wong]

Ulf Dittmer wrote:
If that's not an option somehow, the dirty (and comparatively slow) approach might be to check the stack trace that the calling method or class is what you want it to be.

Although called "dirty", I actually like this option -- it seems "clean" to me...

peter cooke wrote:
I have 2 classes (Foo and Bar) in 2 different packages

Foo does not/cannot inherit from Bar.


Foo needs to call a method on bar.
The problem is the method need to allow access only to it from a call from the class Foo or Bar. Preferably hide it all together from other classes.

I guess theMethod() on Bar can be written like so...

package com.javaranch.bar;

class Bar {
	private boolean confirmCaller(String callclass) {
		String classname = getClass().getName();
		Exception ex = new Exception();
		StackTraceElement[] elements = ex.getStackTrace();
		
		int i;
		for (i = 0; i < elements.length; i++) {
			if (!classname.equals(elements[i].getClassName())) break;
		}

		return ((i < elements.length) && (elements[i].getClassName().equals(callclass))) ||
		       ((i >= elements.length) && (classname.equals(callclass)));
	}
	
	public void theMethod() {
		if (confirmCaller("com.javaranch.foo.Foo") || confirmCaller("com.javaranch.bar.Bar")) {
			System.out.println("run code here");;
		}
	}
}

And it can be called from Foo, like so...

package com.javaranch.foo;

import com.javaranch.bar.Bar;

public class Foo {

	public static void main(String[] args) {
		new Bar().theMethod();
	}

}

Henry

[Winston Gutkowski]

Henry Wong wrote:Although called "dirty", I actually like this option -- it seems "clean" to me...

Hmmm. My main worry is that it relies on parsing a structure that is very slow to create and from which you can only get Strings. It seems to me that my set-up - cumbersome though it is - could possibly be developed into a class-specific method Pattern; maybe involving a proxy class so as not to disturb the original.

Personally, I don't like the idea of class-specific methods in general; but if you're going to do it, it seems to me that passing a class-specific key is more self-documenting. Whether or not you use that key to pass back results is up to you.

Winston