First, there are basic code standards documented for Java here: https://www.oracle.com/technetwork/java/codeconventions-150003.pdf. Like most coding guidelines, these are quite reasonable and differ only in minor details from other guidelines.

The web page http://geosoft.no/development/javastyle.html also has some very nice tips. Note that we won't prefix instance variable names with underscores--instead we use Eclipse syntax coloring to make ivars easily visible.

We use the prefix fetch in method names in entity implementation classes, in order to perform object navigations that aren't already defined by Hibernate mappings.

Here are some additional notes:

Not surprisingly, a lot can be learned from good Smalltalk style. The books "Smalltalk With Style" (Klimas, Skublics, Thomas) and "Smalltalk Best Practices Patterns" (Kent Beck) provide a lot of good ideas for code organization and naming that are applicable to Java as well as Smalltalk.

All code should be:

Written with tabs equal to 4 spaces, not "hard" tabs. Each level of indentation should be one "tab".

Generally free of hard-coded "magic" strings or numbers (e.g. max number of items in some list). If you need such a string or number value, you should use (or create) a constant or property.

Classes should use specific, not package-based imports, where practical. I.e. import com.foo.UsefulClass, not com.foo.*.

Variables should generally be private. Only create accessor (e.g. get/set) methods when absolutely needed ("Dont reveal your private parts").

Prefix "getter" methods with "get", e.g. "getFoo()", setters with "set", e.g. "setBar(aBar)". Don't use "Flag" or "Switch", or abbreviations thereof, e.g. "getAllowedSw()" should be "getIsAllowed(), and "setAllowedSw(aBoolean)" should be "setIsAllowed(aBool)".

Use camel-case instance and parameter variable names, without underscore prefixes or suffixes (do use uppercase for constants, as suggested in the guidelines reference above). Instance variables start with lower-case letters.

Methods should generally be public or private (again, to allow future subclassing). Use of interfaces is encouraged to declare useful sets of public methods.

Don't abbreviate except for standard industry abbreviations (e.g. HTML, HTTP). Use long, meaningful class, method, and variable names.

Methods should be short and clear. Instead of placing comments before a section of code in a method, rather create another method that describes what is being done by the method name.

When using Java API collections, reference them through generic interfaces, not specific implementation classes, e.g.

This lets you change your mind about implementation (e.g. ArrayList to LinkedList) without breaking any code.