Community
Participate
Working Groups
I20091201-1600 Running some builder tests Darin and I noticed that making a Javadoc change to the class Launch from debug.core was showing our builder doing compatibility checks on the class when it should be a no-op. Stepping through our builder I found out that we are actually getting a delta for Launch.class when the only change made was to Javadoc. Talking with Olivier this never happen since Javadoc is never stored in class files.
I'll investigate why the java builder writes the .class file in this case.
Steps: 1. get org.eclipse.debug.core from HEAD 2. open Launch.java 3. add a @noextend tag to the class and save
Javadoc affects the .class file when a @deprecated tag is added or removed. Also line number attributes may need to be rewritten.
(In reply to comment #3) > Javadoc affects the .class file when a @deprecated tag is added or removed. Right. This is affecting the modifiers of the corresponding type. > Also line number attributes may need to be rewritten. This should not be a structural change.
In fact this is normal. As Markus said, the line number attributes might be different, so the .class file needs to be saved in order to enable debugging on it. But since there is no structural changes, the dependents are not recompiled. So this is the expected behavior. The problem in this case is that we don't know anymore in the API Tooling builder was the modification can be. So we process the corresponding type again.
I confirm. The .class file delta comes from the class file that has different line number attributes. No dependent types are recompiled as this is not a structural change. The only way the API Tooling builder can find out that this doesn't need to reprocess the corresponding type is to add headers information for each type into the API Tooling build state. This might end up being slower than simply processing the type.
(In reply to comment #6) > The only way the API Tooling builder can find out that this doesn't need to > reprocess the corresponding type is to add headers information for each type > into the API Tooling build state. > > This might end up being slower than simply processing the type. Moving to M5 then, we can examine the pros/cons of trying to detect change types.
marking as wontfix, to accurately compute that a class file has structurally changed would never work for the incremental build case.
