Compilación en memoria en cascada con javax.tool

Question

El compilador JDT de Eclipse proporciona una interfaz INameEnvironment que define el método findType(...) que le permite hacer una compilación en cascada. Curiosamente, me gustaría saber si hay algún medio para hacerlo utilizando el kit de herramientas estándar para el compilador JDK.

Nota, el escenario es un motor de plantillas, que se puede hacer en la compilación de memoria para las clases generadas archivo de plantilla que tienen interdependencias, y no se puede predecir el orden en que se encontró con un archivo de plantilla, por lo tanto Foo poder necesita ser compilado primero antes de que sea el padre Bar ya compilado, por lo tanto, se necesita un mecanismo para hacer la compilación en cascada, es decir, durante la compilación de Foo que necesita para generar otra fuente Bar y compilar en primer lugar con el fin de continuar la compilación Foo 's: un código como el siguiente manera:

private NameEnvironmentAnswer findType(final String name) { 
    try { 
     if (!name.contains(TemplateClass.CN_SUFFIX)) { 
      return findStandType(name); 
     } 

     char[] fileName = name.toCharArray(); 
     TemplateClass templateClass = classCache.getByClassName(name); 

     // TemplateClass exists 
     if (templateClass != null) { 

      if (templateClass.javaByteCode != null) { 
       ClassFileReader classFileReader = new ClassFileReader(templateClass.javaByteCode, fileName, true); 
       return new NameEnvironmentAnswer(classFileReader, null); 
      } 
      // Cascade compilation 
      ICompilationUnit compilationUnit = new CompilationUnit(name); 
      return new NameEnvironmentAnswer(compilationUnit, null); 
     } 

     // So it's a standard class 
     return findStandType(name); 
    } catch (ClassFormatException e) { 
     // Something very very bad 
     throw new RuntimeException(e); 
    } 
} 

Answer 1

Según nuestra conversación de comentarios, creo que la respuesta es clara: no, no se puede hacer eso con el compilador JDK. Le da un gancho cuando solicita el paquete, pero no la dependencia de clase específica.

lo más cerca que se puede llegar tan lejos como lo que se es:

Here's a nice article con código pesar de que tiene que ser adaptado para manejar en las clases de memoria. Específicamente, el problema que está describiendo se maneja mediante el método JavaFileManager.list(...). Tienes que devolver JavaFileObjects aquí que has guardado en la memoria. Lo más probable es que necesite crear una subclase de ForwardingJavaFileManager como se describe en el artículo, aunque modificada para manejar las clases en caché con las que está trabajando.

Puede usar eso para compilar algo. Si devuelve errores, use expresiones regulares para averiguar qué falta. Después de generar/compilar el código de la falla, vuelva a intentar compilar el código original.

NOTA: Solicita el FQN de la clase dependiente como el argumento packageName en ForwardingFileManager.list (...) en algún momento. No he intentado devolver la clase en ese punto. Puede que no funcione porque el paquete no coincidiría, pero quizás lo haría.

Answer 2

Intente leer este ejemplo HelloWorld para ver si resuelve su problema. Sin publicar el código, es difícil decir cuál es su problema específico.