Categoría: Planet

Por Publicado el Publicado en Planet


Zulu

Although my first development box at this time is an Apple PC, I’m pretty comfortable with Open Source software due technical and security benefits.

In this line, I’ve been a user of Zulu JVM on my Windows+Java deployments, basically because Zulu offers a zero-problems deployment of OpenJDK, being at this time the only Open Source and production ready JVM available for Windows (in Linux you also have OpenJDK distro builds or IcedTea).

As my previous experiences in Windows and considering that Zulu is at some point a supported compilation of OpenJDK (basis for HotSpot aka OracleJDK), using Zulu in OSX has been so far a painless solution.

Compared to HotSpot you have an additional security «feature» only available at Server JRE, the lack of the infamous web plugin, however you will lose Java Mission Control because is a closed source tool.

If you are interested in formal benchmarks this guide (by Zulu creators BTW) could be helpful: http://www.azulsystems.com/sites/default/files/images/Azul_Zulu_Hotspot_Infographic_d2_v2.pdf

In a more «day by day» test, no matter if you are using Eclipse



Wildfly



Or maybe Vuze



Zulu simply works.

¿Why should you consider Zulu?

  • Is based on OpenJDK Open Source project
  • You obtain nearly the same performance of HotSpot
  • You can bundle it on your apps (like Microsoft in Azure)

¿Why avoid Zulu?

  • If you need Java Mission Control
  • If you need the Java Browser Plugin, pretty dead BTW
Leer más ›

Por Publicado el Publicado en Planet Etiquetado con , , , , , , ,

El dilema

Cuando se están diseñando aplicaciones Java que serán desplegadas en un Servlet Container, Web Profile o full JavaEE Application server, se puede llegar a la necesidad de utilizar dependencias (.jars) que no son parte de la especificación estandard y por consiguiente entrar en el dilema: 
  1. Que el empaquetado (.war) incluya dicha(s) dependencia(s). Comúnmente utilizando un sistema gestor de dependencias como por ejemplo maven y su scope: compile.
  2. Que la(s) dependencia(s) se encuentre(n) en el container donde la aplicación será desplegada. En maven utilizando el scope: provided para evitar que el gestor de dependencia incluya los jars dentro del empaquetado.

Seleccionando una solución

Seleccionando para el resto de este artículo la opción número 2 y tomando como ejemplo el Servlet Container más famoso de mundo, Apache Tomcat, a continuación listo algunas de las ventajas y desventajas de dicho enfoque:

Ventajas:
  • Optimización de espacio de disco duro en el sistema host de la instalación de Tomcat
  • Estandarización en los ambientes de deployment
  • Empaquetados (.war) con menor tamaño que contribuyen a reducir tiempos en pipelines de Integración y Entrega continua.
  • Útil cuando lo que se promueve entre ambientes es el artefacto (.war) y no el código fuente.
Desventajas:
  • La instalación de tomcat empieza a convertirse en una personalizada y no estándar.
  • Requiere que tanto los ambientes locales de desarrollo como los diferentes ambientes de producción estén sincronizados con la última versión personalizada de Tomcat.
  • Cambios en una dependencia es replicable para todas las aplicaciones desplegadas en la instancia de Tomcat y si estas poseen diferentes arquitecturas se tendrá que tomar una decisión de no realizar el cambio o desplegar las aplicaciones incompatibles en otra instancia de tomcat. el resultado final será una nueva instancia personalizada.

Class Loaders 101 en apache Tomcat

Acorde a la documentación oficial tomcat provee 3 jerarquías de Class Loaders:
  • Bootstrap: Carga las clases básicas de ejecución provistas en los jars de la JRE que utiliza la instancia de Tomcat.
  • System: Se inicializa a partir del contenido de la variable de ambiente classpath.
  • Common: Carga clases adicionales que normalmente se encuentran en jars ubicados en: $CATALINA_HOME/lib
  • Webapp: Para cada aplicación desplegada tomcat crea un class loader que carga clases ubicadas en /WEB-INF/classes  y clases dentro de jars ubicados en /WEB-INF/lib
La figura 1 describe la jerarquía:
      Bootstrap
          |
       System   
          |
       Common
       /     
  Webapp1   Webapp2 ...
Figura 1.
La Figura 2 describe el orden por default de class loaders que una aplicación desplegada enTomcat 9 utiliza en orden ascendente:
                 Bootstrap (1)
                      |
                    System (4)  
                      |
                    Common (5)
                      |    
                   WebappX
                 /         
