Naming convention for utility classes in Java

Like many such conventions, what's important is not so much what convention you use, as that you use it consistently. Like, if you have three utility classes and you call them CustomerUtil, ProductUtils, and StoreUtility, other people trying to use your classes are going to constantly get confused and type CustomerUtils by mistake, have to look it up, curse you a few times, etc. (I heard a lecture on consistency once where the speaker put up a slide showing an outline of his speech with three main points, labeled "1", "2nd", and "C".)

Never ever ever make two names that differ only in some subtlety of spelling, like having a CustomerUtil and a CustomerUtility. If there was a good reason to make two classes, then there must be something different about them, and the name should at least give us a clue what that difference is. If one contains utility functions related to name and address and the other contains utility functions related to orders, then call them CustomerNameAndAddressUtil and CustomerOrderUtil or some such. I regularly go nuts when I see meaningless subtle differences in names. Like just yesterday I was working on a program that had three fields for freight costs, named "freight", "freightcost", and "frght". I had to study the code to figure out what the difference between them was.

There is no standard rule/convention in Java world for this. However, I prefer adding "s" at the end of Class name as @colinD has mentioned.

That seems pretty standard to what Master java API Designer Josh Bloch does ( java collection as well as google collection)

As long as Helper and Util goes, I will call something a Helper when it has APIs that help to achieve a specific functionality of a package ( considering a package as to implement a module); mean while a Util may be called in any context.

For example in an application related to bank accounts, all number specific utility static APIs would go to org.mycompany.util.Numbers

All "Account" specific business rule helping APIs would go to

org.mycompany.account.AccountHelper

After all, it is a matter of providing better documentation and cleaner code.

I like the convention of just adding "s" to the type name when the type is an interface or a class you don't control. Examples of that in the JDK include Collections and Executors. It's also the convention used in Google Collections.

When you're dealing with a class you have control over, I'd say utility methods belong on the class itself generally.