Java inventor James Gosling has pitched into the debate about real-time extensions to the language which indicate that developers are generally interested in the creation of some sort of Unix-like asynchronous exception handling mechanism. Gosling says: At one time Java actually had that and vestiges of it remain as deprecated methods. This is a really hard problem, and I don’t have any great answers, but having lived with such signal mechanisms for many years, I’m totally convinced that they are a bad idea. Why? Because it is essentially impossible to write a correct program in the face of them. We’ve been deprecating the mechanisms in Java because they’ve proven to be a most pernicious source of obscure bugs. Essentially every piece of code ever written is manipulating some data structure, and when an asynchronous exception arrives in the middle of one of these manipulations, and the exception isn’t accounted for, the data structure is corrupted. These data structure corruption bugs tend to be really tough to detect because they occur essentially randomly and often with very low frequency. In the face of asynchronous exceptions, it is nearly impossible to have any faith in the correctness of any program. He adds that even defensive coding practices – the usual answer to this objection to asynchronous exceptions – are is just about impossible. Partly because one is often importing libraries from others that may or may not have been ‘coded defensively’, and partly because it’s hard to know how to make many code sequences safe. Even if you do manage to code defensively, you often end up finding that the majority of the code is executing in a protected context – this ends up devolving to the equivalent of polling. Moreover, he argues, the problem is that real-time means different things to different people. Real-time for an F16 flight control system is not the same as real-time for a TV set top box. So I don’t think that choosing a particular scheduling algorithm is an appropriate thing to do, rather we should be constructing a framework that allows new scheduling algorithms to be plugged in. Other listers think Sun should be capitalizing on Java’s dynamic personality instead of trying to reconcile it with the traditional static style of centralized synchronous real-time. The argument is that Java’s dynamic personality is a natural fit with the dynamic style required for distributed asynchronous real-time systems.
Content from our partners
