Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
|
Relates :
|
|
Relates :
|
Name: clC74495 Date: 09/10/98 The GeneralPath and Area classes offer one of the most powerful GIS platforms available anywhere today, except for one problem: float is not sufficiently precise to use for global coordinate models (eg a float Longitude has a precision of about 3 meters, far too coarse for modern GIS). GeneralPath needs a double version, just like the float and double versions of Line2D, Rectangle2D etc. (Review ID: 37513) ====================================================================== Suggested implementation by java.net member leouser (Refer to attached file "4172661-Fix-Received.eml" for the entire text) FIX DETAILS BUG ID: 4172661 GeneralPath needs double version FILES AFFECTED: java.awt.geom package, java.awt.geom.GeneralPath class JDK VERSION jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin Discusion(embeded in test case as well): /** * BUG ID: 4172661 GeneralPath needs double version * This has proven to be a vexing problem to solve. I first looked * at it from a storage standpoint: maybe I can just make a Storage * class internal to the GeneralPath and have the GP morph its storage * dependant upon how the user wanted to use it. This road proved bad. * There is not a good way to perform operations on a float array when * you are targeting a double array anc vice versa. We could have set * up a flag and have the thing process differently but the code would * have been grotesque and repetitive. * * I thought about using generics for a solution but there is not a good way * to bound it to only accept Float and Double. There are other issues to, * but that is the main one that I see as blocking it. * * Therefore I moved into looking at solution 3: refactoring out a superclass * called AbstractGeneralPath and deriving GeneralPath from it. This wasn't * too difficult of a chore. Many a method could be swapped up if a much * smaller utility method was implemented. After pushing as much that seems * reasonable upwards I created the DoubleGeneralPath. The DoubleGeneralPath * is a mirror image of the GeneralPath in terms of implementation. The variation * is in swapping double for float --> and that's almost it! Hence we have * 2 files with 500+ lines of quasi code duplication. I say quasi because * they look the same, but when you are operating on double arrays and * float arrays they are different pieces of code. Their essence is what is * similar. * * All of this goes back to the statement: "Unfortunately it is difficult to * figure out how to integrate this new capability into the existing class * structure...". Yes, as I have digged it has certainly proven difficult. * Then again, the mirrors are just 10 methods in each class. On counting * 17 methods were able to be moved upward as well as a whole slew of fields. * So roughly 2/3rds of the GeneralPath could be turned into an AbstractGeneralPath. * * I have considered making the two swappable with each other. But this would * entail making the AbstractGeneralPath public and adding a bunch of useless * mirror methods to each of the classes. From reading the remarks in the * RFE report it seems the users don't want to use the GeneralPath at all * because of its float implementation. The DoubleGeneralPath could be the * preferred solution for them. * * WHY THE NAME? Well because I haven't come up with a better one! We could * try: DBLGeneralPath, DGeneralPath, GeneralPathD, DoubleBackedGeneralPath, * etc... but these are worse * than DoubleGeneralPath. At least with DoubleGeneralPath you think to yourself * hmmm Double, oh yeah double. With the others you think what does D stand for? * * ANTI-RATIONALE: * This adds another public class to the awt.geom package. The new class * does not mirror the structure of other Double/Float pairs in this package, * making it harder to remember. It also adds 2 non-public classes to the * package making the file count larger. Given these, I don't believe any * of this is avoidable. Im not sure if it is even possible if we started * from scratch to design these things like the others. That's something * I have to contemplate. * * TESTING STRATEGY: * 1. Create a visual test. We compare the doodles rendered by GeneralPath * and DoubleGeneralPath by iterating through a cycle of these two. The * doodles should appear the same. We create the Paths by lineTo, curveTo * and quadTo. * 2. Exercise methods on the DGP and GP interface. * This test class is probably going to expand as time goes on. When you * look at all the things that have changed it becomes apparent that doodle * testing isn't going to be enough. It would be nice to the see a visual * test that can show off the differences between double and float. Right * now the tests don't illustrate this... . * * FILES AFFECTED: java.awt.geom package, java.awt.geom.GeneralPath class * * JDK VERSION * jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin * * test ran succesfully on a SUSE 7.3 Linux distribution * * Brian Harry * ###@###.### * Jan 19, 2006 * */ CODE(DIFFS FIRST, then new files): --- /home/nstuff/java6/jdk1.6.0/java/awt/geom/GeneralPath.java Thu Dec 15 02:16:27 2005 +++ /home/javarefs/java/awt/geom/GeneralPath.java Thu Jan 19 12:21:09 2006 @@ -33,39 +33,15 @@ [... snip ...]
|