local class philosophy

Thread view:

puzzlecracker - 21 Jan 2006 00:31 GMT

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.

Reply to this Message

Thomas Hawtin - 21 Jan 2006 02:48 GMT

> 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

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

Torkel Franzen - 21 Jan 2006 03:09 GMT

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

Could you expand on this?

Reply to this Message

duff - 22 Jan 2006 02:23 GMT

>> If non-final variables were copied, the variables would behave
>> differently depending on how they were accessed.
>
> 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.

Reply to this Message

Mike Schilling - 22 Jan 2006 06:51 GMT

>>> If non-final variables were copied, the variables would behave
>>> differently depending on how they were accessed.
[quoted text clipped - 6 lines]
> 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.

Reply to this Message

ricky.clarkson@gmail.com - 22 Jan 2006 16:26 GMT

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

Reply to this Message

Mike Schilling - 23 Jan 2006 15:31 GMT

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

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.
[quoted text clipped - 51 lines]
> 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.

Reply to this Message

Torkel Franzen - 25 Jan 2006 07:09 GMT

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

Reply to this Message

Chris Smith - 25 Jan 2006 09:25 GMT

> The thread seems to have petered out, but I would like to return
> to this topic.
[quoted text clipped - 8 lines]
> 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.

Signature

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Reply to this Message

Torkel Franzen - 25 Jan 2006 10:01 GMT

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

Reply to this Message

Chris Smith - 25 Jan 2006 15:48 GMT

> > If this requirement were not true, then the obvious behavior for
> > accessing a non-final local variable would be that the variable is
[quoted text clipped - 4 lines]
> 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.

> > This obvious behavior suffers from two faults: (1) it's complex to
> > implement and has potentially hidden performance costs, and (2) it
[quoted text clipped - 3 lines]
> 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.

Signature

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Reply to this Message

Torkel Franzen - 25 Jan 2006 15:59 GMT

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

Reply to this Message

Roedy Green - 25 Jan 2006 20:23 GMT

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

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

local class philosophy

Free Magazines