To find an emerging set of technologies that will allow developers to write applications in Java with deterministic run-time requirements, one must embrace the concept of “real-time” Java to help remove the limitations inherent in the language.
To that end, IBM provides a real-time Java solution called IBM WebSphere Real Time, which features real-time GC, ahead-of-time compilation and a conforming RTSJ environment, all running on an enhanced real-time version of Linux. Because Linux uses only freely available technology developed by the Linux community, the technologies provided here offer a first glimpse at where the industry is taking real-time Java.
People often confuse “real-time” with “real fast” simply because, in some cases, real-time is equivalent to real fast. Scientifically speaking, real-time means “the ability to reliably and predictably reason about and control the temporal behavior of program logic.” The computer will respond each time before an established deadline, meaning that it is predictable. Therefore, depending on how you set your deadlines, numerous systems can, in actuality, be called real-time.
Unfortunately, the Java Virtual Machine (JVM) caches the IP addresses of hosts so that it does not have to conduct a DNS lookup for the same node more than once. This leads, however, to the development environment's incorrect identification of any host that changes its IP address for any reason.
To work around this problem, the development environment must be terminated and relaunched, or the host's new IP address (for example, on the first page, also known as the Hosts page of the Launch Remote Java Process wizard) must be provided. When a process on the local machine has changed its IP address, users can do one of the following:
Java's inability to express structured data leads to an overreliance on XML, with the corresponding additional complexity and bloat; and Java's many compromises, such as primitives, make the language hard to learn and complex to code. Although Java is more dynamic than C++, it is not nearly so dynamic as other languages, including Smalltalk and Ruby. Java developers are discovering meta-programming, but they cannot execute their ideas quickly enough, because Java's compile/deploy cycle is longer than those of interpreted, dynamic alternative languages.
Taken alone, none of these issues decisively cripples the language. Taken together, however, they make Java noticeably less productive for most developers.
Java implementation should start with a good ground-up design and include setting up a build environment, deciding on an integrated development environment (IDE), such as Eclipse or Net Beans, and setting up the source repository.
A key aspect of a Java implementation is ensuring that the proper version of the JVM is installed on the client machine. Often the application has been developed using a JVM version higher than the target/production machine's JVM.
Sun's real-time Java is the only compliant JSR-1 implementation available today. JSR-1 requires the passing of one of the four technology compatibility kits (TCKs) in the JCP: that is, Java EE, Java SE, Connected Device Configuration (CDC), or Connected Limited Device Configuration (CLDC). Unless a JSR-1 implementation passes one of these, along with the JSR-1 TCK, it cannot be called compliant. Note that if when large companies plan to invest hundreds of millions of dollars into writing new programs, they require the ability to do so on compliant systems.
System predictability and good Java programming
Whenever computers control physical devices in the real world, a control system is required that usually contains three interacting parts: sensing, control and actuation. Sensing means there are sensors in the environment that measure physical quantities such as temperature, pressure, humidity and force. Control takes the values from those sensors and creates an output command for what is called an actuator. Actuators physically affect the environment; control systems with sensors, control mechanisms and actuators are everywhere. We see them in trains, planes, automobiles, traffic lights, financial trading systems and chip fabrication machines.
When controlling something, the time between sensing and command must be limited to a predetermined ceiling. In a real-time environment, downloading something from the Web while trying to control something else could cause a system-wide failure. This type of system is fundamentally different from what most people are accustomed to.
The main problem is that general-purpose computing success, such as the Web and business computing transactions and performance, is measured by speed. When manipulating physical devices in the control space, simply being fast enough is not good enough; predictability is even more essential. But general-purpose machines are not so easily made predictable.
A predictable real-time garbage collector is unattainable unless its developer knows something about how the program demands memory from the heap, because the garbage collector and the program are both using the heap, and the program is making garbage. Because the garbage collector, which is turning garbage into free memory, must also interact with the program in the heap, there must be some synchronization between the two. Thus the developer tells the garbage collector something about how fast the program will create garbage so that the collector knows how fast it needs to clean up after it; but finding that value can be tricky when considering memory use and limitations.
Here are some tips to consider:
By clearly determining Java codes, limitations can be prudently met. Companies such as IBM have developed real-time Java specifications, and, depending on users' needs, programs can be adapted to ensure maximum compliance.
Ganapati Ravishankar Iyer, based in India, holds a master's degree in commerce from the University of Madras. He can be reached at email@example.com.