Packages

[Mark Herschberg]

I know that, in general, Sun recommends package naming based on the name of an organization; for my company, Vaultus, we name our packages "com.vaultus..." For a company which makes an API, those APIs use the company's package name. To my knowledge, there is nothing to stop the user of the API from creating classes in the same packages as the API itself. If the API uses package level protection, such classes could have access not otherwise intended by the API's author.
How do API authors handle this? My only thought is to include a clause in the license to legeally prohibit this. Any other ideas?
--Mark
[e-mail]

[Damian, Harvey]

Why don't you look into preventing your code from being decompiled so users won't have access to view the methods in question.
Search for Obfuscate and in particular Neil Aggarwal's Obfuscate.
Regards,
Damian.

Originally posted by Mark Herschberg:
I know that, in general, Sun recommends package naming based on the name of an organization; for my company, Vaultus, we name our packages "com.vaultus..." For a company which makes an API, those APIs use the company's package name. To my knowledge, there is nothing to stop the user of the API from creating classes in the same packages as the API itself. If the API uses package level protection, such classes could have access not otherwise intended by the API's author.
How do API authors handle this? My only thought is to include a clause in the license to legeally prohibit this. Any other ideas?
--Mark
[e-mail]

[Frank Carver]

In general this is one of the problems of package-level access. Another is the maintenance aspects of classes which are too closely bound together and require that someone working on any class in the package needs to be constantly aware of the state and requirements of the other classes in the package.
For the last year or so, I have survived without ever needing "package" scope, instead using private as much as possible, protected only if I need very closely-coupled child access, and public only for methods and finals never for variable members.
Can you give us some examples of the kind of things you currently use package scope for? It may be that a small amount of refactoring could convert them to private or public-but-safe-to-call instead.

[Mark Herschberg]

Frank, ok, here's an example. I have five classes:

com.Facade
com.alpha.Hidden1
com.alpha.Hidden2
com.beta.Hidden3
com.beta.Hidden4

The hidden classes have a number of methods, not all of which I want to expose. I want all access to their functionality through the Facade class, making the API cleaner and easier to use. The developer using this API should never have to know about the alpha or beta packages, or their classes. (Often, methods in th4e Facade class are just call throughs.)
The four hidden classes may need to invoke methods on each other. What protection should I give those methods? Private won't work. package/Protected will work for Hidden1-Hidden2 method calls, as well as Hidden3-Hidden4. For calls between alpha and beta classes, I need public access. (I think tryig to create proxy objects, as subclasses with access to protected methods would make the code too complex. I'm not even sure if that would work.) What about the methods I need to let the Facade class expose?
NB: I would be extremely hesitant to collapse alpha and beta into one package.
What do you recommend? Currently, if a developer (API user) creates a class in com.alpha, that class can have access to methods I don't want to expose.
Damian, yes, we do obfuscate our code. Of course, obfuscation does not prevent methods from being invoked, it only makes it harder for those methods to be understood. Since these methods are "close to the surface," meaning invoked from methods in the visible API, they should be pretty easy to follow once decompiled.

--Mark
[e-mail]

[mohit joshi]

This looks like an interesting concept, having a facade for your code. Since you do not want to merge the two packages and still want to have method calls across them, how about having a facade class for each of your package.So all method calls to the Classes in package alpha will be accessed through a facade class.
In case you want some method to be private, you can have facade methods to access those methods as well.