Re: Local Class Question

From: John C. Bollinger (jobollin_at_indiana.edu)
Date: 11/09/03 

Date: Sun, 09 Nov 2003 17:18:36 -0500

Tim Hill wrote:

> I'm just getting up to speed on Java, and have a question about local class
> behavior. Here's a mini-app to illustrate:
>
> interface Foo { void print(); }
>
> class LocalClassTest
> {
> public static void main(String[] args) {
> Foo foo = getFooImpl(100);
> foo.print();
> }
>
> public static Foo getFooImpl(final int i) {
> class FooImpl implements Foo {
> public void print() {
> System.out.println("i = " + i);
> }
> }
> return new FooImpl();
> }
> }
>
> As expected (at least, as I expect) this code prints "i = 100". But what
> bugs me is where does this come from? By the time I call "foo.print" the
> method "getFooImpl" has returned, and its local variables/parameters should
> have been flushed off the stack, along with the value "100" that eventually
> gets printed. The only way I can see this as working is that the compiler
> has somehow promoted the parameter "i" in "getFooImpl" into a hidden field
> within class FooImpl, but I cannot find any docs about this anywhere. Or is
> "i" really a reference and has FooImpl grabbed a shadow(y) ref to it?
>
> Any of you experts care to shed some light on this?

The Inner Classes Specification is available as part of the JDK 1.1
documentation, and perhaps elsewhere as well. It describes this
particular kind of situation specifically. Similar to your guess, the
compiler creates a synthetic field inside the inner class into which
the value in question is written. Because the variable is final in the
containing method, there is no worry that the value of the copy will
ever differ from the original. The local variable in the containing
method is distinct from the copy in the inner class instance, however,
and is not in fact special in any way not reflected by its declaration.

It _is_ necessary for variables referenced in this way to be final, but
I suspect you already realize that that does not necessarilly make them
compile-time constants. The variable in your example certainly isn't
one. The key, though, is that there should be no externally detectable
difference in behavior from what would be observed if the containing
method's local variable were somehow retained and used directly.

John Bollinger
jobollin@indiana.edu

Relevant Pages

  • Re: Local Class Question
    ... Thanks John, I'd kinda reached this conclusion by looking at some of the ... bytecodes and what the compiler was up to. ... > ever differ from the original. ... > method is distinct from the copy in the inner class instance, however, ...
    (comp.lang.java.programmer)
  • redefinition of generic methods
    ... int F ... it is however interesting that this restriction also applies to generic methods that differ on constraints: ... note that constraints are strictly exclusive here. ... it would be deterministic then for the compiler to pick a method to call: ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Compiling in 32 vs 64 platform problem
    ... I use Intel Fortran compiler version 8.1. ... -|followed by linking of the different object files. ... -|go smoothly but the results obtained from the program differ from ... -|those that I get on 32 bit architecture machines. ...
    (comp.lang.fortran)
  • Re: What is Expressiveness in a Computer Language
    ... as much of the working fragments as I can, and I want a `safety net' to ... and staying where the compiler can prove I'll be ok. ... on the static/dynamic thing and see how the approaches differ. ...
    (comp.lang.functional)
  • Re: effects of "final" in parameters
    ... I /have/ to use it to satisfy the compiler that an inner class won't ... break if it refers to the parameter). ...
    (comp.lang.java.programmer)
Loading