XML-Encoder -- Constructors with arguments that are not properties

Question

Hi, I have the problem that I need an argument to initialize the object. That argument isn't stored, to prevent problems with gc (Back-Ref.).
According to
http://java.sun.com/products/jfc/tsc/articles/persistence4/
I have to do something like this:
Encoder e = new XMLEncoder(System.out);
e.setPersistenceDelegate(Integer.class,
                         new PersistenceDelegate() {
    protected Expression instantiate(Object oldInstance,
                                      Encoder out) {
        return new Expression(oldInstance,
                              oldInstance.getClass(),
                              "new",
                              new Object[]{ oldInstance.toString() });
The preceding implementation uses the special method name "new" to refer to the Integer class's string constructor.The problem is that I don't know how to do that, cause I can't receive the needed value from the oldInstance.
To make it a little bit clearer, I have a structure like this.
Class A {
private B b;
A(){
b =  new B(this);
Class B{
B(final A a){
}Providing an empty public constructor would be the easiest but ugly solution, cause you offer an constructor which is not intended to be used anywhere, cause it leaves the object in an not valid state. For hibernate I have to provide such an empty constructor anyways, but at least it can be private.
So is there any other solution out there with limited complexity? You may assume that A will be stored and B is stored by reachability.
Thanks a lot in advance.
Greetings Michael
By the way: the link symbol seems to be broken, whats the plain text markup for that?

Answer 1

ejp wrote:
I don't want to, to avoid problems caused by Back-Ref's. They are hard to solve for the GC. No they're not.The Artcicle below tells different. It is in German and unfortunately not freely available.
Michael K. Klemke, Kersten AuelAbfallwirtschaft
Wissen, Performance-Optimierung,
iX 4/2005, Seite 102>
Also the pages about "Memory Leak Sources" especially "Instances of Inner Classes" are giving an indication, that you should avoid them, at least as long they are having different life cycles.
http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2906.pdf
By the way, if they weren't a problem, why should anyone use WeakReferences?
But a WeakReference or a SoftReference might be a solution for the above problem. Even I'm not quite sure how XMLEncoder threats them.
In the meantime I avoid the problem, by providing a standard constructor without any initialization code.
Introducing a back ref would lead to code like this:
Class A {
private B b;
A(){
b =  new B(this);
Class B{
private A a;
B(final A a){
this.a = a;
}This would be quite hard for the gc to solve, if at least one Instance is still referred form the outside. Even if there isn't an reference form outside, they are only collected if the gc is running longer and can care for such complex structures. Cause the first check if there isn't any active reference is left, won't be true for such constructs. Normally they are only collected just before an OutOfMemoryException.
I had inherited code form a former college (switched from C++ to Java) which was filled up with this kind of stuff and caused huge memory leaks.
So you should only use such an construct, if you are quite sure that they are having the same life-cycle and such a peace of code is an exemption and you can't avoid it.
Greetings Michael