Java basic question about protected methods

[b4u]

Hi,

About protected methods: a protected method is available to sub-classes of the declaring class, and to all other classes that belong to the same package.

Well, this is a basic Java definition, and it works quite well.

Now my problem is the following, how can I block the access to any others but the sub-classes? Any trick to do that?

Let's say I create a protected (and final) method that will be called from the main class itself. Since I want the implementation to be required, on the main method I create it as an abstract method. So anyone that extends the class will have to implement the method. Perfect! But then again, I don't want anyone to be able to call it externally ... the question is, I cannot (or can I?) avoid people to create an external (totally independent) class, put it on the same package, and call the method directly.

So I could develop a framework for some job, distribute as a single external jar file, but people could still create a class on the same package and directly access the protected methods. There are some partial solutions on my mind to control this (nothing concrete yet), but I was hopping to also get some opinions from this forums.

Is there any trick to avoid that?

 

[b4u]

Something I found (google is great 🙂):

Sealing Packages in Extensions

You can optionally seal packages in extension JAR files as an additional security measure. If a package is sealed, all classes defined in that package must originate from a single JAR file.

Without sealing, a "hostile" program could create a class and define it to be a member of one of your extension packages. The hostile software would then have free access to package-protected members of your extension package.

Sealing packages in extensions is no different than sealing any JAR-packaged classes. To seal your extension packages, you must add the Sealed header to the manifest of the JAR file containing your extension. You can seal individual packages by associating a Sealed header with the packages' Name headers. A Sealed header not associated with an individual package in the archive signals that all packages are sealed. Such a "global" Sealed header is overridden by any Sealed headers associated with individual packages. The value associated with the Sealed header is either true or false.

Sealing Packages in Extensions

So would sealling the package solve this problem? That info (seal info) will be stated on the manifest file, so can anyone change the jar manifest file to "remove" the sealing?

 

[MrChad]

One possible option is to give your base classes private constructors so that they can't be instantiated directly. Assuming that your protected methods are not static, only subclasses of the base classes would have access to those methods.

 

[kamper]

Originally posted by: MrChad
One possible option is to give your base classes private constructors so that they can't be instantiated directly. Assuming that your protected methods are not static, only subclasses of the base classes would have access to those methods.

2 things:
1) "base class with private constructors" is an oxy-moron 😉
2) As he explained above, your second sentence is not true. protected members are available to any class in the same package. Imho, this is one of the more serious flaws in the language. The package concept is not used nearly as much as the designers planned, people mostly use it only for organization.

Originally posted by: b4u
So would sealling the package solve this problem? That info (seal info) will be stated on the manifest file, so can anyone change the jar manifest file to "remove" the sealing?

Yes, but they could also use reflection to call your protected (or even private) methods unless you go to the hassle of setting up a security manager which might not be possible to do safely if someone else is using your jar.

Or, they could just manipulate your byte code to change the access level, or anything else they could dream of. I guess you can get around that by signing your jars but then you have to trust the virtual machine that they choose to use as well 😛

Basically the only real 'security' in java code is obfuscation, which is obviously doesn't work if you want people to inherit from your base classes (and it's not really infallible).

But that's all a little extreme for your example. At some point you have to give up and let people screw themselves over if they really want to. I'd personally consider sealed jars but it wouldn't be a priority.

 

[MrChad]

Originally posted by: kamper

Originally posted by: MrChad
One possible option is to give your base classes private constructors so that they can't be instantiated directly. Assuming that your protected methods are not static, only subclasses of the base classes would have access to those methods.

2 things:
1) "base class with private constructors" is an oxy-moron 😉
2) As he explained above, your second sentence is not true. protected members are available to any class in the same package. Imho, this is one of the more serious flaws in the language. The package concept is not used nearly as much as the designers planned, people mostly use it only for organization.

*slaps forehead*

You're right, they would need to be protected at a minimum in order to be subclassed. Forget what I said.

 

[b4u]

Originally posted by: kamperImho, this is one of the more serious flaws in the language. The package concept is not used nearly as much as the designers planned, people mostly use it only for organization.

Exactly what I thought after some intense testing ... as if it wasn't enough that anyone could decompile my code, there is no way I could give some base functionality for any extending classes, without people being able to access it from outside.

Is it just me thinking, or there is room to some revamp of Java language? Like a java 2.0 version (since the 5.0 really is a 1.5 version), making a revamp like microsoft did with .net ...?

Originally posted by: kamperYes, but they could also use reflection to call your protected (or even private) methods unless you go to the hassle of setting up a security manager which might not be possible to do safely if someone else is using your jar.

That is something else that bothers me ... wtf people being able to call out private methods? Even with reflection??? I saw that not long time before, as some software was able to show up all private methods ... haven't tried it yet, but I'll give it a go soon ... testing that invoke private method thing ...


I believe some of these "problems" or "features" as some might prefer to call are all part of the cross-platform base of Java ...

 

[kamper]

The only thing I have a problem with is the lack of a real protected access level. In my experience though, it hasn't been a real problem. It can be managed fairly easily by telling the developers not to do stupid things and by actually trying to make use of the package pattern (if that's the right word for it).

All the other stuff is fine since you can control it if you run it yourself and if someone else is running your code it's kinda dumb to stop them from doing whatever they want with it (at least from a security perspective). For the most part the rules are just to encourage good practices rather than to strictly enforce anything. The power to do anything comes in very handy for debuggers and other fun things that play God with the code.

Btw, java 2.x started a long time ago (right after 1.0, I believe). Hence the J2SE and J2EE. I think the current 5.0 is technically still java 2, it's just that sun has absolutely no idea how to count 😕😛 As for fundamental changes like changing the meaning of access levels, I highly doubt you'll see it any time soon. Sun is far too concerned with backwards compatibility.