In Javadocs, how should I write plural forms of singular Objects in <code> tags?

It sounds like there are two things you want to do here: use good grammar but also use the literal, verbatim names of your classes so that users of your javadoc may look them up.

One thing you can do when working with plurals is use the phrase "X instances". So using your example, you could put:

/**
 * Returns an <code>IdentityBank</code> of <code>Identity</code> instances with the given sex.
 */

If you need to specify a plural of a value type (which doesn't have instances per se), you can use "X values". For example, you could say "Returns a list of int values". Other acceptable names might be "records", "notes", "entries", "notices", or, as @Marco13 mentioned, "objects".

You should avoid using terms that collide with an existing term of art or class name in your framework, system, or application unless you are using that term as it is already used. For example, do not say "returns a list of Case files" unless you are referring to literal files in a filesystem. Using it to refer to a business rules concept of a file adds potential for confusion. Other terms to consider avoiding for this reason may be "databases", "tables" (unless referring to actual tables in a database or an abstraction or representation of them), "pages", "forms", "sheets", "drivers", "ports", "windows", "lists", "heaps", "stacks", "applications", "exceptions" (unless they are Throwable), "pins", and "buses".

Similarly, any reasonable noun at all is useful if it fits the business rules of the code and is understandable. You could do any of the following:

• Returns a Quadrant of MapNode entries
• Returns a BalancedTree of Employee dossiers

^{When I saw the question title, I wondered: How can this not have been closed after 5 minutes as "Primarily opinion-based"? But I think it is an important question, and I've been agonizing over this far too much, eventually coming to the conclusion that there may be different (objective, i.e. not opinion-based!) arguments for the different options - so here are my two cents:}

Using the class names Customer and Identity as examples, there are different options, which would be rendered as follows:

1. All Customers have Identitys

   Having the "s" in a different font decreases readability. The wrong plural of "Identity" is questionable.

2. All Customers have Identities

   This may look nice at the first glance. But it has a severe drawback: It is a common practice to append an s to class names for classes that contain factory methods! For example, a class that contains factory methods for Customer objects would, by convention, be called Customers. And a JavaDoc like this...:

   You can create Customers with the methods in the Customers class

   is plainly confusing: The link does not lead to the documentation that you might expect from the name that you are clicking on.

3. The solution that I usually apply (and I already used it above, when talking about the drawback of approach 2.) :

   All Customer objects have Identity objects.

   Yes, it may sound a bit unnatural, but I consider it as the best trade-off: The name Identity is readable, it is obvious that it is a class name, and it is unambigous that the name of the class is Identity.

---

A side note: I usually insert the names as {@link ...}. This is convenient due to the auto-completion in Eclipse, and because it can significantly simplify browsing through the resulting JavaDocs. I'd recommend to use {@link ...} at least the first time when a class name appears in a documentation block. For further appearances, <code>...</code> may be used.

Use a "...(s)" style plural label, with a {@link} to the class:

/**
  * Returns an {@link IdentityBank} of {@link Identity Identity(s)} with the given sex.
  */

This will render as:

Returns an IdentityBank of Identity(s) with the given sex.

It's easy and more natural to read, and obvious and clear what you are saying.

You should be using {@link} anyway for classes. It takes care of <code> style formatting, and provides an HTML link to the actual class.

---

You could code the "(s)" after the link, ie {@link Identity}(s), meaning a completely conventional usage of {@link}, but there would be a font change mid-word:

Returns an IdentityBank of Identity(s) with the given sex.

which IMHO reduces clarity and could cause confusion.