View all newsletters
Receive our newsletter - data, insights and analysis delivered to you
  1. Technology
November 23, 1998


By CBR Staff Writer

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
DTX Manchester welcomes leading tech talent from across the region and beyond
The hidden complexities of deploying AI in your business
When it comes to AI, remember not every problem is a nail

Websites in our network
Select and enter your corporate email address Tech Monitor's research, insight and analysis examines the frontiers of digital transformation to help tech leaders navigate the future. Our Changelog newsletter delivers our best work to your inbox every week.
  • CIO
  • CTO
  • CISO
  • CSO
  • CFO
  • CDO
  • CEO
  • Architect Founder
  • MD
  • Director
  • Manager
  • Other
Visit our privacy policy for more information about our services, how Progressive Media Investments may use, process and share your personal data, including information on your rights in respect of your personal data and how you can unsubscribe from future marketing communications. Our services are intended for corporate subscribers and you warrant that the email address submitted is your corporate email address.