[OpenJDK Rasterizer] [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

[Phil Race]

Hi,

you placed the test in the java.awt.geom package.

   25 package java.awt.geom;

and are accessing internals of that package.

In jigsaw/modular mode that won't even compile.

So the test should go in the anonymous package and avoid accessing 
internals.
It should be possible to use just public API  to verify the arrays  of a 
shape
being cloned are trimmed .

Why is it necessary to explicitly add the call to super(); ?

223             super();


-phil.


On 3/6/2015 10:35 AM, Laurent Bourgès wrote:
> Jim,
>
> Here is my first "official" webrev (vs graphics-rasterizer forest) 
> concerning Path2D copy constructors:
> http://cr.openjdk.java.net/~lbourges/webrev_Path2D_0/ 
> <http://cr.openjdk.java.net/%7Elbourges/webrev_Path2D_0/>
>
> this is a simple Path2D patch to trim arrays (numTypes & float/double 
> Coords) in copy constructors (Path2D.Float and Path2D.Double variants) 
> with the requested test: Path2DTrimCopy.
>
> Please tell me if the test is correct as I do not run it with jtreg 
> (annotations ?)
>
>
>     2015-02-25 2:05 GMT+01:00 Jim Graham <james.graham at oracle.com
>     <mailto:james.graham at oracle.com>>:
>
>         Those changes were exactly what I was referring to.  I don't
>         see why we shouldn't make trimmed arrays when copying the
>         shape.  I'm pretty sure that the copy constructors are going
>         to be overwhelmingly used to make a protected copy of an
>         existing shape/path2d which is likely meant mostly for
>         reading. In particular, in the case of the return value from
>         createStrokedShape() I don't think the intention is to create
>         the shape and then scribble on it, the intent is to treat the
>         answer as if it were immutable - at least the 99.9% case - so
>         I think a perfectly sized shape is OK.
>
>         Be sure to add a test case that creates an empty Path2D,
>         clones it, copy constructs it (to both .Double() and .Float()
>         variants) and then tries to add new segments to it - to make
>         sure that the array growth code doesn't get
>         ArrayIndexOutOfBounds exceptions due to making assumptions
>         about the lengths of the arrays (I eyeballed the makeRoom()
>         code and it looks good, but we should test it if we are making
>         arrays that are potentially zero length or very tiny)...
>
>
> Laurent