Is it really necessary to write @Override when you override or is this just "a good thing"?

On 23/07/2012 20:30, bob smith allegedly wrote:
> Is it really necessary to write @Override when you override or is this just "a good thing"?

Just a good thing. Catches cases where you aren't actually overriding.

-- 
DF.

On 7/23/2012 11:30 AM, bob smith wrote:
> Is it really necessary to write @Override when you override or is
> this just "a good thing"?
>


Well, it's "just a good thing," but it's *really* a good thing.  If you 
were programming professionally, you'd expect your boss (or coworkers, 
say during a code review) to insist that you use @Override wherever 
appropriate.

In short, "just do it."

In article <75036e8b-8b5f-4ea4-aef7-c063249f5707@googlegroups.com>,
 bob smith <bob@coolfone.comze.com> wrote:

> Is it really necessary to write @Override when you override or is 
> this just "a good thing"?

So good, in fact, that another strongly-typed language added a very 
similar check at about the same time.

<http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-2-7.html>
<http://www.adaic.org/resources/add_content/standards/05rm/html/RM-8-3-1.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

markspace wrote:
> bob smith wrote:
> Is it really necessary to write @Override when you override or is
> this just "a good thing"?

Since when does "a good thing" ever deserve a "just"?

If it's a good thing, what's your objection?

Did you read the docs on '@Override'?

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.4>
<http://docs.oracle.com/javase/7/docs/api/java/lang/Override.html>

Why not?

Seriously, why in the world would you not want to use '@Override'?

Based on the documentation, now that you're aware of it, rephrase 
your question as "What are the advantages and disadvantages of 
'@Override'?" Then evaluate its utility.

> Well, it's "just [sic] a good thing," but it's *really* a good thing.  If you 
> were programming professionally, you'd expect your boss (or coworkers, 
> say during a code review) to insist that you use @Override wherever 
> appropriate.
> 
> In short, "just do it."

OP: There is benefit to using '@Override' and serious risk of harm if you don't.

Consider 'Object#equals()'.

public class BadEquals
{
  private String attribute = "";
  public String getAttribute() { return attribute; }
  public void setAttribute(String attr) { this.attribute = (attr == null? "" : attr); }
  public boolean equals(BadEquals other)
  {
    if (this == other)
    {
      return true;
    }
    if (other == null)
    {
      return false;
    }
   return getAttribute().equals(other.getAttribute());
  }
}

Let's say you have another class that uses a collection of 'BadEquals'. 

Without '@Override', as shown above, you won't catch that bug until 
runtime.

With it, you'll catch it at compile time.

-- 
Lew

On 7/23/2012 2:30 PM, bob smith wrote:
> Is it really necessary to write @Override when you override or is this just "a good thing"?

     Two benefits of @Override appear to me, one from its presence
and one from its absence:

     - If you write @Override and then misspell the method name or
       mess up the parameter list, Java will say "Hey, wait: There's
       nothing in the superclass with this signature; what do you
       think you're doing?"  And then you'll say "Oops!" and fix
       the problem, instead of wondering why your "overriding" method
       doesn't seem to work.

     - If you write a method and your IDE starts suggesting that you
       ought to tag it with @Override, you'll be alerted that you've
       overridden something you didn't intend to.[*]

     Two benefits; that's all I see.  Hence, like indentation and
Javadoc comments, not "really necessary" ...

     [*] This actually happened to me earlier today.  I was writing
a little Swing doodad to edit the "locations" of inventory items,
and I gave it a getLocation() method.  NetBeans started clamoring
for @Override, and I realized that my doodad extended JPanel which
in turn extended JComponent, which already has a getLocation() ...
Time for "Facepalm!" and a quick name change.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman wrote:
> bob smith wrote:
>> Is it really necessary to write @Override when you override or is this just "a good thing"?
> 
>      Two benefits of @Override appear to me, one from its presence
> and one from its absence:
> 
>      - If you write @Override and then misspell the method name or
>        mess up the parameter list, Java will say "Hey, wait: There's
>        nothing in the superclass with this signature; what do you
>        think you're doing?"  And then you'll say "Oops!" and fix
>        the problem, instead of wondering why your "overriding" method
>        doesn't seem to work.
> 
>      - If you write a method and your IDE starts suggesting that you
>        ought to tag it with @Override, you'll be alerted that you've
>        overridden something you didn't intend to.[*]
> 
>      Two benefits; that's all I see.  Hence, like indentation and

And that wasn't enough?

Add the third benefit that I mentioned upthread. Aren't they enough now?

Is your disparaging tone rhetorical, or do you really find the 
benefit of '@Override' to be that marginal?

Because it isn't.

> Javadoc comments, not "really necessary" ...

Dental patient:
  Is flossing my teeth really necessary? Which ones do 
  *really* need to floss?

Dentist:
  Just the ones you want to keep!

>      [*] This actually happened to me earlier today.  I was writing
> a little Swing doodad to edit the "locations" of inventory items,
> and I gave it a getLocation() method.  NetBeans started clamoring
> for @Override, and I realized that my doodad extended JPanel which
> in turn extended JComponent, which already has a getLocation() ...
> Time for "Facepalm!" and a quick name change.

That is an excellent anecdote to support the idea that the 
'@Override' annotation is really necessary.

But only where you want to catch bugs at compile time before 
they bite you in production.

-- 
Lew

On Mon, 23 Jul 2012 11:30:22 -0700 (PDT), bob smith
<bob@coolfone.comze.com> wrote:

>Is it really necessary to write @Override when you override or is this just "a good thing"?

     In my Visual FoxPro classes, I ended up annotating each method
with "base" or "overrides" to indicate whether the method was or was
not defined in a parent.

     I have many classes that use parent class methods.  I also have
to override these from time to time.  The annotations help me keep it
all straight.

     I tend to be very strict on using such aids.  If you want to be
sloppy, you can do it, but do not think that you are doing yourself a
favour.

Sincerely,

Gene Wirchenko

On Mon, 23 Jul 2012 15:56:12 -0400, John B. Matthews wrote:

