This series, The Object-Oriented Thought Process, is intended for someone just learning an object-oriented language and who wants to understand the basic concepts before jumping into the code, or someone who wants to understand the infrastructure behind an object-oriented language he or she is already using. These concepts are part of the foundation that any programmer will need to make the paradigm shift from procedural programming to object-oriented programming.
Figure 1: Statically Linked Applications
Note that the link process can accept multiple inputs, not just a single object module. This is what the term link means, a executable module can contain code that is ‘linked’ together from various places. For example, besides an object module produced from a single file, a developer can ‘link’ other modules, including those produced by other developers as well as libraries, possibly from third party vendors.
The other term that is pertinent here is ‘statically.’ All of the linked modules produce an executable that is static, not dynamic, as are the examples you will explore later. A search on Google finds a definition for statically linked as follows:
|Definitions of statically linked on the Web:|
Linked as a physical part of an executable file. The linkage between calls and subprograms is completely fixed at link time. See dynamically linked.
Figure 2: Statically Linked Java Applications
The issue here is that these are Microsoft Windows applications only. You could not copy this version of javac.exe and run it directly on a UNIX machine.
Obviously, there is a Java language specification. Although the Microsoft version of java.exe will run only on a Windows platform, the java compiler on UNIX and other platforms must abide by the same Java language specification. Despite the fact that each individual platform has its own non-portable java compiler, they all, theoretically at least, behave in consistent ways. Thus, a Java program on a Windows platform should run unchanged on a UNIX platform—even though the tools themselves were written on different platforms by different developers.
As already stated, the Microsoft javac.exe file contains Microsoft Windows-specific machine code. It is interesting to try and open an executable file with a text editor. This is actually a meaningless operation in this context, except that you will be able to compare it to a file of bytecodes and it provides a baseline for this discussion. When you open the javac.exe file in Notepad, you get the results seen in Figure 3.
Figure 3: javac.exe opened in Notepad.
Obviously, this exercise provides us no useful information. However, I always find it interesting to take a look at this type of output. It also provides students a way to differentiate between character and binary files. Because Notepad is a text editor, the characters displayed are the ACSII representation of the file. Perhaps the most interesting thing about the display of this file is that there are no recognizable words—at least none that I can determine. That is not the case when you look at a file of bytecodes in the same way.
Dynamically Linked Executables
The bytecode model uses a different approach. In this case, if you don’t want the kitchen sink, you won’t get it. The corresponding definition of dynamically linked is: