Ignore my post here. See the other one. Even simpler solution.
Jonathon
Jonathon -- Improov wrote:
Adrian,
Method overriding is only possible with different parameters, not with
different returns, I believe?
Rather than deprecating one of those 2 methods, might I suggest that you
retain just one? One method that will serve both the old and the new
usages.
Here's how it works.
If Properties continues to extend FlexibleProperties, your original
method signature works for old usages. What about the new ones requiring
a Map to be returned?
If FlexibleProperties implements Properties, then it can be viewed as a
"type of Properties". If it also implements Map, then it can be cast
into a Map!
One class (FlexibleProperties), 2 perspectives. Everybody is happy. :)
Hope that is clear. It's some Java stuff. Check out multiple interfaces
for a single class.
Not that you don't know Java (you've certainly done lots for Widget
Engine!!). I'm just hoping to keep the coding as Java-OO as possible.
Neat and clean. There are certainly many ways of going about it.
Jonathon
Adrian Crum wrote:
Jonathon,
Properties extends Map. I ended up having two methods - one that
returns a Map in addition to the original.
I've been using it for nearly a week and everything seems to be
working well. I'll post it to Jira in the next few days.
-Adrian
Jonathon -- Improov wrote:
Adrian,
How about getting FlexibleProperties to implement Map, in addition to
Properties?
Jonathon
Adrian Crum wrote:
I've been working on the UtilProperties class to clean up some of
the code, improving the cache handling algorithm, improve support
for i18n, and add support for the new XML properties file format.
I believe we could really improve the performance of OFBiz if we
cached FastMap instances instead of java.util.Properties instances.
That would require a slight change in the UtilProperties API -
UtilProperties.getProperties(...) would return a Map instance
instead of a Properties instance.
Doing so wouldn't have a large impact on the existing code base -
there are only a handful of places where
UtilProperties.getProperties(...) is called. The problem would be
legacy installations - custom code that calls
UtilProperties.getProperties(...) would break.
Should I change the existing method signature, or add the new
methods and deprecate the old ones?
-Adrian
