2010-03-01 20 views
20

El objeto Properties de Java no ha cambiado mucho desde pre-Java 5, y no tiene compatibilidad con Generics o métodos de ayuda muy útiles (patrón definido para conectar clases para procesar propiedades o ayudar a cargar todos los archivos de propiedades en un directorio , por ejemplo).¿Están las propiedades de Java en desuso de manera efectiva?

¿Se ha detenido el desarrollo de propiedades? Si es así, ¿cuál es la mejor práctica actual para este tipo de propiedades de ahorro/carga?

¿O me he perdido algo por completo?

+0

¿Y qué hay de java.util.Dictionary? Se ha actualizado para usar Generics, pero también se ha documentado como "obsoleto". Sin embargo, todavía no está marcado como @deprecated. Supongo que la desaprobación es un problema difícil. – omerkudat

+0

@omerkudat, el diccionario es básicamente un mapa antes de colecciones en 1.2.Aunque no está formalmente obsoleto, está en el mismo grupo que Vector. Eso generalmente no es preferido. http://stackoverflow.com/questions/1386275/why-java-vector-class-is-considered-obsolete-or-deprecated/ – Yishai

Respuesta

10

Muchos de los conceptos en torno a las propiedades son definitivamente antiguos y cuestionables. Tiene una internacionalización muy pobre, agrega métodos que hoy en día solo se lograrán a través de un tipo genérico, amplía Hashtable, que en general no está en uso, ya que su sincronización tiene un valor limitado y tiene métodos que no están en armonía con el Las clases de colecciones introducidas en 1.2 y muchos de los métodos añadidos a la clase Propiedades proporcionan esencialmente el tipo de seguridad de tipo que es reemplazado por Genéricos.

Si se implementa hoy, probablemente sea una implementación especial de Map<String, String>, y sin duda es compatible con una mejor codificación en el archivo de propiedades.

Dicho esto, en realidad no hay un reemplazo que no agregue complejidad. Seguro que java.util.prefs.Preferences api es el "nuevo y mejorado", pero agrega una capa de complejidad que va mucho más allá de lo que se necesita para muchos casos de uso. El solo uso de XML también es una opción (que al menos soluciona los problemas de internacionalización) pero un objeto de propiedades a menudo se ajusta perfectamente a las necesidades, y en ese momento se usa.

+0

Para la internacionalización normalmente usaría la API ResourceBundle. Consulte http://java.sun.com/developer/technicalArticles/javase/i18n_enhance/ y http://bordet.blogspot.com/2007/01/utf-8-handling-for-resourcebundle-and.html – BalusC

+2

@BalusC Mi suposición es que Yishai se refirió a las peculiaridades de la codificación de archivos de propiedades como "mala internacionalización", y por defecto ResourceBundle usa la misma codificación. –

1

La estructura del diccionario es una de las estructuras más antiguas utilizadas en la mayoría de los lenguajes de programación http://en.wikipedia.org/wiki/Associative_array, dudo que esté en desuso.

Incluso si se eliminaran, pronto habría nuevas implementaciones fuera del núcleo.

Ya hay extensiones externas, los recursos comunes de apache son excelentes recursos que creo que han ayudado a dar forma a Java a lo largo de los años, consulte http://commons.apache.org/configuration/howto_properties.html.

+1

La interfaz e implementadores de Collections Map parecerían ser la solución formal de Java para matrices asociativas - Propiedades de IMHO es más una cosa de conveniencia – Brabster

7

Sigue siendo una solución viable para los requisitos de configuración simples. No necesitan soporte de genéricos porque las claves de propiedad y los valores son intrínsecamente cadenas, es decir, se almacenan en archivos ascii planos. Si necesita un/marshaling/serialización de objetos, las propiedades no son el enfoque correcto. El método preferido ahora es java.util.prefs.Preferences para cualquier cosa más allá de las necesidades de configuración incluso moderadamente sofisticadas.

3

Hace lo que tiene que hacer. No es tan difícil escribir soporte para leer en todos los archivos de propiedades en un directorio. Diría que ese no es un caso de uso común, así que no veo eso como algo que deba estar en el JDK.

Además, ha cambiado ligeramente desde pre-Java 5, ya que el Javadoc dice que se extiende Hashtable<Object, Object> e implementa Map<Object, Object>.

+1

Para explicaciones de por qué 'Hashtable ' not 'Hashtable ' ver: http://stackoverflow.com/questions/873510/why-does-java-util-properties -implement-mapobject-object-and-not-mapstring-str –

+0

Gracias por el enlace @Tom Hawtin, lectura interesante. – Brabster

2

"no tiene soporte genérico", ¿por qué necesita soporte genérico? se trata de la clave de cadena y los valores de cadena No consideraría las propiedades de Java obsoletas. Es una biblioteca madura: eso es todo

+2

en realidad se trata de la clave de objeto y los valores de objeto: para restringir a la clave de cadena y valores de cadena, necesitaría genéricos. – Brabster

+0

La clase proporciona funciones de conveniencia de String key y String value. – dbrown0708

+2

@brabster y @ dbrown0708 Las API basadas en objetos se filtraron en Propiedades debido a un diseño incorrecto. Persona creada ignorada: "Favorecer la composición por herencia" aunque la intención era diferente (como se indica en javadoc: "La clase Propiedades representa un conjunto persistente de propiedades. Las Propiedades se pueden guardar en una secuencia o cargar desde una secuencia. y su valor correspondiente en la lista de propiedades es una cadena. ") –

Cuestiones relacionadas