Real-time Java interoperability

Question

I am wondering how it's the interoperability between JRE6 and the JVM from rtsj. It seems that I have to use only their implementation (since the code will be interpreted using their JVM), so I cannot use many of the features that Java 6 has to offer. Can it support a GUI? (say for example to modify the parameters of an industrial process).

I might be wrong, hoping to get some feedback from you.

Also, it seems that are more real time implementations for Java. Which one did you use and which one did you like most?

Answer 1

In order to provide real-time behavior, the JVM needs to be very specifically engineered. This includes integration at the operating system level to get access to real-time scheduling features of the host OS.

The Sun rea-time JVM is compatible with J2SE5, for instance. http://java.sun.com/javase/technologies/realtime/faq.jsp#4

Generally, any specialized instance of a system (OS, JVM, etc) that offers niche functionality, like security or real-time behavior, tends to be a release behind the general purpose version.

As to using a GUI for real-time, you should investigate using 2 tier client-server control of the real-time process using something like JMX, RMI or web-services (whichever is the lightest-weight). Using a GUI directly in real-time code seems like it could introduce lots of potential problems for the application as it tries to execute withing real-time constraints.

Answer 2

See my answer to another question for some more examples of RTSJ commercial-grade implementations. The latest version (2.1) is compliant with JDK1.5, so you should have Swing/AWT available.

While it is feasible to write a GUI to execute within the same JVM as real-time processes, it's not clear that this is a good architectural decision. It is more likely that you'd prefer to isolate the real-time behaviors in a JVM and provide a separable interface that implements to GUI in a separate memory space.

In principle, you are supposed to be able to write RTSJ code such that it runs in the same JVM with non-real-time threads (and I have done a lot of this) but it can be tough to get synchronization right.