java - plugin - Eclipse webtools project(WTP) y su rendimiento/calidad

java ee eclipse marketplace

Question

Nuestra compañía está usando eclipse desde hace varios años (estamos usando WTP desde la versión 0.7)

Actualmente estoy evaluando eclipse 3.6.2 con WTP 3.2.3 que debería reemplazar eclipse 3.4.2 con WTP 3.0.4 como nuestro principal IDE.

Y debo decir que una vez más estoy bastante decepcionado con las preocupaciones sobre el rendimiento:
WTP 3.2.3 parece ser mucho más lento que 3.0.4.
De hecho, realmente me estoy preguntando por qué WTP se vuelve más lenta con cada lanzamiento.

Una de nuestras aplicaciones (proyecto web dinámico) contiene aproximadamente 4000 clases de Java y 700 fragmentos de jps / jsp . Solo necesitamos la funcionalidad básica de WTP para desarrollar jsps, xmls y xsd. No necesitamos funciones de alta sofisticación como Dali (¿deberían las herramientas de JPA estar realmente cubiertas por un proyecto de herramientas web ?), Libra o un editor visual de xml en primer lugar.

Otro punto interesante es que WTP parece ralentizar todo el IDE . SWT no responde por una fracción de segundos, el uso de la CPU es muy alto (especialmente después de una compilación realizada; si observas los trabajos del sistema, varios indexadores jsp / javascript están trabajando durante algunos minutos, incluso si todos los validadores de compilación de WTP) han sido deshabilitados), la apertura de nuevos archivos es más lenta, navega por el proyecto, etc.

Esto se puede ver especialmente en máquinas más antiguas que solo contienen una sola CPU central.

