Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 343134

Summary: [builder] Java builder triggers building of each source file even if class file is already present
Product: [Eclipse Project] JDT Reporter: Ayushman Jain <amj87.iitr>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: CLOSED DUPLICATE QA Contact:
Severity: enhancement    
Priority: P3 CC: daniel_megert, deepakazad, Olivier_Thomann, srikanth_sankaran
Version: 3.7   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Ayushman Jain CLA 2011-04-18 07:23:15 EDT 
I20110322-0800.

In some cases, there are millions of java files in a project, which rarely change. Suppose user A has checked in these files, along with the .class files in a repository. Now user B wants to check out these files. These may be junit tests which he just wants to run. Now he wants to add another Junit and compile it and run it. But, as soon he writes the new class and presses CTRL + S, the Java builder will build ALL the java sources in the project (when the build automatically option is checked), which in this case may be a complete waste when there's no dependency of the existing files on the newly added file. 

Why don't we make the builder a bit flexible to make sure that it does not build wastefully? A case such as the one above means the user is crippled and cannot use JDT to compile a new class. I understand that this is because the builder in a fresh workspace does not have any state info on what is already built and what isn't, so it just goes ahead to build everything. Perhaps, we can allow the user to save/share the build state info as well.
Comment 1 Dani Megert CLA 2011-04-18 08:02:28 EDT 
>which in this case may be a complete waste
Calling it a complete waste is just wrong. Not even the saved build state is enough. The workspace might contain new problem detection capabilities or bug fixes for the compiler that make it very important to build the project again.

Having said that, an option to lock the project could be useful and has been requested before (see bug 80162).

A (tedious) workaround is to put the  output folder onto the build path and remove the source folder.

*** This bug has been marked as a duplicate of bug 80162 ***