Re: How to let the methods of a class only can be invoked by a special package(the class not in the package)?



Jebel.Star@xxxxxxxxx <Jebel.Star@xxxxxxxxx> wrote:
1 Add a protect method GetInstance() in Class B;
2 Add a class E which is extends from B in package XX.ZZ.GG. Create a
protected method GetInstance() which has the same function of
A.GetInstance() in class E. Remove the Method A.GetInstance().
3 Add a static member 'B e ' withe the default access right in Class
B, construct 'e'in the static block of B as 'E':
static{ e = new E; }

I'm not sure if I remember all involved classes correctly:
xx.zz.gg.B is the one you want only accessible from
classes in package xx.zz, which is principially
not possible to guarantee from JLS point fo view.

So, you create a class
xx.zz.E which derives from B, and thus has also available
all of B's protected functionality.

However, anyone else could create yet another derivative of B,
as hostile.mypackage.MyE, using the same mechanism as your E does,
to still access xx.zz.gg.B

Is my design OK ?
It's quite complicated for hardly any gain.

Java's protection scheme *cannot* discriminate between two
packages, when both are different from the current one.
Whatever you can do from classes of package xx.zz to access
classes in xx.zz.gg, you can always do the same from any
unrelated package aa.bb.cc, as well.

There are exactly these possibilities:
- use reflection or exception-stacktraces at runtime to
determine calling class (quite complicated, if you're
stuck in 1.3, and still some overhead even with 1.4's
new methods for easier stack-inspection.
- put all the relevant classes in one package. Or add a
class C to package xx.zz.gg that will wrap B's methods
such, that no misuse can occur when calling through C.
Then you can give all B's methods default-access.

Maybe we can help more, if you tell us, who/what exactly you
want to protect your class B from.
E.g. against crackers? Against accidental inappropriate use
from other parts of your own project?

.



Relevant Pages

  • RE: Passwords again
    ... You can not see the password after you set the package protection ... The password part of a connection string. ... please change the protection level to ...
    (microsoft.public.sqlserver.dts)
  • Re: "call to super must be first statement in constructor"
    ... I'm starting to find out some weird things about Java -- well, ... unnecessarily narrow use of interfaces. ... The package seems to be too large a unit of subdomain development. ... "protection" within a package at all. ...
    (comp.lang.java.help)
  • Re: SSIS package protection level
    ... You can't choose ServerStorage when saving to File System. ... deploy your package to SQL Server or change your ProtectionLevel to another ... Failed to apply package protection with error 0xC0014061 "The protection ...
    (microsoft.public.sqlserver.dts)
  • Re: Cant derive from class with private constructor?
    ... Protected is subclasses and package only. ... early days there was no such thing as private members. ... Everything was always accessible to package members. ... protection beyond C++, which probably makes sense because in reality package ...
    (comp.lang.java.programmer)