26

Java's Properties object hasn't changed much since pre-Java 5, and it hasn't got Generics support, or very useful helper methods (defined pattern to plug in classes to process properties or help to load all properties files in a directory, for example).

Has development of Properties stopped? If so, what's the current best practice for this kind of properties saving/loading?

Or have I completely missed something?

brabster
  • 42,504
  • 27
  • 146
  • 186
  • And what about java.util.Dictionary? It has been updated to use Generics, but it has also long been documented as "obsolete". However, it is still not marked as @deprecated. I guess deprecation is a difficult problem. – omerkudat Mar 01 '10 at 20:52
  • @omerkudat, Dictionary is basically a Map before Collections in 1.2. Although not formally deprecated, it is in the same group as Vector. That is generally not preferred. http://stackoverflow.com/questions/1386275/why-java-vector-class-is-considered-obsolete-or-deprecated/ – Yishai Mar 01 '10 at 23:16

5 Answers5

11

A lot of the concepts around Properties are definitely ancient and questionable. It has very poor internationalization, it adds methods that today would just be accomplished via a Generic type, it extends Hashtable, which is itself generally out of use, since its synchronization is of limited value and it has methods which are not in harmony with the Collections classes introduced in 1.2, and many of the methods added to the Properties class essentially provide the kind of type safety that is replaced by Generics.

If implemented today it would probably be a special implementation of a Map<String, String>, and certainly support better encoding in the properties file.

That being said, there isn't really a replacement that doesn't add complexity. Sure the java.util.prefs.Preferences api is the "new and improved" but it adds a layer of complexity that is well beyond what is needed for many use cases. Just using XML is also an option (which at least fixes the internationalization issues) but a properties object often fits the needs just fine, at which point use it.

Yishai
  • 90,445
  • 31
  • 189
  • 263
  • For internationalization you would normally use the ResourceBundle API. Check http://java.sun.com/developer/technicalArticles/javase/i18n_enhance/ and http://bordet.blogspot.com/2007/01/utf-8-handling-for-resourcebundle-and.html – BalusC Mar 02 '10 at 01:48
  • 2
    @BalusC My guess is that Yishai referred to the quirks of the properties file encoding as "poor internationalization", and by default ResourceBundle uses the same encoding. – Christian Semrau Mar 27 '11 at 09:21
7

It's still a viable solution for simple configuration requirements. They don't need generics support because Property keys and values are inherently Strings, that is, they are stored in flat, ascii files. If you need un/marshaling/serialization of objects, Properties aren't the right approach. The preferred method is now java.util.prefs.Preferences for anything beyond even moderately sophisticated configuration needs.

nicerobot
  • 9,145
  • 6
  • 42
  • 44
3

It does what it needs to do. It's not that hard to write support for reading in all the properties files in a directory. I would say that's not a common use-case, so I don't see that as something that needs to be in the JDK.

Also, it has changed slightly since pre-Java 5, as the Javadoc says that extends Hashtable<Object, Object> and implements Map<Object, Object>.

dbrown0708
  • 4,544
  • 4
  • 25
  • 22
  • 2
    For explanations of why `Hashtable` not `Hashtable` see: http://stackoverflow.com/questions/873510/why-does-java-util-properties-implement-mapobject-object-and-not-mapstring-str – Tom Hawtin - tackline Mar 01 '10 at 20:16
3

"it hasn't got Generics support," why does it need generics support; it deals with string key and string values I would not consider Java properties deprecated. It is a mature library - that's all

ring bearer
  • 20,383
  • 7
  • 59
  • 72
  • 3
    it actually deals with Object key and Object values - to restrict to String key and String values, you would need generics. – brabster Mar 01 '10 at 20:17
  • The class provides for String key and String value convenience functions. – dbrown0708 Mar 01 '10 at 20:25
  • 2
    @brabster and @dbrown0708 The object based APIs seeped in to Properties due to bad design. Person built it ignored:"Favor composition over inheritance" though the intention was different (As stated in javadoc: "The Properties class represents a persistent set of properties. The Properties can be saved to a stream or loaded from a stream. Each key and its corresponding value in the property list is a string. ") – ring bearer Mar 01 '10 at 21:00
1

The dictionary structure is one of the oldest most used structures in most programming languages http://en.wikipedia.org/wiki/Associative_array, I doubt it would be deprecated.

Even if were to be removed there would soon be new implementations outside of the core.

There already are external extensions, apache commons are great resources that I think have helped to shape java over the years, see http://commons.apache.org/configuration/howto_properties.html.

crowne
  • 8,456
  • 3
  • 35
  • 50
  • 1
    The Collections Map interface and implementers would seem to be Java's formal solution for Associative arrays - IMHO Properties is more a convenience thing – brabster Mar 01 '10 at 20:18