static or not should generally be a design issue rather than a performance
issue. This is true especially for larger applications. If the method
belongs to a class rather than an object, then make it static.
IMO, it is perfectly ok to make helper methods static.

andreas

In general, if the method is related to the functionality focus
of the class, but doesn't make use of any of an instance
object's member variables, then make the method static; to
do elsewise misleads the next maintainer.

Also, it can be helpful to have a class never meant to be
instanced (instead of letting its parameterless constructor
come into existence by default, make it  "private" to prevent
that ever happening, like so:

 public class Foo
 {
   private Foo() { super(); }
 }

and no client can accidentally "new" it and not have the
compiler complain), which contains helper methods
that are universally useful. Two I'm finding handy now
are one to create an ImageIcon from a URI's PNG file's
data, and one to both add a Component to a JPanel,
and also add that Component to the JPanel's layout
manager, to allow me to create the Component without
giving it a name, in the client routine:

package edu.asu.dt.evwf;

import java.awt.Component;

import javax.swing.JPanel;
import javax.swing.ImageIcon;

import java.net.URL;

public class EvwfUtilities
{

 /**
  * Prevent accidental instancing.
  */
 private EvwfUtilities() {super();}

 /**
  * Add a Component to both a JPanel and its layout
  * manager's responsibility.
  */
 public static void addComponentToJPanel
 (
   JPanel targetJPanel,
   String componentName,
   Component componentToAdd
 )
 {
   targetJPanel.add( componentToAdd);
   targetJPanel.getLayout().addLayoutComponent
   (
     componentName,
     componentToAdd
   );
 }

 /**
 *  Returns an ImageIcon, or null if the path was
 *  invalid.
 */
 public static ImageIcon getImageIconByLocation
 (
   String imageLocation
 )
 {
   java.net.URL imgURL = EvwfUtilities.class.getResource
   (
     imageLocation
   );
   if (imgURL != null)
   {
     return new ImageIcon(imgURL);
   }
   else
   {
     System.err.println
     ( "ERROR in " +
       "EvwfUtilities.getImageIconByLocation(...)\n" +
       "Couldn't find file: " +
       imageLocation
     );
     return null;
   }
 }
}

The former allows creating of the Component right in the method call,
anonymously, like so, where the output of the createVerticalGlue()
method would otherwise need to be assigned to a local variable to
use it two places.

   EvwfUtilities.addComponentToJPanel
   (
     s_soliton,

"EvwfWaterLayersTabDeltaSurfacesControlsJCheckBoxStackVerticalGlue",
     Box.createVerticalGlue()
   );

This tends to make for clean, pretty, terse code.

FWIW

xanthian.

That would be more quickly implemented with   str.charAt( 0 );

String.valueOf( str.charAt( 0 ) );

or even more efficiently

str.substring( 0, 1 );

It is not as good as inline code (unless the optmizer is able to
actually inline it), but it is faster than a public call. The big deal
is not on the method beeing static or not, but on beeing private.

A private static call generates a "invokestatic" opcode.. (code 0xB8)
A private call generates a "invokespecial" opcode.. (code 0xB7)
A public call generates a "invokevirtual" opcode.. (code 0xB6)

Both "invokestatic" and "invokespecial" are faster than
"invokevirtual", but I couldn't find any information about wich one is
faster (please note that this is obviously implementation-depedent).

Interface calls are the slowest ones... and they generate a
"invokeinterface" opcode (0xB9).

Hope this helps,
Zechin