#33 Code Generator Configuration

[Lars Braubach]

Hello Stefan,

in my application it often occured that I wanted to
access multiple data from the generated classes.
Currently only the iterXYZ methods are provided which
return an iterator. At least for my application this is
somewhat uncomfortable, because I need an array of
the values.

Is there a chance to make the "Code Generation
Cartridge" so configurable that it will allow to customize
the return type for a multiple element (Array, List,
Iterator, ...)?

The second thing is rather nitpicking ;-) It would also be
very nice to allow the specification not only of the
whole element name for generation (via jb:name) but
also the exact setter and getter names. This would e.g.
allow to name the boolean getters 'isXYZ'.

Cheers
Lars

[Stefan Wachter]

Logged In: YES
user_id=588968

HI Lars,

the reason why there is no array valued getter is that the
sequence of elements of one kind may be mixed with elements
of other kinds in content models. Therefore the best thing I
could offer is an array valued accessor which returns an
immutable array. Would this be fine with you?

About method names: I also had sometimes the wish to have
other method names to be generated (e.g. getElementsIterator
instead of iterElements). I am thinking of a solution where
you can specify the method prefix and suffix for each kind
of method (i.e. creatorPrefix, creatorSuffix,
iteratorPrefix, iteratorSuffix, ...). In addition there
could be an additional binding attribute handling the
boolean idiosyncraty (getterPrefixForBooleans).

Volunteers are welcome.

[Lars Braubach]

Logged In: YES
user_id=363207

Hi Stefan,

the reason for the question about the iter methods is that I
currently needed to add a lot of getter methods which
convert the iterator to an array (iterator->list->array :-(
which I suppose causes not very good performace (first
measurement indicate that we have to face a performance
loss of our framework by round about 30% compared with our
non-jbind version, still trying to figure out what the concrete
reasons might be).
We use the arrays mainly because of the type-safety also
hoping that the generics of 1.5 might offer a convenient
solution in the future. I think it would help if it would be
possibile to have getters which return immutable arrays that
are stored in the elements and are only recreated on demand
when elements are added or removed.

Generally I would like to help improving jbind but currently I
cannot make concrete offers because of my full agenda.

Best,
Lars

[Stefan Wachter]

Logged In: YES
user_id=588968

Hi Lars,

I fear that introducing arrays that are cached is not easy.
The best thing I can offer is to generate methods that
return arrays. These methods would use the iterators and
System.arraycopy. I think these methods would be more
performant than your current solution because the "list
step" is skipped.

Yet, if type safety is your major concern then maybe moving
to java 1.5 would be the better solution. If you want then I
can teach JBind to return "generic" iterators.

--Stefan

[Alexander Pokahr]

Logged In: YES
user_id=346801

Hi Stefan,

working on the same project as Lars, I just found one cause
for the performance loss in our system:
The generated accessor methods always lead to a call to the
AttributeImpls.getAttributeImpl() method, which creates a
lookup key composed of namespace and name.
Although looking pretty simple, the creation of those keys
seems to be rather slow (because several StringBuffer and
String objects are implicitly created).
Because those methods are called very often, a performance
improvement here would have a huge effect. Maybe there are
better ways to store and lookup attributes, or even use a
caching mechanism.

Regards,
Alex

[Stefan Wachter]

Logged In: YES
user_id=588968

Hi Alex,

thanks for the performance investigation.

I checked in a new version of JBind that uses QName objects
in order to access attributes. The QName objects are
initialized statically when the generated classes are
loaded. In addition, QName objects now cache their hashCode.
These changes should improve performance.

The changes in the CVS will be visible only after 24 hours.

--Stefan

I hope these changes will improve performance.

[Lars Braubach]

Logged In: YES
user_id=363207

Hi Stefan,

coming back to the iter methods. Our concern is twofold:
type safety and performance, but if I had to choose between
those two I would prefer the performance ;-). The problem
with the iterator approach is in my opinion that they cannot
be converted directly to some other format and provide no
direct access to their size. Would it be possible to return a
list or collection? I think this would help in working with the
multiple elements. (Type safe iterators are a good idea but
we don't want to move to 1.5 so early mainly because of
compatibility issues)

Regarding the performance issue: Thank you for the quick
improvements. Will will test it and actually make
some "benchmarks".
When discussing about this issue we came up with the idea
that some kind of write-through cache would be very nice. If
the generator could generate a variable for each attribute
the getter could return directly this value and the setter
could set both the cached and the real value.
What do you think about this?

Best,
Lars

[Alexander Pokahr]

Logged In: YES
user_id=346801

Hi Stefan,

thanks for your quick response.
I just tried out the QName patch, and it accelerates our
benchmark by 3-4%. :-)

Still I wonder if we could get back some more of the 30% we
lost by switching to jBind.
I think that attribute lookup cannot be further improved as
the remaining bottleneck seems to be HashMap.get() ;-), but
maybe the nested method calls also play some role.

So, to further improve performance of attribute access the
only option seems to be some kind of cache, as proposed by
Lars.

Regards,
Alex