This is an article written by MS engineers. It should be said to be more objective to Java. Welcome everyone to read it.
Portability of Java
Michael EDWARDS Microsoft Development Technical Engineer
Preface
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 (the best Java programming questions and answers)
· "Java jolt" (Web Developer.com Guidance Column Weekly)
· "Digital Espresso" (Java Mail List Summary Week and Mentor Software Solutions News Group Activity)
· JavaWorld (monthly updated IDG magazine about Java community)
· Javology (monthly updated Java news and online insights e-zine)
Some authority some about Java's view made me feel encouraged, I returned to the Applet example of the original starting phase, but soon, I quickly transferred the sight, and I started reading the SUN Java Development Tool (JDK) Applet Example Source Program - 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).
About portability
Providing a convenience of creating a highly portable application is a core element 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 的 轮 will get a refueling, 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 that the code compiles the Java byte code as different local code before being executed on the virtual machine. You can change the operational characteristics of Java. 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
The interpreted language itself does not mean that its procedure 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.
Progressive language
In short, the elements of the Java language itself make it very convenient 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. What good concept! When is the last time you have the last time that the software is unable to explain? With my experience, the creation of robust software needs to have professional coordination efforts before writing, I appreciate the additional standards provided by Java to ensure that this effort is indeed. Of course, some C compilers (including Microsoft) have an abnormal inspection, but this feature is not a standard language element that can be integrated with the API. Error Check for compile provides an example of another API merge with the concept of a language and an advantage. (On the web, I encountered such an article "Transforming a C communication software into the Java framework" If you are interested, you can go see if you really care the portable software?
Applets created when I have learned Java is what I have written without any "additional" work (except for testing, of course, some small harses need to be corrected) to run on multiple platforms. On the other hand, I have been talking about these software developers who can operate anywhere, but have not been convinced. After all, Windows and MS-DOS® occupy the rule of our era. But the point of view of the core platform is ignored that only content on the web is the fact that you need everyone to access your content, whether it is still in the future.
Even if you don't care, there will be other people to do. For example, in a business, automatic compatibility between all major machines, servers, desktop, portable and handheld can greatly reduce programming and technical support. Of course, Web publications can reach a variety of UNIX workstations and Windows CE handheld PCS.
I have discussed people who believe that Java is excessively promoted and will soon become a failure. Others believe that the soaring valuation of Java is a self-deprecating in the past. I think the fact may be intermediate results between the two: Java is a tool, like other tools, only correct use to reflect its value.
If you think this article is helpful to you, or what advice, distress, greetings, please send me to michale@microsoft.com let me know.
