About a year ago I discovered that the DII COE Integration and Run-Time
Specification (I&RTS) 4.0 prohibited the use of tools that compiled
languages other than Java into Java Byte Code (JBC). This obviously
precluded the use of Ada products such as JGNAT and AppletMagic to develop
"portable Web-based" applications. (The use of analogous compilers for
other languages, such as Eiffel and Python, were therefore barred as well.)
Here's the original prohibition:
"Developers shall not use compilers designed to convert code developed in
other languages (e.g., Ada, C++) to create Java byte-codes. This
restriction is important because such compilers may inadvertently bypass
intended Java security features." -- Section 8.2.3, bullet 3.
The original rationale for this in the I&RTS was an incorrect belief that
the JBC resulting from the compilation of other languages could bypass
Java's security features, and that only by using Java as the source of
class files could adherence to the security features be ensured. This was
a clear misunderstanding of Java's security model, as it is the
responsibility of a Java Virtual Machine (JVM) to enforce security. To the
JVM (and its security implementation), how a class file comes to exist is
An objection to this prohibition was created and discussed in this forum
in April of 2000, and with a large number of co-signers (some from outside
of the Ada community as well), was submitted to the DII COE Chief Engineer,
in accordance with the process described in the I&RTS itself.
I periodically attempted to follow up on its progress, but could get no
feedback. The only information I ever got back was a result of querying
the Chief Engineer, and his only response was a terse acknowledgement that
it was received and put into the process.
As it had been quite some time since I'd last tried to check up on this, I
went to see if an I&RTS update had been released--which had, it's now
version 4.1. I looked up the section corresponding to the original
"Miscellaneous" section, which has been renumbered as 8.2.4.
I was pleased to find that there is no longer any mention (pro or con) of
the means used to produce JBC class files. Although our original
submission suggested alternative wording for this bullet, simply removing
it can certainly be counted as removing an unjustified barrier to Ada.
As I mentioned, having never received any feedback, I have no idea what
role our submission played in the descision to remove the bullet. Perhaps
major, perhaps none, perhaps it was the Python advocates that got it out
:-) Whatever the reason, we did our part, and I'm pleased with the way
things turned out.
Marc A. Criley
Senior Staff Engineer
P.S. A plaintext version of the submission is available in the Team Ada