[jira] Updated: (OFBIZ-1485) UtilProperties - The Next Generation

["Adrian Crum (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Crum updated OFBIZ-1485:
-------------------------------

    Attachment: props_tng.patch

While I was working on adding the XML properties file capability to UtilProperties, I noticed a few things about the UtilProperties class that bothered me. After the initial XML properties support was committed (rev 599356) I went back to the UtilProperties class to work on those issues.

#1 The caching algorithm in getInternalRbmWrapper(...) (line 493) - could potentially store multiple copies of the same ResourceBundle in the cache.
#2 The getProperties(String resource, Locale locale) method wasn't fully implemented (see notes at line 546).

Issue #1 was easy to fix - I just used the ResourceBundle.getLocale() method to do a second cache lookup, around line 506. If one was found, I cached the new key with the existing bundle. Now multiple locales could share a single ResourceBundle instance. There was still the potential to have multiple copies of the same ResourceBundle though. I'll get back to that later.

The solution to issue #2 was obvious - UtilProperties needed a properties file location resolver. I already had one working in the XmlResourceBundle inner class, so I just moved that code from the inner class to the outer class. I did the same for the XML properties file to Map conversion code.

At this point, everything was working well - but something else started to bother me. Why does UtilProperties have three caches? They all contain basically the same thing. Technically, UtilProperties only needs two - one for non-locale-specific properties, and one for locale-specific properties. I changed the code a bit so that the ResourceBundle cache wasn't needed - I wrote a method that wraps a XmlResourceBundle (renamed to UtilResourceBundle) instance around an existing cached properties object. Methods that need a ResourceBundle call the wrapper method. That eliminated one cache. That also solved the issue that bugged me about the multiple same ResourceBundle instances in the cache.

Now that the code was reduced down to two caches of FlexibleProperties objects, I started to look at the FlexibleProperties class to see if there was a way to convert it to a Javalution FastMap. So I traced through the UtilProperties-to-FlexibleProperties code. I determined that the FlexibleProperties object contributes nothing to the UtilProperties class. I converted all references to FlexibleProperties to plain Maps, and used the Javalution FastMap for new instances.

The final step was to rewrite bits of code so that UtilProperties would pass around Maps internally, and only use the Properties class when one is requested.

The attached patch is the result. I have used it for about a week - it seems to work well. The performance gains, memory savings, etc will have to be determined by real-world installations.

Comments are welcome.


> UtilProperties - The Next Generation
> ------------------------------------
>
>                 Key: OFBIZ-1485
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-1485
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework
>            Reporter: Adrian Crum
>            Priority: Minor
>         Attachments: props_tng.patch
>
>
> Improve the UtilProperties class. Details in comments.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.