Roadmap

For 0.4

Get rid of internal circular dependency

Frankly, the MessageBundles code sucks big time because of that.

Replace ServiceProvider support with something else

Most probably a classpath scanner. Two candidates:

• corn-cps (preferred; oo external dependency);
• reflections at Google Code (requires... Guava!! Ouch);
• write my own (NOT!)

Use the Maven assembly plugin

Here is a SO post on how to create a full-blown, ready-to-use jar with all dependencies.

In the future

Possible candidates; none of this is either decided or prioritized.

Dual gradle/maven build

Gradle is becoming more and more prevalent, especially since it is the officially recommended tool by the Android community.

Get head out of black hole and Just Do It(tm).

Annotations?

Possible use: prepend or append to another bundle. Would need to modify MessageBundle to provide its source list.

Hypothetical code:

@PrependTo(com.foobar.MyMessageBundle.class)

Legacy ResourceBundle support?

That is, provide a way to read property files using ISO-8859-1.

Not sure whether it is of any use. If this is provided, maybe also provide a conversion utility from these bundles to new bundles?

More generic: support for using "arbitrary" charsets to read property files?

That would be nice. But useful? Good question.

Loading/caching control?

Right now the loading and caching policy is fixed (except you can specify the timeout you want for loading). Give more control? Like, for instance, expiration (which currently doesn't happen)?

Salvage some functionality of ResourceBundle.Control?

Seen on Stack Overflow: you can use the class above to return a list of relevant locales for the locale of your choice. Right now, this logic is hardcoded. Is it worth it to provide an override in this library?

MessageFormat support?

This was in the initial plans. But why use a 20th century technology when you have printf() (which is actually even older, but works miles better)?

Bah. If requested, one day, maybe...