Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #16253 > unrolled thread

@Override

Back to article view | Back to comp.lang.java.programmer

Contents

  @Override bob smith <bob@coolfone.comze.com> - 2012-07-23 11:30 -0700
    Re: @Override Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-23 20:52 +0200
    Re: @Override markspace <-@.> - 2012-07-23 11:54 -0700
      Re: @Override Lew <lewbloch@gmail.com> - 2012-07-23 13:05 -0700
      Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-23 19:54 -0400
    Re: @Override "John B. Matthews" <nospam@nospam.invalid> - 2012-07-23 15:56 -0400
      Re: @Override Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-07-23 14:19 -0700
        Re: @Override rossum <rossum48@coldmail.com> - 2012-07-24 13:09 +0100
          Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-24 21:29 -0400
        Re: @Override Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-24 09:04 -0400
    Re: @Override Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-23 16:35 -0400
      Re: @Override Lew <lewbloch@gmail.com> - 2012-07-23 13:59 -0700
        Re: @Override Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-23 23:40 +0200
          Re: @Override Lew <lewbloch@gmail.com> - 2012-07-23 14:51 -0700
            Re: @Override Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-24 00:08 +0200
              Re: @Override Lew <lewbloch@gmail.com> - 2012-07-23 16:57 -0700
        Re: @Override Robert Klemme <shortcutter@googlemail.com> - 2012-07-24 09:46 +0200
      Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-23 19:58 -0400
        Re: @Override Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-23 22:16 -0400
          Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-23 22:57 -0400
            Re: @Override Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-23 23:47 -0400
              Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-24 21:35 -0400
      Re: @Override Jim Janney <jjanney@shell.xmission.com> - 2012-07-26 20:00 -0600
    Re: @Override Gene Wirchenko <genew@ocis.net> - 2012-07-23 14:01 -0700
    Re: @Override Silvio Bierman <silvio@moc.com> - 2012-07-24 00:22 +0200
      Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-23 19:53 -0400
        Re: @Override Gene Wirchenko <genew@ocis.net> - 2012-07-23 18:59 -0700
        Re: @Override Silvio Bierman <silvio@moc.com> - 2012-07-24 22:57 +0200
          Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-24 21:24 -0400
      Re: @Override Robert Klemme <shortcutter@googlemail.com> - 2012-07-24 15:36 +0200
        Re: @Override Gene Wirchenko <genew@ocis.net> - 2012-07-24 09:54 -0700
        Re: @Override Silvio Bierman <silvio@moc.com> - 2012-07-24 23:14 +0200
          Re: @Override Robert Klemme <shortcutter@googlemail.com> - 2012-07-25 07:57 +0200
            Re: @Override Gene Wirchenko <genew@ocis.net> - 2012-07-25 10:34 -0700
            Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-25 14:54 -0400
              Re: @Override Wanja Gayk <brixomatic@yahoo.com> - 2012-07-30 14:42 +0200
        Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-24 21:20 -0400
          Re: @Override Lew <noone@lewscanon.com> - 2012-07-25 06:26 -0700
            Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-25 17:16 -0400
    Re: @Override Roedy Green <see_website@mindprod.com.invalid> - 2012-07-23 20:59 -0700
    Re: @Override Wanja Gayk <brixomatic@yahoo.com> - 2012-07-24 16:06 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#16296

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

[toc] | [prev] | [next] | [standalone]

#16330

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

[toc] | [prev] | [next] | [standalone]

#16402

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

[toc] | [prev] | [next] | [standalone]

#16266

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

[toc] | [prev] | [next] | [standalone]

#16272

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..

[toc] | [prev] | [next] | [standalone]

#16276

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

[toc] | [prev] | [next] | [standalone]

#16287

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

[toc] | [prev] | [next] | [standalone]

#16316

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

[toc] | [prev] | [next] | [standalone]

#16328

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

[toc] | [prev] | [next] | [standalone]

#16302

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/

[toc] | [prev] | [next] | [standalone]

#16305

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

[toc] | [prev] | [next] | [standalone]

#16317

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

[toc] | [prev] | [next] | [standalone]

#16331

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/

[toc] | [prev] | [next] | [standalone]

#16353

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

[toc] | [prev] | [next] | [standalone]

#16357

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

[toc] | [prev] | [next] | [standalone]

#16610

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 ---

[toc] | [prev] | [next] | [standalone]

#16327

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

[toc] | [prev] | [next] | [standalone]

#16335

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

[toc] | [prev] | [next] | [standalone]

#16362

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

[toc] | [prev] | [next] | [standalone]

#16297

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web