Bienvenido a Java Mexico

Java México es una comunidad de desarrolladores mexicanos en el lenguaje Java.

Este sitio es colaborativo, automáticamente al registrarte obtienes un Blog para compartir tus conocimientos o información acerca del lenguaje. Antes de publicar en tu blog o los foros por favor lee los lineamientos de publicación.

Para dudas y problemas con respecto al lenguaje Java puedes visitar los Foros de Discusión.

RTFS: Read The F.... Stacktrace

Tal vez hayas leido del acronimo RTFM, se utiliza en tipicamente (sobre todo en los foros de internet) cuando se le quiere indicar a alguien que para responder a su pregunta todo lo que tendria que haber hecho es leer el manual.

Bueno, quisiera proponerles un nuevo acronimo que me comento una amigo cuando estabamos platicando sobre los problemas a los que nos enfretamos todos los dias cuando estamos desarrollando: RTFS, la S es the StackTrace.

Cuando una aplicacion de Java se traba, en el 99% de los casos (a menos que le hayas logrado pegar a un bug de bajo nivel de la maquina virtual, cosa que ocurre muy pero muy rara vez)  la aplicacion te presentara a una StackTrace que te permitira saber no solamente en que linea ocurrio el problema, si no tambien que metodo(s) estaban llamando al metodo dentro del cual ocurrio el problema.

Digamos por ejemplo que  tenemos el metodo:

public static boolean areEqual(Object object1, Object object2) {
return object1.equals(object2);
}

Que ocurre cuando el parametro object1 es null? Pues una NullPointerException, que se nos presentara de la siguiente forma:

Exception in thread "main" java.lang.NullPointerException
    at JavaSnippet$1.equals(JavaSnippet.java:5)
    at JavaSnippet$1.run(JavaSnippet.java:11)
    at JavaSnippet.main(JavaSnippet.java:14)

Ahi podemos ver que el error ocurrio en la linea 5 del archivo “JavaSnippet.java”, cuando la linea 11  del mismo archivo fue invocada por la la linea 14, inclusive nos dice a que metodo pertenece cada linea de ejecucion!

Java 5 esta muriendo...

Java 5 esta muriendo... y "Java 2" debería estar muerto.

Hace un año publiqué una nota sobre el fin del ciclo de vida de la última versión de Java SE de lo que conocimos como "Java 2", y con ello se anunciaba la lenta muerte de dicha era (Java 2 esta muriendo). Pues bien, ahora le toca el turno a Java SE 5 (Java SE & Java SE for Business Support Road Map) por lo que, al menos en teoría e idealmente, todos deberíamos estar ya desarrollando sobre, o migrar a, Java SE 6.

No obstante a un año aún veo proyectos "Java 2", y en una encuesta en la que participé (lamentablemente no recuerdodo la url) hubo varios a los que no les importaba demasiado la llegada del fin soporte para Java 5, ya que estarían dispuestos a enrolarse al programa de soporte pagado, pero otros (en ese momento cerca del 40%) simplemente les daba igual y siguirían trabajando en Java 5 sin soporte... como lo dije, esto mismo estoy viendo incluso con "Java 2".

Entiendo que a muchas empresas les resulte "costoso" migrar una aplicación, sobre todo cuando es crítica y funciona "bien". Pero lo que no entiendo es como pueden ejecutar dicha aplicación que es crítica sobre algo que no tiene soporte, eso es simplemente riesgoso y por ende costoso. Pero eso si, el día que truene todo mundo tendrá la culpa menos ellos, los que se negaron a migrar... O será que la culpa es de Sun por crear versiones "robustas" y quererles dar fin tan pronto...

¿Que opinan ustedes del fin de ciclo de vida de Java 5 y "Java 2" y todas las aplicaciones, ahora "legacy", que dejaron...?

Comparación de Java Web Framework

Semanas atras en el blog Simple Thoughts se publicó una lista, sin ordenar, de los que según su autor son los 10 mejores Web Framework para Java, acompañada con cometarios de sus virtudes y defectos, pero sin mas ayuda que su opinión. De cualquier forma a continuación la listo:

El artículo completo se puede leer en: 10 Best Java Web Development Framework.

Un poco mejor estructurada fue la encuesta realizada por Kimberly McClintock acerca Web Framework (la mayoría para Java) a un grupo de “expertos”. La encuesta consistió básicamente en 5 preguntas:

  1. What’s the ’sweet spot’ of your project? For what type of projects should users strongly consider it?
  2. What type of scenarios does your project not fit into as well? Would you recommend another project in this scenario? If so, which one?
  3. Of the projects included here, which have you tried? Of those, which ones did you like or dislike, and why?
  4. What is the future of this project? What’s coming that will ease development?
  5. Are there myths about this project that you’d like to challenge?

Si bien los resultados de la encuesta tampoco califican numéricamente, si ofrece una matriz de comparativa con las distintas valoraciones, brindando al menos una herramienta que ayuda a la toma de decisiones.

Aplicación multi-modulo “Hola Mundo” con Maven

Hola amigos,

Aca un ejemplo sencillo de como utilizar maven para un proyecto multimodulo.

Aplicación multi-modulo “Hola Mundo” con Maven

Observación en el comportamiento de la sentencia SWITCH.

Hola a todos aquí al estar repasando mis notas me encontré con una curiosidad (Al menos para mi lo es) respecto al funcionamiento de la sentencia SWITCH que quisiera compartir con ustedes, la verdad, no sé si ya lo habrán notado, pero al menos estoy seguro que muchos no tienen ni idea de lo confuso que pudiera ser el funcionamiento de una sentencia SWITCH (Y refiriéndome más hacia las personas que aún dan sus primeros pasos en J2SE).

Si tenemos el siguiente código:

