Jim, Here is my first "official" webrev (vs graphics-rasterizer forest) concerning Path2D copy constructors: http://cr.openjdk.java.net/~lbourges/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.gra...@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
