Note for Core Java - cjava By vineet kumar
- Core Java - cjava
- Note
- 100 Views
- Uploaded 9 months ago
Text from page-1
Core Java™ 2: Volume I–Fundamentals High Performance While the performance of interpreted bytecodes is usually more than adequate, there are situations where higher performance is required. The bytecodes can be translated on the fly (at run time) into machine code for the particular CPU the application is running on. If you use an interpreter to execute the bytecodes, “high performance” is not the term that we would use. However, on many platforms, there is also another form of compilation, the justin-time (JIT) compilers. These work by compiling the bytecodes into native code once, caching the results, and then calling them again if needed. This approach speeds up commonly used code tremendously since one has to do the interpretation only once. Although still slightly slower than a true native code compiler, a just-in-time compiler can give you a 10- or even 20-fold speedup for some programs and will almost always be significantly faster than the Java interpreter. This technology is being improved continuously and may eventually yield results that cannot be matched by traditional compilation systems. For example, a justin-time compiler can monitor which code is executed frequently and optimize just that code for speed. Multithreaded [The] benefits of multithreading are better interactive responsiveness and realtime behavior. If you have ever tried to do multithreading in another language, you will be pleasantly surprised at how easy it is in Java. Threads in Java also have the capacity to take advantage of multiprocessor systems if the base operating system does so. On the downside, thread implementations on the major platforms differ widely, and Java makes no effort to be platform independent in this regard. Only the code for calling multithreading remains the same across machines; Java offloads the implementation of multithreading to the underlying operating system or a thread library. (Threading will be covered in volume 2.) Nonetheless, the ease of multithreading is one of the main reasons why Java is such an appealing language for server-side development. Dynamic In a number of ways, Java is a more dynamic language than C or C++. It was designed to adapt to an evolving environment. Libraries can freely add new methods and instance variables without any effect on their clients. In Java, finding out run time type information is straightforward. This is an important feature in those situations where code needs to be added to a running program. A prime example is code that is downloaded from the Internet to run in a browser. In Java 1.0, finding out runtime type information was anything but straightforward, but current versions of Java give the programmer full insight into both the structure and behavior of its objects. This is extremely useful for systems that need to analyze objects at run time such as Java GUI builders, smart debuggers, pluggable components, and object databases. 21
Text from page-2
Core Java™ 2: Volume I–Fundamentals Java and the Internet The idea here is simple: users will download Java bytecodes from the Internet and run them on their own machines. Java programs that work on Web pages are called applets. To use an applet, you need a Java-enabled Web browser, which will interpret the bytecodes for you. Because Sun is licensing the Java source code and insisting that there be no changes in the language and basic library structure, you can be sure that a Java applet will run on any browser that is advertised as Java enabled. Note that Netscape 2.x and Netscape 3.x are only Java 1.02 enabled, as is Internet Explorer 3.0. Netscape 4 and Internet Explorer 4 run different subsets of Java 1.1. This sorry situation made it increasingly difficult to develop applets that take advantage of the most current Java version. To remedy this problem, Sun has developed the Java Plug-in, a tool that makes the newest Java runtime environment available to both Netscape and Internet Explorer (see Chapter 10). We suspect that most of the initial hype around Java stemmed from the lure of making money from special-purpose applet software. You have a nifty “Will Writer” program. Convert it to an applet, and charge people per use—presumably, most people would be using this kind of program infrequently. Some people predict a time when everyone downloads software from the Net on a per-use basis. This might be great for software companies, but we think it is absurd, for example, to expect people to download and pay for a spell-checker applet each time they send an e-mail message. Another early suggested use for applets was for so-called content and protocol handlers that allow a Java-enabled Web browser to deal with new types of information dynamically. Suppose you invent a new fractal compression algorithm for dealing with humongous graphics files and want to let someone sample your technology before you charge them big bucks for it. Write a Java content handler that does the decompression and send it along with the compressed files. The HotJava browser by Sun Microsystems supports this feature, but neither Netscape nor Internet Explorer ever did. Applets can also be used to add buttons and input fields to a Web page. But downloading those applets over a dialup line is slow, and you can do much of the same with Dynamic HTML, HTML forms, and a scripting language such as JavaScript. And, of course, early applets were used for animation: the familiar spinning globes, dancing cartoon characters, nervous text, and so on. But animated GIFs can do much of this, and Dynamic HTML combined with scripting can do even more of what Java applets were first used for. As a result of the browser incompatibilities and the inconvenience of downloading applet code through slow net connections, applets on Internet Web pages have not become a huge success. The situation is entirely different on intranets. There are typically no bandwidth problems, so the download time for applets is no issue. And in an intranet, it is possible to control which browser is being used or to use the Java Plug-in consistently. Employees can't misplace or misconfigure programs that are delivered through the Web with each use, and the system administrator never needs to walk around and upgrade code on client machines. Many corporations have rolled out programs such as inventory checking, vacation planning, travel reimbursement, and so on, as applets that use the browser as the delivery platform. 22
Text from page-3
Core Java™ 2: Volume I–Fundamentals Applets at Work This book includes a few sample applets; ultimately, the best source for applets is the Web itself. Some applets on the Web can only be seen at work; many others include the source code. When you become more familiar with Java, these applets can be a great way to learn more about Java. A good Web site to check for Java applets is Gamelan—it is now hosted as part of the developer.com site, but you can still reach it through the URL http://www.gamelan.com/. (By the way, gamelan also stands for a special type of Javanese musical orchestra. Attend a gamelan performance if you have a chance—it is gorgeous music.) When the user downloads an applet, it works much like embedding an image in a Web page. (For those who know HTML, we mean one set with an IMG tag.) The applet becomes a part of the page, and the text flows around the space used for the applet. The point is, the image is alive. It reacts to user commands, changes its appearance, and sends data between the computer viewing the applet and the computer serving it. Figure 1-1 shows a good example of a dynamic web page that carries out sophisticated calculations, an applet to view molecules. By using the mouse, you can rotate and zoom each molecule to better understand its structure. This kind of direct manipulation is not achievable with static web pages, but applets make it possible. (You can find the applet at http://www.openscience.org/jmol/JmolApplet.html.) Figure 1-1. The Jmol applet Server-side Java At the time of this writing, the pendulum has swung back from client-focused programs to server-side programming. In particular, application servers can use the monitoring capabilities of the Java virtual machine to perform automatic load balancing, database connection pooling, object synchronization, safe shutdown and restart, and other services that 23
Text from page-4
Core Java™ 2: Volume I–Fundamentals are needed for scalable server applications but are notoriously difficult to implement correctly. Thus, application programmers can buy rather than build these sophisticated mechanisms. This increases programmer productivity—programmers focus on their core competency, the business logic of their programs, and not on tweaking server performance. A Short History of Java This section gives a short history of Java's evolution. It is based on various published sources (most importantly, on an interview with Java's creators in the July 1995 issue of SunWorld's on-line magazine). Java goes back to 1991, when a group of Sun engineers, led by Patrick Naughton and Sun Fellow (and all-around computer wizard) James Gosling, wanted to design a small computer language that could be used for consumer devices like cable TV switchboxes. Since these devices do not have a lot of power or memory, the language had to be small and generate very tight code. Also, because different manufacturers may choose different central processing units (CPUs), it was important not to be tied down to any single architecture. The project got the code name “Green.” The requirements for small, tight, and platform-neutral code led the team to resurrect the model that some Pascal implementations tried in the early days of PCs. What Niklaus Wirth, the inventor of Pascal, had pioneered, and UCSD Pascal did commercially, was to design a portable language that generated intermediate code for a hypothetical machine. (These are often called virtual machines—hence, the Java Virtual Machine or JVM.) This intermediate code could then be used on any machine that had the correct interpreter. The Green project engineers used a virtual machine as well, so this solved their main problem. The Sun people, however, come from a UNIX background, so they based their language on C++ rather than Pascal. In particular, they made the language object oriented rather than procedure oriented. But, as Gosling says in the interview, “All along, the language was a tool, not the end.” Gosling decided to call his language “Oak.” (Presumably because he liked the look of an oak tree that was right outside his window at Sun.) The people at Sun later realized that Oak was the name of an existing computer language, so they changed the name to Java. In 1992, the Green project delivered its first product, called “*7.” It was an extremely intelligent remote control. (It had the power of a SPARCstation in a box that was 6 inches by 4 inches by 4 inches.) Unfortunately, no one was interested in producing this at Sun, and the Green people had to find other ways to market their technology. However, none of the standard consumer electronics companies were interested. The group then bid on a project to design a cable TV box that could deal with new cable services such as video on demand. They did not get the contract. (Amusingly, the company that did was led by the same Jim Clark who started Netscape—a company that did much to make Java successful.) The Green project (with a new name of “First Person, Inc.”) spent all of 1993 and half of 1994 looking for people to buy its technology—no one was found. (Patrick Naughton, one of the founders of the group and the person who ended up doing most of the marketing, claims to have accumulated 300,000 air miles in trying to sell the technology.) First Person was dissolved in 1994. 24
Leave your Comments