I want to learn Java, so I went to java.sun.com and am now downloading the Java SDK. For some reason I read the EULA... It has one interesting rule:

You acknowledge that Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility.

The Windows EULA includes no such restriction for Windows itself. However, it does include a paragraph about how the Java support in Windows is not intended for nuclear facilities, weapons systems, aircraft navigation and communication, direct life support, and one or two other things. It also states that Microsoft is contractually obligated to include this by Sun.

I love the confidence Sun is showing in Java....

You acknowledge that Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility.

While the inclusion of this statement by Sun, which you will find not just in Windows Java support agreements but in Sun's own Java readme files, may at first glance be seen as a lack of confidence or acknowledgment of a fault in the product, this is by no means the case. As noted, the Windows EULA has to include a term about the situations in which Java support is not to be used. The list of things you can’t use it for seems pretty long and is full of important sounding applications, but when it comes down to it, all it is really saying is that Java is not supposed to be used in real time applications. The reason behind the term is really quite simple and is not a ‘flaw’ in the design of the language, its very design just brings with it certain limitations.

Very generally speaking, most languages today are of two types - those in which the programmer must explicitly allocate and de-allocate memory for objects that are created (C, C++) and those in which the system takes care of memory management automatically – Java falls into this last category. Now, as anyone who programs in Java will know, it is a very convenient feature of the language that one can just go about creating objects without having to worry about memory leaks and other such bothersome things. You would never have to worry that you may have forgotten to free up some memory that is no longer in use and could potentially cause major hassles. It’s all taken care of for you.

How does this happen? It’s all thanks to the garbage collector. Basically, when you create an object a reference count for that object is also created by the Java Virtual Machine. Each time that object is accessed, for example by a method call, the reference count is increased, and each time the object instance falls out of scope the count is decreased. When the count reaches zero the object is then marked for destruction. However, much like on E2, the offending object is not removed immediately.

The garbage collector only runs at certain intervals, the options surrounding this are somewhat configurable, for example you can say that it should run when a certain percentage of the allocated heap memory has been used, however it is a largely unpredictable beast1 and one can never be totally certain when and for how long it will run. When it does run, it scans all the memory looking for reference counts of zero and then frees up that memory. If the application is a fairly large, complex and intensive one (as it probably would be in the case of a nuclear facility) this process can take a long time, as many as a couple of seconds, during which time the program slows down significantly and might even halt execution. Now while this may not sound like a lot of time to you, in the context of the program it could be an age, and herein lies the problem.

You wouldn’t want to find yourself or your program in a situation where execution suddenly stops as the garbage collector runs. Oops, those control rods should have been pushed in 3 seconds ago! Oh dear, patient’s heart stops beating for a bit there… Please immediately turn your aircraft .... *garbage collector* ... left. Arrgggh! You get the idea. Those seemingly tiny amounts of what basically amounts to down time can have disastrous consequences in real life, time critical applications. Hence the warning.

Because Java has so many benefits as a language, there have been many efforts to create a JVM which is capable of meeting the demands required by real time applications. The most fruitful of these has been one developed under the Java Community Process and it has already been used in small scale, real time applications.2 There are high hopes that it won’t be too long before those warnings are no longer required.



  1. There are other ways to try and help the garbage collector such as calling the System.gc() method, using the finalize() method and setting all object references = null when you are done with them. However, none of these are guaranteed to reclaim the memory immediately.
  2. Information and specs for Real Time Java can be found at:
    http://www.rtcmagazine.com/home/article.php?id=100069
    http://www.java-channel.org/display.jsp?id=c_16937

Log in or registerto write something here or to contact authors.