¿Alguna vez ha creado su propio kit de desarrollo de Java desde la fuente? La mayoría de los usuarios finales del JDK no necesitarán crear su propio JDK a partir del código fuente de Oracle. He necesitado hacer eso solo unas pocas veces cuando estaba ejecutando un sistema similar a OpenBSD UNIX , que no es una de las tres plataformas compatibles.
Claro, es posible que desee crear su propio JDK para probar una nueva función que cree que debería agregarse a Java. Puede optar por compilar desde la fuente para asegurarse de que está ejecutando un binario más confiable. Tener el código fuente completo disponible y ahora en un formato de descarga más utilizado significa que es más fácil que nunca crear su propio JDK. Sí, es un proceso mejor documentado y fácilmente configurado que en el pasado. Pero sigue siendo un poco confuso.
El código fuente para OpenJDK se movió recientemente del sistema de control de versiones de Mercurial (VCS) al sistema de repositorio Git VCS y GitHub, y eso probablemente sea algo bueno. Aquí hay un poco de historia, por qué es importante y lo que necesita saber.
Culpar o agradecer a BitKeeper
Si no fuera por Larry McVoy, los desarrolladores podrían no tener Git, GitHub o Mercurial.
Larry McVoy trabajó en Sun Microsystems de 1988 a 1994. Mientras estuvo allí, sugirió proféticamente que el sistema operativo UNIX (Solaris) de Sun y Novell deberían fusionarse y ser de código abierto para evitar el crecimiento de Microsoft Windows NT (y Linux). La gerencia de Sun no escuchó.
McVoy también desarrolló un repositorio de código y un sistema de control de versiones llamado TeamWare . Cuando McVoy dejó Sun, amplió ese trabajo a un nuevo sistema de control de versiones llamado BitKeeper . Era mucho más rápido para tratar con grandes bases de código y grandes cambios que los dos principales sistemas de control de versiones de código abierto que estaban en uso: el Sistema de Versiones Concurrentes (CVS) y Subversion.
BitKeeper era un producto de software comercial de la empresa de McVoy, BitMover. Dio una licencia gratuita al proyecto del kernel de Linux, con ciertas condiciones, una de las cuales era que no habría ingeniería inversa del producto.
Hubo consternación entre la comunidad de Linux por la voluntad de Linus Torvalds de usar una herramienta de código cerrado para mantener el kernel de Linux de código abierto, pero era la mejor herramienta para el trabajo, y la angustia simplemente se mantuvo en un segundo plano durante algunos años.
Finalmente, Andrew Tridgell, conocido como el creador del proyecto Samba (la compatibilidad del sistema de archivos de red de Microsoft para UNIX y Linux), intentó aplicar ingeniería inversa a los protocolos de red de BitKeeper para poder crear un cliente de código abierto para el servidor. Esta acción, ya sea correcta o incorrecta, precipitó una grieta en el continuo espacio-tiempo: McVoy rescindió total y abruptamente la licencia del proyecto Linux para BitKeeper, deteniendo abruptamente el desarrollo del kernel.
Esta acción precipitó el desarrollo tanto de Git como de Mercurial, como se puede leer en “ A Git origin story ” de Zack Brown en Linux Journal .
Aquí está la versión corta. Torvalds creó su propio VCS, Git , que dice que nombró en su honor: para los hablantes no nativos de inglés, un “git” se define como “una persona desagradable, despreciable o frustrantemente obtusa”. Git VCS se hizo cargo del soporte del kernel de Linux en cuestión de semanas.
Casi al mismo tiempo, Matt Mackall comenzó a escribir otro VCS, Mercurial . Afirma haberlo llamado Mercurial por el temperamento de McVoy, dado lo abruptamente que se canceló la licencia de BitKeeper de Linux.
Tanto Git como Mercurial ofrecen características y rendimiento similares. Pero con el tiempo, Git se ha ganado en gran medida el corazón y la mente de los desarrolladores. Mercurial permanece en uso pero es mucho menos popular.
Git está preinstalado en muchas distribuciones de sistemas operativos, y se pueden añadir fácilmente a la mayoría de los otros, usando
¿Por qué no Mercurial?
Uno de los proyectos más grandes que utiliza Mercurial fue Java OpenJDK de Sun, distribuido en varios repositorios.
No hay nada intrínsecamente malo con Mercurial. Es solo que Mercurial ha sido visto como un también ejecutado durante décadas, y muchos desarrolladores simplemente lo omitieron a menos que estuvieran realmente dedicados a algún proyecto que lo usara. Sin embargo, todavía hay muchos proyectos que lo utilizan; hay una lista en el sitio web de Mercurial que está algo desactualizada (todavía muestra Java). Curiosamente, esa página termina con un enlace a una lista de proyectos que se movieron de Mercurial a Git.
¿Por qué Git? ¿Por qué GitHub?
Git es ahora casi el estándar de facto en esta área; es difícil conseguir un trabajo como desarrollador a menos que se sienta cómodo usando Git. Git ofrece bifurcaciones, lo que permite a los desarrolladores trabajar en varios conjuntos de cambios al mismo tiempo, y fusionar, llevando varias ramas a otra rama, generalmente la principal.
Una plataforma relacionada es GitHub , un servicio de Git basado en la nube con muchas adiciones. Creas una cuenta y luego creas cualquier cantidad de repositorios de Git. Los repositorios pueden ser públicos (para código abierto o información abierta) o privados. GitHub es gratuito para las personas y tiene un precio razonable para las organizaciones.
Para ver cómo se ve GitHub, consulte uno de mis repositorios más pequeños, que es para PdfShow, una pequeña herramienta de presentación basada en PDF , o uno un poco más grande, javasrc, que tiene fragmentos de programa Java de muestra (incluidos los ejemplos de código de mi Java Libro de cocina ).
Hay varias ventajas de GitHub sobre el alojamiento Git simple o de bricolaje.
Una interfaz web completa. La interfaz web de GitHub ha sido mejorada por muchas manos talentosas y funciona bien. La interfaz del navegador le permite ver el contenido y el historial de los repositorios, ver archivos individuales y editar y confirmar archivos de texto.
Procesamiento de problemas. GitHub proporciona una función de seguimiento de errores llamada Problemas, ya que no todas las cosas que necesitan atención son errores. Puede etiquetar problemas como errores, mejoras o una docena de otras etiquetas, e incluso puede definir sus propias etiquetas. En un entorno de equipo, el administrador del repositorio puede asignar la responsabilidad de un problema a personas específicas.
Solicitudes de extracción. Una solicitud de extracción es un envío de una diferencia , o una lista de cambios, al propietario del repositorio, para extraer los cambios a la rama principal de un repositorio. Esto es muy poderoso porque, a diferencia de enviar listas de diferencias por correo, una solicitud de extracción es consciente de otra actividad en el repositorio y le dirá al propietario si la diferencia aún se aplicaría limpiamente. La solicitud de extracción permite que otros desarrolladores comenten y no se ve alterada por el tratamiento de los finales de línea, los espacios y las pestañas de los diferentes sistemas de correo electrónico. No es necesario que todos los cambios de una solicitud de extracción estén en el mismo repositorio; de hecho, normalmente no lo son. Una persona que realiza cambios normalmente se bifurca(es decir, hacer su propia copia de) un repositorio, trabajar en esa bifurcación, probar los cambios y luego enviar una solicitud de extracción al administrador del repositorio original. Ese administrador podría aceptar la solicitud de extracción para fusionar el código, ofrecer comentarios sobre cómo mejorar el código o rechazarlo por completo.
Codificación social. Estas características se suman a uno de los lemas de GitHub: codificación social . Los equipos o los desarrolladores individuales pueden trabajar juntos sin estar en la misma oficina o incluso en la misma organización. La codificación social era importante antes de la pandemia y, por supuesto, ahora es aún mayor.
Comportamiento. En GitHub, las acciones le permiten realizar una o más acciones relacionadas con el flujo de trabajo cuando se realizan confirmaciones. Una acción puede ser tan simple o compleja como necesite: desde algo tan simple pero importante como crear y ejecutar pruebas hasta crear una imagen de Docker e implementarla a escala con Kubernetes o alguna otra tecnología. Si ha iniciado sesión y está en la página principal de su propio repositorio, GitHub tiene una lista de las aproximadamente dos docenas de acciones listas para configurar disponibles en la
Como puede ver, hay muchas razones por las que el proyecto OpenJDK eligió Git y GitHub.
¿Por qué la mudanza y por qué ahora?
Antes de la mudanza de Mercurial, OpenJDK vivía en varios repositorios. Se decidió que sería mejor consolidarlo en un solo repositorio.
En el momento en que se planeó este movimiento por primera vez, en la era de Java 9, el JDK constaba de ocho repositorios diferentes. Para construir, un desarrollador tuvo que descargar los ocho repositorios en la estructura de directorio correcta. Sin embargo, en Mercurial, las confirmaciones que involucraban a más de un repositorio eran comunes, pero no había ningún mecanismo para hacer cumplir la atomicidad o la coherencia. Para citar de JEP 296: Consolide el bosque JDK en un solo repositorio , creado en 2016
La multiplicidad de repositorios presenta una barrera de entrada más grande de lo necesario para los nuevos desarrolladores y ha dado lugar a soluciones como el script “get source”.
La siguiente lista de documentos de proyecto y JEP completados proporciona información sobre las cuatro etapas principales de la consolidación y migración de GitHub:
- 2016: JEP 296: Consolidar el bosque JDK en un solo repositorio
- 2018: Proyecto Skara: Evaluar alternativas a Mercurial
- 2019: JEP 357: migración de Mercurial a Git
- 2019: JEP 369: migrar a GitHub
El equipo ha tenido un éxito admirable: el JDK ahora se construye a partir de un único repositorio.
Obteniendo el código fuente y compilando el OpenJDK
Obtén el código fuente. Suponiendo que ya tiene Git instalado, puede descargar el código. Tenga en cuenta que la base de código no es pequeña.
$ cd ~/git # or wherever you want the code
# Do not do this until you read the whole article
$ git clone https://github.com/openjdk/jdk
$ du -sh jdk
$ 1.7G jdk
$
Sí, la
Construya requisitos previos. Existe una larga lista de requisitos previos. Para UNIX y Linux, básicamente necesita un sistema moderno que funcione con un compilador (clang o gcc). Para macOS, necesita una versión actual del paquete de desarrollo Xcode de Apple .
Dado que los sistemas UNIX (incluidos BSD y macOS) y Linux han sido construidos en gran parte por desarrolladores de software independientes o de terceros y dependen del trabajo de ellos, estos sistemas tienden a tener más de los requisitos previos preinstalados o integrados en comparación con Microsoft Windows. plataformas. Por lo tanto, para construir en Windows se requiere más configuración. Consulte la documentación de compilación de OpenJDK .
Tu primera construcción. Mi sistema Mac de desarrollador ya tiene muchas herramientas, incluido el paquete completo de Xcode, por lo que pensé en intentarlo sin siquiera preocuparme por los requisitos previos. Para la primera compilación, simplemente verifiqué OpenJDK, escribí
$ git clone https://github.com/openjdk/jdk
$ cd jdk
$ bash configure
... tons of output ...
$ gnumake
... tons more output ...
Finished building target 'default (exploded-image)' in configuration 'macosx-x86_64-server-release'
$ ls build/macosx-x86_64-server-release/jdk
_optimize_image_exec.cmdline conf modules
_optimize_image_exec.log include release
_optimize_image_exec.marker lib
bin man
$ build/macosx-x86_64-server-release/jdk/bin/java --version
openjdk version "17-internal" 2021-09-14
OpenJDK Runtime Environment (build 17-internal+0-adhoc.ian.jdk)
OpenJDK 64-Bit Server VM (build 17-internal+0-adhoc.ian.jdk, mixed mode)
$ exit
¡La construcción funcionó!
No especifiqué qué versión de Java compilar, por lo que de manera predeterminada creé la última versión, Java 17, que está programada para disponibilidad general a partir del 14 de septiembre de 2021; por lo tanto, el sello de fecha está en el futuro y la palabra
Mi construcción tomó poco más de media hora en una Mac más antigua con un Intel Core i7 de doble núcleo (4 subprocesos) de 2,9 GHz con 16 GB de RAM y un disco duro de 2 TB con 600 GB de espacio libre.
Como se señaló en el documento de requisitos previos, el JDK no es un programa pequeño: construirlo funciona mejor con un montón de núcleos de CPU, un disco rápido y mucha RAM y espacio en disco. Mi sistema está un poco por debajo de las recomendaciones en el lado del disco, ya que se recomienda usar un disco de estado sólido (SSD). Sin embargo, mi máquina no tiene un SSD interno disponible para realizar pruebas. Un SSD externo conectado a través de USB 2.0 probablemente sería lento.
FUENTE: https://blogs.oracle.com/javamagazine/openjdk-mercurial-git-github