Applets Interview Questions
1 what is an Applet?
Ans: Applet is a java program which is included in a html page and executes in java enabled client browser. Applets are used for creating dynamic and interactive web applications.
2 Explain the life cycle of an Applet?
Ans: The following methods implement the life cycle of an Applet:
Init: To initialize the applet each time it’s loaded (or reloaded).
Start: To start the applet’s execution, such as when the applets loaded or when the user revisits a page that contains the applet.
Stop: To stop the applet’s execution, such as when the user leaves the applet’spage or quits the browser.
Destroy: To perform a final cleanup in preparation for unloading.
3 what happens when an applet is loaded?
Ans: The following sequence happens when an applet is loaded:
a) An instance of the applet’s controlling class (an Applet subclass) is created.
b) The applet initializes itself.
c) The applet starts running.
4 How to make my class as an applet?
Ans: Your class must directly or indirectly extend either Applet or JApplet.
5 what is Applet Context?
Ans: Applet Context is an interface which provides information about applet’s environment.
6 what is the difference between an Applet and a Java Application?
Ans: The following are the major differences between an Applet and an Application:
a. Applets execute within a java enabled browser but an application is a standalone
Java program outside of a browser. Both require a JVM (Java Virtual Machine).
b. Application requires main () method to trigger execution but applets doesn’t need a main () method. Applets use the init (), start (), stop () and destroy () methods for their life cycle.
c. Applets typically use a fairly restrictive security policy. In a standalone application, however, the security policy is usually more relaxed.
7 what happens when a user leaves and returns to an applet’s page?
Ans: When the user leaves the page, the browser stops the applet and when the user returns to the page, the browser starts the applet and normally most browser’s don?t initialise the applet again.
8 what are the restrictions imposed on an applet?
Ans: Due to Security reasons, the following restrictions are imposed on applets:
a. An applet cannot load libraries or define native methods.
b. It cannot ordinarily read or write files on the host that’s executing it.
c. It cannot make network connections except to the host that it came from.
d. It cannot start any program on the host that’s executing it.
e. It cannot read certain system properties.
9 Can a applet invoke public methods of another applet on the same page?
Ans: Yes. It’s possible.
10 what are untrusted applets?
Ans: By default, all downloaded applets are untrusted. Untrusted Applets are those applets which cannot access or exceute local system files.
11 How to let a downloaded applet to read a file in the local system?
Ans: To allow any files in the directory /home/user1 to be read by applets loaded into the applet viewer, add the following line to your <user home directory>/.hot
java/properties file.
acl.read=/home/user1
you can specify one file to be read:
acl.read=/home/user1/somedir/somefile
12 How to let a downloaded applet to write to a file in the local system?
Ans: You can allow applets to write to your /tmp directory by setting the acl.write
property in your <user home directory>/.hotjava/properties file:
acl.write=/tmp
You can allow applets to write to a particular file by naming it explicitly:
acl.write=/home/user1/somedir/somefile
13 How do I hide system properties that applets are allowed to read?
Ans: To hide the name of the operating system that you are using, add the following line to your <user home directory>/.hotjava/properties file:
os.name=null
14 How can I allow applets to read system properties that they aren’t allowed to read?
Ans: To allow applets to record your user name, add the following line to your <user home directory>/.hotjava/properties file:
user.name.applet=true
15 How can an applet open a network connection to a computer on the internet?
Ans: Applets are not allowed to open network connections to any computer, except for the host that provided the .class files. This is either the host where the html page came from, or the host specified in the codebase parameter in the applet tag, with codebase taking precedence.
16 Can an applet start another program on the client?
Ans: No, applets loaded over the net are not allowed to start programs on the client. That is, an applet that you visit can’t start some rogue process on your PC. In UNIX terminology, applets are not allowed to exec or fork processes. In particular, this means that applets can’t invoke some program to list the contents of your file system, and it means that applets can’t invoke System. exit () in an attempt to kill your web browser. Applets are also not allowed to manipulate threads outside the applet’s own thread group.
17 what is the difference between applets loaded over the net and applets loaded via the file system?
Ans: There are two different ways that applets are loaded by a Java system. The way an applet enters the system affects what it is allowed to do. If an applet is loaded over the net, then it is loaded by the applet class loader, and is subject to the restrictions enforced by the applet security manager. If an applet resides on the client’s local disk, and in a directory that is on the client’s CLASSPATH, then it is loaded by the
file system loader. The most important differences are :
a. applets loaded via the file system are allowed to read and write files
b. applets loaded via the file system are allowed to load libraries on the client
c. applets loaded via the file system are allowed to exec processes
d. applets loaded via the file system are allowed to exit the virtual machine
e. applets loaded via the file system are not passed through the byte code verifier
18 What’s the applet class loader, and what does it provide?
Ans: Applets loaded over the net are loaded by the applet class loader. For
example, the applet viewer?s applet class loader is implemented by the class
sun.applet.AppletClassLoader.The class loader enforces the Java name space hierarchy. The class loader guarantees that a unique namespace exists for classes that come from the local file system, and that a unique namespace exists for each network source. When a browser loads an applet over the net, that applet’s classes are placed in a private namespace associated with the applet’s origin. Thus, applets loaded from different network sources are partitioned from each other. Also, classes loaded by the class loader are passed through the verifier. The verifier checks that the class file conforms to the Java language specification – it doesn’t assume that the class file was produced by a “friendly” or “trusted” compiler. On the contrary, it checks the class files for purposeful violations of the language type rules and name space restrictions. The verifier ensures that:
a. There are no stack overflows or underflows.
b. All register accesses and stores are valid.
c. The parameters to all byte code instructions are correct.
d. There is no illegal data conversion.
e. The verifier accomplishes that by doing a data-flow analysis of the byte code instruction stream, along with checking the class file format, object signatures, and special analysis of finally clauses that are used for Java exception handling.
19 what?s the applet security manager, and what does it provide?
Ans: The applet security manager is the Java mechanism for enforcing the applet restrictions described above. The applet viewer?s applet security manager is implemented by sun.applet.AppletSecurity.A browser may only have one security manager. The security manager is established at startup, and it cannot thereafter be replaced, overloaded, overridden, or extended.
Applets cannot create or reference their own security manager.
20 If other languages are compiled to Java byte codes, how does that affect the applet security model?
Ans: The verifier is independent of Sun’s reference implementation of the Java compiler and the high-level specification of the Java language. It verifies byte codes generated by other Java compilers. It also verifies byte codes generated by compiling other languages into the byte code format. Byte codes imported over the net that pass the verifier can be trusted to run on the Java virtual machine. In order to pass the verifier, byte codes have to conform to the strict typing, the object signatures, the class file format, and the predictability of the runtime stack that are all defined by the Java language implementation.