> In article <75036e8b-8b5f-4ea4-aef7-c063249f5707@googlegroups.com>,
>  bob smith <bob@coolfone.comze.com> wrote:
> 
>> Is it really necessary to write @Override when you override or is 
>> this just "a good thing"?
> 
> So good, in fact, that another strongly-typed language added a very 
> similar check at about the same time.
> 
> <http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-2-7.html>
> <http://www.adaic.org/resources/add_content/standards/05rm/html/RM-8-3-1.html>

Indeed, one of the languages most heavily inspired by Java (at least
initially) incorporated the concept at the outset. C# requires the use of
"override" when overriding, and strongly encourages "new" if hiding.

At the same time, methods default to non-virtual in C#, so arguably C#
could have got along just fine without "override". But it's there, and is
useful.

I will admit that the number of times it's helped me avoid a mistake are
far and few between. But it's happened, and it's certainly no large
inconvenience to have to include "override" (in fact, at least with the
Visual Studio IDE, it's a convenience, as VS will pop up a list of
overridable methods, and then auto-generate a skeleton method to fill in
for the override...maybe Eclipse, NetBeans, etc. would do the same?).

Pete

On 23/07/2012 22:59, Lew allegedly wrote:
> Eric Sosman wrote:
>> bob smith wrote:
>>> Is it really necessary to write @Override when you override or is this just "a good thing"?
>>
>>      Two benefits of @Override appear to me, one from its presence
>> and one from its absence:
>>
>>      - If you write @Override and then misspell the method name or
>>        mess up the parameter list, Java will say "Hey, wait: There's
>>        nothing in the superclass with this signature; what do you
>>        think you're doing?"  And then you'll say "Oops!" and fix
>>        the problem, instead of wondering why your "overriding" method
>>        doesn't seem to work.
>>
>>      - If you write a method and your IDE starts suggesting that you
>>        ought to tag it with @Override, you'll be alerted that you've
>>        overridden something you didn't intend to.[*]
>>
>>      Two benefits; that's all I see.  Hence, like indentation and
> 
> And that wasn't enough?
> 
> Add the third benefit that I mentioned upthread. Aren't they enough now?
> 
> Is your disparaging tone rhetorical, or do you really find the 
> benefit of '@Override' to be that marginal?
> 
> Because it isn't.
> 
>> Javadoc comments, not "really necessary" ...
> 
> Dental patient:
>   Is flossing my teeth really necessary? Which ones do 
>   *really* need to floss?
> 
> Dentist:
>   Just the ones you want to keep!
> 
>>      [*] This actually happened to me earlier today.  I was writing
>> a little Swing doodad to edit the "locations" of inventory items,
>> and I gave it a getLocation() method.  NetBeans started clamoring
>> for @Override, and I realized that my doodad extended JPanel which
>> in turn extended JComponent, which already has a getLocation() ...
>> Time for "Facepalm!" and a quick name change.
> 
> That is an excellent anecdote to support the idea that the 
> '@Override' annotation is really necessary.
> 
> But only where you want to catch bugs at compile time before 
> they bite you in production.
> 

Uh... there was a (pretty long) time when people and programs *did*
manage to exist without that annotation, you know. No need to be overly
dramatic.

-- 
DF.

On Monday, July 23, 2012 2:40:21 PM UTC-7, Daniele Futtorovic wrote:
> On 23/07/2012 22:59, Lew allegedly wrote:
> > Eric Sosman wrote:
> >> bob smith wrote:
> >>> Is it really necessary to write @Override when you override or is this just "a good thing"?
> >>
> >>      Two benefits of @Override appear to me, one from its presence
> >> and one from its absence:
> >>
> >>      - If you write @Override and then misspell the method name or
> >>        mess up the parameter list, Java will say "Hey, wait: There's
> >>        nothing in the superclass with this signature; what do you
> >>        think you're doing?"  And then you'll say "Oops!" and fix
> >>        the problem, instead of wondering why your "overriding" method
> >>        doesn't seem to work.
> >>
> >>      - If you write a method and your IDE starts suggesting that you
> >>        ought to tag it with @Override, you'll be alerted that you've
> >>        overridden something you didn't intend to.[*]
> >>
> >>      Two benefits; that's all I see.  Hence, like indentation and
> > 
> > And that wasn't enough?
> > 
> > Add the third benefit that I mentioned upthread. Aren't they enough now?
> > 
> > Is your disparaging tone rhetorical, or do you really find the 
> > benefit of '@Override' to be that marginal?
> > 
> > Because it isn't.
> > 
> >> Javadoc comments, not "really necessary" ...
> > 
> > Dental patient:
> >   Is flossing my teeth really necessary? Which ones do 
> >   *really* need to floss?
> > 
> > Dentist:
> >   Just the ones you want to keep!
> > 
> >>      [*] This actually happened to me earlier today.  I was writing
> >> a little Swing doodad to edit the "locations" of inventory items,
> >> and I gave it a getLocation() method.  NetBeans started clamoring
> >> for @Override, and I realized that my doodad extended JPanel which
> >> in turn extended JComponent, which already has a getLocation() ...
> >> Time for "Facepalm!" and a quick name change.
> > 
> > That is an excellent anecdote to support the idea that the 
> > '@Override' annotation is really necessary.
> > 
> > But only where you want to catch bugs at compile time before 
> > they bite you in production.
> > 
> 
> Uh... there was a (pretty long) time when people and programs *did*
> manage to exist without that annotation, you know. No need to be overly
> dramatic.

You sound like Grandpaw complaining that kids these days have it too easy.
"In my day, we had to check for ourselves whether the method overrode a 
parent method!"

Your irrelevant observation does not give a reason to eschew '@Override'.

The fact is that Java *does* have it, and it *is* useful for the class of bugs 
it helps prevent. 

A point you ignore in your rush to fallacious argumentation.

That languages (including Java itself) didn't used to have 
it is hardly an argument against it. In fact, that Java added it, given the 
language's resistance to change, is strong evidence in favor of it. 
So your evidence supports use of '@Override'. You drew exactly the 
opposite of the correct conclusion from your data.

-- 
Lew

