2011-12-28 11 views
17

Supongamos una aplicación Java, aceptando un argumento de línea de comando entero, digamos bubu.Java: utilizando los parámetros del sistema frente a las opciones de línea de comando "normal"

Suponiendo que se utiliza un analizador de línea de comandos decente (y yo - http://pholser.github.com/jopt-simple/) más teniendo en cuenta el interruptor java -D, estas son algunas de las formas típicas de pasar este parámetro de línea de comando:

  1. --bubu 5 (o --bubu=5 o --bubu5)
  2. -Dbubu=5

donde el primero es el argumento del programa y debe ser manejado por la aplicación utilizando algún programa de análisis de línea de comandos, WH El segundo es el argumento VM y ya ha sido analizado por java, por lo que está disponible como Integer.getInteger("bubu")

Estoy un poco perplejo. ¿Qué debería usar? El uso de las instalaciones de propiedad del sistema:

  • parece nada
  • no depende de cualquier biblioteca de analizador de línea de comandos
  • proporciona conveniente (aunque inesperada) de la API para obtener los valores

En lo que costaría como puedo ver, el único inconveniente es que todas las opciones de línea de comando deben usar el indicador -D.

Por favor, consejo.

Gracias.

EDITAR

Otras ventajas para los parámetros del sistema - "Son utilizable incluso cuando la aplicación no es una aplicación independiente a partir de un principal, sino también cuando la aplicación es una aplicación web o una unidad prueba." - gracias https://stackoverflow.com/users/571407/jb-nizet

Edit2

Voy a ser más centrado aquí. ¿Hay alguna razón seria (además de la estética) para no usar los parámetros del sistema, como siempre?

Edit3

OK, creo que lo entiendo ahora. Si es probable que una aplicación web cargue mi código, existe un problema de potencial conflicto de nombres, ya que otras aplicaciones web alojadas en el mismo contenedor web comparten el espacio de propiedad del sistema con mi código.

Por lo tanto, tengo que ser prudente y desambiguar las propiedades de mi sistema de antemano. Entonces, no más bubu, es com.shunra.myapp.bubu ahora. Lo que significa que en lugar de un simple

-Dbubu=5 

que tienen

-Dcom.shunra.myapp.bubu=5 

que se vuelve menos atractivo para una aplicación de línea de comandos simple.

Otro motivo lo da Mark Peters, que es bastante bueno para mí.

+2

Bueno, lo resumió. Otra ventaja de las propiedades del sistema es que son utilizables incluso cuando la aplicación no es una aplicación independiente que comienza desde una principal, sino también cuando la aplicación es una aplicación web o una prueba unitaria. Si la aplicación es una utilidad de línea de comandos, es posible que desee cumplir con las convenciones y proporcionar opciones regulares (como -ayuda, etc.). de lo contrario, las propiedades del sistema son más detalladas, pero más simples. –

+0

Entonces, ¿su consejo es usar siempre el distintivo -D? – mark

+2

No. Edité mi comentario. Si se trata de una herramienta de línea de comandos donde el usuario debe pasar opciones cada vez que invoca el programa, usar las opciones estándar es más fácil de usar. Si las opciones son solo opciones de configuración que se deben establecer una vez en un archivo por lotes, entonces las propiedades del sistema son más fáciles. –

Respuesta

10

Argumentaría que la ventaja que cita Fortyrunner es en realidad la negativa más significativa para las propiedades del sistema: están disponibles para cualquiera que las solicite.

Si la bandera u opción está pensada para ser una opción de línea de comando, debería estar disponible para la capa o módulo de su código que trata de tomar entrada de la línea de comandos, no de ningún código que la solicite.

Puede obtener un acoplamiento destructivo del estado global, y las propiedades del sistema no son diferentes de cualquier otro estado global.

Dicho esto, si solo intenta hacer un programa CLI rápido y sucio, y la separación de preocupaciones y el acoplamiento no es una gran preocupación para usted, las propiedades del sistema le dan un método sencillo que sin embargo conduce a (IMO) mala experiencia de usuario Alguna biblioteca de getopt le dará mucho más soporte para construir una buena experiencia de usuario de CLI.

+1

Entonces, lo que está diciendo es que usar -D satura el espacio de propiedades del sistema, compartido por todas las aplicaciones web alojadas por el mismo contenedor. Por lo tanto, presenta un posible problema de enfrentamiento de nombres, es por eso que debería haber usado algo como 'com.shunra.myapp.bubu' en lugar de' bubu', ¿no es así? – mark

+0

De acuerdo, todas las variables globales deben tratarse con cuidado. – Fortyrunner

+1

@mark: No es solo el espacio de nombres, sino también mantener el código aislado y desacoplado. Deberías intentar invertir tus dependencias; el código de bajo nivel debe * contar * cuáles son sus parámetros, no debería tener que * consultar * sus parámetros.Pero con la información global, es fácil para ese código de bajo nivel simplemente consultar sus parámetros (a través de 'System.getProperty()'), que lo relaciona con su contexto de invocación (la línea de comando). Por lo tanto, se hace más difícil probar la unidad o reutilizarla en un contexto diferente. Pero el problema del espacio de nombres es otra preocupación. –

2

Una de las principales ventajas de las propiedades del sistema es que están disponibles en cualquier momento durante la vida de su programa.

Los argumentos de la línea de comando solo están disponibles en el método principal (a menos que los persista).

-1

Creo que hay muchas cosas que un usuario promedio como yo no necesita saber. Las propiedades del sistema ayudarán al desarrollador de un sistema a preestablecer una cantidad de valor que permitirá la ejecución de un sistema. Por ejemplo, cuando descargo el servidor de la aplicación GlassFish, siempre viene con muchos parámetros preestablecidos de los que no tengo idea para qué sirven. No tengo mucha experiencia en lidiar con la configuración del servidor. Si me pides que inicie el servidor GlassFish con 20 parámetros en la línea de comandos, tendría que aprender para qué son estos parámetros y cuánto debo configurar, etc. Es demasiado problemático.

En resumen, cuando un sistema se hace cada vez más grande, puede tener más y más propiedades. Con las propiedades del sistema preestablecidas, los usuarios solo necesitarán saber qué son cuando realmente lo necesiten. Por ejemplo, solo necesito saber acerca de GlassFish's -XX:PermSize cuando necesito aumentar la memoria.

+0

Nada dice que las opciones de línea de comando no pueden ser opcionales. De hecho, PermSize ni siquiera es una propiedad del sistema; es una opción de línea de comando. –

+0

Por supuesto, muchas opciones pueden ser opcionales. Pero también hay muchas opciones obligatorias que los usuarios pueden no necesitar saber. No tengo mucha experiencia con estas cosas. Por lo tanto, mi ejemplo de PermSize no es bueno. Sin embargo, creo que puede pensar en muchas propiedades del sistema GlassFish que son obligatorias. –

Cuestiones relacionadas