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.

customer feels;
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.