On 23/07/2012 23:51, Lew allegedly wrote:
> On Monday, July 23, 2012 2:40:21 PM UTC-7, Daniele Futtorovic wrote:
>> Uh... there was a (pretty long) time when people and programs *did*
>> manage to exist without that annotation, you know. No need to be overly
>> dramatic.
> 
> You sound like Grandpaw complaining that kids these days have it too easy.
> "In my day, we had to check for ourselves whether the method overrode a 
> parent method!"
> 
> Your irrelevant observation does not give a reason to eschew '@Override'.
> 
> The fact is that Java *does* have it, and it *is* useful for the class of bugs 
> it helps prevent. 
> 
> A point you ignore in your rush to fallacious argumentation.
> 
> That languages (including Java itself) didn't used to have 
> it is hardly an argument against it. In fact, that Java added it, given the 
> language's resistance to change, is strong evidence in favor of it. 
> So your evidence supports use of '@Override'. You drew exactly the 
> opposite of the correct conclusion from your data.

And you sound like a drama queen. The fact that Java programs existed at
a point where @Override didn't exist proves that this annotation is not
strictly necessary. And the assiduous JLS reader that you are should
know that this hasn't changed.

Is that annotation a good thing? Yes. Should it be used? Absolutely.

As a matter of fact, its merits are such that with a minimum of
explanation, any sensible person would adopt it on their own. No need to
exaggerate or dramatize the issue. No need to try to ridicule me for
refusing your dramatization. Attempts like that to use coercion rather
than reason are counter-productive.

-- 
DF.

On 07/23/2012 08:30 PM, bob smith wrote:
> Is it really necessary to write @Override when you override or is this just "a good thing"?
>

It is a lame patch for a language fault. Java SHOULD have required some 
"override" keyword anytime a method that has a definition in a base 
class is overridden in a derived class. Using an annotation is, as with 
almost all uses of annotations, a poor attempt at making up for the lack 
of a proper language feature.

Yes, it is better to use @Override than to not use it. However, the 
compiler will only complain if you do use the annotation when you do not 
actually override anything. If you simply leave it out there will be no 
complaint.

Backward compatibility makes it impossible to enforce an override 
keyword after the fact. Using an annotation as an afterthought is lame 
but better than nothing.

Luckily, Scala has fixed this omission, amongst other things..

On 7/23/2012 6:22 PM, Silvio Bierman wrote:
> On 07/23/2012 08:30 PM, bob smith wrote:
>> Is it really necessary to write @Override when you override or is this
>> just "a good thing"?
>>
>
> It is a lame patch for a language fault. Java SHOULD have required some
> "override" keyword anytime a method that has a definition in a base
> class is overridden in a derived class. Using an annotation is, as with
> almost all uses of annotations, a poor attempt at making up for the lack
> of a proper language feature.
>
> Yes, it is better to use @Override than to not use it. However, the
> compiler will only complain if you do use the annotation when you do not
> actually override anything. If you simply leave it out there will be no
> complaint.
>
> Backward compatibility makes it impossible to enforce an override
> keyword after the fact. Using an annotation as an afterthought is lame
> but better than nothing.

True.

But we are still waiting for the language that gets everything right.

Arne

On 7/23/2012 2:54 PM, markspace wrote:
> On 7/23/2012 11:30 AM, bob smith wrote:
>> Is it really necessary to write @Override when you override or is
>> this just "a good thing"?
>
> Well, it's "just a good thing," but it's *really* a good thing.  If you
> were programming professionally, you'd expect your boss (or coworkers,
> say during a code review) to insist that you use @Override wherever
> appropriate.

I think that it would slip through code reviews in many places.

I agree that it is a good thing.

Arne

On Monday, July 23, 2012 3:08:04 PM UTC-7, Daniele Futtorovic wrote:
> On 23/07/2012 23:51, Lew allegedly wrote:
> > On Monday, July 23, 2012 2:40:21 PM UTC-7, Daniele Futtorovic wrote:
> >> Uh... there was a (pretty long) time when people and programs *did*
> >> manage to exist without that annotation, you know. No need to be overly
> >> dramatic.
> > 
> > You sound like Grandpaw complaining that kids these days have it too easy.
> > "In my day, we had to check for ourselves whether the method overrode a 
> > parent method!"
> > 
> > Your irrelevant observation does not give a reason to eschew '@Override'.
> > 
> > The fact is that Java *does* have it, and it *is* useful for the class of bugs 
> > it helps prevent. 
> > 
> > A point you ignore in your rush to fallacious argumentation.
> > 
> > That languages (including Java itself) didn't used to have 
> > it is hardly an argument against it. In fact, that Java added it, given the 
> > language's resistance to change, is strong evidence in favor of it. 
> > So your evidence supports use of '@Override'. You drew exactly the 
> > opposite of the correct conclusion from your data.
> 
> And you sound like a drama queen. The fact that Java programs existed at

Ad hominem argument.

> a point where @Override didn't exist proves that this annotation is not
> strictly necessary. And the assiduous JLS reader that you are should
> know that this hasn't changed.

I'm sorry, but where did I claim that the annotation is strictly necessary?

You're refuting a claim not made.

Straw-man argument.

> Is that annotation a good thing? Yes. Should it be used? Absolutely.

So we agree.

> As a matter of fact, its merits are such that with a minimum of
> explanation, any sensible person would adopt it on their own. No need to
> exaggerate or dramatize the issue. No need to try to ridicule me for
> refusing your dramatization. Attempts like that to use coercion rather
> than reason are counter-productive.

Like calling me names?

Physician, cure thyself.

-- 
Lew

On 7/23/2012 4:35 PM, Eric Sosman wrote:
> On 7/23/2012 2:30 PM, bob smith wrote:
>> Is it really necessary to write @Override when you override or is this
>> just "a good thing"?
>
>      Two benefits of @Override appear to me, one from its presence
> and one from its absence:
>
>      - If you write @Override and then misspell the method name or
>        mess up the parameter list, Java will say "Hey, wait: There's
>        nothing in the superclass with this signature; what do you
>        think you're doing?"  And then you'll say "Oops!" and fix
>        the problem, instead of wondering why your "overriding" method
>        doesn't seem to work.
>
>      - If you write a method and your IDE starts suggesting that you
>        ought to tag it with @Override, you'll be alerted that you've
>        overridden something you didn't intend to.[*]
>
>      Two benefits; that's all I see.  Hence, like indentation and
> Javadoc comments, not "really necessary" ...

I see the biggest benefits being the documentation.

