@java.lang.DontOverride

[Stefan Ram]

class Example extends javax.swing.JComponent
{ public boolean isValid(){ return true; }}

I do not want to override any method of JComponent with my method.
I just want to add a new method. But now or in future versions of
Swing there might be an »isValid« method in JComponent. So I'd like
to have a @java.lang.DontOverride annotation with the following
meaning: »Aborts compilation if any base class has a non-private
method of the same name.« Why do we have @java.lang.Ovverride, but
not the opposite? Or have I missed something?

 

[markspace]

class Example extends javax.swing.JComponent
{ public boolean isValid(){ return true; }}

I do not want to override any method of JComponent with my method.
I just want to add a new method. But now or in future versions of
Swing there might be an »isValid« method in JComponent.

Yeah, I see what you are saying, I believe, but now we're getting into
C++ territory: "A keyword and semantics for every corner-case imaginable."

So if you have a interface "BillingInvoice" with an "isValid()" method,
and you add that interface to a subclass of JComponent, you want
something like C++ where you can differentiate which method gets called:

component.JComponent::isValid();
vs.
component.BillingInvoice::isValid();

I realize that's not what you said, but that's the next logical step.
Your issue can be fixed just by reading the API carefully. Don't make
classes where the method names conflict.

Moreover, I find your request questionable. How do you know what
methods should never ever be overridden in future classes? How do you
know someone won't make a new interface for JComponent, some
ImprovedJComponent, where the "isValid()" method needs to be overridden
by the new classes? It's too hard to predict the future like this.
Just require that your coders learn to read, and especially test, their
code and problems like this become manageable.

The keyword "final" is there for the correct behavior of the current
class; that's something you can reasonable predict. Leave the correct
behavior of future classes to future coders.

 

[Arne Vajhøj]

class Example extends javax.swing.JComponent
{ public boolean isValid(){ return true; }}

I do not want to override any method of JComponent with my method.
I just want to add a new method. But now or in future versions of
Swing there might be an »isValid« method in JComponent. So I'd like
to have a @java.lang.DontOverride annotation with the following
meaning: »Aborts compilation if any base class has a non-private
method of the same name.« Why do we have @java.lang.Ovverride, but
not the opposite? Or have I missed something?

Lots of things can be done - far from all are done.

C# has the feature - if override keyword is missing then you will
get a compile error.

But that implementation could give a guess to how Java may do it in the
future - no DontOverride annotation but make Override required if
override (no Override => DontOverride).

But if that was the Java guys where thinking when they made the decision
I have no clue.

Arne

 

[Simon Lewis]

class Example extends javax.swing.JComponent
{ public boolean isValid(){ return true; }}

I do not want to override any method of JComponent with my method.
I just want to add a new method. But now or in future versions of
Swing there might be an »isValid« method in JComponent. So I'd like
to have a @java.lang.DontOverride annotation with the following
meaning: »Aborts compilation if any base class has a non-private
method of the same name.« Why do we have @java.lang.Ovverride, but
not the opposite? Or have I missed something?

A rare requirement but you could just try and call the superclass method
and catch any exception that results and call your own one.

 

[Joerg Meier]

class Example extends javax.swing.JComponent
{ public boolean isValid(){ return true; }}

I do not want to override any method of JComponent with my method.
I just want to add a new method. But now or in future versions of
Swing there might be an »isValid« method in JComponent. So I'd like
to have a @java.lang.DontOverride annotation with the following
meaning: »Aborts compilation if any base class has a non-private
method of the same name.« Why do we have @java.lang.Ovverride, but
not the opposite? Or have I missed something?

It seems to me like if you simply don't put @Override on this method, then
even if JComponent gets a method with that signature later, you will still
get a compiler warning or error, depending on your configuration.
Basically, all methods not tagged with @Override already are tagged with an
invisible @DontOverride.

Liebe Gruesse,
Joerg

 

[Arne Vajhøj]

It seems to me like if you simply don't put @Override on this method, then
even if JComponent gets a method with that signature later, you will still
get a compiler warning or error, depending on your configuration.
Basically, all methods not tagged with @Override already are tagged with an
invisible @DontOverride.

Are you saying that this could be done or that it has been done?

If the latter when what is the configuration to enable this?

Arne

 

[Daniel Pitts]

class Example extends javax.swing.JComponent
{ public boolean isValid(){ return true; }}

I do not want to override any method of JComponent with my method.
I just want to add a new method. But now or in future versions of
Swing there might be an »isValid« method in JComponent.

