Details
-
Bug
-
Status: Closed
-
Resolution: Fixed
-
2.5
-
None
-
None
-
Operating System: All
Platform: All
-
50703
Description
Attached patch parametrizes fop.fo.properties.PropertyCache.
As a result, all the different public fetch() overloads can be rolled into one, and suddenly this class seems to have the potential for more general usage. Any class offering reliable implementations for equals() and hashCode() is now a candidate to store its canonical instances in the cache.
The idiom becomes:
PropertyCache<Type> cache = new PropertyCache<Type>(Type.class);
The constructor parameter is still needed, as I could not immediately find a way to derive the class name (for debugging) from the type parameter. Don't know if there even is one... At any rate, the correspondence between constructor and type parameter is enforced by the constructor, so it would not be possible to write:
new PropertyCache<TypeA>(TypeB.class)
not even if TypeB is a subclass of TypeA.
If I judge correctly, applying this patch by itself should, at worst, cause a few unchecked warnings to pop up in the fo.properties package. Locally, I have already adapted all the properties that use it (and added a few new classes), but I kept these changes out of the patch for now, to focus on the main change.
Suggestions welcome. Would it be useful outside of the fo.properties package as well? Could it migrate to fop.util?