¿Por qué Ubuntu 14.04 se adhiere al(viejo) Eclipse 3.8 cuando sale 4.3?
eclipse-juno eclipse-kepler (2)
Ubuntu suele ser una distribución de vanguardia. Pero, ¿por qué se apega a una versión 2011 de Eclipse cuando estamos 4 años en el desarrollo 4.x ?
Ni siquiera es opcional y no se puede instalar desde los repositorios. Y tampoco es ''fácil'' desde una descarga. Por alguna razón, la implementación de referencia de Java SE 7, OpenJDK, no es suficiente, y usted necesita la versión de Oracle. ¿Por qué? Esto tampoco está disponible en los repositorios, y necesita algún repo de terceros extraño que no sea de confianza para eso o siga todo un capítulo sobre cómo instalarlo usted mismo .
Hubo problemas hace tres años. Cuando salió Juno 4.2 , tenía muchos problemas de rendimiento . El director de Eclipse, Mike Milinkovich, explains una de las razones es la falta de fondos. Por primera vez en un lanzamiento importante:
"La prueba de rendimiento se apagó porque el equipo de la plataforma Eclipse tiene un serio problema de recursos".
Por esa razón, los desarrolladores lanzaron la versión 3.8 no nombrada y no promocionada simultáneamente con 4.2 para cerrar la brecha de este (con suerte) problema temporal, y su popularidad causó una tendencia notable hacia abajo entre los desarrolladores. Como un desarrollador de Eclipse b3 mentioned :
"Me sorprendió la mejora del rendimiento después del cambio. La plataforma 3.8 es mucho MUCHO más rápida"
La versión 3.8 sigue siendo una alternativa popular a la rama 4.x entre los desarrolladores (pregunte a mis colegas o a Google), creo que principalmente debido a problemas (genuinos) de confianza. Pero el puente (léase: soporte para 3.8 ) se ha cerrado ahora que se lanzó 4.3 .
Sin embargo, los problemas principales (financiación y desarrolladores) no se han solucionado, como lo demuestra el gesto de Google de donar dinero a la Fundación Eclipse con la esperanza de que otras compañías hagan lo mismo. ¿Esto significa que 4.3 aún no está a la altura de los estándares 3.x ?
Esto no es un problema con un complemento o una función para un idioma específico, este es un problem dentro del núcleo de la plataforma. (Pero estoy usando WST con Javascript y plugins V8 para el desarrollo de PHP y Node en particular).
Este tampoco es un problema de plataforma específico. Existen quejas similares de los usuarios de Linux, Windows y OSX. (Pero estoy usando Linux (Mint 13).)
Por un lado, hay personas que le dicen al EOL que el 3.8 "prueba" que 4.3 está bien ahora. Por otro lado (ver comentarios):
"He retrocedido a 3.8 debido a bloqueos constantes en ubuntu con 4.3"
3.8 está lejos de tener problemas y no me importaría obtener una experiencia de desarrollo más fluida. Entonces, me pregunto, ¿por qué Eclipse 4 ''nos lo impide'' la gente que decide qué versiones de software son ''buenas para nosotros'' (también conocido como repositorio oficial)?
- lúcido (10.04 LTS)
- Eclipse 3.5.2-2
- preciso (12.04 LTS)
- Eclipse 3.7.2-1
- raring (13.04)
- Eclipse 3.8 .1-1
- descarado (13.10)
- Eclipse 3.8 .1-4
- confiable (14.04 LTS)
- Eclipse 3.8 .1-5.1
- utópico (14.10)
- Eclipse 3.8 .1-5.1
Actualización 2014-05-30: Acabo de probar Kepler (de nuevo) y todavía sufre fallas en la interfaz de usuario de la caja. P.ej:
Y no, cambiar el color de fondo de la barra de herramientas de la ventana inactiva en las preferencias no soluciona esto. (Incluso si lo fuera, esta sería una opción tonta por defecto).
Me gustaría saber, de alguien que no está predispuesto de manera positiva o negativa debido a su flujo de trabajo altamente especializado y modificado, preferiblemente de alguien con experiencia en el paquete de Ubuntu que mantiene el proceso para paquetes no triviales, por qué esta decisión es tomada por un equipo de profesionales que saben lo que están haciendo para la distribución de Linux más utilizada en el mercado?
Eclipse Juno fue lanzado el 2012-06-27 . El 2012-07-17 se informó un error relacionado con la capacidad de respuesta de la UI. Cuatro meses después, alrededor del 2012-11-14, se lanzó el primer patch al sitio de actualizaciones oficial.
Muchos usuarios, sin embargo, perdieron por completo el lanzamiento de los parches. Supongo que la información se ahogó en el FUD y otras noticias más importantes que se difundieron en ese momento. A fines de 2012 publiqué una respuesta sobre SO . Aparentemente, no fui el único para quien el parche solucionó este problema de rendimiento. El 22-02-2013 se lanzó Eclipse 4.2.2, que contenía el mismo parche, pero seguí recibiendo votaciones por mi respuesta en SO hasta junio.
Probablemente, el único hecho conocido entre los desarrolladores es que Eclipse tuvo serios problemas de rendimiento en algún momento. Sin embargo, el conocimiento sobre el alcance, la magnitud y la duración de estos problemas me parece una serie de conceptos erróneos comunes. Hubo un período de cuatro meses durante el cual fue una buena idea que muchos usuarios de Eclipse se quedaran con la rama 3.8. Digo "muchos" porque trabajé con 4.2.0 y 4.2.1 y estaba bien para mí. Subjetivamente, cambiar las pestañas era aproximadamente dos veces más lento y el IDE se congeló tal vez una vez al día durante un par de segundos. Para mis colegas, el problema era mucho más grave. Supongo que dependía de su configuración y de su flujo de trabajo, sin embargo, nunca tuve ganas de seguir investigando porque sabía que los desarrolladores de la plataforma estaban trabajando en los problemas, y había una buena alternativa, utilizando 3.8.
Un año y tres versiones de Eclpse más tarde, estos graves problemas de rendimiento aún están solucionados. Por supuesto, esto no significa que no haya más problemas de rendimiento. A partir de ahora, find informes de 1979 en el bugzilla Eclipse con la palabra clave "rendimiento". Esto no significa que Eclipse tiene muchos errores, pero solo que está muy bien documentado y abierto. Ya sea que esté o no afectado por alguno de estos problemas, nuevamente, depende de la configuración, los complementos que esté utilizando y su flujo de trabajo. Soy un desarrollador de Java, plug-in y EMF. Trabajo con espacios de trabajo medianos a grandes (~ 1M LoC) y Eclipse 4.3.1 es lo suficientemente rápido . La versión 3.8 no es una opción para mí porque, como dijo Eric, no recibirá todas las actualizaciones importantes. La gente aún continuará usándolo en el futuro. Muchos de ellos también continuarán usando Internet Explorer 5.5. Si prueba la rama 4.x y nota cualquier problema de rendimiento, informe de ello , pero especifique su configuración.
De la página oficial de Wiki :
Varios defectos de rendimiento importantes se han abordado en Juno SR2 (4.2.2). Los miembros de la comunidad han confirmado que estas correcciones solucionan sustancialmente los problemas de rendimiento con el editor y visualizan la apertura, el cierre y el cambio. Estas correcciones están ampliamente disponibles en Juno Service Release 2 (febrero de 2013). Todos los defectos también se resuelven en el flujo de lanzamiento de Kepler (junio de 2013).
La declaración "3.8 release fue lanzada específicamente como una alternativa más rápida y estable a 4.2" es claramente incorrecta; 3.x ha entrado en su "fin de vida" de mantenimiento y ciertamente no fue lanzado como una alternativa a 4.x.
Si bien la gente puede seguir utilizando la transmisión 3.x si satisface sus necesidades, reconozca que a medida que avancen los distintos proyectos habrá una divergencia significativa en las características disponibles entre las dos versiones ...