It can be important to know that ones method may be called
by the super class.

And all arguments seems related to extends not implements, so
I m not convinced that extending it to interface methods was
wise.

Arne

On Mon, 23 Jul 2012 19:53:21 -0400, Arne Vajh�j <arne@vajhoej.dk>
wrote:

>On 7/23/2012 6:22 PM, Silvio Bierman wrote:
>> On 07/23/2012 08:30 PM, bob smith wrote:
>>> Is it really necessary to write @Override when you override or is this
>>> just "a good thing"?

[snip]

>> Backward compatibility makes it impossible to enforce an override
>> keyword after the fact. Using an annotation as an afterthought is lame
>> but better than nothing.
>
>True.
>
>But we are still waiting for the language that gets everything right.

     And it is a very good thing that we are not holding our breaths
while doing so.  Unless, of course, you REALLY like blue.

     And assuming we ever agree on "right".  If we do, there will be
one language only.  Not likely.  I prefer different languages for
different things, sometimes for opposite reasons.

Sincerely,

Gene Wirchenko

On 7/23/2012 7:58 PM, Arne Vajh�j wrote:
> On 7/23/2012 4:35 PM, Eric Sosman wrote:
>> On 7/23/2012 2:30 PM, bob smith wrote:
>>> Is it really necessary to write @Override when you override or is this
>>> just "a good thing"?
>>
>>      Two benefits of @Override appear to me, one from its presence
>> and one from its absence:
>>
>>      - If you write @Override and then misspell the method name or
>>        mess up the parameter list, Java will say "Hey, wait: There's
>>        nothing in the superclass with this signature; what do you
>>        think you're doing?"  And then you'll say "Oops!" and fix
>>        the problem, instead of wondering why your "overriding" method
>>        doesn't seem to work.
>>
>>      - If you write a method and your IDE starts suggesting that you
>>        ought to tag it with @Override, you'll be alerted that you've
>>        overridden something you didn't intend to.[*]
>>
>>      Two benefits; that's all I see.  Hence, like indentation and
>> Javadoc comments, not "really necessary" ...
>
> I see the biggest benefits being the documentation.
>
> It can be important to know that ones method may be called
> by the super class.
>
> And all arguments seems related to extends not implements, so
> I m not convinced that extending it to interface methods was
> wise.

    A separate @Implements annotation instead of @Override might
have been better for interfaces.  But what should one do about
abstract methods in abstract superclasses?  Are those @Override
or @Implements, or maybe @Concretizes?  And why should the class
with the actual implementation care about the distinction?  And
what about concrete methods *intended* to be overridden, as in
MouseAdapter?  @ProFormaOverrides?

     Looks like fodder for a "whichness of the why" debate.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 7/23/2012 10:16 PM, Eric Sosman wrote:
> On 7/23/2012 7:58 PM, Arne Vajh�j wrote:
>> On 7/23/2012 4:35 PM, Eric Sosman wrote:
>>> On 7/23/2012 2:30 PM, bob smith wrote:
>>>> Is it really necessary to write @Override when you override or is this
>>>> just "a good thing"?
>>>
>>>      Two benefits of @Override appear to me, one from its presence
>>> and one from its absence:
>>>
>>>      - If you write @Override and then misspell the method name or
>>>        mess up the parameter list, Java will say "Hey, wait: There's
>>>        nothing in the superclass with this signature; what do you
>>>        think you're doing?"  And then you'll say "Oops!" and fix
>>>        the problem, instead of wondering why your "overriding" method
>>>        doesn't seem to work.
>>>
>>>      - If you write a method and your IDE starts suggesting that you
>>>        ought to tag it with @Override, you'll be alerted that you've
>>>        overridden something you didn't intend to.[*]
>>>
>>>      Two benefits; that's all I see.  Hence, like indentation and
>>> Javadoc comments, not "really necessary" ...
>>
>> I see the biggest benefits being the documentation.
>>
>> It can be important to know that ones method may be called
>> by the super class.
>>
>> And all arguments seems related to extends not implements, so
>> I m not convinced that extending it to interface methods was
>> wise.
>
>     A separate @Implements annotation instead of @Override might
> have been better for interfaces.  But what should one do about
> abstract methods in abstract superclasses?  Are those @Override
> or @Implements, or maybe @Concretizes?  And why should the class
> with the actual implementation care about the distinction?  And
> what about concrete methods *intended* to be overridden, as in
> MouseAdapter?  @ProFormaOverrides?
>
>      Looks like fodder for a "whichness of the why" debate.

I think abstract methods should be treated like other methods in
classes.

The abstract class could later introduce an implementation.

We know that the interface will never.

Arne

On 7/23/2012 10:57 PM, Arne Vajh�j wrote:
> On 7/23/2012 10:16 PM, Eric Sosman wrote:
>> On 7/23/2012 7:58 PM, Arne Vajh�j wrote:
>>> On 7/23/2012 4:35 PM, Eric Sosman wrote:
>>>> On 7/23/2012 2:30 PM, bob smith wrote:
>>>>> Is it really necessary to write @Override when you override or is this
>>>>> just "a good thing"?
>>>>
>>>>      Two benefits of @Override appear to me, one from its presence
>>>> and one from its absence:
>>>>
>>>>      - If you write @Override and then misspell the method name or
>>>>        mess up the parameter list, Java will say "Hey, wait: There's
>>>>        nothing in the superclass with this signature; what do you
>>>>        think you're doing?"  And then you'll say "Oops!" and fix
>>>>        the problem, instead of wondering why your "overriding" method
>>>>        doesn't seem to work.
>>>>
>>>>      - If you write a method and your IDE starts suggesting that you
>>>>        ought to tag it with @Override, you'll be alerted that you've
>>>>        overridden something you didn't intend to.[*]
>>>>
>>>>      Two benefits; that's all I see.  Hence, like indentation and
>>>> Javadoc comments, not "really necessary" ...
>>>
>>> I see the biggest benefits being the documentation.
>>>
>>> It can be important to know that ones method may be called
>>> by the super class.
>>>
>>> And all arguments seems related to extends not implements, so
>>> I m not convinced that extending it to interface methods was
>>> wise.
>>
>>     A separate @Implements annotation instead of @Override might
>> have been better for interfaces.  But what should one do about
>> abstract methods in abstract superclasses?  Are those @Override
>> or @Implements, or maybe @Concretizes?  And why should the class
>> with the actual implementation care about the distinction?  And
>> what about concrete methods *intended* to be overridden, as in
>> MouseAdapter?  @ProFormaOverrides?
>>
>>      Looks like fodder for a "whichness of the why" debate.
>
> I think abstract methods should be treated like other methods in
> classes.
>
> The abstract class could later introduce an implementation.
>
> We know that the interface will never.

     Ah, but what about

	abstract class Super implements ActionListener {
	    protected void helperMethod() { ... }
	    ...  // maybe an actionPerformed() here, maybe not
	}

	class NowWhat extends Super {
	    @WhatAnnotationGoesHere  // ?
	    public void actionPerformed(ActionEvent evt) {
	       ...
	    }
	}

