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

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

Re: A small exercise

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: A small exercise lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-20 17:02 +0100
    Re: A small exercise Arne Vajhøj <arne@vajhoej.dk> - 2013-04-20 15:15 -0400
      Re: A small exercise lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-21 11:04 +0100
        Re: A small exercise Arne Vajhøj <arne@vajhoej.dk> - 2013-04-26 22:13 -0400
          Re: A small exercise lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-27 09:25 +0100
            Re: A small exercise Arne Vajhøj <arne@vajhoej.dk> - 2013-04-27 21:58 -0400
              Re: A small exercise "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-04-28 11:34 +0100
                Re: A small exercise Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-28 12:17 +0000
                Re: A small exercise lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-28 14:05 +0100
                  Re: A small exercise Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-28 16:14 +0300
                    Re: A small exercise lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-28 14:54 +0100
                  Re: A small exercise Arne Vajhøj <arne@vajhoej.dk> - 2013-04-28 09:57 -0400
                Re: A small exercise Arne Vajhøj <arne@vajhoej.dk> - 2013-04-28 10:14 -0400
    Re: A small exercise Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-27 22:28 +0300
      Re: A small exercise markspace <markspace@nospam.nospam> - 2013-04-27 13:53 -0700
        Re: A small exercise Arne Vajhøj <arne@vajhoej.dk> - 2013-04-27 21:44 -0400
      Re: A small exercise lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-28 10:37 +0100

#23527 — Re: A small exercise

On 20/04/13 14:11, Stefan Ram wrote:
>    Try to predict the behavior of the execution or compilation
>    of the following code!
>
> public class Main
> { final int a; final int b;
>    Main(){ this.a = 0; Main.this.b = 0; }
>    public static void Main( final java.lang.String[] args )
>    { new Main(); }}
>
>    (I made this observation while programming something else
>    using Oracle JDK 7, but I have not read the JLS about it yet.)

open-jdk6 and open-jdk7

I think that logically, Main.this.b refers to the enclosing *instance* 
which implies that the class has been instantiated, final fields can 
only be initialized once in a constructor so trying to (logically) 
assign a value to a final variable after instantiation is illegal.

I think :-|

If you remove the final modifier from b then the code compiles, but then 
you know this already.


lipska


-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [next] | [standalone]

#23537

On 4/20/2013 12:02 PM, lipska the kat wrote:
> On 20/04/13 14:11, Stefan Ram wrote:
>>    Try to predict the behavior of the execution or compilation
>>    of the following code!
>>
>> public class Main
>> { final int a; final int b;
>>    Main(){ this.a = 0; Main.this.b = 0; }
>>    public static void Main( final java.lang.String[] args )
>>    { new Main(); }}
>>
>>    (I made this observation while programming something else
>>    using Oracle JDK 7, but I have not read the JLS about it yet.)
>
> open-jdk6 and open-jdk7
>
> I think that logically, Main.this.b refers to the enclosing *instance*
> which implies that the class has been instantiated, final fields can
> only be initialized once in a constructor so trying to (logically)
> assign a value to a final variable after instantiation is illegal.
>
> I think :-|
>
> If you remove the final modifier from b then the code compiles, but then
> you know this already.

My understanding of the question is that it is why a work but not b
as this and Main.this should be the same.

Arne

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

#23547

On 20/04/13 20:15, Arne Vajhøj wrote:
> On 4/20/2013 12:02 PM, lipska the kat wrote:
>> On 20/04/13 14:11, Stefan Ram wrote:
>>>    Try to predict the behavior of the execution or compilation
>>>    of the following code!
>>>
>>> public class Main
>>> { final int a; final int b;
>>>    Main(){ this.a = 0; Main.this.b = 0; }
>>>    public static void Main( final java.lang.String[] args )
>>>    { new Main(); }}
>>>
>>>    (I made this observation while programming something else
>>>    using Oracle JDK 7, but I have not read the JLS about it yet.)
>>
>> open-jdk6 and open-jdk7
>>
>> I think that logically, Main.this.b refers to the enclosing *instance*
>> which implies that the class has been instantiated, final fields can
>> only be initialized once in a constructor so trying to (logically)
>> assign a value to a final variable after instantiation is illegal.
>>
>> I think :-|
>>
>> If you remove the final modifier from b then the code compiles, but then
>> you know this already.
>
> My understanding of the question is that it is why a work but not b
> as this and Main.this should be the same.