/WEB-INF/classes (2)     /WEB-INF/lib/*.jar (3)
Figura 2.

Iniciando a implementar la solución

Un primer enfoque que en muchos tutoriales realizan con los JDBC Drivers es posicionar los jars en la carpeta: $CATALINA_HOME/lib. Esto hará que el class loader Common incluya dichas dependencias en el orden y jerarquías especificados en las figura 2.

Optimizando la solución

Por simple lógica se pude observar en la Figura 1. que tanto System como Common  ponen a disposición de las aplicaciones las clases que cada uno carga, sin embargo la recomendación es que no utilicemos Common (por ende la ubicación $CATALINA_HOME/lib) para exponer clases de jars que queremos compartir entre las aplicaciones desplegadas en la instancia de Tomcat.
Un enfoque recomendado es posicionar las clases y/o dependencias necesarias en los directorios:
$CATALINA_HOME/shared/lib y
$CATALINA_HOME/shared/classes

Quedando como último paso indicarle a tomcat que tome en consideración las rutas anteriormente descritas para que este nuevo class loader (shared) sea tomando en consideración luego de common. Para realizar esto debemos de editar el archivo: 
$CATALINA_HOME/conf/catalina.properties
y dentro del archivo especificar las rutas en:
shared.loader=»${catalina.base}/shared/classes»,»${catalina.base}/shared/lib/*.jar»
Leer más ›

Por Publicado el Publicado en Planet Etiquetado con , , , , , , , ,

OTN Speaker Bureau

I’m glad to inform you that I was accepted to be part of the Oracle Technology Network Speaker Bureau :). 
The Speaker Bureau is a new place where you can find, connect and request topnotch speakers from the IT Industry around the world including Oracle employees and community members such as Oracle ACEs, Java Champions, and other community evangelists. 
This resource is a excellent way in which conference planners, event organizers, journalists,  Java and Oracle communities and the general public can find and request expert speakers according with area of expertise, geographic location, languages spoken, certifications, and other criteria.

My Bureau profile page:
https://community.oracle.com/people/cesarHernandezGT?customTheme=osb

OTN Speaker Bureau home page
https://community.oracle.com/community/otn-speaker-bureau

[Español]
Me alegra informarles que fui aceptado para formar parte de laOracle Technology Network Speaker Bureau :).
Speaker Bureau es un nuevo lugar donde se puede encontrar, conectar y solicitar conferencistas de primera categoría en la industria de TI al rededor del mundo. Incluye a los empleados de Oracle y miembros de la comunidad, tales como Oracle ACE, Java Champions, y otros evangelistas de la comunidad Oracle y Java.
Este recurso es una excelente manera en la que los planificadores de conferencias, organizadores de eventos, periodistas, comunidades de Java y Oracle así como el público en general pueden encontrar y solicitar conferencistas expertos de acuerdo con el área de especialización, ubicación geográfica, idioma, certificaciones y otros criterios.
Leer más ›

Por Publicado el Publicado en Planet


Java 20

For me 2015 hacktivism is officially closed, this year I had the opportunity to attend my first Java One and met some of my development heroes, folks from another JUGs, being trapped at Patricia’s hurricane (no kidding), and bring a huge amount of Java t-shirts to Guatemala. I must say thanks to the people that made this trip possible, special acknowledgments to Nichole Scott from Oracle, my peers at Nabenik that gratefully sponsored my trip and the Guatemala Java User Group for allowing me to take advantage of the Java One ticket :-D.

I think that every techie has a list of conferences to attend before die, as 2015 my top five is:

  • JavaOne (2015 finally)
  • Gentoo Miniconf
  • OSCON
  • Forum Internacional de Sofware Livre – FISL (2013 as a speaker yey!)
  • Convención de Informatica Guatemala (2005 – now dead, but it made the list for nostalgia)

Although I had some health issues due stress, Java One and San Francisco were lifetime experiences. As each conference I’ve attended, it has its goods and bads but in general you can feel a strong sense of community between attendants, from Pivotal to Red Hat (and Microsoft), from the peer that shares a beer with you and turns out to be a Java Champion to the people that speaks another languages with you, Java One is about community making awesome things in IT. Programming languages aren’t eternal but I can state that the differential factor that raised 20-year languages like Java and JavaScript among the others is the community.

Random photos:

In a different scale but in the same sense of community, the Guatemala Java User Group held its yearly conference Java Day Guatemala.

I’ve been involved directly in the organization of 2 Java Days and spoken in three. As I said in our keynote, for me GuateJUG has been the most successful user group where I’ve participated. Characterized by pragmatism, openness and community structure since its inception, GuateJUG became one of the strongest user groups in Central America, the integration between industry, academia, Open Source communities, Free Software communities and HR people looking for the next generation of developers is unique.

As a special occasion we held a traditional birthday celebration, including birthday cake and mexican piñatas. It was great to share words with some old friends and meet new IT enthusiasts, as a matter of fact we also sang «Happy birthday Java and happy birthday GuateJUG».

Video and some more random photos:

I hope to see you the next year in Java One and Java Day :-).

Leer más ›