In your original post, you mentioned a concern about breaking legacy codes.
I gave a suggestion that (if I'm not wrong) would fix the concern. Legacy codes will work, nothing
will be broken. Yet, the efficient FastMap will be used. Both ends of spectrum benefit.
I thought you wanted to address
Jonathon,
I've already answered the question I originally posted. The rest of the details
will be obvious when I submit the patch. Be patient.
-Adrian
Jonathon -- Improov <[EMAIL PROTECTED]> wrote: Oh, ok. I think it's perfectly
alright. Have you checked usages of method
UtilProperties.getPro
Oh, ok. I think it's perfectly alright. Have you checked usages of method
UtilProperties.getProperties(...)? Those will need to be changed to expect Map.
If you keep the original getProperties(...), and enhance FlexibleProperties to internally use
FastMap, the change propagation will not be nee
No, it's not destructive - the class is still there. It's just that
UtilProperties doesn't use it any more.
-Adrian
Jonathon -- Improov <[EMAIL PROTECTED]> wrote: That's a bit destructive.
Last count of usage: Debug, UtilProperties, VelocityViewHandler.
Well, long as it works. :)
Jonathon
Ad
That's a bit destructive.
Last count of usage: Debug, UtilProperties, VelocityViewHandler.
Well, long as it works. :)
Jonathon
Adrian Crum wrote:
Jonathon,
Thank you for the ideas. Actually, I ended up getting rid of references to
FlexibleProperties - it didn't do anything special and only
Jonathon,
Thank you for the ideas. Actually, I ended up getting rid of references to
FlexibleProperties - it didn't do anything special and only one other class is
using it.
-Adrian
Jonathon -- Improov <[EMAIL PROTECTED]> wrote: Oh, I missed this.
Yeah, Properties implements Map. Isn't it pos
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 ju
Oh, I missed this.
Yeah, Properties implements Map. Isn't it possible to get a Properties from method
getProperties(...), and the cast it to a Map?
In FlexibleProperties, override the Hashtable methods in Properties. That is, in
FlexibleProperties, encapsulate one FastMap, and make sure all M
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 Properti
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 ab
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
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
12 matches
Mail list logo
