«

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/wikipedi.../c/cf/Friz.jpg

On Wed, 25 Jul 2012 07:57:00 +0200, Robert Klemme
<> 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 <> 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