Yes, this is what I understood.

I just don't think that >>this<< and >>Main.this<< are logically 
equivalent.

 >>this<< refers to the current instance,

 >>Main.this<< refers to the (logically) enclosing instance which 
implies that the >>Main.this.b<<  assignment occurs after instantiation 
which would be illegal which is why the compiler complains.


lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

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

#23662

On 4/21/2013 6:04 AM, lipska the kat wrote:
> On 20/04/13 20:15, Arne Vajhøj wrote:
>> On 4/20/2013 12:02 PM, lipska the kat wrote:
>>> On 20/04/13 14:11, Stefan Ram wrote:
>>>>    Try to predict the behavior of the execution or compilation
>>>>    of the following code!
>>>>
>>>> public class Main
>>>> { final int a; final int b;
>>>>    Main(){ this.a = 0; Main.this.b = 0; }
>>>>    public static void Main( final java.lang.String[] args )
>>>>    { new Main(); }}
>>>>
>>>>    (I made this observation while programming something else
>>>>    using Oracle JDK 7, but I have not read the JLS about it yet.)
>>>
>>> open-jdk6 and open-jdk7
>>>
>>> I think that logically, Main.this.b refers to the enclosing *instance*
>>> which implies that the class has been instantiated, final fields can
>>> only be initialized once in a constructor so trying to (logically)
>>> assign a value to a final variable after instantiation is illegal.
>>>
>>> I think :-|
>>>
>>> If you remove the final modifier from b then the code compiles, but then
>>> you know this already.
>>
>> My understanding of the question is that it is why a work but not b
>> as this and Main.this should be the same.
>
> Yes, this is what I understood.
>
> I just don't think that >>this<< and >>Main.this<< are logically
> equivalent.
>
>  >>this<< refers to the current instance,
>
>  >>Main.this<< refers to the (logically) enclosing instance which
> implies that the >>Main.this.b<<  assignment occurs after instantiation
> which would be illegal which is why the compiler complains.

For the given code this and Main.this refer to the same object.

And I don't see the implication you mention - in fact the so called
implication is not true for the provided code.

Arne

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

#23666

On 27/04/13 03:13, Arne Vajhøj wrote:
> On 4/21/2013 6:04 AM, lipska the kat wrote:
>> On 20/04/13 20:15, Arne Vajhøj wrote:
>>> On 4/20/2013 12:02 PM, lipska the kat wrote:
>>>> On 20/04/13 14:11, Stefan Ram wrote:
>>>>>    Try to predict the behavior of the execution or compilation
>>>>>    of the following code!
>>>>>
>>>>> public class Main
>>>>> { final int a; final int b;
>>>>>    Main(){ this.a = 0; Main.this.b = 0; }
>>>>>    public static void Main( final java.lang.String[] args )
>>>>>    { new Main(); }}
>>>>>
>>>>>    (I made this observation while programming something else
>>>>>    using Oracle JDK 7, but I have not read the JLS about it yet.)
>>>>
>>>> open-jdk6 and open-jdk7
>>>>
>>>> I think that logically, Main.this.b refers to the enclosing *instance*
>>>> which implies that the class has been instantiated, final fields can
>>>> only be initialized once in a constructor so trying to (logically)
>>>> assign a value to a final variable after instantiation is illegal.
>>>>
>>>> I think :-|
>>>>
>>>> If you remove the final modifier from b then the code compiles, but
>>>> then
>>>> you know this already.
>>>
>>> My understanding of the question is that it is why a work but not b
>>> as this and Main.this should be the same.
>>
>> Yes, this is what I understood.
>>
>> I just don't think that >>this<< and >>Main.this<< are logically
>> equivalent.
>>
>>  >>this<< refers to the current instance,
>>
>>  >>Main.this<< refers to the (logically) enclosing instance which
>> implies that the >>Main.this.b<<  assignment occurs after instantiation
>> which would be illegal which is why the compiler complains.
>
> For the given code this and Main.this refer to the same object.

Ah yes, the old 'state the obvious to discredit the poster' technique 
... weak (and incorrect, see below).

Instead of making incorrect observations try to come up with
a theory of your own. Here's an expansion of my theory

Java-7-openjdk, Eclipse Juno

The following code snippet gives 2 compile time errors

final int a; final int b;