In the NowWhat class, does actionPerformed() "implement" the
method required by the ActionListener interface, or does it
"concretize" the abstract actionPerformed() method of the Super
class?  Or does it "override" Super's concrete actionPerformed()
method (not shown)?  What if Super explicitly declares an abstract
actionPerformed() method?

     More to the point, is the distinction useful?  No, let's
"concretize" that question: Can you suggest a scenario in which
it would be helpful to distinguish among different flavors of
overriding:

     - Implement a method of an interface the class `implements'

     - Implement a method of a superinterface of an interface
       the class `implements'

     - Implement a method of an interface an abstract superclass
       `implements' but leaves abstract

     - Implement a method explicitly declared as abstract by an
       abstract superclass

     - Replace a superclass' concrete implementation

At the risk of dating myself (again), where's the beef?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On Mon, 23 Jul 2012 11:30:22 -0700 (PDT), bob smith
<bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
who said :

>Is it really necessary to write @Override when you override or is this just "a good thing"?

I asked for this in the days of Java 1.1. The syntax is a little
different that I had in mind, but it still has the same function.  So
obviously I am keen on it.

I wanted it because sometimes I would override some method, but spell
it a little incorrectly or get the signature a little off.  Then I
created an ambiguity sometimes calling the base method and sometimes
my new one.  With @Override, if I don't get the match exact, I get an
error message.

I am big on ways for programs to cross check themselves for
consistency.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
The greatest shortcoming of the human race is our inability to understand the exponential function. 
 ~ Dr. Albert A. Bartlett (born: 1923-03-21 age: 89)
http://www.youtube.com/watch?v=F-QA2rkpBSY

On 23.07.2012 22:59, Lew wrote:
> Add the third benefit that I mentioned upthread. Aren't they enough now?

Are variant of this is where the super class or interface is in a 
library and a later version removed the method.  You'll immediately 
notice when replacing the lib with the newer version.  This is a good 
thing (being noticed - not removing something from a public API) and you 
are immediately aware that your method won't be invoked the same way as 
it used to be.

Granted this should be a rare situation but - for example - if the 
library method had been deprecated and you somehow missed adjusting your 
code to the imminent removal the compiler will force it on you once it 
is gone.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

On Mon, 23 Jul 2012 14:19:16 -0700, Peter Duniho
<NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:

>in fact, at least with the Visual Studio IDE, it's a convenience, as 
>VS will pop up a list of overridable methods, and then auto-generate 
>a skeleton method to fill in for the override...maybe Eclipse, 
>NetBeans, etc. would do the same?
NetBeans does that: Alt+Insert or right click and select "Insert
Code".  I don't use Eclipse, so I can't comment on that IDE.

rossum

On 7/23/2012 5:19 PM, Peter Duniho wrote:
>[...]
> I will admit that the number of times it's helped me avoid a mistake are
> far and few between. But it's happened, and it's certainly no large
> inconvenience to have to include "override" (in fact, at least with the
> Visual Studio IDE, it's a convenience, as VS will pop up a list of
> overridable methods, and then auto-generate a skeleton method to fill in
> for the override...maybe Eclipse, NetBeans, etc. would do the same?).

     NetBeans will do two things about @Override (maybe more). It
will flag an overriding method that lacks an @Override annotation
and suggest that you add it (which you can do with a shortcut).
A feature I find even more convenient is that it notices when you
attempt to intantiate an abstract class, and suggests that you
provide overrides for the missing methods.  Another shortcut, and
presto! it writes skeletons for the missing methods, with @Override
already in place.  Saves the bother of hunting up the exact spelling
of a method name.

     Illustration: If I type

	button.addActionListener(new ActionListener(){});

.... NetBeans tells me I've failed to implement abstract methods.
After Alt-Enter and a confirming Enter, it rewrites my code as

	button.addActionListener(new ActionListener() {
	    @Override
	    public void actionPerformed(ActionEvent e) {
	        throw new UnsupportedOperationException(
	            "Not supported yet.");
	    }
	});

.... which I find very helpful, especially for interfaces that
have several abstract methods.  (I've even been known to let
NetBeans expand MouseListener, then change it to MouseAdapter
and delete the auto-written methods I don't care about, just
to be sure I've got everything spelled properly.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 24.07.2012 00:22, Silvio Bierman wrote:
> Using an annotation is, as with
> almost all uses of annotations, a poor attempt at making up for the lack
> of a proper language feature.

That is nonsense.  The mere fact that users can define their own 
annotations along with handling these annotations demonstrates that 
annotations solve problems which cannot be tackled by changing a 
language's syntax.  Annotations add *arbitrary* meta data to language 
constructs; if all these would have to be handled by a language change 
you would need a new Java for every custom library which requires 
additional meta data.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

In article <75036e8b-8b5f-4ea4-aef7-c063249f5707@googlegroups.com>, 
bob@coolfone.comze.com says...
> 
> Is it really necessary to write @Override when you override or is this just "a good thing"?

It's not necessary but beneficial. Not only because it documents 
something, but also because your IDE checks that and in case you're 
changing some interface of a parent class you'll get an error message 
for the classes that now claim to override something, but don't (because 
you've changed theparents method's signature). Since this kind of 
refactoring-failure can easily lead to a non apparent error, it's good 
to check that.

Kind regards,
-Wanja-



-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On Tue, 24 Jul 2012 15:36:15 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote:

>On 24.07.2012 00:22, Silvio Bierman wrote:
>> Using an annotation is, as with
>> almost all uses of annotations, a poor attempt at making up for the lack
>> of a proper language feature.
>
>That is nonsense.  The mere fact that users can define their own 
>annotations along with handling these annotations demonstrates that 
>annotations solve problems which cannot be tackled by changing a 
>language's syntax.  Annotations add *arbitrary* meta data to language 
>constructs; if all these would have to be handled by a language change 
>you would need a new Java for every custom library which requires 
>additional meta data.

     Let me add that useful annotations added by one user and group of
users might be useful only for them so changing the language would not
be a good fit.

Sincerely,

Gene Wirchenko

On 07/24/2012 01:53 AM, Arne Vajh�j wrote:
> On 7/23/2012 6:22 PM, Silvio Bierman wrote:
>

SNIP

> True.
>
> But we are still waiting for the language that gets everything right.
>
> Arne
>
>

There is no such language and there never will be since it is and always 
will be a moving target.

I am not saying that Scala is the perfect language for anyone, let alone 
for everyone. But for me it is so extremely much closer to what I 
need/want than Java that, since it is already available, it would be 
stupid FOR ME not to use it. The fact that Scala happens to fix a lot of 
Java design errors is a minor point, by the way.

For others it may be Groovy, Clojure or perhaps even Ruby if you are not 
tied to the JVM. And for many staying with Java may be the most sensible 
thing to do. But even then, it remains a fact of life that there will be 
JVM languages that chose to fix Java omissions and mistakes.

For me one thing I like is that the Scala language developers are not 
stuck on backward compatibility. They are not afraid to fix things, even 
if that will break existing code. The language comes/exists in versions 
and existing code may be tied to an older version. Does not have to be a 
problem at all and the owner of the code can choose to update it if and 
when he desires so.

If only they had done that with Java they could have fixed a lot of 
annoying things. Now newer versions introduce new language features but 
developers can not use them since their users do not want to upgrade to 
the latest JVM. That is also a version problem, but then backwards.

Silvio

On 07/24/2012 03:36 PM, Robert Klemme wrote:
> On 24.07.2012 00:22, Silvio Bierman wrote:
>> Using an annotation is, as with
>> almost all uses of annotations, a poor attempt at making up for the lack
>> of a proper language feature.
>
> That is nonsense.  The mere fact that users can define their own
> annotations along with handling these annotations demonstrates that
> annotations solve problems which cannot be tackled by changing a
> language's syntax.  Annotations add *arbitrary* meta data to language
> constructs; if all these would have to be handled by a language change
> you would need a new Java for every custom library which requires
> additional meta data.
>
> Kind regards
>
>      robert
>

Well, I already really dislike annotations for their use in frameworks 
like for example Hibernate or for all examples I have seen in "user code".
But to use it for plain language level constructs like @Override, 
@NotNull etc. is plain ugly. Why have keywords like final, public, etc. 
at all, then?

Someone really disliked the lack of an override keyword and since adding 
that would break existing code they opted to introduce an annotation.
Perhaps we should introduce some to repair the design error that is the 
combination of private, protected and public keywords with the ludicrous 
default of package visibility when none of them is specified?

This way the language gets polluted using the generic annotation hammer. 
Leave it be or actually fix it! I would applaud a bold language revision 
that breaks backward compatibility for the benefit of fixing the 
language. I could even imagine an annotation that could hint the 
compiler at what language version a source is targeting.

Silvio

On 7/24/2012 9:36 AM, Robert Klemme wrote:
> On 24.07.2012 00:22, Silvio Bierman wrote:
>> Using an annotation is, as with
>> almost all uses of annotations, a poor attempt at making up for the lack
>> of a proper language feature.
>
> That is nonsense.  The mere fact that users can define their own
> annotations along with handling these annotations demonstrates that
> annotations solve problems which cannot be tackled by changing a
> language's syntax.  Annotations add *arbitrary* meta data to language
> constructs; if all these would have to be handled by a language change
> you would need a new Java for every custom library which requires
> additional meta data.

True.

There are two types of annotations:
* those acting as a supplement to the language
* those intended for runtime reflection

Arne

On 7/24/2012 4:57 PM, Silvio Bierman wrote:
> On 07/24/2012 01:53 AM, Arne Vajh�j wrote:
>> On 7/23/2012 6:22 PM, Silvio Bierman wrote:
>> True.
>>
>> But we are still waiting for the language that gets everything right.

> There is no such language and there never will be since it is and always
> will be a moving target.

And both the problems to be solved and the people trying to solve them
are different.

> I am not saying that Scala is the perfect language for anyone, let alone
> for everyone. But for me it is so extremely much closer to what I
> need/want than Java that, since it is already available, it would be
> stupid FOR ME not to use it. The fact that Scala happens to fix a lot of
> Java design errors is a minor point, by the way.

I also like Scala.

But I do not see it overtake the role of Java.

Two reasons:
- the language is not stable enough
- the language is too difficult

> For others it may be Groovy, Clojure or perhaps even Ruby if you are not
> tied to the JVM.

You can run Ruby in the JVM.

>                  And for many staying with Java may be the most sensible
> thing to do. But even then, it remains a fact of life that there will be
> JVM languages that chose to fix Java omissions and mistakes.
>
> For me one thing I like is that the Scala language developers are not
> stuck on backward compatibility. They are not afraid to fix things, even
> if that will break existing code. The language comes/exists in versions
> and existing code may be tied to an older version. Does not have to be a
> problem at all and the owner of the code can choose to update it if and
> when he desires so.
>
> If only they had done that with Java they could have fixed a lot of
> annoying things. Now newer versions introduce new language features but
> developers can not use them since their users do not want to upgrade to
> the latest JVM. That is also a version problem, but then backwards.

A high level of backwards compatibility is a requirement in much
of the enterprise market.

Arne

On 7/24/2012 8:09 AM, rossum wrote:
> On Mon, 23 Jul 2012 14:19:16 -0700, Peter Duniho
> <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>> in fact, at least with the Visual Studio IDE, it's a convenience, as
>> VS will pop up a list of overridable methods, and then auto-generate
>> a skeleton method to fill in for the override...maybe Eclipse,
>> NetBeans, etc. would do the same?
> NetBeans does that: Alt+Insert or right click and select "Insert
> Code".  I don't use Eclipse, so I can't comment on that IDE.

right click
refactor
override/implements methods
pick what one want

Arne

On 7/23/2012 11:47 PM, Eric Sosman wrote:
> On 7/23/2012 10:57 PM, Arne Vajh�j wrote:
>> On 7/23/2012 10:16 PM, Eric Sosman wrote:
>>> On 7/23/2012 7:58 PM, Arne Vajh�j wrote:
>>>> And all arguments seems related to extends not implements, so
>>>> I m not convinced that extending it to interface methods was
>>>> wise.
>>>
>>>     A separate @Implements annotation instead of @Override might
>>> have been better for interfaces.  But what should one do about
>>> abstract methods in abstract superclasses?  Are those @Override
>>> or @Implements, or maybe @Concretizes?  And why should the class
>>> with the actual implementation care about the distinction?  And
>>> what about concrete methods *intended* to be overridden, as in
>>> MouseAdapter?  @ProFormaOverrides?
>>>
>>>      Looks like fodder for a "whichness of the why" debate.
>>
>> I think abstract methods should be treated like other methods in
>> classes.
>>
>> The abstract class could later introduce an implementation.
>>
>> We know that the interface will never.
>
>      Ah, but what about
>
>      abstract class Super implements ActionListener {
>          protected void helperMethod() { ... }
>          ...  // maybe an actionPerformed() here, maybe not
>      }
>
>      class NowWhat extends Super {
>          @WhatAnnotationGoesHere  // ?
>          public void actionPerformed(ActionEvent evt) {
>             ...
>          }
>      }
>
> In the NowWhat class, does actionPerformed() "implement" the
> method required by the ActionListener interface, or does it
> "concretize" the abstract actionPerformed() method of the Super
> class?  Or does it "override" Super's concrete actionPerformed()
> method (not shown)?  What if Super explicitly declares an abstract
> actionPerformed() method?

I would tend to use the extend way here because Super
could implement the method.

>      More to the point, is the distinction useful?  No, let's
> "concretize" that question: Can you suggest a scenario in which
> it would be helpful to distinguish among different flavors of
> overriding:
>
>      - Implement a method of an interface the class `implements'
>
>      - Implement a method of a superinterface of an interface
>        the class `implements'
>
>      - Implement a method of an interface an abstract superclass
>        `implements' but leaves abstract
>
>      - Implement a method explicitly declared as abstract by an
>        abstract superclass
>
>      - Replace a superclass' concrete implementation
>
> At the risk of dating myself (again), where's the beef?

