Don't worry about subclassing or instantiation. The following utility classes in JDK can be subclassed or instantiated, yet nobody has misused them in all those years. People are not that stupid.
java.beans.Beans
java.beans.PropertyEditorManager
java.lang.invoke.LambdaMetafactory
java.lang.reflect.Modifier
java.net.URLDecoder ...but not URLEncoder:)
javax.management.DefaultLoaderRepository
javax.management.Query
javax.management.loading.DefaultLoaderRepository
javax.management.relation.RoleStatus
javax.print.ServiceUI
javax.swing.UIManager
javax.swing.plaf.basic.BasicBorders
javax.swing.plaf.basic.BasicGraphicsUtils
javax.swing.plaf.basic.BasicHTML
javax.swing.plaf.basic.BasicIconFactory
javax.swing.plaf.metal.MetalBorders
javax.swing.plaf.metal.MetalIconFactory
javax.swing.text.Utilities
javax.swing.text.html.HTML
However, as a public API, you do want to suppress the default constructor, otherwise there is an undocumented constructor on the javadoc page which is awkward and confusing. For your own in-house APIs, it doesn't matter, nobody cares.
There is no reason to suppress subclassing though. If anyone wants to subclass a utility class, for whatever reason, let him. Of course, private constructor will suppress subclassing as a side effect.
In java8, there are more design possibilities to consider -
An interface with all static methods - this is just as good as a class with all static methods. Neither interface nor class is designed for this purpose, so either one is OK. However, don't expect to inherit these static methods in subtypes of the interface - interface static methods are not inheritable. One plus point for using interface is that we don't need to suppress the default constructor from appearing on javadoc.
An interface with all default methods - accessed through inheritance. This is interesting but problematic in general (the inheritance works only in non-static context). But it might be a better option in some API designs, for example, this html builder API.