[jdt-core-dev] Maven jdt-based incremental java compiler

[Igor Fedorenko <igor@xxxxxxxxxxxxxx>]

I was working on jdt-based Maven incremental java compiler on and off
for last couple of months and I finally have proof of concept
implementation I'd like to discuss... if, of course, anyone is interested.

I have to admit I don't fully understand how jdt incremental build works
inside Eclipse IDE and there is a chance I am reinventing the wheel, but
at high level my idea is the following

* for each compilation unit, collect fully qualified names of all types
that can possibly affect compilation results. this should include types
from the same project as the compilation unit, types from project
dependencies and types from jre standard library. this should also
include types that do not exist but may be introduced in the future.

* for each referenced type, calculate special hash that changes whenever
corresponding class changes structurally (as per
ClassFileReader#hasStructuralChanges) and persist type/hash information
for use during the next build.

* During the next build, recalculate structural hashes of all types
referenced during previous build, find all structurally changed types
and recompile all affected compilation. I want to stress ability to
incrementally react to changes inside the project and to the project
dependencies. The latter is very important for Maven but I do not
believe is supported by IDE IncrementalImageBuilder, or at least I could
not figure out how it works.

As I mentioned, I have proof of concept implementation of this approach
that appears to work for fairly large codebase, but I'd like to ask few
questions to jdt developers to help me decide what to do next

First and foremost, does this approach make sense at all or there are
some fundamental problems with Java type references that make this
impossible?

Second, am I correct that currently JDT compiler does not provide fully
qualified names of all types that can affect specific compilation unit?

Assuming the answer to the previous question is "yes", will you be
willing to accept a patch that enables collection of this kind of type
reference information?

I will almost certainly have more questions if I decide to go ahead with
this implementation, but these are the most immediate questions I have.
Thank you in advance.

--
Regards,
Igor