The beef is that it is not needed if it is known to be
an implements interface.

Arne

On 24.07.2012 23:14, Silvio Bierman wrote:
> On 07/24/2012 03:36 PM, Robert Klemme wrote:
>> On 24.07.2012 00:22, Silvio Bierman wrote:
>>> Using an annotation is, as with
>>> almost all uses of annotations, a poor attempt at making up for the lack
>>> of a proper language feature.
>>
>> That is nonsense.  The mere fact that users can define their own
>> annotations along with handling these annotations demonstrates that
>> annotations solve problems which cannot be tackled by changing a
>> language's syntax.  Annotations add *arbitrary* meta data to language
>> constructs; if all these would have to be handled by a language change
>> you would need a new Java for every custom library which requires
>> additional meta data.

In all what you say below you do not address my argument.  I take that 
as agreement.

> Well, I already really dislike annotations for their use in frameworks
> like for example Hibernate or for all examples I have seen in "user code".

Do you have other arguments against annotations besides "dislike"? 
(Btw., many people actually like JPA over previous versions of EJB 
persistence just because lengthy XML files have been replaced by a few 
annotations.)  Do you at least concede that having the option to add 
user defined type safe meta data to language constructs is a totally new 
feature which allows to do things which cannot be done without?

> But to use it for plain language level constructs like @Override,
> @NotNull etc. is plain ugly. Why have keywords like final, public, etc.
> at all, then?

