why is var superValue not getting initialized to 911 in this code

[Lew]

If it was not valid, then it would be an error not a warning.

And yet Eclipse does not issue warnings for all valid code, just for certain
valid code.

The distinction between Eclipse and compiler is a bit fuzzy
since Eclipse uses its own compiler.

Well, normally when one refers to 'javac' explicitly, it refers to one from
Sun, otherwise one has a responsibility to specify to which 'javac' one
refers. Understanding that to be common, I spoke of 'javac' without further
brand attribution, an error I now correct; I was speaking of "javac 1.6.0_10"
from Sun, running in 64-bit Linux.

I consider the issuance of messages from that 'javac' to be normative.

On the flip side of that, when I said, "Eclipse would give a warning", I was,
of course, referring to its compiler metonymically. The distinction between
them is non-germane to how interesting it is that Eclipse would warn that one
has used a method declaration in a subclass when there exists a
signature-equivalent superclass method that is package-private.

Among the interesting thoughts that swirl around that:
- Eclipse goes out of its way to engender good coding practices.
- Eclipse provides a superset of the canonical compiler.
- Why would one care if one "pseudo-overrode" a private or package-private
method? Corollate: Should one care?
- Does Eclipse allow one to disable that particular warning? It has pretty
fine-grained control over its compiler warnings, so I expect it could.

It certainly trained the OP, me and anyone else listening to think about what
conditions actually define a method override, and about related matters like
method overloads, member visibility, package layout, escaping "this"
references fleeing from constructors, hiding, obscuring, obfuscating, ...

Bravo, OP - excellent topic.

 

[Arne Vajhøj]

And yet Eclipse does not issue warnings for all valid code, just for
certain valid code.

Obviously.

Like SUN javac issues warning when using generic types non genericly.

Well, normally when one refers to 'javac' explicitly, it refers to one
from Sun, otherwise one has a responsibility to specify to which 'javac'
one refers.

I agree with that.

By point was that the "work with SUN javac => the error most
come from the IDE not the compiler" is a bit fuzzy for Eclipse,
because they are part of the same product and the compiler are
different from the standard javac.

Arne

 

[heyx]

heyx_new

becase "SubclassB extends SuperclassA",so SubclassB replace the method:doValue(),you got the method is not SuperclassA's.we called thisuoTai.

 

[ankur]

Obviously.

Like SUN javac issues warning when using generic types non genericly.


I agree with that.

By point was that the "work with SUN javac => the error most
come from the IDE not the compiler" is a bit fuzzy for Eclipse,
because they are part of the same product and the compiler are
different from the standard javac.

Arne

Yes I confirm that if I do not use eclipse then no warning is given
on compiling or running the code. Its just eclipse, thats gives a
warning in this case.
Thanks for your help Lew, all! Its good to discuss and learn new
things.

 

[ankur]

Yes I confirm that if I do not use eclipse then no warning is  given
on compiling or running the code. Its just eclipse, thats gives a
warning in this case.
Thanks for your help Lew, all! Its good to discuss and learn new
things.

Also full text of the warning:

"The method SubclassB.doValue() does not override the inherited method
from SuperclassA since it is private to a different package"

 

[ankur]

Also full text of the warning:

"The method SubclassB.doValue() does not override the inherited method
from SuperclassA since it is private to a different package"

Also, the warning itself can be hidden by using eclipse setting
under : Window > Preferences > Compiler > Errors/ Warnings> Name
shadowing and conflicts > Method overridden but not package visible !

 

[Lew]

Also full text of the warning:

"The method SubclassB.doValue() does not override the inherited method
from SuperclassA since it is private to a different package"

 

[Lew]

Sorry about the previous trivial post. Stumble-fingered a mistaken "send".

This warning is erroneously worded, in that the method from SuperclassA is not
inherited if it's private or package-private in a different package.

JLS ss. 6.6.5 and 6.6.8.

 

[ankur]

Sorry about the previous trivial post.  Stumble-fingered a mistaken "send".


This warning is erroneously worded, in that the method from SuperclassA is not
inherited if it's private or package-private in a different package.

JLS ss. 6.6.5 and 6.6.8.

So, finally a bug in eclipse! , do we agree ?

 

[Lew]

So, finally a bug in eclipse [sic]! , do we agree ?

No. I understand "bug" as a variance from designed behavior. This is what I
call a "mistake".

 

[ankur]

So, finally a bug in eclipse [sic]! , do we agree ?

No.  I understand "bug" as a variance from designed behavior.  This is what I
call a "mistake".

Mistake in shipped products are bugs.

 

[Lew]

So, finally a bug in eclipse [sic]! , do we agree ?

No. I understand "bug" as a variance from designed behavior. This is what I
call a "mistake".

Mistake in shipped products are bugs.

If you say so. That's at variance with how the term has been used in my
experience, but so be it.

 

[Martin Gregorie]

So, finally a bug in eclipse [sic]! , do we agree ?

No. I understand "bug" as a variance from designed behavior. This is
what I call a "mistake".

Mistake in shipped products are bugs.

If you say so. That's at variance with how the term has been used in my
experience, but so be it.

There is a clear difference between programming errors, which result in
crashes or results that don't conform to the design specification, and
design errors, where a program that is conformant to the design doesn't
do what its required to do.

Some people call these 'bugs' and 'features' respectively.