Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

252
Vistas
¿Cómo puedo especificar --add-opens desde un nivel de proyecto y asegurarme de que se tenga en cuenta sea cual sea el medio para ejecutar mi aplicación?

Recientemente me mudé a Java 17 y con él surgieron un par de restricciones que me obligaron a usar --add-opens debido a una dependencia al ejecutar mi aplicación.

Necesito agregar esto cuando se ejecuta el comando java -jar . Por ahora encontré estas soluciones:

  • Puedo agregarlo al argumento de la línea de comando en mi Dockerfile que ejecuta el proyecto
 java --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/sun.util.calendar=ALL-UNNAMED -jar my.jar
  • Puedo agregarlo en mi MANIFEST.MF a través de mi maven pom.xml
 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifestEntries> <Add-Opens>java.base/sun.util.calendar java.base/java.util</Add-Opens> </manifestEntries> </archive> </configuration> </plugin>

Ambos funcionan bien para la producción aparentemente. Sin embargo, cuando ejecuto mi aplicación a través de IntelliJ, no está seleccionando las opciones, lo cual es normal, supongo. Tengo que configurarlos en mi configuración de ejecución (que, por cierto, también está comprometida con mi proyecto) como argumentos de VM.

Estoy buscando una manera de garantizar la coherencia automáticamente y no tener que mantener en paralelo dos lugares donde declaro mis complementos abiertos.

EDITAR: Me pregunto si se puede hacer algo con argfiles. Como tener un archivo arg dentro de mi proyecto al que se haría referencia en el contenedor y al que se podría hacer referencia en cualquier configuración de ejecución. Todavía no he encontrado mucha evidencia, pero ese es el camino que estoy siguiendo actualmente.

EDIT 2: Agregué un archivo addopens en la raíz de mi proyecto y ahora puedo hacer referencia a esto desde los diversos puntos donde lo necesito. Para las pruebas, agregué esto y funcionó de inmediato con las pruebas de IntelliJ Y las pruebas de Maven juntas:

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <!-- This adds the options contained in the addopens file to the test JVM arguments --> <argLine>@addopens @{argLine}</argLine> </configuration> </plugin>

También puedo enviar ese archivo addopens en mi ventana acoplable para usarlo en producción. Todavía necesito agregar a mi configuración de ejecución en IntteliJ el @addopens manualmente.

over 4 years ago · Santiago Trujillo
1 Respuestas
Responde la pregunta

0

Puede usar la opción para agregar los parámetros JDK en los complementos maven como el complemento surefire.

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <argLine> --add-opens java.base/java.time=ALL-UNNAMED ${surefireArgLine} </argLine> </configuration> </plugin>

Probé el enfoque anterior para IntelliJ IDE y Java 17 (Temurin-17.0.1). Funciona bien al ejecutarse a través del comando java -jar , así como al ejecutar la aplicación a través de IDE.

Si tiene varias opciones de JVM de este tipo para agregar, intente mantener las asignadas a una propiedad y use esa propiedad aquí en argLine.

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda