At 02:34 a.m. 17/07/02 -0700, you wrote:

>Browsing the CVS sources I noticed the use of patterns
>which cause unnecessary object creations.
>
>2. Another place where object creations could be
>avoided are ArrayList creations.
>
>Not optimal code:
>
>ArrayList params = new ArrayList();
>if (<condition1>)
> params.add(<param1>);
>if (<condition2>)
> params.add(<param2>);
>...
>foo(..., params, ...);
>...
>
>Optimized code:
>
>ArrayList params = null;
>if (<condition1>) {
> if (params == null)
> params = new ArrayList();
> params.add(<param1>);
>}
>if (<condition2>) {
> if (params == null)
> params = new ArrayList();
> params.add(<param2>);
>}
>...
>foo(..., params, ...);
>...
>
>Of course all methods have to accept null parameters
>to avoid the need to create empty (dummy) objects.

Assumming the variable is a field...
if you rather have a lot of if's instead of creating the object when you
don't need it (assumming there's a high percentage of the times when you
don't need it) you should use getter methods for instance variables
(fields) and do lazy initialization. This way you don't repeat code and its
clearer.

public List getParams(){
if(params==null)
params=new ArrayList();
return params;
}

The continuous calls to the getter method are inlined by the hotspot VM
(if necesary) so the actual running code is the same.

>3. Checking for empty strings:
>
>Not ideal code:
>
>if (!str.equals("")) {
> ...
>}
>
>Better:
>
>if (str != null && str.length() > 0) {
> ...
>}

I disagree. I think there should be a message to check if a string is the
empty string in the class String, but since there's not such method, you
have to do as it's done in the first version.
This is not a OOP programming style forum, but code is ment to be read by
others beside the original author, and that kind of refactorings provide a
marginal efficency improvements (if any) at the cost of increased
difficulty in understanding the code.

Of course some things are necesary like using StringBuffer when you do a
lot of String concatenations, but those things are more related with using
objects as they were ment to be used. (Some people think getting an object
from HashMap with 3 elements is better that using a List and interating it.)

>Java is a high level language and a lot of things are
>done behind the scenes. But considering these and
>others while coding can make even a Java app
>efficient.

Even old time C hackers tell that efficiency is not a matter of saving
cycles by rewritting line by line. You can inprove efficiency changing an
algorithm, a design, rethinking everything from the requirement analisys or
maybe by doing the kind of refactoring you suggest in the 10% of the code
that runs 90% of the cycles. Leave the rest as readable as possible because
you are not making any improvement worth the effort.

Unless you are in realtime programming where you have strict requirements,
allways favour readability and clarity over efficency.