ADDITIONAL SYSTEM INFORMATION :
Windows 10
Worked on Java 11.0.5 (with other heavy UI customization)
Fails on Java 11.0.7 (11.0.6 untested)

A DESCRIPTION OF THE PROBLEM :
The calculation for the width of a text area is:
width = columns * columnWidth + insets
The calculation for the available space of a text area to draw in is:
drawableWidth = width - insets - caretMargin
This disparity causes the JTextArea to calculate it's size such that the drawableWidth is one pixel narrower than it needs to be (assuming the caretMargin is at it's default 1 pixel width)
When used with a monospaced font, this leaves the text area one pixel too narrow to wrap at the desired number of columns, causing wrapping to occur early.

Please compare the size calculation of JTextArea.getPreferredSize() and BasicTextUI.getVisibleEditorRect() (used by paintSafely()). (JTextArea.getPreferredSize() overrides the size returned by BasicTextUI.getPreferredSize())
Besides causing unexpected wrapping, I believe this can cause the component to miscalculate it's height, when the height calculation doesn't encounter wraps that paintSafely() does.

Note: May have a HiDPI component (See Workaround notes).


REGRESSION : Last worked in version 11

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Apologies, I'm unable to provide reproduce steps - The SSCCE I made for this demonstrated a different bug (Review ID 9068907 for that), which is likely masked by heavy customization of TextArea sizing in our full Application.
Without regard to any UI customization, the function calculating the component size and the function deciding how much room is available for use are using different equations.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
When configured to wrap at 35 columns, text will wrap at 35 columns.
ACTUAL -
When configured to wrap at 35 columns, text will wrap at 34 columns.

CUSTOMER SUBMITTED WORKAROUND :
Overriding BasicTextUI to make the caretMargin public, and JTextArea.getPreferredSize() to use the caretMargin appears to fix this issue outside of a HiDPI context. With one HiDPI monitor and one standard monitor however, the HiDPI monitor is still wrapping early.
Setting the caretMargin to 0 would plausibly mask this, but I assume that would defeat the purpose of caretMargin and likely break whatever the margin is fixing.

FREQUENCY : always