Adaptive Software Solutions

Even though the Java compiler ensures that Java source code does not violate any safety rule, how can we be sure that the bytecode running in our JVM was not created by malicious compiler? If the code we run was compiled by us or trusted third parties, then we can be sure, but that is not the case with Applets. When we run an Applet, we run untrusted code. We have no way of knowing if it was created using a malicious compiler. Such code could potentially snoop into our computer's memory, or cause programs to fail by corruppting data structures in memory. This is why the JVM looks at every class with suspicion. The class is subjected to a bytecode verification process before it is loaded. The bytecode is verified by the Bytecode Verifier. It checks the code for the following violations: * forging of pointers * violation of access restrictions * usage of objects in ways that they were not meant to be used (eg: calling a method on an object, which is not a part of that object) T...

The Java HopSpot VM uses a modified form of generational algorithms for garbage collection. Generational algorithms are based on two assumptions: Most program objects exist for a short period of time There are a few objects that exist for very long periods of time Generational algorithms divide the heap into subsections, each of which represents a generation of objects. The young heap (or the subsection containing the youngest generation of objects) gets garbage collected most frequently. Objects from the young heap that survive a few rounds of garbage collection are promoted to an older subsection. This algorithm is efficient because objects with the least probability for eing garbage collected are tested for their elligibility the least number of times. Also since some garbage collection algorithms involve moving objects (regardless of whether they will be garbage collected), this approach is faster because it moves fewer objects.

Learning continuously is imperative. Software professionals are in a field that is constantly changing. In order to provide effective solutions for clients we must keep up with changes in technology. Our learning must continue beyond university education. However, due to work and personal commitments, many professionals may not be able to attend formal classes once they start working. We are fortunate to have the Internet at our disposal. It is a wonderful medium for sharing and gaining knowledge. Educational material on the Internet allows people to learn at a time and pace that is convinient to them. It enables people to adopt a principle of "continuous education". Because a teacher is not present in front of us when we use the Internet as a learning medium, it is easy to stray away from the main topic. At times grasping a concept may be difficult because we cannot ask doubts to a teacher in real time. However these minor disadvantages are not very difficult to overcome...

Even though I have been programming in Java for several years, I am a bit displeased with the way Java and the J2EE platform has evolved. It seems like carrying a huge burden while programming, a burden that does not add much value. Think of the amount of things we have to know while developing J2EE applications. For building a small application developers must be familiar with: The Java language The core Java API JDBC Servlets JSP + Tags, EL Struts (or another MVC framework) Hibernate (or another OR tool or EJB's) Learning these technologies takes a long time, but after learning one also has to keep himself updated on these technologies, and we know the rapid rate at which stuff changes in the Java world. When we make a simple web based application, beyond the source code we deal at least with 3 configuration files; web.xml, struts-config.xml, and hbm.xml, not to mention the developer needs to know about packaging a J2EE application using jar, war, ear, ... files. All this seems l...

This is a simple informational posting. Since I am reading Java security, I thought I'd share some information about SSL with readers of this blog. SSL or Secure Sockets Layer is a layer above regular TCP/IP sockets which is used to encrypt and decrypt all data exchanged between the sockets. SSL is used for several reasons; - To ensure that the client and server know exactly who they are talking with. - To ensure the integrity of data that is exchanged. - To ensure that an eavesdropper cannot access the data while it is transmitted. Before the data exchange can actually begin, the client and server must establish an SSL connection using the following steps. 1. The client send the server it's SSL version number, and cipher settings. 2. The server send the client it's SSL version number, cipher settings, and it's public key certificate. 3. The client authenticates the server using the certificate. After successful authentication the client generates a premaster ...

A few days ago I wrote on the disadvantages of using an MVC framework in a web based project. The main points of contention were that it takes time to learn a framework and sometimes we have to learn different different frameworks for different clients, each adding to the learning curve. At times we have to understand the entire framework just to use a part of it. However upon further deliberation I think that we cannot obviate the need for a framework. Even if we choose not to use an available framework, we will still have to write code to provide the functionality. Over time that code will evolve into our own home grown framework. The time we will have to invest in creating and maintaining the code will be way more than the time it will take to learn something like Struts. I think frameworks are here to stay. But there might be a shift to light weight frameworks that allow us to extend them by adding components. More about that later!

In Java a local variable has to be initialized before it can be used. I always thought the reason for imposing this rule was to ensure that variables are never used with junk values if a programmer forgets to initialize them. This would result in runtime bugs. However while reading "Java Security - Scott Oaks" I realized that there is a also a security concern in allowing usage of initialized variables. A rogue programmer could create a very large uninitialized variable and then inspect the contents of it's memory location. Such an operation could compromise the security of the machine on which the program (applet) is being run.