> >Most Java checking was put in there for security, not safety,
> Java rules prevent references to uninitialized variables, and the absence of
> unchecked deallocation (as well as the presence of other rules, such as the
> requirement that inner classes can only reference constants (final
> variables) from outer scopes) prevent dangling references. These have
> security implications but can also be regarded as safety issues.
> BTW I am perfectly well aware of the large number of omissions from Java ...
> [which may] lead to less safe programs. So I can argue this issue either way.
> But I have seen some folks from the Ada community dismiss Java as just a
> bunch of hype, and this is a serious delusion.
The number of changes made to Java and/or the JVM to solve security
problems (and some of the published security issues that are NOT solved)
show that the Java security claims ARE partly hype. They designed in
prevention for what they happened to think of, then advertised it as
"secure." It is no doubt more "secure" than Ada--but then, Ada never
advertised that you know longer have to worry about security!
And "omissions" are not Java's only problem. They claim that they removed
unsafe and unsecure features from C/C++ to create Java. Yet they left IN
the "break from switch" feature that has been adequately proven to be a
major cause of bugs.
Finally, any discussion of whether Java is "better" or even "adequate" for
real-time or any other domain needs to consider the actual language and
libraries, independent of the JVM, since Ada, Eiffel, Smalltalk, COBOL,
and many others can now be compiled to J-code, and since most of these can
interface with the Java libraries.