FULL PRODUCT VERSION :
java version "1.4.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
SunOS eclipse 5.7 Generic_106541-29 sun4u sparc

A DESCRIPTION OF THE PROBLEM :
pathiterator returned by the GeneralPath object and Area object are not the same. They generate two different set of coordinates for the same geometry . This bug was reported by me about 3 years ago under a java version 1.2.1. It remains unresolved todate even under the latest versions both on solaris and NT. Many a time the extraneous data returned by the Area object translates to an empty shape.





STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the source code given below to reproduce.






EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The results from gp.getPathIterator and a.getPathIterator should be the same.
But they are not.

Results returned:

****POINTS FROM GENERALPATH OBJECT****
MOVE TO:4.0705664E7 1.04785696E8
LINE TO:4.070588E7 1.04785688E8
LINE TO:4.0705844E7 1.04785328E8
LINE TO:4.07058E7 1.04784336E8
LINE TO:4.07069E7 1.04784344E8
LINE TO:4.0706896E7 1.04785328E8
LINE TO:4.07069E7 1.04785408E8
LINE TO:4.070688E7 1.0478548E8
LINE TO:4.0706812E7 1.04785576E8
LINE TO:4.0706776E7 1.04785624E8
LINE TO:4.070672E7 1.0478568E8
LINE TO:4.0705848E7 1.04785688E8
LINE TO:4.0705664E7 1.04785696E8
CLOSE
****POINTS FROM AREA OBJECT****
MOVE TO:4.07058E7 1.04784336E8
LINE TO:4.0705844E7 1.04785328E8
LINE TO:4.070587997066911E7 1.0478568770669112E8
LINE TO:4.0705879970668346E7 1.0478568770669112E8
LINE TO:4.070672E7 1.0478568E8
LINE TO:4.0706776E7 1.04785624E8
LINE TO:4.0706812E7 1.04785576E8
LINE TO:4.070688E7 1.0478548E8
LINE TO:4.07069E7 1.04785408E8
LINE TO:4.0706896E7 1.04785328E8
LINE TO:4.07069E7 1.04784344E8
LINE TO:4.07058E7 1.04784336E8
CLOSE
MOVE TO:4.0705879970668346E7 1.0478568770669112E8
LINE TO:4.0705848E7 1.04785688E8
LINE TO:4.0705664E7 1.04785696E8
LINE TO:4.070588E7 1.04785688E8
LINE TO:4.070587997066911E7 1.0478568770669112E8
CLOSE

 The second path (5 points) returned from the Area object is inaccuarate and extraneous.
The review ID used for an earlier bug report on this was
(Review ID: 136975)

ACTUAL -
See above.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.*;
import java.util.*;
import java.awt.geom.GeneralPath;
import java.awt.geom.*;
import java.awt.*;

import java.lang.Math;

public class tempShape {


 public static void getPoints(PathIterator pi){
  double [] coords = new double[6];
  int curseg;
  Point2D.Double p;
  while (!pi.isDone()){
    curseg = pi.currentSegment(coords);
    switch(curseg){
      case PathIterator.SEG_MOVETO:{
         p = new Point2D.Double(coords[0],coords[1]);
System.out.println("MOVE TO:"+p.x+" "+p.y);
          break;
      }
      case PathIterator.SEG_LINETO:{
         p = new Point2D.Double(coords[0],coords[1]);
System.out.println("LINE TO:"+p.x+" "+p.y);
          break;
      }
      case PathIterator.SEG_CLOSE:{
System.out.println("CLOSE");
           break;
      }
      default:{
        System.out.println("Undefined Seg type");
        break;
      }
    }
    pi.next();
  }
 }
 public static void main(String args[]){
    GeneralPath gp = new GeneralPath(GeneralPath.WIND_EVEN_ODD);
    gp.moveTo(40705662f, 104785693f);
    gp.lineTo(40705878f, 104785687f);
    gp.lineTo(40705845f, 104785332f);
    gp.lineTo(40705799f,104784340f);
    gp.lineTo(40706901f, 104784342f);
    gp.lineTo(40706896f, 104785325f);
    gp.lineTo(40706900f, 104785409f);
    gp.lineTo(40706878f, 104785483f);
    gp.lineTo(40706813f, 104785578f);
    gp.lineTo(40706776f, 104785621f);
    gp.lineTo(40706720f, 104785684f);
    gp.lineTo(40705846f, 104785691f);
    gp.lineTo(40705662f, 104785693f);
    gp.closePath();
    Area a = new Area(gp);
    System.out.println("****POINTS FROM GENERALPATH OBJECT****");
    getPoints(gp.getPathIterator(null));
    System.out.println("****POINTS FROM AREA OBJECT****");
    getPoints(a.getPathIterator(null));
 }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
No workaround possible. Reducing the magnitude of coordinates did not help, that is, using smaller numbers for coordinates by applying x and y offsets thus eliminating float round-off errors. The code given is a scaled-down version of a major implementation. Ironically, the bug occurs only for certain type of polygons. The nature of those polygons is pretty random to identify and it makes it difficult to plan any workaround.