Subclass only modifier possible?

[Robert Elliot]

Just wondering if the Java Language gurus ever gave thought to another
visibility modifier to go alongside public, private and protected;
something along the lines of subclass. Idea being that methods and
classes marked subclass would only be visible to instance methods of
the class and instance methods in subclasses of the class.

The reason I'd like that is not to protect me from being really,
really stupid and referencing a method or field I shouldn't be
referencing from another class in the same package; rather it's
because this visibility modifier could be over-ridden to private in
sub-classes, since it could never be called externally anyway. This
would mean that in a class hierarchy Foo -> FooExt -> Bar you could
have a method on Foo subclass visible to FooExt so that FooExt
instance methods could call it, but over-ride it in FooExt to private
so that Bar methods could not call it.

You can achieve something similar by over-riding the method in FooExt
and putting @deprecated in the Javadoc, of course, but this would be
more conclusive and would mean that dev environments like Eclipse
would not show the methods as available to the subclass, making it
easier for someone to learn the new API.

Practical idea, or dumb and unnecessary? Just that I'm writing an API
where the lack of this means that when the client subclasses FooExt,
as I intend them to, they get access to a bunch of methods on Foo that
FooExt needs but that I don't want the client to have access to; they
are no benefit to them, and their presence is confusing.

Rob

 

[Liz]

Just wondering if the Java Language gurus ever gave thought to another
visibility modifier to go alongside public, private and protected;
something along the lines of subclass. Idea being that methods and
classes marked subclass would only be visible to instance methods of
the class and instance methods in subclasses of the class.

The reason I'd like that is not to protect me from being really,
really stupid and referencing a method or field I shouldn't be
referencing from another class in the same package; rather it's
because this visibility modifier could be over-ridden to private in
sub-classes, since it could never be called externally anyway. This
would mean that in a class hierarchy Foo -> FooExt -> Bar you could
have a method on Foo subclass visible to FooExt so that FooExt
instance methods could call it, but over-ride it in FooExt to private
so that Bar methods could not call it.

You can achieve something similar by over-riding the method in FooExt
and putting @deprecated in the Javadoc, of course, but this would be
more conclusive and would mean that dev environments like Eclipse
would not show the methods as available to the subclass, making it
easier for someone to learn the new API.

Practical idea, or dumb and unnecessary? Just that I'm writing an API
where the lack of this means that when the client subclasses FooExt,
as I intend them to, they get access to a bunch of methods on Foo that
FooExt needs but that I don't want the client to have access to; they
are no benefit to them, and their presence is confusing.

Rob

Rather than modify the language would it not be better for your IDE to
warn you just like it warns you when you refer to a static field improperly.

 

[Robert Elliot]

Rather than modify the language would it not be better for your IDE to
warn you just like it warns you when you refer to a static field improperly.

Using the @deprecated Javadoc setting? Or is there another I've
managed to miss? Perhaps in the annotation stuff 1.5 has added...
something else about 1.5 to explore.

Cheers,
Rob

 

[Guest]

The reason I'd like that is not to protect me from being really, really
stupid and referencing a method or field I shouldn't be referencing from
another class in the same package; rather it's because this visibility
modifier could be over-ridden to private in sub-classes, since it could
never be called externally anyway. This would mean that in a class
hierarchy Foo -> FooExt -> Bar you could have a method on Foo subclass
visible to FooExt so that FooExt instance methods could call it, but
over-ride it in FooExt to private so that Bar methods could not call it.

In Java, it is impossible for a subclass to restrict access to inherited
fields and methods, but can broaden access. A field (or method) declared
protected can never be downgraded to private.

Yes, at times I wish "protected" really meant limited just to instances of
that class or subclasses. With all the changes in 1.5, I wouldn't expect
to see this change until the next major version (1.6 or 3.0).

La'ie Techie

 

[Tony Morris]

In Java, it is impossible for a subclass to restrict access to inherited

fields and methods, but can broaden access. A field (or method) declared
protected can never be downgraded to private.

Incorrect - fields (and classes) are not virtual - methods are.

// Perfectly fine
class Base
{
protected int x;

protected class C{}
}

class Derived extends Base
{
private int x;

private class C{}
}


--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Dale King]

Hello, =?UTF-8?b?TMSByrtpZSBUZWNoaWU=?= !

not call it.

In Java, it is impossible for a subclass to restrict access to inherited
fields and methods, but can broaden access. A field (or method) declared
protected can never be downgraded to private.

Yes I believe that Robert understood that. He is suggesting that
in this case where it was only visible to subclasses that it
might make sense to tighten that security.

Yes, at times I wish "protected" really meant limited just to instances of
that class or subclasses. With all the changes in 1.5, I wouldn't expect
to see this change until the next major version (1.6 or 3.0).

I wouldn't expect that change ever as it could break existing
code. They could add an additional access specifier, but should
not change the existing ones. Java originally was going to have
such an access specifier. It was called private protected, but
was removed before the initial release. Some of the early Java
books still included it even though it no longer existed.

But I don't think anyone is really losing any sleep over the fact
that package members can access protected fields and methods.