[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Maven jdt-based incremental java compiler
|
On 2014-03-29, 7:12, Stephan Herrmann wrote:
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?
Yes, I've looked at CompilationUnitScope.record* methods and this is
what I needed to change to make my proof of concept work. Again, this
may be due to my lack of understanding, but I see three major
differences between what I need and what current CompilationUnitScope
provides
1. It does not provide all possible fully qualified type references. For
example, if my code has both "new java.util.ArrayList()" and "new
ArrayList()", potential matches of "ArrayList" within on-demand imports
are not reported.
2. It does not provide package references. For example, "import
foo.bar.*" will be reported as "foo.bar" qualified name reference, but
it is not possible to tell if this is a type or a package.
3. It reports references to types that cannot affect CU unless CU
changes first. For example, if CU has "import java.util.List", simple
name "List" referenced in the CU can only resolve to java.util.List.
I have unit tests that show these and few other similar/related
problems and I am happy to show the code if you (or anyone else) is
interested.
I think the major difference between what JDT does and what I need to do
boils down to who detects changes. In Eclipse IDE, workspace detects
changes and JDT needs to match these changes to CUs. In my cases, I want
to use information extracted from CUs to determine if there is a change.
My idea is to introduce pluggable type reference recording strategy into
CompilationUnitScope, so I can provide alternative implementation
without breaking current behaviour.
So my question is, do you think jdt team will be willing to accept this
change or do you prefer me to maintain JDT fork for now? I, obviously,
would like to avoid maintaining a fork, but I can understand why you may
not have resources and/or interest to accept this kind of change.
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.
This is relatively small difference. In my implementation I took current
ClassFileReader#hasStructuralChanges and translated it into class
structure digester. I need hashes because original class bytes may not
be available during the next build. For example, one of dependencies
changed from version 1.2.0 to 1.2.1, class bytes are not available but
most of the classes did not have structural changes. Although it'd be
nice if JDT provided digester implementation, I can live without it.
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?
Are you talking about "Run-As->Maven_Install" and similar actions? It is
true, m2e does not suspend workspace builds and it is possible to see
interference between workspace and maven builds. I don't think the
solution is as simple as suspending workspace builds, though, but I am
happy to discuss possible solutions (m2e-dev is probably better place
for this discussion).
--
Regards,
Igor
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
