Abstract Class

Issue with Abstract class having abstract methods with no access modifier.

Please go through the following code snippet.

package different;

public abstract class AbstractParent {

abstract void doStuff();

}

This is a public class having an abstract method with no access modifier.

Now say we extend the class from a different package than that of the base class.

package somepackage;

import different.AbstractParent;

public class ChildAbstractTest extends AbstractParent {

}

Now this class gives a compilation error

"This class must implement the inherited abstract method AbstractParent.doStuff(), but cannot

override it since it is not visible from ChildAbstractTest. Either make the type abstract or

make the inherited method visible." I am trying to run my code from RSA 7.0

According to my opinion to remove this problem the compiler must allow only public and protected abstract methods, neither private (already enforced) nor default.

Please give your opinion regarding this issue.

[1101 byte] By [onlyratula] at [2007-11-27 8:31:32]
# 1
Perhaps the author wanted all concrete instances of the class to be in the same package.
malcolmmca at 2007-7-12 20:27:03 > top of Java-index,Java Essentials,Java Programming...
# 2

> According to my opinion to remove this problem

That language feature is not a problem. See reply 1.

If the "problem you're talking about is the fact that the abstract methods are package private, then it's only a problem if that's not what the author of that class intended. (Again, see reply 1.) If it is a "problem"--for example, if he forgot to add the word "protected"--then the way to fix it is to fix that code, not to change the JLS, as you're suggesting.

jverda at 2007-7-12 20:27:03 > top of Java-index,Java Essentials,Java Programming...
# 3
If the author wants all concrete instances to be inthe same package then he can make the class itself default that can be accessed from that package only , instead of public
onlyratula at 2007-7-12 20:27:03 > top of Java-index,Java Essentials,Java Programming...
# 4

still, what you want is NOT correct.

You're looking for inconsistent behaviour of keywords, which is NOT the way to go.

Instead let the person writing that class know of his error and have him fix it, the language spec is NOT to be changed simply because someone sometimes makes an error.

jwentinga at 2007-7-12 20:27:03 > top of Java-index,Java Essentials,Java Programming...
# 5
I'm with jw, I believe default access methods in an abstract could and should result in a meaningful compile time warning.
corlettka at 2007-7-12 20:27:03 > top of Java-index,Java Essentials,Java Programming...
# 6
> Perhaps the author wanted all concrete instances of the class to be in the same package.Or perhaps the author simply forgot to give the method protected or public access ;-)
Hippolytea at 2007-7-12 20:27:03 > top of Java-index,Java Essentials,Java Programming...
# 7

But if the author wanted all concrete classes to be in the same package then he could have made the class itself default.

And the comiler points out most common mistakes or possible mistakes to the author of a class. In this case what is the problem if the compiler points it out to the author that either you make the class default or make all the abstract methods public or protected?

onlyratula at 2007-7-12 20:27:03 > top of Java-index,Java Essentials,Java Programming...