Agent Characteristics of Java

 Platform-independence. Java is designed to operate in heterogeneous networks. To enable a Java application to execute anywhere on the network, the compiler generates architecture-neutral byte code as opposed to non-portable native code. For this code to be executed on a given computer, the Java runtime system needs to be present. There are no platform-dependent aspects of the Java language. Primitive data types are rigorously specified and not dependent on the underlying processor or operating system. Even libraries are platform-independent parts of the system. For example, the window library provides a single interface for the GUI that is independent of the underlying operating system. java allows us to create a mobile agent without knowing the types of computers it is going to run on.

 Secure execution. Java is intended for use on the Internet and intranets. The demand for security has influenced the design in several ways. For example, Java has a pointer model that eliminates the possibility of overwriting memory and corrupting data. Java simply does not allow illegal type casting or any pointer arithmetic. Programs are no longer able to forge access to private data in objects that they do not have access to. This prevents most activities of viruses. Even if someone tampers with the byte code, the Java runtime system ensures that the code will not be able to violate the basic semantics of Java. The security architecture of Java makes it reasonably safe to host an un-trusted agent, because it cannot tamper with the host or access private information.

 Dynamic class loading. This mechanism allows the virtual machine to load and define classes at runtime. It provides a protective name space for each agent, thus allowing agents to execute independently and safely from each other. The class-loading mechanism in extensible and enables classes to be loaded via the network.

 Multithread programming. Agents are by definition autonomous. That is, an agent executes independently of other agents residing within the same place. Allowing each agent to execute in its own lightweight process, is a way of enabling agents to behave autonomously also called a thread of execution. Fortunately, java not only allows multithread programming, but also supports a set of synchronization primitives that are built into the language. These primitives enable interaction between agents.


 Reflection. Java code can discover information about the fields, methods, and constructors of loaded classes, and can use reflected fields, methods, and constructors to operate on their underlying counterparts in objects, all within the security restrictions. Reflection accommodates the need for agents to be smart about them and other agents.


Although these great advantage, we should be aware of some significant shortcomings.
Note: Some of these shortcomings can be worked around; others are more serious, and have implications for the overall conceptual design and deployment of Java-based mobile agent systems.
 No protection of references. A Java object’s public methods are available to any other object that has a reference to it. Since there is no concept of a protected reference, some objects are allowed access to a larger set of public methods in the Java object’s interface than others. This is important for the agent. There is no way that it directly can monitor and control which other agents are accessing its methods. We have found that a practical and powerful solution to this problem is to insert a proxy object between the caller and the callee to control access. This not only provides protection of references, it also offers a solution to the problem mentioned in the next item and provides location transparency in general.


 No object ownership of references. No one owns the references to a given object in Java. For an agent, this means that we can take its thread of execution away from it, but we cannot explicitly void the agent (object) itself. This is a task for the automated garbage collector. At present, the garbage collector will not reclaim any object until all references to the object have been voided. So if some other agent has a reference to our agent, it will unavoidably open a loophole for that agent to keep our agent alive against our will. All we can do is to repeat the warning against giving away direct references to agents in Java. The upcoming Java Development Kit (JDK) 1.2 provides support for weak reference, which will solve this problem.


 No support for preservation and resumption of the execution state. It is currently impossible in Java to retrieve the full execution state of an object. Information such as the status of the program counter and frame stack is permanently forbidden territory for Java programs. Therefore, for a mobile agent to properly resume a computation on a remote host, it must rely on internal attribute values and external events to direct it. An embedded automaton can keep track of the agent's travels and ensure that computations are properly halted and properly resumed.