I am confused. Isn't this deleted doc, in fact the doc that you want on both methods now.
Although 'high precision' if it means float, not int return coords, might not be part of the other method spec.
Also there is a JCK test that fails with this change. Looks like it expects the looser bounds for getBounds().
So we'd definitely need a CSR.
And there'd be a practical compatibility issue as well for someone who relied on those looser bounds.
That's what worries me most.

Also (minor) from JBS I see this comment -
"It looks like the math in getBounds2D could be greatly simplified - at which
point it would make sense to have getBounds also return a tighter bounding
box."

which suggests to me that performance was part of the original reason for the looser bounds of getBounds()

(Everything that follows is very subjective; feel free to disagree.)

Isn't this deleted doc, in fact the doc that you want on both methods now..

The previous javadoc existed because it was explaining a very unusual distinction between Arc2D.getBounds() and Arc2D.getBounds2D() that does not exist in any other Shape. That distinction/difference is the crux of JDK-4197755. It was worth explaining precisely because it was unintuitive/weird.

IMO we don't need any additional javadoc around these methods now (with this PR), because now they are behaving like most developers assume they would. Most other Shape implementations already follow the same pattern, and they don't offer any accompanying method documentation. If I was redesigning the Shape interface today from scratch, I would probably go so far as to include:

    default public Rectangle getBounds() {
        return getBounds2D().getBounds();
    }

    default public Rectangle2D getBounds2D() {
        return Path2D.getBounds2D(getPathIterator(null));
    }

I'd argue this is the "normal" behavior that most developers expect. We should only override those methods if a specific alternative is faster and approximately as accurate.

(This case study is also weird because Arc2D extends RectangularShape. The shape of a slice of pie does not have a "is-a" relationship with the shape of its pie tin. And yet without this PR: Arc2D inherits getBounds() from RectangularShape.)

And there'd be a practical compatibility issue as well for someone who relied on those looser bounds.

I agree; that's always a risk. We took the same risk when we resolved JDK-8176501 ; is there room to argue this PR is riskier than JDK-8176501 's resolution?

If this PR is too controversial: I'm fine with closing it. I see you reopened JDK-4197755, which is the thing I feel most strongly about here. (That is: keeping the ticket database up-to-date and fixing 4197755's status is enough for me.)

I just thought if I was going to call out reopening 4197755: it'd be trivial to also submit this PR for consideration.

which suggests to me that performance was part of the original reason for the looser bounds of getBounds()

Hmm. Maybe. I'd just add: RectangularShape provides a getBounds() implementation, but it does NOT provide a getBounds2D() implementation. So I'd suggest getBounds() is looser simply because of legacy design decisions. I do think it's peculiar the Arc2D authors anticipated this complaint and didn't act on it, but I'll probably never know exactly how those decisions were made.