Some strangeness in generated factory coding

["Millies, Sebastian" <Se...@ids-scheer.com>]

sorry for opening yet another thread on some subject related to
XSD2JavaGenerator, but I'm finding all this out piecemeal while
experimenting.

The generated coding for the factory class is somewhat strange.
Consider the following extracts:

package generated;

public static final GeneratedFactory INSTANCE = generated.GeneratedFactory.init();

private static GeneratedFactory instance = null; 

public static GeneratedFactory init()
	{
		if (instance != null ) return instance;
		instance = new GeneratedFactory();

		// Create package meta-data objects
		instance.createMetaData();

		// Initialize created meta-data
		instance.initializeMetaData();
		
		// Mark meta-data to indicate it can't be changed
		//theGeneratedFactory.freeze(); //FB do we need to freeze / should we freeze ????

		return instance;
	}

public GeneratedFactory()
	{
		super(NAMESPACE_URI, NAMESPACE_PREFIX, "generated");
	}


Clearly, the factory is supposed to be a singleton but still has a public (instead
of protected) constructor. It is also not clear to me why there are two static references 
to that single instance. And why is the init() method public when it is supposed to be called 
exactly once during static initialization? Surely, these are just minor flukes, but together 
with the commented stuff about freeze(), it makes me wonder if the generator tool is still in 
a state of flux.

Is the generated coding reliable? Does anyone have practical experience with this?

-- Sebastian

Re: Some strangeness in generated factory coding

[Frank Budinsky <fr...@ca.ibm.com>]

I think your right that some of these things are just minor flukes (public
vs protected methods). I don't know why there are two static instance
fields (maybe some kind of backward compatibility issue???).

I do know about the commented out freeze() call. It's very dangerous to
allow types to change after they've been defined, especially once
instances, generated classes, or subtypes exist. For that reason, we should
really freeze the metadata once defined. I'm not sure if there was a
particular use case, but we decided not to call freeze() and basically say
that if you want to modify existing types, do it at your own risk.

Frank.

"Millies, Sebastian" <Se...@ids-scheer.com> wrote on 10/05/2010
01:29:56 PM:

> [image removed]
>
> Some strangeness in generated factory coding
>
> Millies, Sebastian
>
> to:
>
> user
>
> 10/05/2010 01:34 PM
>
> Please respond to user
>
> sorry for opening yet another thread on some subject related to
> XSD2JavaGenerator, but I'm finding all this out piecemeal while
> experimenting.
>
> The generated coding for the factory class is somewhat strange.
> Consider the following extracts:
>
> package generated;
>
> public static final GeneratedFactory INSTANCE =
> generated.GeneratedFactory.init();
>
> private static GeneratedFactory instance = null;
>
> public static GeneratedFactory init()
>    {
>       if (instance != null ) return instance;
>       instance = new GeneratedFactory();
>
>       // Create package meta-data objects
>       instance.createMetaData();
>
>       // Initialize created meta-data
>       instance.initializeMetaData();
>
>       // Mark meta-data to indicate it can't be changed
>       //theGeneratedFactory.freeze(); //FB do we need to freeze /
> should we freeze ????
>
>       return instance;
>    }
>
> public GeneratedFactory()
>    {
>       super(NAMESPACE_URI, NAMESPACE_PREFIX, "generated");
>    }
>
>
> Clearly, the factory is supposed to be a singleton but still has a
> public (instead
> of protected) constructor. It is also not clear to me why there are
> two static references
> to that single instance. And why is the init() method public when it
> is supposed to be called
> exactly once during static initialization? Surely, these are just
> minor flukes, but together
> with the commented stuff about freeze(), it makes me wonder if the
> generator tool is still in
> a state of flux.
>
> Is the generated coding reliable? Does anyone have practical
> experience with this?
>
> -- Sebastian