public Main(){
    this.a = 0;
    Main.this.b = 0;
}

the errors are,

"the blank final field b may not have been initialized"
and
"the final field Main.b cannot be assigned"

This *implies* to me that this.b and Main.this.b are not *logically 
equivalent*, this is what I said, nothing to do with whether
"For the given code this and Main.this refer to the same object." that 
is entirely a fabrication of your own confused mind, in any case, I 
would never have used the work 'object' in this context, I would use the 
word instance, not the same thing at all.

If this and Main.this not equivalent then they must be different, now 
all we need to figure out is what the difference is.

I say that the difference is that the construct Main.b *logically* 
refers to a concrete instance of Main which implies that Main has been 
instantiated which means that you are trying to initialize a blank final 
variable outside the class constructor which is illegal.

As usual I'm happy to be proved wrong as it will mean I have learned 
something which implies that I don't know everything which I have no 
difficulty with.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

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

#23681

On 4/27/2013 4:25 AM, lipska the kat wrote:
> On 27/04/13 03:13, Arne Vajhøj wrote:
>> On 4/21/2013 6:04 AM, lipska the kat wrote:
>>> On 20/04/13 20:15, Arne Vajhøj wrote:
>>>> On 4/20/2013 12:02 PM, lipska the kat wrote:
>>>>> On 20/04/13 14:11, Stefan Ram wrote:
>>>>>>    Try to predict the behavior of the execution or compilation
>>>>>>    of the following code!
>>>>>>
>>>>>> public class Main
>>>>>> { final int a; final int b;
>>>>>>    Main(){ this.a = 0; Main.this.b = 0; }
>>>>>>    public static void Main( final java.lang.String[] args )
>>>>>>    { new Main(); }}
>>>>>>
>>>>>>    (I made this observation while programming something else
>>>>>>    using Oracle JDK 7, but I have not read the JLS about it yet.)
>>>>>
>>>>> open-jdk6 and open-jdk7
>>>>>
>>>>> I think that logically, Main.this.b refers to the enclosing *instance*
>>>>> which implies that the class has been instantiated, final fields can
>>>>> only be initialized once in a constructor so trying to (logically)
>>>>> assign a value to a final variable after instantiation is illegal.
>>>>>
>>>>> I think :-|
>>>>>
>>>>> If you remove the final modifier from b then the code compiles, but
>>>>> then
>>>>> you know this already.
>>>>
>>>> My understanding of the question is that it is why a work but not b
>>>> as this and Main.this should be the same.
>>>
>>> Yes, this is what I understood.
>>>
>>> I just don't think that >>this<< and >>Main.this<< are logically
>>> equivalent.
>>>
>>>  >>this<< refers to the current instance,
>>>
>>>  >>Main.this<< refers to the (logically) enclosing instance which
>>> implies that the >>Main.this.b<<  assignment occurs after instantiation
>>> which would be illegal which is why the compiler complains.
>>
>> For the given code this and Main.this refer to the same object.
>
> Ah yes, the old 'state the obvious to discredit the poster' technique
> ... weak (and incorrect, see below).
>
> Instead of making incorrect observations try to come up with
> a theory of your own. Here's an expansion of my theory
>
> Java-7-openjdk, Eclipse Juno
>
> The following code snippet gives 2 compile time errors
>
> final int a; final int b;
>
> public Main(){
>     this.a = 0;
>     Main.this.b = 0;
> }
>
> the errors are,
>
> "the blank final field b may not have been initialized"
> and
> "the final field Main.b cannot be assigned"
>
> This *implies* to me that this.b and Main.this.b are not *logically
> equivalent*, this is what I said, nothing to do with whether
> "For the given code this and Main.this refer to the same object." that
> is entirely a fabrication of your own confused mind, in any case,

Nope.

The JVM agrees.

Try:

System.out.println(this==Main.this);

>                                                                       I
> would never have used the work 'object' in this context, I would use the
> word instance, not the same thing at all.

You may not have used the term, but since JLS use the term "object
equality", then that is not my problem.

> If this and Main.this not equivalent then they must be different, now
> all we need to figure out is what the difference is.

The logic that:

the compiler must be correct => different handling by compiler most mean
that they are different => compiler is right

is a circular logic.

> I say that the difference is that the construct Main.b *logically*
> refers to a concrete instance of Main which implies that Main has been
> instantiated which means that you are trying to initialize a blank final
> variable outside the class constructor which is illegal.

