L2J Java Setup: JDK, Eclipse y XAMPP sin adivinar

Un l2j java setup que funciona tiene menos que ver con instalar tres programas y más con hacerlo en el orden y las versiones correctas. La mayoría de primeros builds fallidos vienen de un JDK más nuevo o más viejo de lo que espera el pack, un JAVA_HOME que apunta a otra instalación o una base de datos que ya ocupa el puerto que quiere XAMPP. Esta guía recorre el entorno en el orden que evita esas trampas: primero el JDK, después la base, luego el IDE, y XAMPP solo donde aporta algo.

El orden que ahorra tiempo

Instala el JDK, verifícalo desde una terminal, instala después la base de datos y abre el proyecto en Eclipse al final. Empezar por el IDE parece productivo, pero Eclipse se enganchará al runtime equivocado y te hará perseguir errores de compilación que en realidad son errores de entorno.

1. Elige la versión de JDK que pide tu pack.
2. Instálala y configura JAVA_HOME.
3. Instala MariaDB o MySQL y crea el usuario de la base.
4. Importa el pack en Eclipse y compila sin tocar código.
5. Solo entonces empieza a editar configuración y código.

Elige el JDK que pide tu pack

No hay una versión correcta única de Java para servidores de Lineage 2. Cada pack declara la suya, e instalar la más reciente porque es la más reciente es la vía más rápida a un build que falla el primer día.

Abre primero el README del pack y busca la versión de Java. Si no dice nada, revisa el archivo de build o la configuración del compilador de Maven. Dos minutos de comprobación evitan una tarde de errores "Unsupported class file major version".

Para el runtime, usa una distribución OpenJDK como Eclipse Temurin. Es gratuita, está bien documentada y existe para Windows, Linux y macOS. La guía de instalación oficial de L2J usa la misma distribución.

Instala el JDK y configura JAVA_HOME

En Windows, winget instala y registra el JDK en un paso. En Linux, usa el gestor de paquetes de tu distribución o el repositorio de Adoptium. En ambos casos, lo importante es la variable de entorno.

• Windows: apunta JAVA_HOME a la carpeta del JDK, no a la subcarpeta bin, y añade %JAVA_HOME%\bin al PATH.
• Linux: exporta JAVA_HOME en el perfil de tu shell y pon $JAVA_HOME/bin primero en PATH.
• Varias versiones: mantenlas instaladas y cambia a propósito. En Linux, update-alternatives gestiona las herramientas de línea de comandos.

Verifica los dos comandos, no solo uno: java --version y javac --version. Si no coinciden, tu PATH está mezclando un JRE con un JDK, y el build fallará más tarde de forma confusa.

Eclipse: importar y compilar

Usa Eclipse IDE for Java Developers. Para un pack basado en Maven, importa como proyecto Maven existente y deja que resuelva las dependencias. Para un pack basado en Ant, importa el proyecto y confirma que detecta el archivo de build.

• Configura el JRE instalado con el mismo JDK que pide el pack, no con el más nuevo de la máquina.
• Ajusta el nivel de compilación a ese JDK.
• Pon la codificación de texto en UTF-8 antes de editar un solo archivo.
• Haz un build limpio antes de cambiar código, para saber que el punto de partida está sano.

Si el proyecto muestra "JRE System Library unbound", Eclipse apunta a un runtime que se eliminó o cambió de nombre. Corrige la lista de JRE instalados y recompila. No añadas jars a mano para silenciar el error.

XAMPP: útil, pero no obligatorio

XAMPP empaqueta Apache, PHP, MariaDB y phpMyAdmin en un instalador. Para un servidor L2 solo importa la parte de base de datos, y muchos packs funcionan perfectamente con un MariaDB independiente. XAMPP es cómodo cuando quieres phpMyAdmin sin configurar nada, y es una elección habitual para una primera prueba local.

También trae dos trampas:

• Conflicto de puerto: si MariaDB o MySQL ya están instalados como servicio, XAMPP no puede ocupar el puerto 3306. Detén uno antes de arrancar el otro.
• Valores de desarrollo: root puede acabar sin contraseña y el motor incluido puede escuchar más allá de localhost. Pon contraseña de root y átalo a localhost incluso en un escritorio.

Usa XAMPP para desarrollo local si te gusta el panel, pero con contraseña de root y atado a localhost. Para producción, instala MariaDB como servicio, crea un usuario dedicado y mantén el puerto cerrado a internet. El lado de la base está más a fondo en la guía de configuración de la base de datos, y un build específico de pack en la guía de instalación de aCis.

Un cliente de base de datos fiable

phpMyAdmin sirve para un vistazo rápido, pero un cliente de escritorio es más rápido para cargar esquemas y revisar tablas. HeidiSQL en Windows y DBeaver en cualquier plataforma conectan con MariaDB y MySQL, muestran la estructura con claridad y manejan archivos SQL grandes sin agotar el tiempo de una pestaña del navegador.

Prueba la conexión con las mismas credenciales que usará el game server, no con root. Si el usuario dedicado no conecta desde el cliente, el servidor tampoco lo hará.

Errores de versión y qué significan

Los errores de versión de Java suelen ser explícitos cuando sabes leerlos. Un class file compilado para un JDK más nuevo no corre en uno más viejo, y el número de versión mayor te dice qué release lo produjo.

• "Unsupported class file major version": el runtime es más viejo que el compilador. Instala el JDK correspondiente o recompila con el objetivo correcto.
• "JAVA_HOME is not set": falta la variable o apunta a la carpeta equivocada. Configúrala a la raíz del JDK y pon %JAVA_HOME%\bin en PATH.
• "Could not open jvm.cfg": se resuelve primero un java.exe viejo, normalmente una entrada PATH residual o una mezcla de 32 y 64 bits. Elimínala.
• "Port 3306 in use": dos motores de base de datos pelean por el mismo puerto. Detén el que no uses.

Lista de comprobación antes del primer build

Repasa esto una vez y la mayoría de problemas del primer build desaparecen:

• java --version y javac --version devuelven la misma versión mayor.
• JAVA_HOME apunta a la raíz del JDK y su carpeta bin va primero en PATH.
• El servicio de base de datos corre y el usuario dedicado puede entrar.
• Eclipse usa el mismo JDK y codificación UTF-8.
• Un build limpio funciona antes de cambiar código.

El entorno es aburrido a propósito. Hazlo bien una vez, anota las versiones en las notas del proyecto y no repetirás la instalación en la siguiente máquina.

Cuando el servidor esté listo para recibir jugadores, añádelo con el formulario de listado gratuito. Si quieres que destaque, el posicionamiento VIP lo pone por delante en el directorio de servidores.