¿Cuál es el mejor enfoque para la compilación incremental al construir un DSL usando Eclipse?

Question

Como lo sugiere la documentación de Eclipse, tengo un org.eclipse.core.resources.IncrementalProjectBuilder que compila cada archivo fuente y, por separado, también tengo un org.eclipse.ui.editors.text.TextEditor que puede editar cada archivo fuente. Cada archivo fuente se compila en su propia unidad de compilación, pero puede hacer referencia a tipos de otros archivos fuente (ya compilados).

Dos tareas para las que esto es importante son:

1. La compilación (para asegurarse de que existen los tipos que estamos usando en realidad)
2. autocompletar (para buscar el tipo para que podamos ver qué propiedades/métodos están presentes en él)

Para lograr esto, quiero almacenar una representación de todos los tipos compilados en la memoria (a los que se hace referencia a continuación como mi "tipo de tienda").

Mi pregunta es doble:

1. Tarea uno anterior se realiza por el constructor y la tarea de dos en el editor. Para que ambos tengan acceso a esta tienda de tipos, ¿debo crear una tienda estática en alguna parte a la que ambos puedan tener acceso, o Eclipse ofrece una manera más ordenada de lidiar con este problema? Tenga en cuenta que es eclipse, no yo, lo que instancia a los constructores y editores cuando se necesitan.

2. Al abrir Eclipse, no quiero tener que reconstruir todo el proyecto solo para poder volver a llenar mi tienda de tipos. Mi mejor solución hasta el momento es conservar estos datos en algún lugar y luego volver a llenar mi tienda desde allí (tal vez al abrir el proyecto). ¿Es así como otros compiladores incrementales suelen hacer esto? Creo que el enfoque de Java es usar un analizador especial que extraiga de manera eficiente esta información de los archivos de clase.

Cualquier idea sería muy apreciada. Este es mi primer DSL.

Answer 1

Esta es una pregunta interesante y que no tiene una solución simple. Trataré de describir una posible solución y también describiré con un poco más de detalle cómo JDT logra la compilación incremental.

En primer lugar, un poco acerca de JDT:

archivos de clase Sí, JDT no leído para obtener su información, pero sólo para las bibliotecas que no tienen código fuente. Y esta información realmente solo se usa para la asistencia de edición (asistencia de contenido, navegación, etc.).

JDT calcula la compilación incremental al realizar un seguimiento de las dependencias entre las unidades de compilación a medida que se compilan. Esta información de estado se almacena en el disco y se recupera y actualiza después de cada compilación.

Como un ejemplo más completo, digamos que después de una compilación completa, JDT determina que A.java depende de B.java, que depende de C.java.

Si hay un cambio estructural en C.java (un cambio estructural es un cambio que puede afectar a los archivos externos (por ejemplo, agregar/eliminar un campo o método no privado)), entonces B.java será recompilado A.java será no recompilarse ya que no hubo cambios estructurales en B.java.

Después de esto poco de aclaración sobre cómo funciona JDT, aquí están algunas posibles respuestas a sus preguntas:

1. Sí. Esto debe hacerse a través de objetos globales accesibles de forma estática. JDT hace esto a través de los objetos JavaCore y JavaModelManager. Si no desea utilizar singletons globales, puede acceder a su tienda de tipos disponible a través de la instancia del activador de Bundle de su complemento. El proyecto e4 permite la inyección de dependencias, que probablemente sea aún mejor (pero en realidad no forma parte de las API centrales de Eclipse).
2. Creo que la mejor opción es conservar la información en el sistema de archivos. La única manera real de determinar las dependencias de compilación incrementales es hacer una compilación completa, por lo que debe persistir la información en algún lugar. De nuevo, así es como lo hace JDT. La información se almacena en el directorio de sus áreas de trabajo .metadata en algún lugar del complemento org.eclipse.core.resources. Puede echar un vistazo a la clase org.eclipse.jdt.internal.core.builder.State para ver la implementación.

Por lo tanto, esta puede no ser la respuesta que está buscando, pero creo que esta es la forma más prometedora de abordar su problema.