Printable View
It seems that you can access package-private members from outside a third-party package, by adding your own class to the package which would access the package-visible members of other classes and expose them via its own public emthods. E.g. you could define your own class to be in package java.util, which could then access package-private members of java.util classes and expose them. Is that accurate? Are there no restrictions on defining your own classes to be in third-party packages?
Quote:
E.g. you could define your own class to be in package java.util, which could then access package-private members of java.util classes and expose them. Is that accurate?
Unless I'm missing something that sounds reasonable to me. After all that is exactly what the third party developers do all the time: add things to the package.
Have you searched java.util for a package private member and added your own class?
> what the third party developers do all the time: add things to the package.
I meant, what if _you_ add a class to _their_ package?
E.g. I had thought that if I create a package, say org.ilya, and have some
package-private members, then they cannot be read or written by anyone's code without going through my code.
But it seems that anyone can "parachute" their class into my package, and access package-private members that way. People normally don't do that of course; you don't normally write classes to be "parachuted into" java.util .
But it seems that this makes the package-private abstraction barrier optional rather than mandatory: anything exposed to the package can be read/written by any other program part directly. (In contrast to class-private members).
Is that correct?
Quote:
I meant, what if _you_ add a class to _their_ package?
Yes, I understood that. But I simply could not see how the javac executable was supposed to figure out whether or not I who had typed the command to compile was employed by Company X who wrote the library.
I am not sure what you mean by "going through" code. If there is a package private member in org.ilya then any class added to the package (by you, by me, by anyone who can invoke the javac executable) can - by design - access the member.
Personally I wonder whether "package-private abstraction" is any sort of barrier at all.
-------------------
So, have you ripped open src.jar and found a suitable test in one of the classes of java.util?
If you seal the jar where the entire package is stored, you can't add new classes to the package (without performing surgery on the original jar file).Quote:
Originally Posted by pbrockway2
kind regards,
Jos
Just what I was going to mention. If you want an example of that (OP), to see what it looks like, look at some of the jars in the JRE.Quote:
Originally Posted by JosAH
The Java access specifiers are intended as design/architectural features, not security features, assuming that was the thrust of the OP.