MENU JAVA QUE CARGA JAR

Desktop.open()

el problema es como le paso argumentos???

Con una variable?

osea normalmente ejecuto desde consola

java -jar miappJava parametro1 parametor2 parametron

Desktop.getDesktop().open(new File("C:\\miprograma.jar parametro1 parametro2 ")); --> esto me da error

Para pasarle argumentos y tener mas control sobre el programa lanzado utilizas ProcessBuilder

Ejemplo
 

Desktop.open() es util cuando quieres lanzar una aplicacion en tu SO igual que si hicieras dobleclick en el icono de la aplicacion.

si la idea es que como es un programa principal basicamente es el menu con todas las opciones, cada una de esas opciones va ser un aplicativo
un jar independiente, entonces lo que se va hacer es que al cargar el programa principal el usuario se loguee y ese usuario como global debe pasar a todas las aplicaciones como argumentos

Y con eso se va a construir el menu dinamicamente?

Seria mejor cargar esas opciones en un archivo .properties o con algun otro formato ( json por ejemplo ), tenerlos que pasar en la linea de comandos es impractico por que tendría que escribirse cada vez, y lo que terminaran haciendo sera escribir un archivo .bat ( o .cmd , o .sh ) para escribir el programa ahi mismo.

Lo unico que necesitas para ejecutar codigo java desde java es hacer referencia al objeto.

Si tienes 100 clases en 100 JAR diferentes lo que debes asegurar es que están en el mismo classpath y de esa forma lo invocas directamente, por ejemplo, supon que en el paquete   tienes la clase   que es la clase principal de tu JAR; entonces podras invocar con:

Eso puede ser equivalente a:
 
(habrá que revisar cual es la clase principal declarada en el manifest)

Si llamas a java desde java no tendrás una razon para invocar clases con instrucciones del sistema operativo

@jdd Ah claro. Quiza habria que lanzar cada app en un hilo diferente para que no se bloquearan.

Creo que el problema esta en que se require que sea configurable, pero igual eso se resolveria con un archivo properties poniendo las clases y los parametros:

Etc.

Todo depende de lo que este intentando hacer hackchan

OcarRyz el menu con todas las opciones del principal esta en json, menuyopciones.json
tego el aplicativo principal digamos pricipalapp.jar en ese aplicativo segun el loguin digamos se loguio oscarRyz asi:usuario: or88989233 ese usuario contiene la primera letra de tu nombre y la primera letra de tu apellido junto con la cedula.

Recuerda que cada opcion es un jar diferente Menu1-->opcion1.jar opcion2.jar Menu2-->opcion3.jar y cada uno de esos jar le debe llegar la cedula o el objeto del usuario que se loguio para manejar cosas de permisos que si el usuario puede abrir el jar, que si puede consultar, que si puede eliminar etc.

*como te planteo las cosas en el programa principal.app ahi lo ejecuto de la manera que dices por que le paso como parámetro la ruta del archivo de configuracion. java -jar appprincipal rutadelarchivoConfiguracion(COMO RECOMIENDAS , o CUAL ES LA MEJOR OPCION DE ESTO, sino lo paso como un argumento como lo debiria manejar facilitando que mi properties puede estar en cualquier ruta de mi pc)

*lo segundo es que todas las opciones(los programas independientes opcion1.jar.. opcion2.jar...) a ellos igual les paso la cedula conque se loguearon en el principal y la ruta de un properties local de opcion1.jar por ejemplo (PERO TU DICES QUE NO ES PRACTICO PASAR POR ARGUMENTOS como le hago llegar a opcion1.jar.... opcion2.jar... la cedula con que se loguearon en principalapp.jar, como cargo su properties.local igual dando la posibilidad que esos properties pueden estar en la ruta que yo le establesca )

Osea que desde mi programa principal principalapp que no es mas que un ui de menu y opciones y loguin de usuario, Menu1 -- opcion1.jar,
opcion2.jar, opcion3.jar.

osea que desde mi principalapp tan solo para llamar a opcion1.jar(.principalopcion1.java.pruebas.ClaseMain.main("88249432", "C:\\archivoconfiguracion", ); me imagino que todos los jar deben estar en el mismo path y debe existir un carpeta lib para compartir las librerias necesaria para ejecutar todos los programas.

pero Oscar dice que pasar por argumentos es impractico, segun lo que te planteo cual seria la mejor forma de hacer el desarollo.
ten en cuenta que mi appPrincipal se carga un menu apartir de json por eso cuando ejecuto el appPrinciapl (java -jar appPrincipal rutaJson)
osea que todos mis usuarios cargan el mismo menu y opciones solo como cada usuario se loguea y a cada jar le mando como parametors la cedula
valido los permisos que tiene (si puede abrir el programa, si puede consultar, actualizar, elimar etc)

Ah vaya.

Puedes hacer algo tan simple como poner una ventana de login y ahí capturar el id del usuario que se logueo y este se lo pasas como argumentos a todos los subprogramas.

Los menus los puedes seguir armando desde un solo archivo json ( seria más apropiado para mantener las jerarquias entre ventanas y sub-ventanas ). Y puedes instalar distintos archivos json en distintas maquinas. Luego hay que robustecer esto leyendolo desde una base de datos o algo así, porque de otra forma cualquiera podría editar el archivo y darse permisos.

Lo que es inconveniente es tener que escribir toda la configuración desde la linea de comandos y pasarle desde ahi el usuario. No que desde dentro del programa uses argumentos ( entre ellos el usuario ) eso es lo más natural.

Recuerdo que hay un API en Java, aunque ahorita no la recuerdo como se llama. Sirve para lidiar con credenciales. Es mucho más robusto e incluso se puede utilizar para validar sesiones de windows y se puede hacer SSO. Puedes sacar por ejemplo usuarios y roles y con eso armar los menus de acuerdo a los roles ( administrador, usuario general, editor etc. ). Debe de estar en los API´s de Java Enterprise Edition.