private and final methods

[CaptainPinko]

can anyone think of an instance where it wouldn't be advantageous to declared a private method final? b/c as i've read final methods optimized could by being mainline. The only disadvantage of using final is that the method can't be over-riden by a subclass... but private methods aren't inherited anyway! it seems to make perfect sense to me to declare all all my private methods as final .... unless the Java compiler already does that and it would be redundant. Any thoughts anyone?

[Dillinger4]

can anyone think of an instance where it wouldn't be advantageous to declared a private method final?

That's a good question. Since a member declared private is not accessible to any classes but itself like you said the only way i could see declaring a private method final would be for optimization purposes.

Be careful when you say "private methods aren't inherited anyway" according to Java all methods are inherited just private memebers are not accessible. I came accross a question like this on the Java exam.

[CaptainPinko]

well i thought that everything was inherited to but then i discovered them to be in accesible...

but what is the difference between not inherited and inaccessible?

[Dillinger4]

Im not quite sure myself. The way i always understood it was that private members were not inherited at all and other classes were not permitted to acces them. But ive read in two book so far and seen a question on a test that say all memebers are inherited just private member are not accessible.

[Dillinger4]

I really think that a 4th access modifer should be created to add to public, protected, private modifers. If the memeber is private it is not accessible to anyone but the class that declared it. If it is declared protected then it is accessible to all subclasses(wether in the same package or in another package) and to all other classes in the same package.

But what if the programmer wants to rectrict access to just a subclass not every other class in the same package?

[CaptainPinko]

would creating a final private method be any less effecient than just mainlining it? because i have a one line equation that i made into a method for code clarity but it is called on ALOT so its needs to be as effecient as possible

[Dillinger4]

Im not quite sure what you mean by "mainlining".

[CaptainPinko]

mainlining it, ie. stating it explicitly instead of useing a method, in this case writing out the equation instead of calling it from the method

[Dillinger4]

Oh ok. I just wanted to clarify. That im not too sure of. If the amount of lines of code were excessive then i would make a method out of them and call the method when needed for code reuse. I think that any code run inline would complete faster then invoking a method, executing the code, then returning.

[hgroot]

The only time you want to use a final method declaration is when you don't want subclasses to override them. This already is the case with methods declared as private, so you're right it's redundant.

It's only useful if you want a method to be accessible in a sub-class, but not overridden.

Final declared methods are also not in-lined, they're not like C macro's...

One argument why private methods are always inherited: What would otherwise happen with public methods that are not overridden and contain private method calls? I think those would crash!

If you really want to get into security: JDK 1.3 has a run-time method security policy. You can maintain policy files with access privileges for your classes and any unauthorized method call generates a RunTimeException.

What kind of fourth access modifier did you have in mind, dilenger4? I don't quite understand...

[Dillinger4]

Posted by hgroot
What kind of fourth access modifier did you have in mind, dilenger4? I don't quite understand...

As far as i understand it, a member declared protected is accessible to subclasses and all other classes within the package. I fourth modifer would be nice to restrict access just to subclasses.

[hgroot]

But isn't that already the case with protected methods?

As far as I know, protected methods are not accessible from other package classes. Methods that are accessible on package scope, are methods declared with no modifier:

class myClass {
...
public void AlwaysAccessible() {}
private void OnlyAccessibleByMe() {}
protected void OnlyAccessibleByMeAndSubclass() {}
void AccessibleByPackageClasses() {} // !!
}

... and they're all inherited in a subclass.

I think I'll write a test case to check this...

[Dillinger4]

Posted by hgroot
As far as I know, protected methods are not accessible from other package classes.

Unless the subclass resides in another package.

Im pretty sure that protected members are accessible to the class extending the class where the protected methods are contained and to other classes within the same package.

So really all the this modifer does is allow a subclass in another package access to this member. So it is more restrictive than public but less restrictive than package access.

[CaptainPinko]

Originally posted by hgroot
One argument why private methods are always inherited: What would otherwise happen with public methods that are not overridden and contain private method calls? I think those would crash!

one question 've always had was what happens to a subclass when it's suber class is deleted? would it fail to work b/c it relies on the super class?

I'm pretty that there is some optimization done on final methods

Dil, that would be a pretty useful scope

[hgroot]

Ok, I wrote the test case and found that you are absolutely right. The protected method was accessible by all classes in the same package. I was surprised how fast I had forgotten this after my Certification Exam, so I think I'll brush it up a bit.

Also, the sub class .class file was much smaller than the super class. What's happening there? I'm not going to scan through bytecode, but either the subclass is optimized, or the inherited methods aren't present in the subclass .class-file.

So, maybe I wasn't completely right too with saying that inherited methods are always present in the subclass. That may be the case for classes in memory, but not in files.

If you're interested, here's the code.


/myPackage/ProtectionTest.java:
------------------------------------------

package myPackage;

public class ProtectionTest {

public static void main(String[] args) {
(new ProtectionTest()).callProtected();
(new ProtectedSubClass()).callProtected();
(new AnotherClass()).callProtected();
}

public void callProtected() {
System.out.println("Calling my own protected...");
protectedMethodCall();
}

protected void protectedMethodCall() {
System.out.println("Protected call succeeded.");
}
}

class ProtectedSubClass extends ProtectionTest {
public void callProtected() {
System.out.println("Calling my super protected...");
protectedMethodCall();
}
}

/myPackage/AnotherClass.java:
------------------------------------------

package myPackage;

class AnotherClass {
public void callProtected() {
System.out.println("Calling my package protected...");
(new ProtectionTest()).protectedMethodCall();
}
}