The exact same logic could just as well be applied to this, so it
does not hold water.

Arne

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

#23691

Arne Vajhøj wrote:
> On 4/27/2013 4:25 AM, lipska the kat wrote:
> > This *implies* to me that this.b and Main.this.b are not *logically
> > equivalent*, this is what I said, nothing to do with whether
> > [obnoxious stuff elided]
>
> Nope.
>
> The JVM agrees.
>
> Try:
>
> System.out.println(this==Main.this);

But that proves nothing, doesn't even indicate anything.  It's commonplace for
two independent identifiers to refer to the same object.  And those two
different forms of reference may have different rules (consider using protected
access via "this" verses an independent reference to the same object).  Lipska
is suggesting that this is one of those occasions, and that's a perfectly
plausible hypothesis.

I don't think it turns out to be true, though -- the JSL3 seems to be in
opposition.  A trawl through the spec (my first in years) discovers 15.8.4,
quoted in toto (with the usual bloody difficulty):

  15.8.4   Qualifed this
  Any lexically enclosing instance can be referred to by explicitly qualifying
  the keyword this.
    Let C be the class denoted by <ClassName>. Let n be an integer such that C
  is the nth lexically enclosing class of the class in which the qualified
  [this] expression appears.The value of an expression of the form
  <ClassName>.[this] is the nth lexi cally enclosing instance of [this]. 
(8.1.3).
  The type of the expression is C.It is a   compile-time error if the current 
class
  is not an inner   class of class C or C itself.

(my <>s and []s)

The last three words seem, if not decisive, then at least strongly indicative
to me.

I'm guessing (and I admit that I can find no other supporting evidence) that
this is a bug in the compiler where code that is written on the assumption that
"C" above must be a strictly enclosing class.  In those case the (equivalent)
code would obviously be incorrect (and that goes for the blank-final example
too).  In particular I suspect that its something going squiffy in the
contorted logic that allows nested classes to refer to private fields of the
[not actually] "enclosing" class at runtime: that horrible stuff that is added
to circumvent the JVMs own checking.

But I may as well admit that one piece of evidence against my guess is that
both javac and Eclipse "fail" in the same way.

    -- chris

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

#23694

On Sun, 28 Apr 2013 11:34:49 +0100, Chris Uppal wrote:

> But I may as well admit that one piece of evidence against my guess is
> that both javac and Eclipse "fail" in the same way.
>
Might that point to an error in the validation suite? 

It seems to me that this is the only unique set of files based on the JLS. 
You cannot make the same statement about JVM or compiler sources and 
hence about code compiled from them. 
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#23695

On 28/04/13 11:34, Chris Uppal wrote:

[snip]

> I'm guessing (and I admit that I can find no other supporting evidence) that
> this is a bug in the compiler where code that is written on the assumption that
> "C" above must be a strictly enclosing class.  In those case the (equivalent)
> code would obviously be incorrect (and that goes for the blank-final example
> too).  In particular I suspect that its something going squiffy in the
> contorted logic that allows nested classes to refer to private fields of the
> [not actually] "enclosing" class at runtime: that horrible stuff that is added
> to circumvent the JVMs own checking.
>
> But I may as well admit that one piece of evidence against my guess is that
> both javac and Eclipse "fail" in the same way.

Not sure what you mean here as Eclipse can be configured to use 
different compilers independently of the version of Java used to run the 
application (Eclipse)

I configured Eclipse to compile against

java-7-openjdk
and, separately
java version 1.6.0_35

and both times came up with the same error

So, it's not actually Eclipse that barfed per-se but two different 
releases of the language ... which is leading me to believe that it's 
not a *bug* but a poorly understood (by me) application of the rules of 
the language by the compiler.

If I could just figure out what the rule was :-(

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

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

#23696

On 04/28/2013 04:05 PM, lipska the kat wrote:
> Not sure what you mean here as Eclipse can be configured to use
> different compilers

Eclipse only has one compiler. It's specially written by IBM for 
Eclipse, and it's not based on javac as far as I know.

> independently of the version of Java used to run the
> application (Eclipse)
>
> I configured Eclipse to compile against
>
> java-7-openjdk
> and, separately
> java version 1.6.0_35

But each time, you're using Eclipse's compiler, and not the javac of the 
JDK.


Regards,
   Sven

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

#23699

On 28/04/13 14:14, Sven Köhler wrote:
> On 04/28/2013 04:05 PM, lipska the kat wrote:
>> Not sure what you mean here as Eclipse can be configured to use
>> different compilers
>
> Eclipse only has one compiler. It's specially written by IBM for
> Eclipse, and it's not based on javac as far as I know.
>
>> independently of the version of Java used to run the
>> application (Eclipse)
>>
>> I configured Eclipse to compile against
>>
>> java-7-openjdk
>> and, separately
>> java version 1.6.0_35
>
> But each time, you're using Eclipse's compiler, and not the javac of the
> JDK.

OK, well, I'm no Eclipse expert so I'll have to look into that, in the 
meantime apologies to Chris Uppal, it appears he was correct and I was 
wrong.

For the time being let's call it the Eclipse compiler compliance level 
then, with compliance set to 1.6 or 1.7 the same error occurs

also, and independently of Eclipse

/usr/lib/jvm/java-7-openjdk-amd64/bin/javac Main.java
Main.java:10: error: cannot assign a value to final variable b
         Main.this.b = 0;

/opt/java/jdk1.6.0_35/bin/javac Main.java
Main.java:10: cannot assign a value to final variable b
         Main.this.b = 0;
                  ^
None of which changes my thought that

"it's not a *bug* but a poorly understood (by me) application of the 
rules of the language by the compiler"

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

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

#23700

On 4/28/2013 9:05 AM, lipska the kat wrote:
> On 28/04/13 11:34, Chris Uppal wrote:
>
> [snip]
>
>> I'm guessing (and I admit that I can find no other supporting
>> evidence) that
>> this is a bug in the compiler where code that is written on the
>> assumption that
>> "C" above must be a strictly enclosing class.  In those case the
>> (equivalent)
>> code would obviously be incorrect (and that goes for the blank-final
>> example
>> too).  In particular I suspect that its something going squiffy in the
>> contorted logic that allows nested classes to refer to private fields
>> of the
>> [not actually] "enclosing" class at runtime: that horrible stuff that
>> is added
>> to circumvent the JVMs own checking.
>>
>> But I may as well admit that one piece of evidence against my guess is
>> that
>> both javac and Eclipse "fail" in the same way.
>
> Not sure what you mean here as Eclipse can be configured to use
> different compilers independently of the version of Java used to run the
> application (Eclipse)
>
> I configured Eclipse to compile against
>
> java-7-openjdk
> and, separately
> java version 1.6.0_35
>
> and both times came up with the same error

That is the runtime enviroment.

Eclipse uses a special incremental compiler no matter what
runtime environment.

I believe it is called ecj.

And it is actually used in a few other products like
newer versions of Tomcat.

Arne

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

#23701

On 4/28/2013 6:34 AM, Chris Uppal wrote:
> Arne Vajhøj wrote:
>> On 4/27/2013 4:25 AM, lipska the kat wrote:
>>> This *implies* to me that this.b and Main.this.b are not *logically
>>> equivalent*, this is what I said, nothing to do with whether
>>> [obnoxious stuff elided]
>>
>> Nope.
>>
>> The JVM agrees.
>>
>> Try:
>>
>> System.out.println(this==Main.this);
>
> But that proves nothing, doesn't even indicate anything.

It shows that it is the same object.

>                                             It's commonplace for
> two independent identifiers to refer to the same object.  And those two
> different forms of reference may have different rules (consider using protected
> access via "this" verses an independent reference to the same object).

Nothing unusual in that a.b and c.d.f.g.h.j refers to same object.

And if the question is about accessibility then obviously the
path to the object is relevant.

But should the path used for access be relevant for whether something
in the object is definite assigned or definite unassigned?

> I'm guessing (and I admit that I can find no other supporting evidence) that
> this is a bug in the compiler where code that is written on the assumption that
> "C" above must be a strictly enclosing class.  In those case the (equivalent)
> code would obviously be incorrect (and that goes for the blank-final example
> too).  In particular I suspect that its something going squiffy in the
> contorted logic that allows nested classes to refer to private fields of the
> [not actually] "enclosing" class at runtime: that horrible stuff that is added
> to circumvent the JVMs own checking.

Yes.

> But I may as well admit that one piece of evidence against my guess is that
> both javac and Eclipse "fail" in the same way.

