> >I have read some Web pages (sorry, forgot URIs) that made it quite clear
> >that "Java security" is not nearly what it's hyped to be. It's hacked in
> >rather than designed in. In one case, the language syntax was even
> >changed to plug a security hole.
> If Ada is to be more popular, it necessarily must be used in many
> settings where security and correctness are not taken seriously.
> Regardless of whether or not the Java bytecode engine has any
> security worth considering, a restriction against Ada compilers
> that produce Java bytecode is not reasonable.
I agree. I was just pointing out that it might backfire to fight this
stupid rule with the argument that the JVM is secure. The fact that the
JVM is not "proven" secure might be an argument FOR using Ada to minimize
The notion that an Ada applet might inadvertently let a hacker into a DOD
system is kind of silly. An applet in any language for the DOD must be
designed to meet certain requirements--including security. The DOD is not
going to load an applet from an unknown source just because it is written
in Ada (or Java or Fortran or....) If the applet reveals sensitive data
or trashes critical data, it is because of inadequate design, review,
and/or testing, not because of the language it is written or the virtual
CPU it is running on. The only two difference between Ada and Java on
this point are (1) Java needs MORE testing and MORE careful review; and
(2) Java will take longer to write in _some_ applications because of its
lack of certain features (and the presence of others).