Actually (I believe) all the standard JTextComponents preserve new
lines. It's just that the return and enter keys don't always enter a
line break...

Take your favourite Java application. Copy some text including a new
line from a text area. Paste into a text field. Unless there is some
DocumentFilter shenanigans going on, the new line should be pasted. You
can then use the arrow keys to move up and down through the slit view.
Same goes for tabs. Can be useful for search and replace.

It seems a bizarre approach to usability to me. Field traversal uses a
peculiar key (tab) instead of a more natural key (return). Then when it
comes to text areas the traversal key is used to enter a character code
that presumably is almost never wanted.

Return would be an even better choice if it wasn't moved out miles to
right. Obviously it's more important to have symbols like ~ and # in
closer. And ; as a home key (other than for curly brace language
programmers).

Going back to my call centre days I had an interesting usability
problem. Following the existing DOS environment, I had return move to
the next field. That didn't make sense for text areas, so tab needed to
be used as a fallback.

To complicate matter I (briefly) had a bug where a field with a single
new line would prevent the form from being submitted. Agents returning
through fields would hit a text area and when return didn't work would
switch to the tab key. The form wouldn't submit. They would swear blind
that they always used tab, but there would be a new line in the first
text area.

Tom Hawtin