It may be ugly - but it may actually be the best solution considering 
all effects of language changes.  I did not think through all the 
effects of such a language change, did you?

> This way the language gets polluted using the generic annotation hammer.
> Leave it be or actually fix it! I would applaud a bold language revision
> that breaks backward compatibility for the benefit of fixing the
> language. I could even imagine an annotation that could hint the
> compiler at what language version a source is targeting.

I am glad that it's not you who decides about the further evolution of 
Java.  These dramatic changes all too often look like a good idea 
initially - and later turn out to be a nightmare when implemented 
without thoughtfully considering all effects of that change.

The term "software" creates the illusion that code can be changed at 
will.  But in reality changing code (especially when it's part of a 
public API) does have a cost - and it can be significant.  I suspect 
that this illusion is one of the reasons for so many project failures.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Arne Vajhøj wrote:
> Robert Klemme wrote:
>> Silvio Bierman wrote:
>>> Using an annotation is, as with
>>> almost all uses of annotations, a poor attempt at making up for the lack
>>> of a proper language feature.
>>
>> That is nonsense.  The mere fact that users can define their own
>> annotations along with handling these annotations demonstrates that
>> annotations solve problems which cannot be tackled by changing a
>> language's syntax.  Annotations add *arbitrary* meta data to language
>> constructs; if all these would have to be handled by a language change
>> you would need a new Java for every custom library which requires
>> additional meta data.
>
> True.
>
> There are two types of annotations:
> * those acting as a supplement to the language
> * those intended for runtime reflection

In many respects and for many purposes annotations obviate the need for 
byte-weaving approachs like AspectJ's. Annotations arguably are the most 
significant improvement to Java ever.

They make life ridiculously easy compared to not having them. For example, 
JUnit4 tests are simpler than JUnit3 and safer because annotations replace 
fragile and non-compiler-enforceable spelling conventions for method names. 
JPA uses annotations to define object-to-RDBMS correlations. For Android 
testing, annotations allow one to create multiple test suites off the same 
code base with no recompilation. The topical '@Override' is a significant 
assistance.

So many good things have come out of Java's adoption of annotations.

