✓ Cómo usar OpenJDK 11 con Liferay 7.1 GA3

Como ya sabréis, la Eclipse Foundation tomó las riendas de la evolución de Java hará algo más de un año y actualmente, las versiones de la jvm de Oracle superiores a la versión 8 son de pago si las usamos con fines comerciales.

Por ello, se recomienda cambiar a OpenJDK, que no tienen restricción en el licenciamiento, y más precisamente a una versión Long Term Support, salvo que queráis estar en la cresta del desarrollo y uséis versiones más recientes sin ser LTS (la versión 12 de java será de este tipo) aunque si tenéis que usar otras librerías, es posible que algunas no sean compatibles con las versiones más nuevas de java ya que con la velocidad que han cogido las releases de Java, no da tiempo a que los desarrolladores actualicen las versiones de sus librerías con las últimas novedades.

Además, actualmente las jvm de OpenJDK y de Oracle son prácticamente iguales y deberían ser intercambiables en todos los casos salvo que uséis componentes que añade Oracle a su jvm.

La última versión LTS, y también la más reciente estable en el momento de escribir este post, es OpenJDK 11, y por eso vamos a configurar nuestro servidor y entorno de trabajo para poder usar esta versión.

Configurar el servidor de aplicaciones con Liferay

Para que el servidor de aplicaciones en el que está instalado Liferay pueda funcionar sobre OpenJDK 11, hay que añadir las siguientes propiedades al entorno:

JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.base/java.awt.font=ALL-UNNAMED"
JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.base/java.io=ALL-UNNAMED"
JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.base/java.lang=ALL-UNNAMED"
JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.base/java.lang.reflect=ALL-UNNAMED"
JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.base/java.net=ALL-UNNAMED"
JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.base/java.nio=ALL-UNNAMED"
JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.base/java.text=ALL-UNNAMED"
JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.base/java.util=ALL-UNNAMED"
JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.base/sun.nio.ch=ALL-UNNAMED"
JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED"

Por ejemplo, si estuviéramos trabajando con tomcat, deberíamos poner esas propiedades en $RUTA/tomcat-9.0.10/bin/setenv.sh

Configurar el workspace con el código fuente

Ahora lo que tenemos que hacer es asegurarnos que nuestro workspace está usando la última versión de la serie 4.x de gradle, la versión 4.10.3 al escribir este post.

*Notad que la última versión de blade disponible en el momento de escribir este post. la versión 3.5.0.201902260105, genera el código usando la versión 4.10.2 del wrapper por lo que también tendréis que ejecutar este comando

Desde el directorio raíz de vuestro workspace

./gradlew wrapper --gradle-version=4.10.3 --distribution-type=bin

*Si no sabéis crear un workspace, está explicado en este otro post, que aunque se ha quedado un pelín desactualizado en esencia sigue siendo válido.

En el fichero build.gradle de cada module, añadid lo siguiente

compileJava {
  sourceCompatibility = '1.8'
  targetCompatibility = '1.8'
}

o mejor aún, poned lo siguiente en el build.properties raíz

allprojects {
    apply plugin: 'java'
    sourceCompatibility = 1.8
    targetCompatibility = 1.8
}

Date cuenta que las anteriores líneas impiden usar las nuevas funcionalidades de Java 11, pero hasta que no se actualice la librería bndlib del portal a la versión 4.1.0 o superior me temo que no será 100% compatible. Aunque por lo menos sí que podremos hacer los test con Java 11 (léase java.net.http.HttpClient)

Configurar el path

Bueno, esto es obvio. Pero por si acaso. Aseguraos de tener la variable de entorno JAVA_HOME apuntando a la versión openJDK11 y que en el PATH tenéis añadida la ruta JAVA_HOME/bin

Cargando comentarios...