local class philosophy

[puzzlecracker]

In a local class we can reference local members only if they declared
as final. However, whenever local class is using, jvm makes an internal
copy. Therefore, why cannot we use nonfinal local variables.,? What is
the idea behind it? I guess the same argument can be applied to
anonymous classes.

suggestions, issues, illustrations as always are appreciated.

 

[Thomas Hawtin]

In a local class we can reference local members only if they declared ^^^^^^^variables
as final. However, whenever local class is using, jvm makes an internal
copy. Therefore, why cannot we use nonfinal local variables.,? What is
the idea behind it? I guess the same argument can be applied to
anonymous classes.

If non-final variables were copied, the variables would behave
differently depending on how they were accessed.

A sane handling of the mutable local variables would be to have a single
heap allocated copy. Ten years ago, when inner classes were introduced,
allocating on the heap implicitly was widely considered a bad thing.
Particularly from the backgrounds Java programmers tended to have in
those days. IIRC, the language designers preferred the shared mutable
option, but popular opinion was against them. Why it hasn't been
corrected since, I don't know.

Tom Hawtin

 

[Torkel Franzen]

If non-final variables were copied, the variables would behave
differently depending on how they were accessed.

Could you expand on this?

 

[duff]

Could you expand on this?

I could be wrong but this is what I think:

The JVM does not know of "local classes" as they are compiled into
separate classes, so final variables are actually copied into the
classes during compilation.

 

[Mike Schilling]

I could be wrong but this is what I think:

The JVM does not know of "local classes" as they are compiled into
separate classes, so final variables are actually copied into the
classes during compilation.

No, the values a local class knows must be final, but are not necessarily
compile-time constants, e.g.

void method() throws IOException
{
final long time = System.currentTimeMillis();
class LocalClass
{
// can use the value of time;
}
}

These final but not-known-at-compile-time values are passed to the local
class's constructor(s), as you can check for yourself using javap.

 

[ricky.clarkson]

These final but not-known-at-compile-time values are passed to the local

class's constructor(s), as you can check for yourself using javap.

Interesting, I always thought that was synthetic methods, but it seems
you're right.

<code>
class One
{
void method()
{
final long time=System.currentTimeMillis();

class Local
{
public Local(int test)
{
}

public void method2()
{
System.out.println(time);
}
}

new Local(5).method2();
}
}
</code>

The above gets compiled to look like this:

<code>
class One
{
void method()
{
final long time=System.currentTimeMillis();
new One$1Local(this,5,time).method2();
}
}

class One$1Local
{
public One$1Local(One oneThis,int number,long time)
{
this$0=oneThis;
this.val$time=time;
}

public void method2()
{
System.out.println(val$time);
}
}

So the order is enclosing instance first, then explicit parameters from
the original source, then extra variables as required.

Interesting.

 

[Mike Schilling]

Interesting, I always thought that was synthetic methods,

Methods on what?

There's no method call that returns the value of a local variable in a
pre-existing scope.

but it seems
you're right.

<code>
class One
{
void method()
{
final long time=System.currentTimeMillis();

class Local
{
public Local(int test)
{
}

public void method2()
{
System.out.println(time);
}
}

new Local(5).method2();
}
}
</code>

The above gets compiled to look like this:

<code>
class One
{
void method()
{
final long time=System.currentTimeMillis();
new One$1Local(this,5,time).method2();
}
}

class One$1Local
{
public One$1Local(One oneThis,int number,long time)
{
this$0=oneThis;
this.val$time=time;
}

public void method2()
{
System.out.println(val$time);
}
}

So the order is enclosing instance first, then explicit parameters from
the original source, then extra variables as required.

I believe it's compiler-specific, but, yes, that's what javac does.

 

[Torkel Franzen]

If non-final variables were copied, the variables would behave
differently depending on how they were accessed.

The thread seems to have petered out, but I would like to return
to this topic.

The relevant passage in JLS is in 8.1.3:

Any local variable, formal method parameter or exception handler
parameter used but not declared in an inner class must be declared
final.

To understand the rationale behind this requirement, I would like to
see some examples of what could go wrong or would become troublesome
without it.

 

[Chris Smith]

The thread seems to have petered out, but I would like to return
to this topic.

The relevant passage in JLS is in 8.1.3:

Any local variable, formal method parameter or exception handler
parameter used but not declared in an inner class must be declared
final.

To understand the rationale behind this requirement, I would like to
see some examples of what could go wrong or would become troublesome
without it.

If this requirement were not true, then the obvious behavior for
accessing a non-final local variable would be that the variable is
shared between the local method context and the inner class. That is,
if one changes the value, the change is visible from the other.

This obvious behavior suffers from two faults: (1) it's complex to
implement and has potentially hidden performance costs, and (2) it
breaks the assumption that local variables never contain shared state
and access to them never need to be synchronized. To avoid these
faults, the requirement was added that they be final... which guarantees
that one possible implementation is for them to be copied into the inner
class; easy to implement, and no threading issues.

The final keyword is required, rather than implying a copy, for two
reasons. First, least surprise as hinted in my first paragraph above.
Second, it leaves an opening for implementing mutable local variables by
transparently encapsulating the locals into an object on the heap when
the method is called. I'm unsure whether this is a good idea and Sun
may never do it; but it could be done compatibly just by lifting the
final requirement for local variables and parameters.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Torkel Franzen]

If this requirement were not true, then the obvious behavior for
accessing a non-final local variable would be that the variable is
shared between the local method context and the inner class. That is,
if one changes the value, the change is visible from the other.

To prevent this, it would suffice to stipulate that only the value of
the local variable may be used in the inner class. But I suppose a
wholesale "final" modifier is simpler.

This obvious behavior suffers from two faults: (1) it's complex to
implement and has potentially hidden performance costs, and (2) it
breaks the assumption that local variables never contain shared state
and access to them never need to be synchronized.

So is (2) the reason why the restriction only applies to local
variables (and parameters)?

 

[Chris Smith]

To prevent this, it would suffice to stipulate that only the value of
the local variable may be used in the inner class. But I suppose a
wholesale "final" modifier is simpler.

It would be possible to do so, of course. Then again, the more non-
obvious behavior is added to a language, the harder it is to learn.
Some -- though not all -- people in Sun seem to understand this.

So is (2) the reason why the restriction only applies to local
variables (and parameters)?

Both are reasons. There also exists a simple and relatively
performance-cost free implementation for fields.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Torkel Franzen]

Both are reasons. There also exists a simple and relatively
performance-cost free implementation for fields.

Well, the upshot seems to be that the requirement is a rather
recondite one, unlike many other rules of the language, and does
not admit any "compelling" justification.

 

[Roedy Green]

Well, the upshot seems to be that the requirement is a rather
recondite one, unlike many other rules of the language, and does
not admit any "compelling" justification.

recdondite: abstruse, out of the way, little known.