The same problem occurs with <pre> tags. The lines within <pre> aren't broken, but new breaks are added after <pre> and before </pre>.

This is more serious because it changes how the formatted HTML API documentation looks. See attached test cases.
linebreakpre.zip

Thanks for the report.

Inserting a newline after <pre> and before </pre>, despite how it changes the output, was intentional. We should probably document somewhere that we do change the output in this case. (I wonder if there are others?)

Doing the same for <code> was probably an oversight. I'm not sure offhand how hard this would be to fix. Hmm.

the space is not closed up when google-java-format runs again, even if there is an opportunity to do so

This does seem to work for {@code ... }, handling <code> differently seems like an oversight.

Part of the rationale for breaking before and after <pre> is that it's a block element, and breaking makes it consistent with what you get in the rendered html.

It doesn't seem to be consistent now. In the ClassFileVersion test case I provided, google-java-format introduced a break before one occurrence of </pre> but not before the other.

This made the formatting of the two <pre> blocks in the code inconsistent with one another: one was followed by two blank lines in the HTML output, whereas the other was followed by only normal paragraph spacing (one blank line).

My personal preference is not to have the extra trailing newline in the <pre> block, because then in the rendered HTML some paragraphs are separated by more space than others. This looks bad and confuses readers who wonder the reason for the extra space and apparent emphasis. I would rather have consistent spacing in the output, even if some line's length is 6 characters longer to accommodate </pre>. Per Chris's comment, maybe that's not the view of the gjf maintainers, though.

Ah, I hadn't thought about the additional inconsistency. It looks like we are willing to break between <pre> and the following character (and between a character and the following </pre>), so whether we do so depends on the length of the resulting line.

We have some logic to pin <p> to the following character, and we could reuse it for <pre>. I think it might be harder to pin </pre> to the preceding character. I think I had some ideas about a similar situation, but I'm blanking on what it was... :\

But I guess it's also possible that we'd just fully commit to putting <pre> and </pre> on their own lines. I think we're happy with that for <pre>{@code, but I think our current handling of <pre> may be more of an accident.

Thanks for raising all this. It does sound like we have some different preferences, but I think there's room for changes that will make things incrementally better (or at least more consistent).

Another problem with breaking after <code> is where the wrapped text starts with an at-sign (@). This can actually breaks a build because the text is now treated as an annotation, which doesn't exist.