Lo peor es que tengo la sensación de que al equipo de desarrollo WTP no le importa mucho el rendimiento (por ejemplo, echa un vistazo a la página http://wiki.eclipse.org/WTP_Performance_Tests - la última actualización tuvo lugar en 2008).

Los informes de errores y las publicaciones del grupo de noticias relacionadas con el rendimiento de las funciones básicas (por ejemplo, edición / validación de jsp) a menudo se ignoran o cierran después de un tiempo, algunos ejemplos: here , here y aquí .

Quo vadis, WTP?

Por favor no me malinterpreten:

No quiero culpar a WTP.
De hecho, creo que WTP es un buen proyecto de código abierto desarrollado por un equipo talentoso.
Pero obviamente el proyecto tiene un problema con su garantía de calidad , especialmente en términos de rendimiento que afecta la usabilidad y la aceptación del usuario.

Solo quiero señalar que el equipo debe centrarse en las cosas que son esenciales para la mayoría de los usuarios en primer lugar y luego trabajar en la implementación de características súper-duper.

Mis preguntas

• ¿Cuáles son sus experiencias con WTP, especialmente las versiones más recientes?
• ¿Puedes confirmar o refutar mis observaciones?
• ¿Hay mejores alternativas?
• ¿Cambiaste de o a WTP y por qué?
• ¿Tiene algunas mejores prácticas para acelerarlo, especialmente para el tamaño medio-alto como el nuestro?

ACTUALIZAR

Me gustaría hacer una actualización de esta pregunta para reflejar las respuestas actuales y resumir los resultados actuales:

• Muchos usuarios se quejan más o menos de los mismos problemas, así que veo esos problemas como confirmados.
  Por cierto, esta pregunta también se menciona en una publicación de noticias en theserverside.com con comentarios adicionales.

• El responsable del proyecto de WTP, nitind, hizo una publicación destacada sobre la situación actual de WTP, que me gusta citar:
  "El hecho simple es que no pasamos mucho tiempo en las pruebas de rendimiento porque no tenemos recursos para hacerlo".
  "Por supuesto que nos gustaría ser proactivos en lugar de reactivos, pero tendemos a dedicar primero nuestro tiempo a los problemas funcionales".
  

Entonces, esta pregunta se convierte un poco en una especie de carta abierta de la comunidad al equipo de WTP:

Dear WTP team,

it''s obvious that WTP is suffering from major quality/performance issues 
which you try to play down or to ignore.
Please invest some time to improve the current situation 
at the cost of new features and do everything what''s required 
to solve the current problems.
E.g. revive the performance team, do some regression tests between 
previous releases or ask the community for (precise defined) help.

I am sure that they are enough people willing and able to help here.

If you like, do some kind of poll to get a feeling what should be 
the most important scopes of future''s WTP releases.

Please, please, listen to your community.

Answer 1

Con mucho, la mejor manera de acelerar mis proyectos ha sido precompilar el código que no estoy usando actualmente. Tenemos alrededor de 20 proyectos que conforman nuestro sistema y cuando trabajamos en un problema específico, solo estoy tocando un subconjunto específico de esos archivos java. Compilar la mayor parte del código que no voy a tocar y tirarlo en algunos .jar, y luego usarlo como fuente en lugar de incluir los proyectos, ha demostrado que acelera bastante las cosas. Me imagino que te ayudará si tienes 4k + archivos. Cada proyecto solo tiene un pequeño build.xml que lo incluirá en un jar.

En cuanto a la lentitud insensible a la mente en la edición JSP. Tengo los mismos problemas, es tan lento. No tengo muchos más de 100 archivos jsp, pero tengo los mismos problemas que tú. Mi solución ha sido simplemente tirar dinero en hardware, lo cual debo admitir que disfruto haciendo: P.

Answer 2

Desactivé el editor JTP de WTP por las razones que mencionaste anteriormente: solo necesita demasiados recursos. Algunas cosas más que debes considerar:

1. Edite JSP en el editor de HTML normal. Eso significa que no obtienes la finalización del código, lo cual es algo bueno . OMI, mezclar Java y HTML es un error en primer lugar y un editor no puede arreglar eso. Coloque todo el código Java en beans auxiliares (que luego puede probar fácilmente) y acceda a los beans desde JSP. Esto debería eliminar el 99% de todas las etiquetas <% %> %% <% %> y resolver la mayoría de sus problemas.

2. Considere usar Spring para poder construir beans más complejos e inyectarlos en sus JSP usando estos patrones:

   • Cómo inyectar beans de primavera en un jsp 2.0 SimpleTag?

   • Use SpringBeanAutowiringSupport:

     <%!
         @Autowired
         private Bean bean;
     
         public void jspInit() {
             SpringBeanAutowiringSupport
             .processInjectionBasedOnServletContext( 
                 this, getServletContext()
             );
         }
     %>

3. Pruebe con una máquina virtual diferente. Los editores de WTP crean grandes cantidades de objetos y ahora todas las máquinas virtuales (implementaciones de GC) pueden manejar eso igualmente bien. Si usa Java de Sun, pruebe JRockit o IBMs J9 . Juega también con la configuración del GC. Aumentar la RAM no ayudará porque si tienes problemas con el GC, más memoria RAM por lo general lo empeora (ya que el GC tendrá que procesar más datos).

4. Precompila la mayor cantidad de código posible. No necesita 4.000 clases abiertas en todo momento en su espacio de trabajo. Corta tu gran proyecto en trozos manejables.

5. Reemplace las JSP con servlets Java simples y use bibliotecas de renderizado HTML como rendersnake o use un lenguaje de programación que se reproduce mejor con HTML (como Groovy ).

6. Obtenga un hardware decente. Una nueva PC con un núcleo cuádruple y 8 GB de RAM cuesta $ 1000. Si ahorra diez minutos todos los días, la inversión se pagará en 50 días (a razón de 1 persona cuesta $ 1000 / día en total).

7. Prueba MyEclipse que tiene editores web mucho mejores. El editor JSP es mejor que WTP (la finalización del código funciona la mayor parte del tiempo, por ejemplo), pero todavía es lento.

Answer 3

He visto efectos similares, aquí hay una solución que podría ser adecuada en algunos entornos de proyectos ...

Para garantizar un entorno de proyecto de Eclipse Web rápido y responsable, considere esto:

1. Utilice Eclipse IDE para desarrolladores de Java
   • La versión 98MB es más delgada que la versión EE de 200MB
   • desde General / Inicio y Apagado, deshabilite todo menos "Interfaz de usuario de Eclipse"
   • de la Validación, deshabilite los validadores que no necesita
   • esto probablemente previene algunos problemas de rendimiento (YMMW)
2. Usar embarcadero
   • no necesita WTP ni ningún otro complemento, es puro Java
   • como Tomcat, pero muy rápido y simple de instalar en cualquier IDE / entorno
   • incrustar directamente en sus archivos de proyecto, configurar una vez para cada desarrollador
   • funciona en cualquier IDE (Eclipse, IDEA, JDeveloper ..)
   • Inicie Servlet Container con "Debug As" / "Run As"
   • cierre Servlet Container haciendo clic en el cuadro rojo en la consola Eclipse
   • La consola IDE, la depuración y el reemplazo del código de acceso y JRebel funciona bien

Resultado: Eclipse rápido y sensible en comparación con muchas otras instalaciones de Eclipse que usan la versión Eclipse EE con cosas de WTP.

¿Por qué? Es posible que alguna característica o complemento de Eclipse contenga errores o simplemente utilice recursos de una manera incorrecta, lo que hace que la IU de Eclipse sea lenta.

El EE Eclipse que no es Java es lo suficientemente bueno incluso para muchos entornos de proyectos Java EE, todo depende de su arquitectura y de las herramientas que esté utilizando.

Aquí hay un tutorial rápido para comenzar en caso de que desee probar Jetty Servlet Container con Eclipse. Consulte https://vaadin.com/web/jani/home/-/blogs/vaadin-for-everyone-how-to-get-started . Descargue VaadinProjectForAnyIDE.zip, es un proyecto de Eclipse. Simplemente ignore las cosas de Vaadin y reemplace HelloWorldApplication.java con su propio servlet y edite web.xml en consecuencia.

Una cosa más. Con la versión Eclipse EE, es posible que también desee probar el servidor de vista previa J2EE que en realidad está incrustado en el paquete Eclipse. Sin embargo, esto también usa el mecanismo WTP.

Answer 4

No pude comentar, así que simplemente incluiré mi comentario en esta respuesta.

¿Has intentado subir la asignación de memoria de Eclipse, sé que solía bloquearse todo el tiempo cuando lo usé en Mac OS X hace un tiempo. Hay un archivo de configuración que tiene la asignación de RAM base, una vez que modifiqué ese archivo y le dí 128 megabytes de memoria extra se comportó mejor. No estoy seguro si esto afectará a WTP, estoy comentando más en lo que respecta a la aplicación Eclipse núcleo en sí.

Answer 5

No sé a quién culpar: WTP o JBoss Tools. El hecho es que, mientras trabajo con GWT (mínimo JSP), fui por el camino opuesto: ¡Sin WTP en absoluto! Ahora estoy usando Eclipse simple para Java, y uso una configuración de ejecución para implementar (invocando a ANT de manera programática) y arranco el servidor, ¡y nunca volví la vista atrás! Eclipse solía tomar ~ 1.5GB y se bloqueaba varias veces. Ahora, se encuentra en ~ 800MB, y todo el entorno se volvió más estable.

Answer 6

Para responder a la siguiente pregunta: ¿Tiene algunas mejores prácticas para acelerarlo, especialmente para el tamaño medio-alto como el nuestro?

Desactivar la validación y la construcción automática después de guardar archivos es un buen comienzo para aumentar el rendimiento.

Answer 7

Para responder, soy el líder de los proyectos que proporcionan la funcionalidad de edición de fuente JSP, XML y JavaScript en WTP. El simple hecho es que no pasamos mucho tiempo en las pruebas de rendimiento porque no tenemos recursos para hacerlo. Por supuesto, nos gustaría ser proactivos en lugar de reactivos, pero tendemos a dedicar primero nuestro tiempo a los problemas funcionales. Tenemos un producto adoptante que ejecuta pruebas de regresión de rendimiento regularmente, pero espero que las pruebas se ejecuten en máquinas de núcleo múltiple por ahora, y no hemos tenido ninguna nueva señal de alerta roja durante un tiempo.

De los 3 errores a los que se vinculó, 2 preceden a la versión 3.0.4 a la que alaba y el tercero es un problema de rendimiento de formateo (desde que se abordó) o uno con validación tipo-específica para archivos XML (la fijación de los cuales desencadenó una fuga de memoria en Xerces, iirc, de ahí que no lo pusimos en ese momento). Si tiene proyectos concretos que puede adjuntar a un error y decir "hacer X es más lento en 3,2 por cantidad Y", haremos lo que podamos para descubrir dónde hay una regresión.

En cuanto a los indexadores, al menos deberían completarse. La información en disco que está almacenada ha cambiado entre las versiones de WTP, y esos archivos deben reprocesarse para que se incluyan de nuevo en las operaciones de refactorización de búsqueda y (cuando se implementen). Una vez que se completa la indexación inicial, debe actuar de forma incremental y ser prácticamente imperceptible. Un cambio arquitectónico con el que puede encontrarse es que, para las JSP, todo el espacio de trabajo debe indexarse ​​en una única sesión de banco de trabajo para que ese índice se considere "actualizado". Cerrar Eclipse por frustración solo prolongará el impacto de ese reprocesamiento.

Parece que la instalación estándar de su empresa incluye la totalidad de WTP en lugar de distribuir su propia distribución personalizada. Le recomiendo que revise la página de preferencias de inicio y cierre y apague el inicio anticipado de cualquier funcionalidad que no esté interesado en utilizar. Nada de lo que haya mencionado interés hace uso de esa instalación, pero hay otras áreas de WTP y la Plataforma que lo hacen. Todo lo que no esté interesado en validar es el juego limpio en la página de preferencias de Validación , así como la configuración para validar fragmentos JSP de forma predeterminada en la página de preferencias Web / Archivos JS / Validación .

Answer 8

Si necesitas barebone Java EE, entonces estás mejor con Netbeans, si necesitas todo pero solo trabajas, estás mejor con IDEA. Es tan simple como eso.

Answer 9

También creo que la estabilidad y el rendimiento de Eclipse / WTP son algo alarmantes. Estoy usando Eclipse desde mediados de 2003 y he estado probando WTP desde sus primeros lanzamientos.

Al principio, la calidad era abismal, pero para una versión 0.x no podía quejarme, por supuesto. Mientras esperaba que madurara la WTP, utilicé MyEclipse, que estaba bien, pero también tenía sus fallas (y al estar basado parcialmente en WTP, heredó parte de WTP).

Cuando MyEclipse se hizo más pesado y más pesado, más lento y más lento y tuvimos varios problemas de estabilidad, cambiamos a ''WTP puro''. Todo lo que estábamos usando era realmente el editor y el implementador JSP / JSF básico.

Como WTP no realiza una implementación incremental (al menos no para el tiempo de ejecución del servidor JBoss), agregamos el tiempo de ejecución del servidor por separado de las herramientas de JBoss. Cuando adoptamos Facelets, también cambiamos al editor de las herramientas de JBoss.

Sin embargo, nos encontramos con muchos problemas que también tuvimos con MyEclipse. Hay desaceleraciones inexplicables, pero mucho peores son varios problemas de estabilidad. Hay muchas excepciones y bloqueos torpes. Un típico archivo .log en muchas estaciones de trabajo diferentes que examiné está repleto de excepciones. Una pequeña selección de las últimas 10 excepciones en mi registro:

1.

java.lang.NullPointerException
        at org.eclipse.jst.jsp.core.internal.validation.JSPActionValidator.isElIgnored(JSPActionValidator.java:147)

2.

java.lang.RuntimeException
        at org.eclipse.jface.viewers.ColumnViewer.checkBusy(ColumnViewer.java:763)

3.

java.lang.ArrayIndexOutOfBoundsException: 38
        at org.eclipse.debug.internal.ui.viewers.model.FilterTransform$Node.addFilter(FilterTransform.java:67)

4.

org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet 302111.
        at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:171)

