Prof. Dr. Th. Letschert
CS5233 Components – Models and Engineering - Komponententechnologien - Master of Science (Informatik)
Components in the Software Life-cycle
Seite 1 © Th Letschert Software Lifecycle : Development
1. Development
coding type checking, byte code generation 2. Linking / Loading 3. Execution
Which language features support separate development in Java? Which units of (mutual dependent) code may be written, type-checked and compiled concurrently?
Seite 2 Th Letschert Software Lifecycle : Development
1. Development component in Java: Compilation Unit
The notion of “program” is obsolete by now Source code : system of interdependent compilation units Compilation unit: Source code fragment, unit of work for the compiler Separate compilation: Type-checking and generation of binary code for code fragments Result Binary code Type information for compiling other fragments Compilation units in Java: Goal symbol (“top” production) of the grammar (see Java language specification) CompilationUnit ::= [PackageDeclaration] [ImportDeclations] TypeDeclarations Types declared in different CUs can depend on each other, even circularly CUs have to be stored in files with a name that conforms to the one and only public type definition files have to placed in directories according to the package structure
Seite 3 Th Letschert Software Lifecycle : Development
Separate Compilation in Java
Compile class C depending on C₁, C₂, ··· Cn . C₁, C₂, ··· must be present in source or binary form
. if some Ci is not present in binary form: compile it . Typing information necessary to compile/check C
is extracted form the binary code of Ci Remarks Java's CUs are similar to John Lakos' “components” CU's don't have an explicit interface (“H-file” in terms of C) Pro: Easier for the user Con: CUs depend on explicitly named other Cus that have to be available completely at compilation time There is no formal / official definition of type-checking Java programs Obviously cyclic dependent definitions can not be sorted into a dependency sequence => Separate compilation of Java is impossible? John Lakos Large-Scale C++ Design, Addison-Wesley 1996: A seminal book on how to organize large C++ projects.
Seite 4 Th Letschert Software Lifecycle : Development
Separate Compilation in Java – Separate Compilation of CUs with dependencies : How smart is it? . Option 1: Do not compile separately, compile CU together with all it's dependent CUs . Option 2: Compile separately, but accept runtime errors – Separate Compilation of CUs with cyclic dependencies : Where will the loop be broken?
public class A { change to public class A { int f(Object o) {return 1;} String f(Object o) {return "A";} } }
public class B extends A { int g() {return f(this);} compile A.java, compile B.java change A.java, compile A.java public static void main(String[] args) { System.out.println(new B().g()); run B: What happens ? } }
Seite 5 Th Letschert Software Lifecycle : Development
Separate Development – Compilation units are Java's primary components of separate development – Java's Compilation units are insufficient as developer components: Appropriate developer components should have interfaces that mediate inter-component dependencies.
Seite 6 Th Letschert Software Lifecycle : Linking and Loading
1. Development 2. Linking / Loading Name / Address resolution across compiled fragments Creation of an executable program Starting the program 3. Execution
Seite 7 Th Letschert Software Lifecycle : Linking and Loading
2. Linking and Loading
In Java there is no concept of “executable program” or “library of object files”
Runnable programs are build from compiled classes
Linking/Loading is dynamic: Class-files are link/loaded on demand
Structure of running Java programs heavily relies on the class loading mechanisms
Remark: In Java there is no special linkage phase prior to run-time. However, without user defined loading / loaders, class loading is determined at start-up time (classpath, etc.) Jar-Files Archive-files used similar to “executables” or “object libraries” they are the de-facto linkage units they get no special treatment by class loaders
Seite 8 Th Letschert Software Lifecycle : Linking and Loading
2. Linking and Loading
C program generation Compilation unit => object file object file 1, … object file n => library object files + libraries => executable static and dynamic linking static: Link complete object-files dynamic: Link “stubs” dynamic linking realizes a plugin system at os-level program execution: the executable is activated os may dynamically add the “body” of dynamically linked object modules
Seite 9 Th Letschert Software Lifecycle : Linking and Loading
2. Linking and Loading
Java Main class gets loaded into the JVM main method is activated additional classes (or interfaces) are loaded as they are needed classes usually are provided through the classpath
Note: The compiler resolves dependencies between compilation units (and the classes / interfaces they contain) at compile time. The JVM solves dependencies between classes at run time. These two processes are independent (!) and thus may lead to different results.
Seite 10 Th Letschert Software Lifecycle : Execution
1. Development 2. Linking / Loading 3. Execution Load program fragments at run-time Replace program fragments at run-time
Seite 11 Th Letschert Software Lifecycle : Execution
3. Execution Load program fragments at run-time Replace program fragments at run-time Runtime - replaceable program fragment: Plugin Java Plugin: (compiled) class Java was designed to load classes at run-time There is no difference between class loading at link-time and class loading at run-time
The purpose of class loaders is to support dynamic loading of software components on the Java platform. The unit of software distribution is a class.
G. Bracha, S. Liang: Dynamic Class Loading in the Java Virtual Machine; OOPLA conference October 1998
Seite 12 Th Letschert Component Model(s) of Java
Summary Compilation units (files) are Java's components at development time
Classes are Java's real components at linkage- and run- time.
Jar-Files are de-facto linkage-units ('libs').
The component model
is poorly realized as neither compilation units nor classes nor jar-files have an appropriate separation of interface and implementation. relies completely on the class loading mechanism.
Seite 13 Th Letschert