Silvio's opinion flies in the face of the evidence. It's an easy kind of thing 
to say - wave your hands about "proper" language features without having to 
say what the damage to the language might be or what such features might look 
like or whether they're even feasible. It would be a much harder claim to make 
if one were to enumerate all the "proper" language features that would be 
needed to approximate the functionality of annotations. That exercise might 
even force the retraction of the opinion, Gods forfend.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On Wed, 25 Jul 2012 07:57:00 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote:

[snip]

>The term "software" creates the illusion that code can be changed at 
>will.  But in reality changing code (especially when it's part of a 
>public API) does have a cost - and it can be significant.  I suspect 

     I have read this idea before.  I agree with it.

>that this illusion is one of the reasons for so many project failures.

     What's a little scope creep, eh?  I suspect that people thinking
that since software can be changed, it must be easy to do so leads to
a lot of scope creep.  That along with not designing in the first
place.

Sincerely,

Gene Wirchenko

On 7/25/2012 1:57 AM, Robert Klemme wrote:
> On 24.07.2012 23:14, Silvio Bierman wrote:
>> Well, I already really dislike annotations for their use in frameworks
>> like for example Hibernate or for all examples I have seen in "user
>> code".
>
> Do you have other arguments against annotations besides "dislike"?
> (Btw., many people actually like JPA over previous versions of EJB
> persistence just because lengthy XML files have been replaced by a few
> annotations.)

Many people prefer annotations over all those XML config files.

But I am also in disagreement about it.

A central XML config file is a cleaner solution than annotations
spread out in a large number of classes.

Replacing config XML is just one of many usages of annotations, so
it is not an argument against annotations.

Arne

On 7/25/2012 9:26 AM, Lew wrote:
> Arne Vajhøj wrote:
>> Robert Klemme wrote:
>>> Silvio Bierman wrote:
>>>> Using an annotation is, as with
>>>> almost all uses of annotations, a poor attempt at making up for the
>>>> lack
>>>> of a proper language feature.
>>>
>>> That is nonsense.  The mere fact that users can define their own
>>> annotations along with handling these annotations demonstrates that
>>> annotations solve problems which cannot be tackled by changing a
>>> language's syntax.  Annotations add *arbitrary* meta data to language
>>> constructs; if all these would have to be handled by a language change
>>> you would need a new Java for every custom library which requires
>>> additional meta data.
>>
>> True.
>>
>> There are two types of annotations:
>> * those acting as a supplement to the language
>> * those intended for runtime reflection
>
> In many respects and for many purposes annotations obviate the need for
> byte-weaving approachs like AspectJ's.

????

I find it difficult to see non-intrusive build time behavior
modification being replaced not even partially by intrusive
runtime behavior modification.

>                                         Annotations arguably are the most
> significant improvement to Java ever.

One could see at as that.

> They make life ridiculously easy compared to not having them. For
> example, JUnit4 tests are simpler than JUnit3 and safer because
> annotations replace fragile and non-compiler-enforceable spelling
> conventions for method names. JPA uses annotations to define
> object-to-RDBMS correlations. For Android testing, annotations allow one
> to create multiple test suites off the same code base with no
> recompilation. The topical '@Override' is a significant assistance.
>
> So many good things have come out of Java's adoption of annotations.
>
> Silvio's opinion flies in the face of the evidence.

There has not been posted any evidence that for the first bullet
type of annotations that a language change would not have been a
better solution if one did not have to consider the backward
compatibility problem.

That leaves the "almost all" part. I am not even sure that evidence
against that has been presented. Plenty of examples of other usages
has made it look highly questionable though.

Arne

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 7/23/2012 2:30 PM, bob smith wrote:
>> Is it really necessary to write @Override when you override or is this just "a good thing"?
>
>     Two benefits of @Override appear to me, one from its presence
> and one from its absence:
>
>     - If you write @Override and then misspell the method name or
>       mess up the parameter list, Java will say "Hey, wait: There's
>       nothing in the superclass with this signature; what do you
>       think you're doing?"  And then you'll say "Oops!" and fix
>       the problem, instead of wondering why your "overriding" method
>       doesn't seem to work.
>
>     - If you write a method and your IDE starts suggesting that you
>       ought to tag it with @Override, you'll be alerted that you've
>       overridden something you didn't intend to.[*]
>
>     Two benefits; that's all I see.  Hence, like indentation and
> Javadoc comments, not "really necessary" ...
>
>     [*] This actually happened to me earlier today.  I was writing
> a little Swing doodad to edit the "locations" of inventory items,
> and I gave it a getLocation() method.  NetBeans started clamoring
> for @Override, and I realized that my doodad extended JPanel which
> in turn extended JComponent, which already has a getLocation() ...
> Time for "Facepalm!" and a quick name change.

When you've overridden a class method in some third-party package and
then upgrade to a later version of that package, it sometimes turns out
that the method has been removed, or renamed, or given some additional
parameters.  It's much nicer to get a compile-time error than to
eventually discover that your overriding method is no longer being
called.  This has happened to me more than once with Hibernate.

-- 
Jim Janney

In article <501040e1$0$290$14726298@news.sunsite.dk>, arne@vajhoej.dk 
says...

> Many people prefer annotations over all those XML config files.
> 
> But I am also in disagreement about it.
> 
> A central XML config file is a cleaner solution than annotations
> spread out in a large number of classes.

It highly depends.

I like XML when it contains some data which is central for the 
application that needs to be configurable without building the product, 
but I'd rather prefer it written and read by the application itself, so 
you'd use it as a config file that is accessible through the 
application's configuration menu.

On the other hand there are loads of things, like for example database-
mappings, where I prefer annotations, simply for the narrow scope - I 
dislike to have to keep several files in sync, as I'm just lika every 
human, doomed to forget it once in a while - and as Murphy said: in the 
worst possible moment.

And sometimes XML is just not funny at all:
When I see hundreds of lines of Maven config XMLs, that contain several 
plugins and their configuration, quite frankly, it disturbs me like a 
god class. 

Kind regards,
Wanja

-- 
"I'm going to put something to you here, and I think you'd better 
listen to this: If we race, if we two race, we could end up with
nothing, so it's up to Eddie. If we don't race each other, 
we've got an opportunity to get first and second." 
[Damon Hill, Spa '98, being chased by Ralf lapping 5s faster than him]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---