please refer to bugID 4558900. I added additional info in this RFE to go along with info that is contained there. Also I am filing this as a new RFE as there is an escalation attached to the other bug. This issue was deemed to be an RFE rather than a bug.
Attached also is a piece of code to demonstrate how AffineTransform is
altering the shape after transformation. The coordinates used are test_corrd.txt, and the results from the run are in results.txt. As you would
notice, the transformed shape is returning a self-intersecting polygon
where as the original shape is not a self-intersecting polygon
It was suggested customer create an extended class of the Area, for example,
"AreaWithOffset", in which you store a Area together with an offset
and then override the Area method, and only when the coordinates are
needed you can add the offset to them.
This approach seems to work well for this application. However, I still feel
this just a work-around to overcome a java 2D limitation. This approach
breaks whenever coordinates deviate from offsets by more than what the
floating point range can allow for. This translates to 8.388607 degrees
( (2^23) -1, allowing for 6 decimal places) for our data to ascertain
accuracy. Many a time, some of the polygons that we deal with cover more
range than this. Such situations will give rise to inaccuracies and invalid
shapes as a result of floating point truncation. A double precision
capability for this kind of scenario will solve our problems and make java
2D technology stand out against competing technologies. I am not sure what
are all the issues involved with this, but I sincerely hope Sun ought to
provide this capability in some fashion or other.