code, not the issues of shielding that developer’s
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