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)
BUG ID: 4172661 GeneralPath needs double version
FILES AFFECTED: java.awt.geom package, java.awt.geom.GeneralPath class
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
* 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?
* 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
* 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 ...]