Community
Participate
Working Groups
Hi, when i modify a class and this class is in imports of a lot of other java files, the build is pretty heavy. It would be great if you could detect what are the minimum amount of files to recompile using access modifiers. Changing the signature of a public method need all the files to recompile, but adding a parameter to a default access method only require files in the same package to be recompiled. You see what i mean?
What about cases where you would introduce a problem by reducing the visibility of a method (public to private) ? If you did not recompile all dependents ?
Well at least, do you not recompile files if the interface doesn't change ?
No we don't. We check if there is a structural changes in it before recompiling dependents (like a signature change). We also do not recompile dependents of local types (since they cannot be referred from outside). But you always need to worry about positive and negative cases when optimizing further...
If there is a compilation error with the structural change, do you recompile all the dependents ?
What are you calling "compilation error with the structural change" ? The compiler is pretty good at scoping error without impacting structure of the file. Please provide an example of the situation you have in mind.
I was merging a changes from the synchronize view and i forgot one '}' before saving so the structure was wrong. And i saw a rebuild of the project starting. So i was asking myself what are the cases gcj optimizes.
Say your existing file looked like : public class X { public void foo() { } } and you changed it by accident to include a syntax error : public class X { public void foo() } } Then yes in this case its possible that X lost its method foo() and all dependents of X must be recompiled. If your problem is caused by a syntax error being saved to the file, then there is a very good chance the build will be long if the type is referenced from numerous other types. I do not see how we can avoid this case.
(In reply to comment #7) > Say your existing file looked like : > > public class X { > public void foo() { > } > } > > and you changed it by accident to include a syntax error : more like: > public class X { > public void foo() { } > } > } > > > Then yes in this case its possible that X lost its method foo() and all > dependents of X must be recompiled. Well i was asking in such a case, it can be useless to recompile dependents. It could be an option, "Do not recocompile dependents when there is a compilation error".
But the problem with NOT recompiling dependents in that case, is existing .class files reference fields/methods in the type X that no longer exist. If a user debugs their code in that situation, the VM will crash instead of stopping at the point when the missing field/method is encountered. Its not an acceptable situation. The alternative is you could turn off Auto-Build so you could decide when a build occurs. Philippe - any other suggestions/alternatives ?
Yet there is an option "Continue launch if project contains error". I was hopping that a compiled class could not be replaced from compilation of java files with error.
Kent - Is the syntax error really changing the shape of the classfile structurally ? Normally we would still issue a problem type, and just minimize the amount of recompilation in the end. Is this a new/exotic scenario for which we have no handling ? Again, specifics would be good.
Without the exact change that caused the syntax error, we cannot tell whether the method should disappear from the .class file or not. But its clearly possible that the parser will not be able to guess all fields/methods in every case & a method could 'disappear' as a result of a syntax error. In that case, I do not see what else we can do.
