On Sun, 10 Aug 2025 04:35:43 GMT, Jeremy Wood <jw...@openjdk.org> wrote:
> 4197755 is marked as a duplicate of > [JDK-8176501](https://bugs.openjdk.org/browse/JDK-8176501) , but I think that > is a mistake. The complaint in that ticket still reproduces, and it is > resolved in this PR. > > The complaint is: Arc2D.getBounds() is too large. If an Arc2D represents a > small slice of an ellipse, then Arc2D.getBounds() always returns the size of > the total ellipse. Arc2D.getBounds2D(), by contrast, has been > "high-precision" for decades. > > This PR makes Arc2D.getBounds() resemble the same implementation already used > in Area, CubicCurve2D, Line2D, Path2D, and QuadCurve2D: > > public Rectangle getBounds() { > return getBounds2D().getBounds(); > } > > > This modifies (simplifies) the javadoc for Arc2D.getBounds2D(). If we > generally like this PR I assume we'll need a CSR to approve the javadoc > change. src/java.desktop/share/classes/java/awt/geom/Arc2D.java line 1067: > 1065: * > 1066: * @return the {@code Rectangle2D} that represents the arc's > 1067: * framing rectangle. 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() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26715#discussion_r2289345340
