Los que lo encontraron y divulgaron fueron los de Apache, pues ya les pasó varias veces en Lucene y Solr. Supongo que les ocurre en sus pruebas así que podrías bajarte los fuentes del proyecto, ejecutar sus pruebas y ver cómo truenan en Java7 y no en Java6 (a menos que en Java6 habilites unas opciones de la JVM que por default están deshabilitadas y causan los mismos problemas).
>Abrir eclipse ( indigo ), ir a Help/Seach. Hacer una búsqueda y eclipse se cae.
Fuente:
Eclipse usa Lucene para las búsquedas.
Lo que me parece raro es que el desarrollador de Lucene explica unas condiciones bastante únicas para el bug y el otro tipo dice "Nomás denle buscar en Eclipse"
- El bug reside en una optimización de ciclos en la JVM, cuando las condiciones para continuar el ciclo son modificadas dentro del mismo ciclo.
- Esa optimización se activa cuando el ciclo realiza más de 10mil iteraciones y el JIT está activado (si corriste la JVM con -Xint entonces no ocurre)
Si tienes Eclipse abierto con un número razonable de proyectos, que contendrá un número algo grande de clases y recursos y demás, es muy probable que la búsqueda cause que alguno de los ciclos en los algoritmos de búsqueda de Lucene rebase las 10mil iteraciones, activando el bug.
Interesante, entonces el bug esta desde el java 6, pero la opcion de la jvm que lo puede activar esta deshabilitada por default, ahora con java 7 que viene habilitada se toparon con el problema.
Siendo objetivos, el bug no es de java 7 entonces, no hay que echarle tanta carrilla.
Siendo objetivos, el bug no es de java 7 entonces, no hay que echarle tanta carrilla.
Tu crees? yo digo que al reves, si existe desde Java 6 habria que hecharle mas carrilla, si fuera algo nuevo, por lo menos tendrian la excusa de "es que es nuevo y no lo habiamos probado lo suficiente", pero si existe desde Java 6... que excusa tienen? si dicen "es que 4 años no alcanzaron para detectar este bug" ciertamente no van a inspirar confianza en sus procesos de QA...
Simplemente imaginatelo usandolo tu de excusa para tu algun cliente: No se preocupe, este defecto que hace que su declaracion de impuestos salga equivocada no es nuevo, esta ahi desde hace años, la version anterior tambien tenia el problema...
Si. Estaba detectado aceptado y fue registrado como de baja prioridad ( que es básicamente como decir, cuando ya no haya bugs de alta prioridad lo arreglamos ) pero con el lanzamiento de Java 7 y el ruido que generó este bug ¿pues que crees? que ya subió de prioridad y lo van a arreglar en el primer update #diicen
No es para defender a QA de Oracle ni nada, pero si hay un montón de pendientes y una cantidad finita de recursos para resolverlos este tipo de cosas pasan.
Lo que yo sigo sin entender ( tampoco le he dedicado mucho tiempo, para ser sincero ) es porque el ingeniero de Lucene dice que se requieren megas y megas de datos y ciclos medio extremos para sacar el bug y otra persona dice que con un search en Eclipse sale, ¿ será que como dice ezamudio pasa cuando tienes un eclipse con muchos proyectos que a su vez tienen mucho código? ¿Es eso? Ahh, entonces si ya entendí.
Simplemente imaginatelo usandolo tu de excusa para tu algun cliente: No se preocupe, este defecto que hace que su declaracion de impuestos salga equivocada no es nuevo, esta ahi desde hace años, la version anterior tambien tenia el problema...
Si el problema se solucionara tan simple como agregar un parámetro extra en la ejecución del programa para la declaración de impuestos, entonces al cliente le da igual si esta el bug o no, mientras su declaración sea correcta y a tiempo.
Nopalin, lo siento pero no. Cuando le dices al cliente "este defecto hace que tu declaración de impuestos salga equivocada, lleva años en el software, pero no importa, agregando un parámetro extra se arregla" no hace que todo sea color de rosa.
El cliente te va a decir "OK, entonces a partir de ahora agregamos ese parámetro y listo, mis declaraciones saldrán bien. y qué hay de todas las que ya salieron mal? qué tal si te demando por todo el dinero que le debo al SAT por haber declarado mal, o por lo que pagué de más?"
El defecto que hace que cuando imprime facturas de menos de $20 pesos en la impresora aquella se salga movida toda la imagen está por corregirse, pero el resto de sus facturas está bien.
El problema ahora es que la nueva versión usa siempre la impresora aquella y se volvió de "no tan importante" a urgente repararse.
Por que todos acá usamos Java y a nadie ( que yo sepa ) le ha pasado esto antes.
Lo que si es que no nadie sensato va y hace el upgrade a producción de una versión que salió ayer, verdaaaaaad!!
Muchos de los clientes ni si quiera les interesa si usas patrones de diseño, o dejas un sistema escalable o si usas junits, él lo unico que quiere es que funcione.
Si vamos a comparar el ejemplo con mas detalle, en realidad es decirle al cliente: mire el sistema tiene un error, el error se sucita cuando usted genera facturas de arriba de los 10 millones de pesos (conocen en mexico mas empresas aparte de ICA que haga facturas tan grandes) pero no se preocupe, deje corrigo este ejecutable y listo, el problema ya no está y uste no lo volverá a ver no importa que haga. Pero aun asi es algo que tengo que atender y para la siguiente ya estará corregido - el cliente responde - ahh ok no hay problema, como quiera yo ni hago facturas tan grandes.
Desde un inicio yo me referia a que no era un bug de java 7, es decir, que el bug salió con programación realizada en versiones anteriores. En ningún momento dije que fuera algo bueno o que se deberia pasar por alto, solo dije que no se le deberia echar tanta carrilla, mejor deberían echarsela a java 6 o a la 5 o donde haya surgido el problema.
Submitted by wishmaster77 on Lun, 08/08/2011 - 11:37.
No sé, pero creo que Oracle no debió liberar Java 7 sin antes haber resuelto bugs de Java 6. Digo, ya llevábamos tiempo de retraso para "algo bueno" y que salgan con esto. En fin.
Por mi parte creo que una empresa cómo Oracle no puede exponerse a esto y menos cuando la comunidad Javalera no esta del todo contenta con el movimiento o transición de Sun a Oracle.
Mmhh estaría bien saber como
Mmhh estaría bien saber como reproducir el bug, como en se hizo con el problema del punto flotante que tiraba la máquina.
He visto quejas y comentarios sobre ese bug, pero no como reproducirlo ( no digo que no exista )
Si alguien encuentra como reproducirlo que pase el link o lo postee. De otra forma no pasa de "dicen que truena".
Solr y Lucene
Los que lo encontraron y divulgaron fueron los de Apache, pues ya les pasó varias veces en Lucene y Solr. Supongo que les ocurre en sus pruebas así que podrías bajarte los fuentes del proyecto, ejecutar sus pruebas y ver cómo truenan en Java7 y no en Java6 (a menos que en Java6 habilites unas opciones de la JVM que por default están deshabilitadas y causan los mismos problemas).
En SO hay una buena discusión de esto de boca de los devs que encontraron la bronca.
A poco es, tan simple como esto?
>Abrir eclipse ( indigo ), ir a Help/Seach. Hacer una búsqueda y eclipse se cae.
Fuente:
Eclipse usa Lucene para las búsquedas.
Lo que me parece raro es que el desarrollador de Lucene explica unas condiciones bastante únicas para el bug y el otro tipo dice "Nomás denle buscar en Eclipse"
Raro no?
únicas
Pues ni tan únicas. El resumen es así:
- El bug reside en una optimización de ciclos en la JVM, cuando las condiciones para continuar el ciclo son modificadas dentro del mismo ciclo.
- Esa optimización se activa cuando el ciclo realiza más de 10mil iteraciones y el JIT está activado (si corriste la JVM con -Xint entonces no ocurre)
Si tienes Eclipse abierto con un número razonable de proyectos, que contendrá un número algo grande de clases y recursos y demás, es muy probable que la búsqueda cause que alguno de los ciclos en los algoritmos de búsqueda de Lucene rebase las 10mil iteraciones, activando el bug.
Interesante, entonces el bug
Interesante, entonces el bug esta desde el java 6, pero la opcion de la jvm que lo puede activar esta deshabilitada por default, ahora con java 7 que viene habilitada se toparon con el problema.
Siendo objetivos, el bug no es de java 7 entonces, no hay que echarle tanta carrilla.
sobres
Bug Ciclos: Desde Java 6: Aun peor para reputacion de area de QA
Tu crees? yo digo que al reves, si existe desde Java 6 habria que hecharle mas carrilla, si fuera algo nuevo, por lo menos tendrian la excusa de "es que es nuevo y no lo habiamos probado lo suficiente", pero si existe desde Java 6... que excusa tienen? si dicen "es que 4 años no alcanzaron para detectar este bug" ciertamente no van a inspirar confianza en sus procesos de QA...
Simplemente imaginatelo usandolo tu de excusa para tu algun cliente: No se preocupe, este defecto que hace que su declaracion de impuestos salga equivocada no es nuevo, esta ahi desde hace años, la version anterior tambien tenia el problema...
Si. Estaba detectado aceptado
Si. Estaba detectado aceptado y fue registrado como de baja prioridad ( que es básicamente como decir, cuando ya no haya bugs de alta prioridad lo arreglamos ) pero con el lanzamiento de Java 7 y el ruido que generó este bug ¿pues que crees? que ya subió de prioridad y lo van a arreglar en el primer update #diicen
No es para defender a QA de Oracle ni nada, pero si hay un montón de pendientes y una cantidad finita de recursos para resolverlos este tipo de cosas pasan.
Lo que yo sigo sin entender ( tampoco le he dedicado mucho tiempo, para ser sincero ) es porque el ingeniero de Lucene dice que se requieren megas y megas de datos y ciclos medio extremos para sacar el bug y otra persona dice que con un search en Eclipse sale, ¿ será que como dice ezamudio pasa cuando tienes un eclipse con muchos proyectos que a su vez tienen mucho código? ¿Es eso? Ahh, entonces si ya entendí.
Simplemente imaginatelo
Simplemente imaginatelo usandolo tu de excusa para tu algun cliente: No se preocupe, este defecto que hace que su declaracion de impuestos salga equivocada no es nuevo, esta ahi desde hace años, la version anterior tambien tenia el problema...
Si el problema se solucionara tan simple como agregar un parámetro extra en la ejecución del programa para la declaración de impuestos, entonces al cliente le da igual si esta el bug o no, mientras su declaración sea correcta y a tiempo.
sobres
no
Nopalin, lo siento pero no. Cuando le dices al cliente "este defecto hace que tu declaración de impuestos salga equivocada, lleva años en el software, pero no importa, agregando un parámetro extra se arregla" no hace que todo sea color de rosa.
El cliente te va a decir "OK, entonces a partir de ahora agregamos ese parámetro y listo, mis declaraciones saldrán bien. y qué hay de todas las que ya salieron mal? qué tal si te demando por todo el dinero que le debo al SAT por haber declarado mal, o por lo que pagué de más?"
Aunque en realidad es más del
Aunque en realidad es más del tipo:
El defecto que hace que cuando imprime facturas de menos de $20 pesos en la impresora aquella se salga movida toda la imagen está por corregirse, pero el resto de sus facturas está bien.
El problema ahora es que la nueva versión usa siempre la impresora aquella y se volvió de "no tan importante" a urgente repararse.
Por que todos acá usamos Java y a nadie ( que yo sepa ) le ha pasado esto antes.
Lo que si es que no nadie sensato va y hace el upgrade a producción de una versión que salió ayer, verdaaaaaad!!
Muchos de los clientes ni si
Muchos de los clientes ni si quiera les interesa si usas patrones de diseño, o dejas un sistema escalable o si usas junits, él lo unico que quiere es que funcione.
Si vamos a comparar el ejemplo con mas detalle, en realidad es decirle al cliente: mire el sistema tiene un error, el error se sucita cuando usted genera facturas de arriba de los 10 millones de pesos (conocen en mexico mas empresas aparte de ICA que haga facturas tan grandes) pero no se preocupe, deje corrigo este ejecutable y listo, el problema ya no está y uste no lo volverá a ver no importa que haga. Pero aun asi es algo que tengo que atender y para la siguiente ya estará corregido - el cliente responde - ahh ok no hay problema, como quiera yo ni hago facturas tan grandes.
Desde un inicio yo me referia a que no era un bug de java 7, es decir, que el bug salió con programación realizada en versiones anteriores. En ningún momento dije que fuera algo bueno o que se deberia pasar por alto, solo dije que no se le deberia echar tanta carrilla, mejor deberían echarsela a java 6 o a la 5 o donde haya surgido el problema.
sobres
Re: Muchos de los clientes ni si
No sé, pero creo que Oracle no debió liberar Java 7 sin antes haber resuelto bugs de Java 6. Digo, ya llevábamos tiempo de retraso para "algo bueno" y que salgan con esto. En fin.
Por mi parte creo que una empresa cómo Oracle no puede exponerse a esto y menos cuando la comunidad Javalera no esta del todo contenta con el movimiento o transición de Sun a Oracle.