David Holmes on Java Real-Time Systems
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Dr. David Holmes is a Senior Java Technologist and currently a member of the engineering team developing Sun Java Real-Time System at Sun Microsystems. He's also co-author of two books, The Java™ Programming Language, 4th Edition, and Java Concurrency in Practice. Steve Haines, host of the InformIT Java Reference Guide, caught up with David right before this year's JavaOne conference.
InformIT: You have a robust background, both professionally as well as in publication, in Java Real-Time Systems, can you tell us how you got started in it?
David Holmes: My interest in real-time goes back to my undergraduate days in computer systems engineering when I did my thesis on the design and implementation of a real-time microkernel on a microcontroller. My PhD work took me more generally into concurrent systems and synchronization in object-oriented systems, which is when I got heavily involved with Java. I saw a lot of the early discussion papers on real-time Java, and at one stage almost became part of one of the groups investigating it in detail. But then JSR-01 (the Real-time Specification for Java) was formed and I concentrated on my PhD, just keeping an eye on things as drafts of the specification were released, and annoying people like Greg Bollella and Ben Brosgol (both on the JSR-01 expert group) with a lot of questions.
About 18 months after my thesis was complete, some associates in the US had the opportunity to work on a DARPA funded research project in which they were going to implement the RTSJ, and they asked me to join them. Naturally I said yes. That led to a lot of interaction with the JSR-01 Technical Interpretation Committee (which was a fancy name given to the small group of people who volunteered to look after JSR-01 maintenance and updates), and that in turn led me being invited to join the TIC, and later the expert group for JSR-282 (RTSJ 1.1).
That project wound up in 2004. By late 2005 Greg Bollella wanted me to join his team at Sun Microsystems. I joined Sun at that time, working on the Hotspot VM, and eventually made my way into the engineering team for Sun's Java Real-Time System, which is where I am today.
IT: The Java Community Process started many years ago with JSR-01, for which you are a member of the Technical Interpretation Committee. What have you see change in Real-Time Java Systems since the inception of JSR-01? How far have Java Real-Time applications come in that time?
DH: Surprisingly, I haven't seen a huge amount of change since JSR-01 was first released in 2000. Primarily, I think, because the RTSJ was "ten years ahead of its time" as Tim Lindholm (former Distinguished Engineer at Sun) said to me back in 2002. It took quite a while for people to seriously consider using Java for real-time, and in particular using the RTSJ, in part because it took quite a while for commercial quality implementations to emerge.
What has happened though, is that there has been pressure on traditional VMs to become more predictable. For a long time it has all been about throughput, throughput and throughput, but as large scale applications put more and more strain on the VM, these applications have started to suffer from the non-determinism in such systems, and in particular the unpredictable latencies of garbage collection. This has led to the development of so-called low-pause collectors for traditional VMs. In addition interest in the use of the RTSJ for application domains that are definitely not what you would consider traditional real-time domains, has grown considerably. This is particularly so in financial systems — and there are a couple of sessions at this year's JavaOne discussing these areas.
IT: I see that you're a member of JSR-166, the Expert Group defining concurrency utilities. Can you tell us a little bit about JSR-166 and what types of specifications it is turning out?
DH: JSR-166 defines the contents of the java.util.concurrent package, which is a toolkit for concurrent programmers — which, as Java is inherently concurrent, is pretty much all Java programmers. It was first introduced in Java 5 and has had some further enhancements in Java 6, and planned ones for Java 7. It's really about making effective concurrent programming achievable by the average Java programmer — though it caters for beginners through to advanced experts.
IT: Many people still believe that Java, and any interpreted or partially interpreted language, is not suitable for developing real-time systems. Is there anything you can tell us to dispel that misconception?
DH: Being able to develop real-time systems is all about managing non-determinism so that an application's behaviour is predictable. This has to apply through all layers — from the hardware to the application code. Because people tend to think of the Java platform in its entirety, they think the complexity prohibits achieving predictable behaviour. But by managing different aspects of the platform — in particular memory management, and thread scheduling — you can get that predictability: which is exactly what the RTSJ set out to define. This doesn't mean that any arbitrary piece of Java code can magically become predictable — you have to adapt the programming model and how you use the platform features: for example, by ensuring that classes are loaded and initialized before the time-critical portion of your code, and perhaps by ensuring that code has also been compiled. In addition, outside of the RTSJ, real-time garbage collectors have become reality, allowing the use of Java in a broader range of applications, extending through soft-real-time to more traditional hard real-time. There are even efforts under way (JSR-302) to extend Java into the safety-critical domain.
IT: What are some examples of real-time systems written with Java?
DH: Well, some of the ones I can tell you about have been showcased at past JavaOnes. For example, last year Sun previewed its "BlueWonder" system, which is an industrial strength PC running Solaris 10 and Java Real-Time System, for use in industrial automation and control (and on show again this year). There was also the Tommy autonomous vehicle that used real-time Java. In the earlier DARPA project I mentioned, we had, we believe, the first example of real-time Java flying — that was executing mission control software on an un-manned aerial vehicle (UAV). In addition there have been past public announcements, such as the ITT Eglin Space Surveillance Radar's "Control and Signal Processing Upgrade" program.
IT: I see that you're presenting a Hands-On Lab entitled "The Real-Time Java Platform Programming Challenge: Taming Timing Troubles." Can you give us a sneak preview of what to expect from this presentation?
DH: Hands-on Labs are all about getting your hands dirty. What we do with the Java Real-Time lab is introduce people to some of the basic APIs and features of the RTSJ and get them to flesh out some code skeletons to get a simple real-time application running. But then we show how the code, while functionally correct, can sometimes miss deadlines and fail to be real-time. We then employ a new tool we have, the Thread Scheduling Visualizer, to examine what happens during the execution of the application and to discover why deadlines are missed. That information can then be used to correct the code, taking into account things that in a non-real-time environment the programmer doesn't have to think about: priorities, scheduling and priority inversion. In this way people get a taste of the RTSJ and the tools we have with Java RTS, and learn that real-time involves thinking about more than just the basic functional code.
IT: What are you particularly excited to see at this year's JavaOne?
DH: Well I'm very pleased that real-time finally has its own track! Though we let a couple of the other technologies (Embedded and JavaCard) share it with us. :) This shows how interest in real-time is expanding.
IT: What's next for you? What are you working on?
DH: Working on a product engineering team, what's next for me is whatever is in the next version of our product. As we're releasing Java RTS 2.2 in the very near future (beta available now), what's after that is something you'll just have to stay tuned for. :)