Re: [eclipselink-users] Support for inner classes?

[Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>]

On Wednesday 16 April 2008, Tom Ware wrote:
> There is support in EclipseLink for alternate ways of instantiating classes.
> 
> http://wiki.eclipse.org/Configuring_a_Descriptor_(ELUG)#Configuring_Instantiation_Policy
That looks promising. Thanks for the pointer.

Looking at the Javadoc of, e.g., ClassDescriptor#useMethodInstantiationPolicy(java.lang.String)
I see no description of what the instantiation method should look like, but I'm afraid
it may have to be an argument-less method? Or is it possible to access any context?
(see also below).


> They require you to use some EclipseLink specific configuration (e.g. you will 
> not be able to use pure JPA, for instance)
That's OK, for now.
 
> James Sutherland wrote:
> > [...]
> > 
> > Perhaps include an example of the exact type of inner class you want to
> > persist and someone can try it out.
I'm sure it won't work out-of-the box. Here is the simplest of all examples:

public class Outer {
	public class Inner {
		String value;
	}
}

Now when creating an instance of Inner, Java offers two options:
a) within a non-static method of Outer you may simply use "new Inner()"
b) outside Outer you need an explicit instance of Outer as in
	Outer o = ...
	Outer.Inner i = o.new Inner();
Note, that this distinction is relevant only at the source code level.
At the bytecode level class Inner looks pretty much like this:
	public class Outer$Inner {
		final Outer this$0;
		public Outer$Inner(Outer this$0) {
			this.this$0 = this$0;
		}
	}
Thus instantiation is translated into
a)	new Inner(this); // within a non-static context of Outer
b)	new Inner(o);    // outside Outer with an explicit Outer instance

As for reading an Inner from a database this means, we need to retrieve 
the enclosing instance (this$0) first, before we can create the Inner.
If this$0 is stored as a foreign key, the instantiation method would need
to fetch and resolve this key before creating the Inner instance.
That's why I ask about context above: is the current db-row already available
when the instantiation method is invoked?

thanks,
Stephan