Introduction of inheritance in Propertyresourcebundles

propertyResourceBundle is a Java mechanism for separating locale-specific text from the actual Java code. When an application invokes one of these locale-specific properties, a text file associated with a given user locale is opened and read.

Separating language-sensitive messages from Java code is key to dealing with internationalization issues. As long as the application uses propertyResourceBundle to obtain its locale-specific properties, the application can be easily translated into any language by providing a property text file for all supported locales.

Maintaining a large number of resource bundles can be a daunting task--just as daunting as trying to maintain a large piece of code. So why not apply some of the principles used in code to facilitate the reuse of resource bundles?

The focus of this paper is to introduce the concept of inheritance for propertyResourceBundle. In this way, the public bundle can be shared, and more specific bundles can be introduced without affecting other beam users.

First, I will outline the most commonly used design strategies.

Current policies and their problems

The currently used propertyResourceBundle design usually follows the following three policies:

Use a large, all-inclusive bundle (all application components share this bundle).

Allows each application component to have its own separate bundles that are not reused between applications.

Allows some resource bundles that do not have duplicate attribute definitions.

Let's look at each of these strategies in more detail:

Tan: No reuse, high maintenance costs

The first approach is highly controversial in both design-time and run-time resource bundles. It does not support reuse because only one bundle exists and any changes made to the bundle affect other components that use the bundle.

The redefinition of any property in this method requires that all components use the new version, or add a new attribute. In any case, maintaining a large bundle of resources can quickly become laborious and consumes more time than you would like.

Smaller, independent bundles: no reuse, make the problem consistent

Another option for the first approach is to split a single resource bundle into subsets of the original bundle. This method will make each bundle independent of the other bundles, allowing each bundle to redefine the attribute for its own use.

This design does not support reuse because each bundle must define its own properties. And each bundle retains its independence in its definition.

It is now more difficult to maintain consistency between the bundles because each bundle is independent. For example, each bundle might define a property with a mailing address. If this address changes now, every bundle associated with this email address must be changed.

Attribute-specific bundles: high-cost steering code for maintenance

The third approach relies on which resource bundles the code developer is going to turn to when it comes to a clear understanding of any given property.

When using the Mail Address property sample, where the Address property is defined in only one resource bundle, any application component that needs to contain an address must go to a specific resource bundle that defines the address. In this mode, the application component must determine which resource bundle to go to when given a key. Any changes you make to the resource bundle may require similar changes to the application components that use them.

When using this method, the maintenance problem really happens to go from the resource bundle to the code that gets the property.

In order to find an effective solution, we need to weigh the pros and cons of these three approaches.