[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Maven jdt-based incremental java compiler
|
Hi Igor,
that sounds like a cool project.
I guess the initial answer is: surely the code for recording qualified
names of referenced types is there - as in "it is implemented" - but
it's not "there" as in - "it's published API".
Have you seen the CompilationUnitScope.record* family of methods?
During CUS.storeDependencyInfo() this information is transfered
into the ComplationResult, from where it is accessed by the
AbstractImageBuilder.
Does that look like what you need?
Only the way the JDT builder uses that information seems to differ from
what you are doing: instead of storing hashes, we compare the actual bytes
of what we find on disk against the result of a recompile.
BTW, I have a question at the other end of the spectrum:
tribal knowledge seems to say that when you let m2e do a big run as maven install,
you should disable automatic building, as both builds tend to interfere.
Is this just a myth or can such interference indeed happen? If so,
wouldn't it be neat if m2e automatically suspends build automatically
while active? Should I file a bug?
cheers,
Stephan
On 03/29/2014 04:55 AM, Igor Fedorenko wrote:
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
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
