We all know that Microsoft doesn’t like Java. But did you know that Microsoft in their license agreement even warns users that Java technology is potentially deadly?
Yakov Fain discovered this when he was reading a Microsoft end-user license agreement:
The software product may contain support for programs written in Java. Java technology is not fault tolerant and is not designed, manufactured, or intended for use or resale as on-line control equipment in hazardous environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life support machines , or weapon systems, in which the failure of Java technology could lead directly to death, personal injury, or severe physical or environmental damage.
See also the article on TheServerSide, one of the major J2EE community websites.
January 2nd, 2006 at 11:01 pm
This is Hilarious!
Are they trying to imply, though, that their software IS fault tolerant?
January 2nd, 2006 at 11:11 pm
Obviously not.
Its like me saying - “Aviad is a terrible potato”
I’m not saying I am any better a portato, but Aviad is definatly a terrible potato.
January 3rd, 2006 at 1:50 am
I remember reading this on a small piece of paper included with my copy of Windows 98
January 3rd, 2006 at 4:04 am
This verbage is common in software licenses:
Apple Quicktime
Objectmatter
Apple Webobject
Filemaker
Acez
Macromedia
January 3rd, 2006 at 8:31 am
Hi,
Something reminds me of my old days (around 1999-2000).
Earlier days, the JDK 1.2 source code had the same sort of message. Looks like microsoft has picked the same message from there. Althought I guess the world deadly and death was missing. But they did caution not to use Java in nuclear, aircraft navigation etc.
Just open the src.zip directory on JDK1.2 and see it in any .java file yourself.
Regards,
Goldy.
January 4th, 2006 at 8:50 pm
As far as I understood this, it was to do with Garbage Collection. Back in those days, MS language runtimes (like VB6) did not do garbage collection, but relied instead on reference pointer counting. This had the advantage that the behaviour of finalizers at runtime was predictable, or at least consistent, but had the disadvantage of circular references and memory leaks.
Garbage collection, on the other hand, is not predictable in the same way, and can cause an application to hang at inopportune moments, and so was deemed unsuitable for critical applications.
However, two caveats.
1. I might have just made this up and later convinced myself it was the true explanation for the warning. I tend to do that sometimes.
2. With modern MS .NET languages, Garbage Collection is present and is almost identical to Java.
January 5th, 2006 at 12:42 pm
Software for life-critical systems must be certified before it can be used. Certification is a rigorous process, in which both the development environment and the quality of the software itself are evaluated. Aviation software, for instance, must be developed according to the DO-178B standard.
A DO-178B compliant development process yields not only the software itself, but also a huge amount of documents in which every aspect of the software and its development is described and recorded. This makes such processes very expensive, and not everyone is prepared to follow such standards.
Even if you produce Java software in a DO-178B compliant process, you are still dependent on a JRE whose DO-178B compliance is not known (it probably is not). This impleis that the whole application (including your own compliant parts) is not compliant and can not be certified. I have always assumed that the legal implications of this fact are the reason for the texts in licenses.
Memory management, whether it is based on garbage collection, reference counting (which I consider another grabage collection strategy) or (m)alloc/free-based approaches are always a source of bugs and require special attention in any life-critical development process. Many garbage collection strategies interfere with real-time requirements, so it is unlikely to find these on board of an airplane, but it is not impossible, nor is it forbidden by the regulations.
January 12th, 2006 at 10:02 am
And that is where realtime java comes in play. See this article about Java and DO178B
)
(Thank you google for providing this link when searching for both keywords
January 13th, 2006 at 5:06 pm
Okke, I realy like the phrase: “Why Java is Superior to C and C++” in that article
January 16th, 2006 at 1:03 pm
Yeah, sure, there is a lot to be said about the reasons for this “superiority” of Java, but first I would like to answer the question: “Is Java superior to C[++]?”. But that is worth a thread of its own.
I already stumbled on the claim in the very first sentence of the article, that Java offers a two- to ten-fold productivity benefit over C[++]. I know from the literature that productivity of C is much higher than of C++, so comparing Java to both languages is silly. But I have never seen any support, neither in the literature nor in personal experience, for the assumption that Java allows a higher productivity.