Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / June 2007

Tip: Looking for answers? Try searching our database.

Understanding class access

Thread view: 
André Wagner - 31 May 2007 17:33 GMT
Hello,

let's say I'm writing a extension organized in packages such as:

mycompany.mypackage.MyClass
mycompany.mypackage.subpackage.MySubClass

The people who are going to use my extension will extend MyClass. So I
declare it to be public.

But I don't want people to be able to access MySubClass, so I can't
declare as public. But I want MyClass to be able to access MySubClass,
and if I don't declare MySubClass to be public, the compiler complains
that MySubClass is in a different package and must be public.

(I hope I'm being clear here :-)

Is there anyway that I can access MySubClass from MyClass, but make
MySubClass invisible for packages outside mycompany.mypackage?

Thank you in advance,

André
Chris Smith - 31 May 2007 18:03 GMT
> let's say I'm writing a extension organized in packages such as:
>
> mycompany.mypackage.MyClass
> mycompany.mypackage.subpackage.MySubClass

> Is there anyway that I can access MySubClass from MyClass, but make
> MySubClass invisible for packages outside mycompany.mypackage?

No, because in fact, though the names look herarchical, your
mycompany.mypackage.subpackage is outside of mycompany.mypackage.  (As a
side note, if MySubClass is a subclass of MyClass, then trying to access
MySubClass from MyClass is a cyclic dependency anyway.)

It's hard to suggest more than that without knowing why you don't want
anyone outside of mycompany.mypackage to access MySubClass.  Is it
simply an organizational principle?  If so, then you'll notice a lot of
packages in the standard librari have "implementation" or "provider"
subpackages, and just rely on documentation to say that others shouldn't
use it.  If it's a security issue, such as when running untrusted code
in the VM, then you'll have to redesign a bit more than that.

Signature

Chris Smith

angrybaldguy@gmail.com - 31 May 2007 18:07 GMT
> Hello,
>
[quoted text clipped - 19 lines]
>
> André

If you don't want MySubClass to be subclassed, declare it final --
that's what it's there for.
André Wagner - 31 May 2007 18:56 GMT
> If you don't want MySubClass to be subclassed, declare it final --
> that's what it's there for.

What I mean is: I don't want it to be accessed.

André
Twisted - 31 May 2007 21:37 GMT
> > If you don't want MySubClass to be subclassed, declare it final --
> > that's what it's there for.
>
> What I mean is: I don't want it to be accessed.

If you don't want it confusing people or "cluttering things up", just
don't include the javadoc for mysubpackage in your released
documentation bundle, or include in the package-info.html that it's a
private subpackage of little interest to most users.

If you really want to completely deny access to MySubclass except via
MyClass, make it a private nested class of MyClass.
Lew - 31 May 2007 21:42 GMT
>> If you don't want MySubClass to be subclassed, declare it final --
>> that's what it's there for.
>
> What I mean is: I don't want it to be accessed.

Move it to the same package and declare it package-private.

Signature

Lew

angrybaldguy@gmail.com - 01 Jun 2007 03:08 GMT
> Hello,
>
[quoted text clipped - 19 lines]
>
> André

If you don't want MySubClass to be subclassed, declare it final --
that's what it's there for.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.