Yes.

Arne

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

#23670

Am 20.04.2013 19:02, schrieb lipska the kat:
> I think that logically, Main.this.b refers to the enclosing *instance*
> which implies that the class has been instantiated

"this" also refers to an instance - doesn't it?
And following your argument, I should not be able to use "this" in the
constructor.

I'm not saying, that the JLS makes a different between a mere "this" and
a construct of the form "Classname.this" and that this is essentially
the cause for the code not compiling. But I don't see the point of your
argument.


Regards,
  Sven

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

#23671

On 4/27/2013 12:28 PM, Sven Köhler wrote:
> Am 20.04.2013 19:02, schrieb lipska the kat:
>> I think that logically, Main.this.b refers to the enclosing *instance*
>> which implies that the class has been instantiated
>
> "this" also refers to an instance - doesn't it?
> And following your argument, I should not be able to use "this" in the
> constructor.

Right, in a ctor, "this" refers to the object under construction. Ctors 
are not static methods, they are instance methods that don't inherit or 
participate in dynamic method name resolution.

The original question is kinda weird, Main.this.b feels like it should 
be a static reference of some sort, or a reference to an enclosing 
instance or something.  It's a valid question, but also rather unnatural 
to write and a corner case of the language.

I think the OP is asking for his class and students.  I can't really 
give a good answer why it does what it does.  "It no work" is about all 
I can say, and encourage the student to use "this.b" in cases like the 
one cited.

>
> I'm not saying, that the JLS makes a different between a mere "this" and
> a construct of the form "Classname.this" and that this is essentially
> the cause for the code not compiling. But I don't see the point of your
> argument.

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

#23680

On 4/27/2013 4:53 PM, markspace wrote:
> On 4/27/2013 12:28 PM, Sven Köhler wrote:
>> Am 20.04.2013 19:02, schrieb lipska the kat:
>>> I think that logically, Main.this.b refers to the enclosing *instance*
>>> which implies that the class has been instantiated
>>
>> "this" also refers to an instance - doesn't it?
>> And following your argument, I should not be able to use "this" in the
>> constructor.
>
> Right, in a ctor, "this" refers to the object under construction. Ctors
> are not static methods, they are instance methods that don't inherit or
> participate in dynamic method name resolution.
>
> The original question is kinda weird, Main.this.b feels like it should
> be a static reference of some sort, or a reference to an enclosing
> instance or something.  It's a valid question, but also rather unnatural
> to write and a corner case of the language.
>
> I think the OP is asking for his class and students.  I can't really
> give a good answer why it does what it does.  "It no work" is about all
> I can say, and encourage the student to use "this.b" in cases like the
> one cited.

No doubt about that.

But it is still puzzling about why the compilers give that error.

And it is both SUN javac and Eclipse JDT that barfs over it.

Arne

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

#23690

On 27/04/13 20:28, Sven Köhler wrote:
> Am 20.04.2013 19:02, schrieb lipska the kat:
>> I think that logically, Main.this.b refers to the enclosing *instance*
>> which implies that the class has been instantiated
>
> "this" also refers to an instance - doesn't it?
> And following your argument, I should not be able to use "this" in the
> constructor.
>
> I'm not saying, that the JLS makes a different between a mere "this" and
> a construct of the form "Classname.this" and that this is essentially
> the cause for the code not compiling. But I don't see the point of your
> argument.

java-7-openjdk, Eclipse Juno

this compiles

final int a; int b;
	
public Main(){
    this.a = 0;
    Main.this.b = 0;
}

this doesn't

final int a; *final* int b;
	
public Main(){
    this.a = 0;
    Main.this.b = 0;
}

The only difference is the final modifier applied
to the second b

I suppose I agree that at first site this and Main.this refer to the 
same instance, however we are still left with the fact the second 
snippet doesn't compile. So, I'm saying that *logically* this and 
Main.this are not equivalent. If they were then we wouldn't be having 
this problem would we?

Or maybe you know better, in which case can you tell me 'cause this is 
starting to bug me.

Now I'm trying to figure out *why* they are different and one theory is 
that as far as the complier is concerned the construct Main.this.b in 
some way *implies* that Main has already been instantiated so attempting 
to initialize a final variable after instantiation is illegal.

Does that make more sense?

No!, well do you have a better idea?

Interesting discussion

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [standalone]

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

csiph-web