-
Bug
-
Resolution: Fixed
-
P3
-
6
GeneralPath has a createTransformedShape method which is declared to return
a Shape. Before Mustang, this method always returned a GeneralPath object.
In Mustang, the Path2D classes were created to offer alternate storage
precision for paths and as a result now this method can (and does) return
a double precision path which provides for more accuracy. Unfortunately,
this means the returned object is no longer the same type as GeneralPath.
While returning a double precision path from this method represents the best
tradeoff in terms of precision, the new return type will not be compatible
with code that may have expected the method to return a GeneralPath object.
As it turns out, as an example of existing code that may be broken by this
change in behavior, assumptions were discovered in some of the JCK tests that
this method would return a GeneralPath object even though it was not declared
to do so. These tests then failed. From a purely implementational point
of view, those tests are broken since they make an assumption that goes beyond
the spec. But from a practical point of view, they may be an indicator that
other code may exist which might make this same erroneous assumption.
While the new behavior is definitely valid, the change has potential to break
existing code so we should examine that possibility and decide if we want to
maintain strict behavioral compatibility or provide better precision.
a Shape. Before Mustang, this method always returned a GeneralPath object.
In Mustang, the Path2D classes were created to offer alternate storage
precision for paths and as a result now this method can (and does) return
a double precision path which provides for more accuracy. Unfortunately,
this means the returned object is no longer the same type as GeneralPath.
While returning a double precision path from this method represents the best
tradeoff in terms of precision, the new return type will not be compatible
with code that may have expected the method to return a GeneralPath object.
As it turns out, as an example of existing code that may be broken by this
change in behavior, assumptions were discovered in some of the JCK tests that
this method would return a GeneralPath object even though it was not declared
to do so. These tests then failed. From a purely implementational point
of view, those tests are broken since they make an assumption that goes beyond
the spec. But from a practical point of view, they may be an indicator that
other code may exist which might make this same erroneous assumption.
While the new behavior is definitely valid, the change has potential to break
existing code so we should examine that possibility and decide if we want to
maintain strict behavioral compatibility or provide better precision.
- relates to
-
JDK-4172661 GeneralPath needs double version
-
- Resolved
-