The first word in the image file is compared to a fixed value: 6502. Result = ByteOrder.BIG_ENDIAN // Java default Here you can see the detection of the image byte order with the help of the Java library: It provides the possibility to adjust the byte order automatically to the big-endian byte order that is used as Java's default byte order. Reading individual 32-bit words can be done with the help of the class FileCacheImageInputStream. Similarly, when loading the image file, the byte order may has to be converted. When a Squeak image is saved to a file, it will either be in the big-endian or little-endian format, depending on the architecture. (Despite the word "Image" in its name this is a class from the Java library and has nothing to do with Squeak images in general.) This is now done in a more simple (and more Java-like) way by using the tools available in the Java class library, e.g., the FileCachedImageInputStream class. The JSqueak approach to accomplish this involved a lot of handwork for the byte handling. The objective of the image loading process is to read the bytes from the image file and reconstruct the objects they represent. The picture shows the structure of a Squeak Image containing the objects of the application (blue) as well as meta data (green). Thus it also contains all objects and data of the running application. But the image is not just one mega class file, it is a snapshot of the memory of a running application. Instead of having multiple class files containing algorithms and type description, everything resides in one file - the image. The concept of an image might sound strange for Java programmers, but has its advantages.
In order to understand the image loading process we first take a look at the image concept and the image format.
0 kommentar(er)
