[Pride-users] Re: Issues/Problems with code generated by Pride Eclipse plug-in

[<jle...@ma...>]

Joseph
Thanks a lot for the information. In fact I never used this bugfinder
plugin before and I looks very interesting to me what it suggests. Let me
try to comment some of the suggestions:

> This Eclipse Plug-in(http://findbugs.sourceforge.net/) found some
> Issues/Problems with the generated Java code.
> You might/might not include these changes to your Pride Eclipse
> plug-in
>
> ICD0_Before is the code generated by your plug-in. ICD0_After has the
> FindBugs suggested changes. I also included an additional constructor
> for the Class.
>
> sql2.txt is the DDL used to create the table within HSQLDB.
>
> Change 1:  Line 10 Include the final clause
This is ok for most cases of course (lets say 99.99999%), so I guess we
will adopt this to the generator. On the other hand it should be kept in
mind that it is one of PriDE's advantages that records descriptors can be
dynamically constructed and modified at runtime. We use this sometimes to
construct dynamic table joins depending on query criteria. However I admit
that we usually don't modify the static version of a descriptor ;-)

> Change 2: Line 26 use the method .clone() to return the String Array
Ok, I see the point of potential misuse. But isn't that a bit overcareful ;-)

> Change 3: Added a serialVersionUID variable after the RecordDescriptor
> getDescriptor() method. The Serialable interface likes to have it.
Yes, ok.

> Change 4: Replace keyword Long with long (3 occurences)
I don't agree at this point. The corresponding column in the table was
declared as BIGINT, allowing null values. So the data type to be used in
the Java entity must also be one which supports null values. I guess the
generator is right here. What do you think?

> Change 5: Added a new Constructor that adds a  record and uses a
> small-case version of the field autofields
I'm not so shure here. We explicitly left out a constructor like this in
the entity generator because it usually produces a very ugly method
signature with lots of parameters for each field which is not an auto
field (i.e. the majority). If we would do so, we'd probably get complains
from other people saying that their code metrics plugins whould not except
the generated code ;-)

Well. We will see how we can incorporate the results of your analysis.

Regards,
Jan