Portability of Java
Michael EDWARDS Microsoft Development Technical Engineer
The preamble I have always doubt the most popular topic JavaTM that is self-thoughtful. You can treat these problems with a point of view, and eventually you are forced to believe that Java will bring world peace and can repay the US national bonds or it is completely wasting time. I often want to be involved in these discussions, but I still try to avoid it until I can provide Guangbo's view. Imagine when I returned from Christmas holidays, I found that my next task is to learn Java, how scared (or should be a fear). You can say "I am paying attention to what you want to get, because you may get it"? " However, I am very happy to find that learning is easier than I expected. Java is an object-oriented design method as a long-term C world struggled C programmer, after years of object-oriented programming, as a reward me to find some principles and technologies. Indeed, I admit that I am an OLE enthusiast (MSDN subscriber who read Nigel Tompson's series of articles will understand what I mean), at least in product code migration. However, gradually I left the unordered ranks, at least when considering Java. My first decision - and is a correct decision - avoid choosing a book similar to "Time to use you five days to brush your teeth" such a book. If you have recently arrived at the computer technical section of the bookstore (if you can go out), you will know that there are many Java books. In order to narrow your lookup, you can choose the book that suits you. Because I have a rich experience in C, I found some books for C programmers to learn Java. For example, find a "simple Java" in David Flanagan (Java In A Nutshell Special System Reference December 1996. ISBN: 1556592183). I also bought "Java Series" out of Addison-Wesley (see http://www.awl.com/cp/javaseries/), which is indeed useful, but most of them are programming. I will be familiar with the habit of learning through practice. I started to write sample Applet programs, which seems very useful at the time, but soon I realized that my knowledge is very limited to study. So I started browsing Microsoft's Java Developer Web Site and Sun Microsystems Site and found some information in the following sites (this is not a comprehensive list): · Java developers (best Java programming questions and answers) · "Java Jolt "(Web Developer.com Guidance Column) ·" Digital Espresso "(Java Mail List Summation Week and Mentor Software Solutions News Group Activity) · JavaWorld (IDG magazine about Java association) JavoLogy Monthly Update Java News and Online Configuration E-Zine) Authorither Some about Java's view makes me feel encouraged, I will return to the Applet example in the original starting phase, but soon, I will transfer my sight and start reading Sun Java development. Applet Example Source Program of Tool (JDK) - You can download from http://www.javasoft.com/nav/developer/index.html. Naturally, when I start to see the source code of the system class, I feel more interesting. My Java learning method has proved to be successful.
Because of the correct choice of enlightenment books that suits you C programming background, I have a considerable deep understanding of Java. The second phase of the study browsing through the Web site, I also master the latest information about Java development tools and related issues. After reading the source code, I have an essential understanding of Java's structure and implementation. The first article of the Java series will help each C programmer answer "What is the key to Java portability?". I will focus on the design of the Java application than other technologies with better portability between different computer platforms. However, if you want to completely understand this, Java's good portability internal theory will be a focus of your study. I saw a lot of books in the Java newsgroup, reflecting the true problem that is constantly appearing during actual use. Of course, people are also complaining about Java compatibility issues, I will fundamentally explain this issue. If you think that the subject is helpful, I will be grateful. You can tell me (my E-mail address is Michaele@microsoft.com). The convenience of providing highly transplantable applications is the core elements of the Java design system. Most of my programming experience is about C language. When I started my computer game programmer career, I started with the portable code. My game company is often supporting several different platforms, including Apple II, C64, Mac, Amiga, Atari ST, and PC - using game console, but failed to succeed. Therefore, "transplanted instrument" seems to have become my name. When I transferred the game between these platforms, I learned an important lesson: there is no completely portable code; it is just a multi-and less than the portable code. I also master a method of producing as many portable code as possible. For us, this method includes writing code as much as possible, using the technology we are called virtual machine - we transplanted to the basic library code used in different platforms, the library acts as a game program The virtual graphics needed to enter the library. Therefore, from my personal experience, I can confirm that Java usually uses reliability techniques to generate high-portability code easier. Overall, I think the virtual machine method treats all the different platforms to treat a certain agreement. In order to explain this, let me tell a story about the project I have, this is the last project before I quit the development of computer games. In 1988, my game company faced a difficult decision, whether to put down Amiga and Atari St support for our PC games. At that time, I was young and true, this problem angered me. Since we have made a preliminary success on Amiga - how can we consider giving up the best game computer created? So I kept working for three months on the day and night to transfer our virtual machines to the Amiga and Atari ST platform, and I am convinced that I can post the problem of these versions simply recompile. Naturally, I successfully realized our virtual machine transplant, and even in less than a week, I used to demonstrate an Amiga and Atari ST version of our game. Can you guess what happened? In the end, we still gave up the platform. It is not willing to spend only for the PC game in 1988. If they want to have a PC, they will buy a PC. Conversely, if they want a real game computer, they will buy a Amiga (this is 1988). I have accepted a heavy lesson: virtual machine forces you to use as little non-public standards in the desired structure when writing software. Factively support different features in different structures require additional work and not necessarily always a feasible choice.
A brief clarity: My colleague programmer Paul Johns When I reviewed this article, he pointed out that my unjustly rhetoric metaphor: the portable code is the same as the cross-platform code. Portability means that simple recompilation software can run on another platform, while cross-platform (definition of Java assist) means that you can run anywhere as long as you build a code (or said according to critics It is possible to run the place where it can run once). I think Paul is different from the correct cross-platform code and the portable code, but you can think that cross-platform code is the root of all portable code. What makes Java suitable for a variety of needs, so that it is transplantable for cross-platform? There are three main reasons: Structurally provide source code grade portability; application programming model is wide and accurate description (especially as a part of language itself); several elements of language make them easy to transplant. Virtual machine I have repeatedly read Java is an interpreted programming language. However, this is not strictly correct; more accurately, Java language is usually (not always) compiling into bytecles, and byte code is sometimes (but not always) is explained. Therefore, the Java source code is not directly translated into a low-level machine instruction specific to a particular computer. But wait until "When I fix the Java Applet sample program, I use a compiler to generate a Java class file from its source code. When I use the Microsoft Internet browser to test the compiled applet, I use the Microsoft's Just-In-Time compiler to accelerate the execution of the Java Applet (see "Just-in-Time Compiler in the MSDN library", basic knowledge Article Q154580). What is compiled, what is explained? The binary instruction generated by the Java compiler (called byte code) is composed of a new set of low-level machine instructions in a new set of virtual machines. The virtual machine used to explain the compiled Java byte code is used as a software machine created. Essentially can be run on any computer - can even be created as a new hardware platform, which uses Java byte code as itself Machine command. In other words, Java virtual machines can be implemented with hardware or software, while Java programs do not "know" the difference. In fact, if Sun Microsystems Javastation (an idea known as a network computer) directly executes Java byte code (I can't say it), we can think that the Java program simulates on the Java virtual machine implemented by the software. This concept is of course not fresh on a completely different computer that simulates another computer structure. For example, some people who love their old 8 games are exhausted to make themselves to continue playing on the PC. However, Java is accurately defined by language specifications and virtual machines to make it run on different structures. This has become a core factor interested in people who care about cross-platform transplantation - it provides a precisely defined language and virtual machine specifications that create virtual Java computers on any computer platform. This is theoretically very good, but the critics for this terminology are more concerned about the huge challenges of providing the same behavior on different code bases and different platforms. In fact, a lot of quite new Java implementations are being disclosed, so we can start collecting new theories to become actual successful information. If I have to decide whether it is recommended to turn to Java to use its cross-platform characteristics, I will carefully study the Java actual compatibility advantages. (At least if Ronald Reagan said), I will test it in every place I intend to run the software, I will ask myself to find myself.
"The buzzing wheel will get fuel, but the wheel that does not ring will be broken." If you read the basic knowledge article Q154580, "Just-In-Time Compiler Description" (MSDN Basic Knowledge Base), you will see The code can change the operation characteristics of Java by compiling Java byte code as different local code on virtual machines. Therefore, replacing the explanation of the program, you can do it normally. This gives you transplantation in the source code, allowing you to keep the program's advantage, compiling efficient code for your computer in the preferred location. From claiming that I claim to be transplantable, I heard a strong opinion: C language fankeeper claims that by recompiling C language can also be transplanted, Java's fanators say that recompile is a transplantability Sad excuse. I stuffed the ear ignored these - once you understand the characteristics of the Java language (this makes the support to the slave to the source code level) are an important part of Java portability, those who say that is almost unrelated. of. Not another API interpretation type language itself does not mean that its program can naturally have cross-platform compatibility because all factors in the program depends on the operating system below. There is currently no public approach to get these elements from different operating systems (if you don't ask Java to do). Therefore, in addition to mastering their preferred programming languages, software developers insist on learning different application programming interfaces, or APIs. Even if you are familiar with the C language, like your own hand, you need to develop the C app on a variety of platforms means you have to be an expert in a variety of APIs. In fact, the difference between the various APIs provided on the target platform is the key to design the portable procedures. Sun describes a complicated problem that can be transplanted by describing a standard Java API for their defined "Java Compatibility" platform. But what do you know? It is very valid for any concept that supports cross-platform Java API. The concept of language and the operating system-specific API are like: "If you plan to program with C language, you must use Win32® API." Bravings that may be restricted, the concept of language and the API combine into a single package is indeed a big step in creating portable software. ! I now understand the true meaning of Java. It is not just a language, or just an API, but the combination of both! Synthesate a single source with a language and API, there is a potential disadvantage: if you don't like the API, or if you don't have a release, or you find many of these problems, you will be powerless. However, the Java API can be extended. In fact, the Sun's Java Group is trying to address the issues such as excessive simple graphics and multimedia support in the published version (see http://java.sun.com:81 /products/api-overview/index.html). Of course, when the required function is not possible, the Java API can be expanded by implementing the functionality required by the existing Java virtual machine, and new transplantability is introduced. If the new VM is released before all Java-compatible platforms implement these extensions, new content that is expanded to join the standard Java VM will result in new problems. The original download of new VMs will stimulate people, especially if their VM is a part of the browser, they will have to upgrade together with the browser. On the other hand, if the extension of the VM cannot be implemented on all platforms, it will bring problems. Since Java is explained, create a new class library in Java is another way to extend cross-platform API. This means that by using the Java language itself can expand in a fully portable and compatible manner.
Of course, if you can't solve the problem of critical issues or the short-level VM, you may be restricted to do what you want to do. But your Java program will be portable. In fact, many companies are issuing a Java class library with all cross-platform and extended features - for example, Microsoft's new application base class (AFC). For more information on AFC, see http://www.microsoft.com/java/default.htm. In JDK 1.0.2 and 1.1, 22 Java user interface classes describe a set of objects that must be implemented using the local machine operating system. To achieve these, Java contacts each class in this special 22 class with a peer object. The peer object is responsible for drawing the object and handling the user entered. These 22 classes are part of the advanced window kit and provide a clearly defined interaction between the Java and Java VM components, the same appearance and feelings with the platform (see "components on the Sun Java Guide Sites" Detail of the structure "). A peer-to-peer object implements most of its functionality. If you use a debugger on a Windows® machine to track your Java code to a local method call, and switch to the local code, the other end will appear in the Windows Dynamic Link Library (DLL). If you always like to know how things work, you can view Microsoft's Java SDK site to find how Microsoft's Java VM is how to effect (click "Raw Native Interface" on the frame on the left. . I still narrate how the platform-specific appearance and feelings are working (how it changes it), because I think this is a key chapter in cross-platform transplantation. Layout user interface components in the container also have potential transplantability (see the layout part of the Java Guide), as Java places the component to the specified location by a layout manager architecture that allows the insertion custom manager. To ensure portability, objects containing other objects cannot be excessively focus on the location of the actual location included in the included object. Otherwise, the container code requires processing icon screen resolution, container size, view attribute, and other details. You can solve the layout problem in one time by contacting the Java container object and the layout manager object. You can create a variety of views in the container by custom layout manager (see Java Guide http://www.javasoft.com/nav/read/tutorial/ui/layout/custom.html). For example, you can insert your own layout manager with AFC replacement of Sun's implementation method, creative placement ActiveMovieTM content into the ListView container. Therefore, if you pay attention to your appearance of your Web page on different screen resolutions, or to put new components in the container, Java's layout manager interface can be a solution. Better transplantability, in summary, Java language itself makes it easy to create cross-platform applications. This does not mean that you can't achieve portability by other ways, for example, by using a C language with a reference library like GNU C. As I have already stated, creating portable software is mainly a problem with a suitable program. However, the Java language has been made to do a lot from the perspective of portability. For example, as mentioned earlier, Java's founders struggled to decide any language in terms of Java. For example, take the memory size of the integer variable. In Java, the Short type is always 16 bits, and the LONG is always 32.
Variable size strict definitions are more restrictive than C language, the integer size in C language can grow with the structure, but it is better than only ensures sizeof (short) <= sizeof (int) <= sizeof (long) better portability. Similarly, the size of the floating-point variable of Java is also fixed (all floating point operations abide by a standard IEEE 754. See Appendix A of the "Computer Architecture Principle". In fact, the size of all basic data types left to independent implementation in ANSI C is precisely defined in the Java language specification. Extended precisely defining the concept of data type size, Java language is fixed using a proprietary Unicode Version 2.0 character set. If you have been happy with some code between platforms that support different character sets, then you will think that the fixed character set is anger. Of course, you can use the ANSI code page of the Unicode character set, but your characters will not be 8-bit, so you will not see any Java source on the #ifDef multi-character set. For this reason, you won't see any #ifdef because Java has no prerequisites. Sun's Java team pointed out that you don't need it, because Java provides a better way to implement features such as #define statements and conditional compilation, and conditional compilation is usually used to handle path selection dependent on the platform-dependent code . I haven't found this is a problem so far, but I think I have not fully convicted. Many things you often see in the API are directly replaced in the Java language, and many API elements that are not portable in cross-platform code are portable in Java. For example, synchronization is included therein. If you have a Win32 background, you are familiar with the role of synchronous functions for naming parts in the protection code. In Java, synchronization is specified in the object level. This means that your application is designed to meet the needs of synchronization in a set of naturally occurred objects. Of course, there is no reason to do not allow you to build a special Java class, just like this class like the usage of the crisp "Win32 code. Threads are another field that is often seen in the API, but has been created directly into the Java language. In Java, make sure your thread model is closely related to the tasks or objects that it contains it from its own application. As in synchronization, Java builds serialization in the object-level lock, and Java's method puts your thread activity at an object level. Compared with my traditional concept, I compare Java's functionality with Win32 and find that Java is insufficient. For example, use a waiting function to synchronize objects (this is the only way to implement multi-thread execution synchronization in Java), and this is just one of Win32. Java only provides a single object scheduling method, which cannot specify a thread to be scheduled in multiple blocking objects, while Win32 provides multi-object scheduling and early warning waits (Find "Wait Functions" in the SDK platform in the MSDN library. ). If you are handling Java restrictions, you'd better make sure your program will not conflict with future Java versions. One of the biggest availability issues today is not a rough user interface design. But than that simple problem - software's small shortcomings. Java takes a practical approach to solve those generally and unpredictable program errors; through the selected exception as a part of the language, the appropriate exception is thrown in the JDK's class implementation, forced developers to consider when they How to deal with the program failure. At compile time, the selected exception allows the compiler to check if there is a piece of code to handle problems that may occur when performing the function. In other words, unless you correctly process your own error, you will not run separately by compiling and check.
