A top software consulting is looking for Java developers. There are multiple open positions like Java Developers, Senior Java Developers, Technical Leads and Architects. Candidates who have strong knowledge in Java and in one or more of the following skills can apply:
Struts
Spring
Hibernate
Web services
JSP
EJB
Application servers like Weblogic or Websphere or JBoss.
Databases like Oracle or DB2.
Design tools like Rational Software Architect or Enterprise Architect.
Good knowledge in design patterns.
Version control systems like Clearcase or Subversion.
Company Information
The company is one of the top 4 software consulting companies in US with over 56,000 employees and offices in 87 cities. The company provides very good pay package and benefits. For those who are on H1, the company will transfer H1.
Note: I am an employee of the company and your profile will be submitted as an internal referral.
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.
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 applet's 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's page or quits the browser. destroy : To perform a final cleanup in preparation for unloading.
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.
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 don'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.
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 dont initialize the applet again..
Due to Security reasons, the following restriction 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.
To allow any files in the directory /home/user1 to be read by applets loaded into the appletviewer, add the following line to your <user home directory>/.hotjava/properties file. acl.read=/home/user1 You can specify one file to be read: acl.read=/home/user1/somedir/somefile
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
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
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 precendence.
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.
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 classloader, 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
Applets loaded over the net are loaded by the applet class loader. For example, the appletviewer'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 file 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 bytecode instructions are correct. d. There is no illegal data conversion. e. The verifier accomplishes that by doing a data-flow analysis of the bytecode instruction stream, along with checking the class file format, object signatures, and special analysis of finally clauses that are used for Java exception handling.
The applet security manager is the Java mechanism for enforcing the applet restrictions described above. The appletviewer'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.
The verifier is independent of Sun's reference implementation of the Java compiler and the high-level specification of the Java language. It verifies bytecodes generated by other Java compilers. It also verifies bytecodes generated by compiling other languages into the bytecode format. Bytecodes imported over the net that pass the verifier can be trusted to run on the Java virtual machine. In order to pass the verifier, bytecodes 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.