int x = 2;
switch (x) {
  case 2:  System.out.println("2");
  default: System.out.println("default");
  case 3: System.out.println("3");
  case 4: System.out.println("4");
}

El resultado es el siguiente:
2
default
3
4

Si tenemos ahora el siguiente código:

int x = 7;
switch (x) {
  case 2:  System.out.println("2");
  default: System.out.println("default");
  case 3: System.out.println("3");
  case 4: System.out.println("4");
}

El resultado es el siguiente:
default
3
4

multiprocesadores con ExecutorService

Que onda chavos, como estan? espero que bien...
Haciendo el analisis de una aplicacion me encontre con una duda un poco rara y puede que este divagando demasiado, pero se me hizo interesante.

Voy a tener N colas con activeMQ. Esto implica que tengo los listeners para atender cada mensaje que me llegue. Cada listener tiene que abrir un thread(los cuales tengo pensado manejarlos con el ExecutorService) y este realizar debe realizar su chamba.

El problema es este...
Se tendran N servidores con M procesadores cada uno.
Es Logico que debo tener un Listener en cada servidor( se me ocurre dejar que cada uno escuche una cola diferente)
Ahora... Cada listener debe estar escuchando y cada que llegue un mensaje lanzar un hilo que sera despachado por el ExecutorService

Pregunta 1)
Si el ExecutorService se lanza en un procesador... este puede decir que se utilicen los N procesadores restantes del server para asi balancear la carga de chamba??

Pregunta 2)
Si no lo hace... acaso debo manejar el manejo de concurrencia como se indica aquí

Los programadores de verdad no usan spring-jdbc?

Algunas veces me he visto en discusiones del tipo de "por que usar Spring-JDBC" en un proyecto, si al final de cuentas con JDBC solito es "mas facil" y no hay necesidad de estar leyendo y aprendiendo a usar Spring-JDBC.

Es importante recordar que a menudo, el tiempo para que uno se toma aprender algo nuevo, acaba compensadose con el tiempo ahorrado gracias al nuevo conocimiento adquirido (Aunque tengo que admitir, que a menudo resulta dificil saber de antemano que las cosas resultaran asi).

Veamos el caso por ejemplo, de manejar una conexion (con el statement y resultset respectivos) desde adentro de una aplicacion corriendo en Tomcat.
Cual creen ustedes que es el modo correcto de hacerlo (sin JdbcTemplate, o ConnectionCallback o ninguna de esas "complicaciones" de Spring-Jdbc)

Asi?:

Connection conn = null;
  Statement stmt = null;  // Or PreparedStatement if needed
  ResultSet rs = null;
  try {
    conn = ... get connection from connection pool ...
    stmt = conn.createStatement("select ...");
    rs = stmt.executeQuery();

10a. Reunión de la Comunidad!!

Hacemos la cordial invitación a todos los desarrolladores interesados, miembros de la comunidad, redes sociales y publico que le apasione el desarrollo de software a la 10a. Reunión de la comunidad que se llevará a cabo el día 31 de octubre a las 10:00 A.M., en donde presentaremos el siguiente Taller:

Hands-on Spring 3: The next generation

Impartido por Sergi Almar(@sergialmar) - http://sergialmar.wordpress.com

Descripción:
El taller pretende descubrir las nuevas funcionalidades de Spring 3
dando un previo repaso a lo tenemos hasta ahora con Spring 2.5. Se van
a cubrir aspectos como el nuevo Spring EL, el soporte para REST,configuración al estilo JavaConfig... Todo ello implementando una aplicación real que va a poner en práctica todo lo nuevo!

Acerca del ponente:
Sergi Almar es un ingeniero senior de software apasionado por Java /
JEE. Durante los últimos 4 años, ha estado trabajando en sistemas
desarrollados con Spring. Actualmente, invierte su tiempo impartiendo
cursos oficiales de Spring principalmente en España y latino América
como instructor certificado de SpringSource y desarrollando sus
diferentes proyectos personales.

Requerimientos para aprovechar al máximo el taller:

Los asistentes deberán llevar su propio equipo(laptop) con Java y SpringSource Tool Suite instalado.

Recordandoles que la entrada es totalmente gratuita y que habrá algunas sorpresas para los asistentes...

El lugar de la reunión es en:

Ave. San Lorenzo 1009 Piso 4. Col. del Valle, México, D.F.

El registro es importante que se realice en Coetus, ya que es requerido saber la cantidad de asistentes a la reunión.

La liga del registro es:

http://www.coetus.info/coetus/event/show/13

De antemano agradecemos su asistencia y participación...

Atentamente.

Staff de SH.org, grails.org.mx y JavaMexico.org

JDBC Drivers: Classpathhell en Tomcat, Solucion: Geronimo!?

Necesito mejorar la estabilidad de mi conexión a Oracle desde Java mediante JDBC, hasta el momento, todo apunta a que la solución es actualizar la versión de mi driver JDBC. Parece una solución fácil, si no fuera por el Classpathhell que habita dentro de Tomcat, el application server mas usado en el lugar donde trabajo.

Universal Connection Pool para Driver JDBC de Oracle

Al construir aplicaciones web en java, es muy importante manejar las conexiones a base de datos mediante connection pooling para hacer un uso adecuado de los recursos de la base de datos.

Tomcat cuenta con su propia implementacion de connection pooling que se puede aplicar a cualquier driver JDBC llamado DBCP, pero, desgraciadamente esta implentacion de pooling a menudo falla al cerrar las conexiones por lo que acaba desperdiciando recursos del servidor.

El Driver JDBC de Oracle cuenta con 2 modos de pooling que si bien son mas confiables a la hora de recuperar recursos tampoco estan libres de problemas:

Distribuir contenido