5.

java.lang.NullPointerException
        at org.eclipse.jst.jsf.facelet.core.internal.cm.ElementCMAdapter.getLength(ElementCMAdapter.java:109)

6.

Caused by: java.lang.NullPointerException
        at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.WebappConfiguration.getConfigFilesFromContextParam(WebappConfiguration.java:184)

7.

org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature ''span'' not found. (file:///mysystem/Eclipse.app/Contents/MacOS/com
/sun/faces/metadata/taglib/facelets_jsf_core.taglib.xml, 453, 52)
        at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
        ...
        at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.TagModelLoader.loadFromInputStream(TagModelLoader.java:100)

8.

java.lang.NullPointerException: No IModelProvider exists for project P/my_project of version: Utility Module
            at org.eclipse.jst.j2ee.model.ModelProviderManager.getModelProvider(ModelProviderManager.java:101

9.

 java.lang.NullPointerException
            at org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory.clearCache(J2EEDeployableFactory.java:238)

10.

org.eclipse.jst.jee.model.internal.mergers.ModelException: java.util.ConcurrentModificationException
        at org.eclipse.jst.jee.model.internal.mergers.EjbJarMerger.process(EjbJarMerger.java:79)

Tenga en cuenta que estos son solo los últimos 10, hay muchas, muchas más excepciones.

La reacción casual sería: "¡Su instalación de Eclipse está dañada! ¡Tiene un problema local! " Sí, podría tener un problema local, pero este "problema local" parece estar muy extendido ya que muchas instalaciones de Eclipse que inspeccioné parecen tener esto en su registros

También estoy teniendo problemas con las implementaciones como se informa en el siguiente enlace en varias encarnaciones: http://community.jboss.org/thread/158611 Puede ser específico de las herramientas de JBoss o puede estar basado en la WTP subyacente o incluso en el código de Eclipse . No lo sé, pero sí sé que es un problema desagradable. Cada versión de las herramientas de WTP y JBoss tiene ''algo'' fijo, y cada versión de un problema como ese resurge en una forma ligeramente diferente.

Entre los problemas de estabilidad puedo hacer un poco de trabajo y me encantan las características de autocompletado y navegación que los editores me ofrecen (lo que me impide cambiar a un editor de texto y construir completamente en la línea de comandos), pero estoy seguro Me encantaría una mayor estabilidad.

Answer 10

También tenemos el mismo problema con WTP 3.2.3 aquí. También lo usamos en nuestro producto durante varios años, pero la aceptación de nuestros desarrolladores y clientes en esta herramienta está disminuyendo cada año porque en cada lanzamiento más reciente es cada vez más lento.

Me gustaría utilizarlo si pudiera deshabilitar todas las funciones "avanzadas" pero, como mencionaste, no puedes deshabilitar a los indexadores. Además, no puede detener el validador de archivos JSP si ya se está ejecutando (puede probar esto si tiene tantos archivos como usted y también tenemos alrededor de 1000 archivos JSP y muchos archivos de etiquetas en nuestro proyecto).

También puedo demostrar que aumentar la memoria no ayuda. Solo previene los bloqueos de todo el eclipse, pero no reduce la UI que bloquea las operaciones internas de WTP.

En la versión más nueva 3.2.3 , recibí muchas bloqueos cuando inicio Tomcat desde la vista de servidores . La interfaz de usuario simplemente se bloquea alrededor de 1 minuto . No solo soy yo quien tiene problemas, todos mis colegas que trabajan en Windows tienen el mismo problema. En Linux, no sé sobre este problema.

También hay problemas en WTP cuando no tienes acceso a internet. Parece que hay solicitudes para que algunos registros descarguen esquemas o cosas así y, si no tienes una conexión, simplemente se cuelga y espera el tiempo de espera.

Answer 11

WTP (3.2.3) también es lento para mí. Creo que he encontrado algunas formas de hacerlo no tan lento:

• Usamos maven, por lo que hay un directorio de target que contiene una copia de todos los JSP y algunos otros XML. Reconocí que a veces son escaneados por los validadores de WTP. Pero esto no es necesario, por lo que los excluí de la validación (Proyecto / Propiedades / Validación / XXX / Excluir grupo /). ( Debería poder obtener el mismo efecto al marcar el directorio de target como derivado, pero eso no funciona para mí algunas veces ;-( )
• Hice la observación (no comprobada científicamente) de que WTP parece ser más rápido con JSPX que con archivos JSP.