policies, an applet can interact only with the user and can communicate only over the network with the host from which it originated. Other types of activities, like accessing files or interacting directly with outside applications, are typically prevented by the security manager that is part of the web browser or applet viewer. But aside from these restrictions, there is no fundamental difference between a Java applet and a standalone Java application. 1.7.2 New Kinds of Media When it was first released, Java quickly achieved a reputation for multimedia capabilities. Frankly, this wasn’t really deserved. At that point, Java provided facilities for doing simple animations and playing audio. You could animate and play audio simultaneously, though you couldn’t synchronize the two. Still, this was a significant advance for the Web, and people thought it was pretty impressive. Java’s multimedia capabilities have now taken shape. Java now has CD-quality sound, 3D animation, media players that synchronize audio and video, speech synthesis and recognition, and more. The Java Media Framework now supports most common audio and video file formats; The Java Sound API (part of the core classes) has the ability to record sound from a computer’s microphone. 1.7.3 New Software Development Models For some time now, people have been using visual development environments to develop user interfaces. These environments let you generate applications by moving components around on the screen, connecting components to each other, and so on. In short, designing a user interface is a lot more like drawing a picture than like writing code. For visual development environments to work well, you need to be able to create reusable software components. That’s what the JavaBeans architecture is all about: it defines a way to package software as reusable building blocks. A graphical development tool can figure out a component’s capabilities, customize the component, and connect it to other components to build applications. JavaBeans takes the idea of graphical development a step further. JavaBeans components, called Beans, aren’t limited to visible, user interface components: you can have Beans that are entirely invisible and whose job is purely computational. For example, you could have a Bean that does database access; you could connect this to a Bean that lets the user request information from the database; and you could use another Bean to display the result. Or you could have a set of Beans that implement the functions in a mathematical library; you could then do numerical analysis by connecting different functions to each other. In either case, you could “write” programs without writing a single line of code. Granted, someone would have to write the Beans in the first place; but that’s a much smaller task, and we expect markets to develop for “off the shelf ” Bean collections. Before it can use a Bean, an application builder must find out the Bean’s capabilities. There are a few ways it can do this; the simplest is called reflection. To write a Bean that uses reflection, all you need to do is follow some well-defined conventions (design patterns) that let the graphical interface builder (or any other tool that wants to do the work) analyze the Bean. If they need to, Beans can provide additional information using a process called introspection. But even without introspection, a graphical development tool can analyze a Bean, figure out what it can do, and let a user change the Bean’s properties without writing any code. - 21
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services
1.7.1 Applets The term “applet” is used to mean a small, subordinate, or embeddable application. By “embeddable,” we mean it’s designed to be run and used within the context of a larger system. In that sense, most programs are embedded within a computer’s operating system. An operating system manages its native applications in a variety of ways: it starts, stops, suspends, and synchronizes applications; it provides them with certain standard resources; and it protects them from one another by partitioning their environments. As far as the web browser model is concerned, an applet is just another type of object to display; it’s embedded into an HTML page with a special tag. Browsers make a distinction between items presented inline and items anchored via hypertext links and made available by external means, such as a viewer or helper application. If you download an MPEG video clip, for instance, and your browser doesn’t natively understand MPEG, it will look for a helper application (an MPEG player) to pass the information to. Java-enabled web browsers generally execute applets inline, in the context of a particular document, as shown in Figure 1.4. However, less capable browsers could initially provide some support for Java applets through an external viewer. Figure 1.4. Applets in a web document A Java applet is a compiled Java program, composed of classes just like any Java program. While a simple applet may consist of only a single class, most large applets should be broken into many classes. Each class is stored in a separate class file. The class files for an applet are retrieved from the network as they are needed. A large applet doesn’t need to retrieve all its parts or all its data before beginning to interact with the user. Well-designed applets can take advantage of multithreading to wait for certain resources in the background, while performing other activities. An applet has a four-part life cycle. When an applet is initially loaded by a web browser, it’s asked to initialize itself. The applet is then informed each time it’s displayed and each time it’s no longer visible to the user. Finally, the applet is told when it’s no longer needed, so that it can clean up after itself. During its lifetime, an applet may start and suspend itself, do work, communicate with other applications, and interact with the Web browser. Applets are autonomous programs, but they are confined within the walls of a web browser or applet viewer, and have to play by its rules. We’ll be discussing the details of what applets can and can’t do as we explore features of the Java language. However, under the most conservative security - 20
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Tomcat Web Hosting services
option to flag windows created by an untrusted application with a special, recognizable border to prevent it from impersonating another application and perhaps tricking you into revealing your password or your secret recipe collection. There is also a grey area, in which an application can do devious things that aren’t quite destructive. An applet that can mail a bug report can also mail-bomb your boss. The Java language provides the tools to implement whatever security policies you want. However, what these policies will be ultimately depends on who you are, what you are doing, and where you are doing it. 1.6.1 Signing Classes Web browsers such as HotJava start by defining a few rules and some coarse levels of security that restrict where applets may come from and what system resources they may access. These rules are sufficient to keep the waving Duke applet from clutching your password file, but they aren’t sufficient for applications you’d like to trust with sensitive information. To fully exploit the power of Java, we need to have some nontechnical basis on which to make reasonable decisions about what a program can be allowed to do. This nontechnical basis is trust; basically, you trust certain entities not to do anything that’s harmful to you. For a home user, this may mean that you trust the “Bank of Boofa” to distribute applets that let you transfer funds between your accounts, or you may trust L.L. Bean to distribute an applet that debits your Visa account. For a company, that may mean that you trust applets originating behind your firewall, or perhaps applets from a few high-priority customers, to modify internal databases. In all of these cases, you don’t need to know in detail what the program is going to do and give it permission for each operation. You only need to know that you trust your local bank. This doesn’t mean that there isn’t a technical aspect to the problem of trust. Trusting your local bank when you walk up to the ATM means one thing; trusting some web page that claims to come from your local bank means something else entirely. It would be very difficult to impersonate the ATM two blocks down the street (though it has been known to happen), but, depending on your position on the Net, it’s not all that difficult to impersonate a web site, or to intercept data coming from a legitimate web site and substitute your own. That’s where cryptography comes in. Digital signatures, together with certificates, are techniques for verifying that data truly comes from the source it claims to have come from and hasn’t been modified en route. If the Bank of Boofa signs its checkbook applet, your browser can verify that the applet actually came from the bank, not an imposter, and hasn’t been modified. Therefore, you can tell your browser to trust applets that have the Bank of Boofa’s signature. Java supports digital signatures; the details are covered in . 1.7 Java and the World Wide Web The application-level safety features of Java make it possible to develop new kinds of applications that were infeasible before now. A web browser that implements the Java runtime system can incorporate Java applets as executable content inside of documents. This means that web pages can contain not only static hypertext information but also full-fledged interactive applications. The added potential for use of the Web is enormous. A user can retrieve and use software simply by navigating with a web browser. Formerly static information can be paired with portable software for interpreting and using the information. Instead of just providing some data for a spreadsheet, for example, a web document might contain a fully functional spreadsheet application embedded within it that allows users to view and manipulate the information. - 19
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Java Web Hosting services
application impose an effective level of trust before running an arbitrary piece of code. And once a security manager is installed, it can’t be replaced. In Java 2, the security manager works in conjunction with an access controller that lets you implement security policies by editing a file. Access policies can be as simple or complex as a particular application warrants. Sometimes it’s sufficient simply to deny access to all resources or to general categories of services such as the filesystem or network. But it’s also possible to make sophisticated decisions based on high-level information. For example, a Java-enabled web browser could use an access policy that lets users specify how much an applet is to be trusted or that allows or denies access to specific resources on a case-by-case basis. Of course, this assumes that the browser can determine which applets it ought to trust. We’ll see how this problem is solved shortly. The integrity of a security manager is based on the protection afforded by the lower levels of the Java security model. Without the guarantees provided by the verifier and the class loader, high-level assertions about the safety of system resources are meaningless. The safety provided by the Java byte-code verifier means that the interpreter can’t be corrupted or subverted, and that Java code has to use components as they are intended. This, in turn, means that a class loader can guarantee that an application is using the core Java system classes and that these classes are the only means of accessing basic system resources. With these restrictions in place, it’s possible to centralize control over those resources with a security manager. 1.6 Application and User-Level Security There’s a fine line between having enough power to do something useful and having all the power to do anything you want. Java provides the foundation for a secure environment in which untrusted code can be quarantined, managed, and safely executed. However, unless you are content with keeping that code in a little black box and running it just for its own benefit, you will have to grant it access to at least some system resources so that it can be useful. Every kind of access carries with it certain risks and benefits. The advantages of granting an untrusted applet access to your windowing system, for example, are that it can display information and let you interact in a useful way. The associated risks are that the applet may instead display something worthless, annoying, or offensive. Since most people can accept that level of risk, graphical applets and the World Wide Web in general are possible. At one extreme, the simple act of running an application gives it a resource, computation time, that it may put to good use or burn frivolously. It’s difficult to prevent an untrusted application from wasting your time, or even attempting a “denial of service” attack. At the other extreme, a powerful, trusted application may justifiably deserve access to all sorts of system resources (e.g., the filesystem, process creation, network interfaces); a malicious application could wreak havoc with these resources. The message here is that important and sometimes complex security issues have to be addressed. In some situations, it may be acceptable to simply ask the user to “okay” requests. Sun’s HotJava web browser can pop up a dialog box and ask the user’s permission for an applet to access an otherwise restricted file. However, we can put only so much burden on our users. An experienced person will quickly grow tired of answering questions; an inexperienced user may not be able to answer the questions correctly. Is it okay for me to grant an applet access to something if I don’t understand what that is? Making decisions about what is dangerous and what is not can be difficult. Even ostensibly harmless access, like displaying a window, can become a threat when paired with the ability for an untrusted application to communicate from your host. The Java Security Manager provides an - 18
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Java Web Hosting services
Because an operation always produces a known type, by looking at the starting state, it’s possible to determine the types of all items on the stack and in local variables at any point in the future. The collection of all this type information at any given time is called the type state of the stack; this is what Java tries to analyze before it runs an application. Java doesn’t know anything about the actual values of stack and variable items at this time, just what kind of items they are. However, this is enough information to enforce the security rules and to ensure that objects are not manipulated illegally. To make it feasible to analyze the type state of the stack, Java places an additional restriction on how Java byte-code instructions are executed: all paths to the same point in the code have to arrive with exactly the same type state.[4] This restriction makes it possible for the verifier to trace each branch of the code just once and still know the type state at all points. Thus, the verifier can insure that instruction types and stack value types always correspond, without actually following the execution of the code. For a more thorough explanation of all of this, see The Java Virtual Machine, by Jon Meyer and Troy Downing (O’Reilly & Associates). [4] The implications of this rule are of interest mainly to compiler writers. The rule means that Java byte- code can’t perform certain types of iterative actions within a single frame of execution. A common example would be looping and pushing values onto the stack. This is not allowed because the path of execution would return to the top of the loop with a potentially different type state on each pass, and there is no way that a static analysis of the code can determine whether it obeys the security rules. 1.5.2 Class Loaders Java adds a second layer of security with a class loader. A class loader is responsible for bringing the byte-code for one or more Java classes into the interpreter. Every application that loads classes from the network must use a class loader to handle this task. After a class has been loaded and passed through the verifier, it remains associated with its class loader. As a result, classes are effectively partitioned into separate namespaces based on their origin. When a loaded class references another class name, the location of the new class is provided by the original class loader. This means that classes retrieved from a specific source can be restricted to interact only with other classes retrieved from that same location. For example, a Java- enabled web browser can use a class loader to build a separate space for all the classes loaded from a given uniform resource locator (URL). The search for classes always begins with the built-in Java system classes. These classes are loaded from the locations specified by the Java interpreter’s class path (see Chapter 3). Classes in the class path are loaded by the system only once and can’t be replaced. This means that it’s impossible for an applet to replace fundamental system classes with its own versions that change their functionality. 1.5.3 Security Managers Finally, a security manager is responsible for making application-level security decisions. A security manager is an object that can be installed by an application to restrict access to system resources. The security manager is consulted every time the application tries to access items like the filesystem, network ports, external processes, and the windowing environment, so the security manager can allow or deny the request. A security manager is most useful for applications that run untrusted code as part of their normal operation. Since a Java-enabled web browser can run applets that may be retrieved from untrusted sources on the Net, such a browser needs to install a security manager as one of its first actions. This security manager then restricts the kinds of access allowed after that point. This lets the - 17
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services
classes. A class loader handles loading classes from the network. At the inner level, all system security ultimately rests on the Java verifier, which guarantees the integrity of incoming classes. The Java byte-code verifier is a fixed part of the Java runtime system. Class loaders and the security managers (or security policies to be more precise), however, are components that may be implemented differently by different applications that load byte-code, such as applet viewers and web browsers. All three of these pieces need to be functioning properly to ensure security in the Java environment.[3] [3] You may have seen reports about various security flaws in Java. While these weaknesses are real, it’s important to realize that they have been found in the implementations of various components, namely Sun’s byte-code verifier and Netscape’s class loader and security manager, not in the basic security model itself. One of the reasons Sun has released the source code for Java is to encourage people to search for weaknesses, so they can be removed. 1.5.1 The Verifier Java’s first line of defense is the byte-code verifier. The verifier reads byte-code modules before they are run and makes sure they are well-behaved and obey the basic rules of the Java language. A trusted Java compiler won’t produce code that does otherwise. However, it’s possible for a mischievous person to deliberately assemble bad code. It’s the verifier’s job to detect this. Once code has been verified, it’s considered safe from certain inadvertent or malicious errors. For example, verified code can’t forge references or violate access permissions on objects. It can’t perform illegal casts or use objects in unintended ways. It can’t even cause certain types of internal errors, such as overflowing or underflowing the operand stack. These fundamental guarantees underlie all of Java’s security. You might be wondering, isn’t this kind of safety implicit in lots of interpreted languages? Well, while it’s true that you shouldn’t be able to corrupt the interpreter with bogus BASIC code, remember that the protection in most interpreted languages happens at a higher level. Those languages are likely to have heavyweight interpreters that do a great deal of runtime work, so they are necessarily slower and more cumbersome. By comparison, Java byte-code is a relatively light, low-level instruction set. The ability to statically verify the Java byte-code before execution lets the Java interpreter run at full speed with full safety, without expensive runtime checks. Of course, you are always going to pay the price of running an interpreter, but that’s not a serious problem with the speed of modern CPUs. Java byte- code can also be compiled on the fly to native machine code, which has even less runtime overhead. The verifier is a type of theorem prover. It steps through the Java byte-code and applies simple, inductive rules to determine certain aspects of how the byte-code will behave. This kind of analysis is possible because compiled Java byte-code contains a lot more type information than the object code of other languages of this kind. The byte-code also has to obey a few extra rules that simplify its behavior. First, most byte-code instructions operate only on individual data types. For example, with stack operations, there are separate instructions for object references and for each of the numeric types in Java. Similarly, there is a different instruction for moving each type of value into and out of a local variable. Second, the type of object resulting from any operation is always known in advance. There are no byte-code operations that consume values and produce more than one possible type of value as output. As a result, it’s always possible to look at the next instruction and its operands, and know the type of value that will result. - 16
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Java Web Hosting services
code, not the issues of shielding that developer’s classes and objects from the onslaught of someone else’s viruses and Trojan horses. Arbitrary casting and pointer arithmetic in C or C++ make it trivial to violate access permissions on classes without breaking the rules of the language. Consider the following code: // C++ codeclass Finances { private: char creditCardNumber[16]; … }; main( ) { Finances finances; // Forge a pointer to peek inside the class char *cardno = (char *)&finances; printf(”Card Number = %sn”, cardno); } In this little C++ drama, we have written some code that violates the encapsulation of the Finances class and pulls out some secret information. This sort of shenanigan abusing an untyped pointer is not possible in Java. If this example seems unrealistic, consider how important it is to protect the foundation (system) classes of the runtime environment from similar kinds of attacks. If untrusted code can corrupt the components that provide access to real resources, such as the filesystem, the network, or the windowing system, it certainly has a chance at stealing your credit card numbers. In Visual BASIC, it’s also possible to compromise the system by peeking, poking, and, under DOS, installing interrupt handlers. Even some recent languages that have some commonalties with Java lack important security features. For example, the Apple Newton uses an object-oriented language called NewtonScript that is compiled into an interpreted byte-code format. However, NewtonScript has no concept of public and private members, so a Newton application has free reign to access any information it finds. General Magic’s Telescript language is another example of a device- independent language that does not fully address security concerns. The list goes on … If a Java application is to dynamically download code from an untrusted source on the Internet and run it alongside applications that might contain confidential information, protection has to extend very deep. The Java security model wraps three layers of protection around imported classes, as shown in Figure 1.3. Figure 1.3. The Java security model At the outside, application-level security decisions are made by a security manager. A security manager controls access to system resources like the filesystem, network ports, and the windowing environment. A security manager relies on the ability of a class loader to protect basic system - 15
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost JSP Web Hosting services
either declare the exceptions it can generate or catch and deal with them itself. This promotes error information to the same level of importance as argument and return typing. As a Java programmer, you know precisely what exceptional conditions you must deal with, and you have help from the compiler in writing correct software that doesn’t leave them unhandled. 1.4.6 Multithreading Applications today require a high degree of parallelism. Even a very single- minded application can have a complex user interface which requires concurrent activities. As machines get faster, users become more sensitive to waiting for unrelated tasks that seize control of their time. Threads provide efficient multiprocessing and distribution of tasks for both client and server applications. Java makes threads easy to use because support for them is built into the language. Concurrency is nice, but there’s more to programming with threads than just performing multiple tasks simultaneously. In many cases, threads need to be synchronized, which can be tricky without explicit language support. Java supports synchronization based on the monitor and condition model developed by C.A.R. Hoare a sort of lock and key system for accessing resources. The keyword synchronized designates methods for safe, serialized access within an object. Only one synchronized method within the object may run at a given time. There are also simple, primitive methods for explicit waiting and signaling between threads interested in the same object. Learning to program with threads is an important part of learning to program in Java. See Chapter 8, for a discussion of this topic. For complete coverage of threads, refer to Java Threads, by Scott Oaks and Henry Wong (O’Reilly & Associates). 1.4.7 Scalability At the lowest level, Java programs consist of classes. Classes are intended to be small, modular components. They can be separated physically on different systems, retrieved dynamically, stored in a compressed format, and even cached in various distribution schemes. Over classes, Java provides packages , a layer of structure that groups classes into functional units. Packages provide a naming convention for organizing classes and a second level of organizational control over the visibility of variables and methods in Java applications. Within a package, a class is either publicly visible or protected from outside access. Packages form another type of scope that is closer to the application level. This lends itself to building reusable components that work together in a system. Packages also help in designing a scalable application that can grow without becoming a bird’s nest of tightly coupled code dependency. 1.5 Safety of Implementation It’s one thing to create a language that prevents you from shooting yourself in the foot; it’s quite another to create one that prevents others from shooting you in the foot. Encapsulation is a technique for hiding data and behavior within a class; it’s an important part of object-oriented design. It helps you write clean, modular software. In most languages, however, the visibility of data items is simply part of the relationship between the programmer and the compiler. It’s a matter of semantics, not an assertion about the actual security of the data in the context of the running program’s environment. When Bjarne Stroustrup chose the keyword private to designate hidden members of classes in C++, he was probably thinking about shielding you from the messy details of a class developer’s - 14
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Java Web Hosting services
simply ignore objects you no longer use, with confidence that the interpreter will clean them up at an appropriate time. Sun’s current implementation of Java uses a conservative mark-and-sweep garbage collector that runs intermittently in the background, which means that most garbage collecting takes place between I/O pauses, mouse clicks, and keyboard hits. Next generation runtime systems like HotSpot have more advanced garbage collection that can even differentiate the usage patterns of objects (such as short-lived versus long-lived) and optimize their collection. Once you get used to garbage collection, you won’t go back. Being able to write air-tight C code that juggles memory without dropping any on the floor is an important skill, but once you become addicted to Java you can “realloc” some of those brain cells to new tasks. You may hear people say that Java doesn’t have pointers. Strictly speaking, this statement is true, but it’s also misleading. What Java provides are references a safe kind of pointer and Java is rife with them. A reference is a strongly typed handle for an object. All objects in Java, with the exception of primitive numeric types, are accessed through references. If necessary, you can use references to build all the normal kinds of data structures you’re accustomed to building with pointers, such as linked lists, trees, and so forth. The only difference is that with references you have to do so in a type-safe way. Another important difference between a reference and a pointer is that you can’t do pointer arithmetic with references (they can only point to specific objects or elements of an array). A reference is an atomic thing; you can’t manipulate the value of a reference except by assigning it to an object. References are passed by value, and you can’t reference an object through more than a single level of indirection. The protection of references is one of the most fundamental aspects of Java security. It means that Java code has to play by the rules; it can’t peek into places it shouldn’t. Unlike C or C++ pointers, Java references can point only to class types. There are no pointers to methods. People often complain about this missing feature, but you will find that most tasks that call for pointers to methods, such as callbacks, can be accomplished using interfaces and anonymous adapter classes instead.[2] (We will discuss these in Chapter 6, and in the Swing-related chapters; they are heavily used in tying together graphical user interface components). [2] As of Java 1.1, there is a Method class, which lets you have a reference to a method. This is part of the Java reflection API. You can use a Method object to construct a callback, but it’s not the normal way of doing things. Finally, arrays in Java are true, first-class objects. They can be dynamically allocated and assigned like other objects. Arrays know their own size and type, and although you can’t directly define or subclass array classes, they do have a well-defined inheritance relationship based on the relationship of their base types. Having true arrays in the language alleviates much of the need for pointer arithmetic like that in C or C++. 1.4.5 Error Handling Java’s roots are in networked devices and embedded systems. For these applications, it’s important to have robust and intelligent error management. Java has a powerful exception-handling mechanism, somewhat like that in newer implementations of C++. Exceptions provide a more natural and elegant way to handle errors. Exceptions allow you to separate error-handling code from normal code, which makes for cleaner, more readable applications. When an exception occurs, it causes the flow of program execution to be transferred to a predesignated “catcher” block of code. The exception carries with it an object that contains information about the situation that caused the exception. The Java compiler requires that a method - 13
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Java Web Hosting services
performance reasons; an application can run without the overhead incurred by searching method tables at runtime. But late-binding is more flexible. It’s also necessary in an object-oriented language, where a subclass can override methods in its superclass, and only the runtime system can determine which method to run. Java provides some of the benefits of both C++ and Smalltalk; it’s a statically typed, late-binding language. Every object in Java has a well-defined type that is known at compile time. This means the Java compiler can do the same kind of static type checking and usage analysis as C++. As a result, you can’t assign an object to the wrong type of variable or call nonexistent methods on an object. The Java compiler goes even further and prevents you from messing up and trying to use uninitialized variables. However, Java is fully runtime typed as well. The Java runtime system keeps track of all objects and makes it possible to determine their types and relationships during execution. This means you can inspect an object at runtime to determine what it is. Unlike C or C++, casts from one type of object to another are checked by the runtime system, and it’s even possible to use completely new kinds of dynamically loaded objects with a level of type safety. Since Java is a late-binding language, all methods are like virtual methods in C++. This makes it possible for a subclass to override methods in its superclass. But Java also allows you to gain the performance benefits of early-binding by explicitly declaring (with the final modifier) that certain methods can’t be overridden by subclassing, removing the need for runtime lookup. (Adaptive runtime compilers like HotSpot may be able to eliminate the need for you to worry about this though, as they can detect usage patterns and improve performance automatically, where possible.) 1.4.3 Incremental Development Java carries all data-type and method-signature information with it from its source code to its compiled byte-code form. This means that Java classes can be developed incrementally. Your own Java classes can also be used safely with classes from other sources your compiler has never seen. In other words, you can write new code that references binary class files, without losing the type safety you gain from having the source code. The Java runtime system can load new classes while an application is running, thus providing the capabilities of a dynamic linker. A common irritation with C++ is the “fragile base class” problem. In C++, the implementation of a base class can be effectively frozen by the fact that it has many derived classes; changing the base class may require recompilation of the derived classes. This is an especially difficult problem for developers of class libraries. Java avoids this problem by dynamically locating fields within classes. As long as a class maintains a valid form of its original structure, it can evolve without breaking other classes that are derived from it or that make use of it. 1.4.4 Dynamic Memory Management Some of the most important differences between Java and C or C++ involve how Java manages memory. Java eliminates ad hoc pointers and adds garbage collection and true arrays to the language. These features eliminate many otherwise insurmountable problems with safety, portability, and optimization. Garbage collection alone should save countless programmers from the single largest source of programming errors in C or C++: explicit memory allocation and deallocation. In addition to maintaining objects in memory, the Java runtime system keeps track of all references to those objects. When an object is no longer in use, Java automatically removes it from memory. You can - 12
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Tomcat Web Hosting services