[snip]
Moreover, I find your request questionable. How do you know what
methods should never ever be overridden in future classes? How do you
know someone won't make a new interface for JComponent, some
ImprovedJComponent, where the "isValid()" method needs to be overridden
by the new classes? It's too hard to predict the future like this. Just
require that your coders learn to read, and especially test, their code
and problems like this become manageable.

I think his point is that if "isValid" becomes a member of JComponent,
he wants a compiler error so that he knows his implementation may now
have different semantics than intended. This is to say "My code is now
broken because of an interface change in JComponent." That is a
reasonable thing to want to know.

The keyword "final" is there for the correct behavior of the current
class; that's something you can reasonable predict. Leave the correct
behavior of future classes to future coders.

This is for defining a class that is to be extended, not for defining
the extending class.


Stefan, I think the real answer is "Don't add non-private methods to
your JComponent extension." Instead, create a different class that
provides a JComponent object (perhaps a getComponent() method). All of
the "business" logic that affects the component will live in your
non-component class, or in the appropriate standard methods of your
component class.



HTH,
Daniel.

 

[Joerg Meier]

Are you saying that this could be done or that it has been done?

If the latter when what is the configuration to enable this?

It has been done, but it seems to be an Eclipse feature, not a Java
feature, so my bad.

Liebe Gruesse,
Joerg

 

[markspace]

I think his point is that if "isValid" becomes a member of JComponent,
he wants a compiler error so that he knows his implementation may now
have different semantics than intended. This is to say "My code is now
broken because of an interface change in JComponent." That is a
reasonable thing to want to know.

I think we're in agreement here, at least up to the "reasonable" bit.

This is for defining a class that is to be extended, not for defining
the extending class.

I don't understand what this means. If I understand correctly, Stefan
doesn't want the semantics of his "isValid()" method to change. That's
the class to be extended, the JComponent. That's where he want's to put
the "don't override" annotation.

The extending class, the subclass, is only involved here if it
mistakenly changes the semantics of "isValid()". Putting a "don't
override" in the extended class is too late.

Stefan, I think the real answer is "Don't add non-private methods to
your JComponent extension."

This doesn't seem practical. I've extended JComponent classes before,
I'm just careful to read the existing documentation for those classes
and I make sure to not change any semantics I don't want changed. I
can't think of any other way to do this.

Instead, create a different class that
provides a JComponent object (perhaps a getComponent() method). All of
the "business" logic that affects the component will live in your
non-component class, or in the appropriate standard methods of your
component class.

I'd like to know more about what problem Stefan is actually trying to
solve. His question is highly theoretical to me since there's really no
context or goal other than "I wish this thing worked differently."

 

[Arne Vajhøj]

It has been done, but it seems to be an Eclipse feature, not a Java
feature, so my bad.

I was not even aware that Eclipse could do that.

I assume it is:
- properties
- java compiler
- errors/warnings
- annotations
- missing @Override annotation
that does the trick.

Arne

 

[Joerg Meier]

I was not even aware that Eclipse could do that.

I assume it is:
- properties
- java compiler
- errors/warnings
- annotations
- missing @Override annotation
that does the trick.

Yes, that is the one. It correctly produces a warning (or an error, if you
prefer, which I do, since it should be a 2 second fix) when you forget to
use @Override (or if you wire something together where a method overrides
another unintentionally).

Liebe Gruesse,
Joerg

 

[Sarah Connor]

Stefan, I think the real answer is "Don't add non-private methods to
your JComponent extension." Instead, create a different class that
provides a JComponent object (perhaps a getComponent() method). All of
the "business" logic that affects the component will live in your
non-component class, or in the appropriate standard methods of your
component class.

IOW, "prefer composition to inheritance".

Further to that, you might want to use a private inner class that extends
JComponent and has direct access to the enclosing object. You'd have a
factory method in the outer class that returns either a new instance or
*the* instance (perhaps lazily created), depending on whether you want to
limit to one instance.

Alternatively ... if your non-component logic has to do with some program
state that the component displays and/or allows the user to manipulate,
then you should probably separate it out into a model object and make the
JComponent subclass a view object, similar to the existing ListModel and
various list controls (JList, JComboBox, ...).

 

[markspace]

Alternatively ... if your non-component logic has to do with some program
state that the component displays and/or allows the user to manipulate,
then you should probably separate it out into a model object and make the
JComponent subclass a view object, similar to the existing ListModel and
various list controls (JList, JComboBox, ...).

This is what I would prefer. MVC is neither composition nor
inheritance. It just makes separate classes which aren't related and
have no knowledge of each other. This is vastly superior in many cases.