Skip to main content

Generated code style

4 replies [Last post]
kriegj
Offline
Joined: 2005-01-11
Points: 0

Hi all,

I've just been trying out JAXB 2.0, and I had a question about the style of the generated code.

In my xsd, I had an element definition that looked like this:

In the generated source, this becomes:

-------

protected List dateFormat;

protected List _getDateFormat() {
if (dateFormat == null) {
dateFormat = new ArrayList();
}
return dateFormat;
}

public List getDateFormat() {
return this._getDateFormat();
}
--------

My question is, why not simply:

--------
protected List dateFormat;

public List getDateFormat() {
if (dateFormat == null) {
dateFormat = new ArrayList();
}
return dateFormat;
}
--------

Apart from a small increase in code size and execution overhead, I'm curious to know if we gain anything from the first implementation as opposed to the second?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kohsuke
Offline
Joined: 2003-06-09
Points: 0

It's mostly due to the abstraction inside XJC.

For example, if you tell XJC to use array instead of a list for a collection, you'll see that XJC generates a lot of calls to _getDateFormat().

Similarly, when plugins participate in the code generation process, they generate code that uses _getDateFormat().

When we build the Java code tree, the part of the code that generates the data structure assumes that someone later might need this abstraction.

In the particular case you cited, it's only used by one caller, and the code today isn't smart enough to realize that and do post-optimization of the code tree.

It's an interesting optimization though. I'll see if I can improve this.

kriegj
Offline
Joined: 2005-01-11
Points: 0

Ok, thanks for the information. I think I understand what you are saying (though I'm still a bit fuzzy on the internals of JAXB).

So for my next question: is the abstraction really required? I mean, suppose we had a third method "myMethod()", which called _getDateFormat(). Couldn't we implement it as in the second example that I gave, and just have myMethod() call getDateFormat() instead?

I understand the usefulness of abstractions, but I think that such usefulness mostly applies to code that must be maintained manually. Given that this code should never be edited manually, I don't see maintainability as an important goal. I think we could probably afford to generate code that sacrifices maintainability for optimality, and not lose anything from the system perspective.

Or is perhaps the reason for the abstraction in considering the possibility of user-derived classes? Ie, if a user derives a class and overrides getDateFormat(), we don't want this to affect all the internal processing methods that use _getDateFormat()? Is the possibility of derived classes a consideration in the design goals?

Just my thoughts - as I said, I'm fairly new to JAXB and I don't know what the considerations might be. I hope this is helpful nonetheless.

kohsuke
Offline
Joined: 2003-06-09
Points: 0

I'm not justifying what XJC generates today, so you don't have to try to convince me that we can do better. In fact I believe I already fixed this.

With regard to your particular suggestion, the code may not have the public getDateFormat() method (which is the case when you choose to use array access), so that won't work.

The "abstraction" that I was referring to is the abstraction inside XJC, not the abstraction of the generated code. XJC works as a composition of small code generators, each responsible for generating small portions. Some code generators rely on others and as a whole they collaboratively generate the code. You can think of it as macro expansion if you will.

Most of the time this works nicely and you can't tell that by seeing the generated code. However, sometimes they cause a problem like this.

kriegj
Offline
Joined: 2005-01-11
Points: 0

Thanks for taking the time to explain this to me.

I understand what you mean by "abstraction" now - I apologise for the confusion.