ACM Home Page
Please provide us with feedback. Feedback
Language-specific make technology for the Java programming language
Full text PdfPdf (238 KB)
Source Conference on Object Oriented Programming Systems Languages and Applications archive
Proceedings of the 17th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications table of contents
Seattle, Washington, USA
SESSION: Tools table of contents
Pages: 373 - 385  
Year of Publication: 2002
ISBN:1-58113-471-1
Also published in ...
Author
Mikhail Dmitriev  Sun Microsystems Laboratories, Mountain View, CA
Sponsors
ACM: Association for Computing Machinery
SIGPLAN: ACM Special Interest Group on Programming Languages
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 8,   Downloads (12 Months): 55,   Citation Count: 4
Additional Information:

abstract   references   cited by   index terms  

Tools and Actions: Request Permissions Request Permissions    Review this Article  
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/582419.582453
What is a DOI?

ABSTRACT

Keeping the code of a Java application consistent (code is consistent if all of the project classes can be recompiled together without errors) prevents late linking errors, and thus may significantly improve development turnaround time. In this paper we describe a make technology for the Java programming language, that is based on smart dependency checking, guarantees consistency of the project code, and at the same time reduces the number of source code recompilations to the minimum. After project code consistency is initially assured by complete recompilation, the information extracted from the binary classes is stored in a so-called project database. Whenever the source code for some class C is changed, its recompiled binary is compared to the old version of C preserved in the project database. As a result, we find a minimum subset of classes that depend on C and may be affected by the particular change made to it. These are recompiled in turn, and absence of compilation errors at this phase guarantees the consistency of the new project code. To determine which dependent classes to recompile, we categorize all source incompatible changes, and for each category establish a criterion for finding the smallest possible subset of dependent classes.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

 
1
Sound Languages Underpin Reliable Programming Project (SLURP), Imperial College, University of London, London, UK. http://www-dse.doc.ic.ac.uk/Projects/slurp/index.html.
 
2
Eclipse Open Source Project. http://www.eclipse.org.
 
3
NetBeans Open Source Project. http://www.netbeans.org.
4
 
5
 
6
Borland Inprise Inc. C++ Builder 5. http://www.inprise.com/bcppbuilder/.
 
7
Borland Inprise Inc. JBuilder. http://www.inprise.com/jbuilder/.
 
8
Borland Inprise Inc. Delphi 5. http://www.inprise.com/delphi/.
 
9
R. Crelier. Separate Compilation and Module Extension. PhD thesis, ETH Zurich, Institute of Computer Systems, 1994.
 
10
M. Dmitriev. Safe Evolution of Large and Long-Lived Java Applications. PhD thesis, Department of Computing Science, University of Glasgow, UK, 2001. Available at http://www.dcs.gla.ac.uk/~misha/papers.
11
 
12
 
13
IBM Inc. The Jikes Open Source Project. http://oss.software.ibm.com/developerworks/opensource/jikes/project/index.html.
 
14
IBM Inc. VisualAge for Java. http://www-4.ibm.com/software/ad/vajava/.
 
15
 
16
Microsoft Corp. Microsoft Visual C++ Home Page. http://msdn.microsoft.com/visualc/default.asp.
17
18
 
19
WebGain. Visual Cafe 4.0. http://www.visualcafe.com/.