I made the following postings on comp.lang.ada to get some general feedback, and Britt Snodgrass subsequently suggested I repost them to Team Ada. First the original posting: -------------------------------------------------------------------- To Ada to JBC compiler vendors: Section 8.2.3 (Miscellaneous) of the Defense Information Infrastructure Common Operating Environment (DII COE) Integration & Run-Time Specification (I&RTS) v4.0 states that "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." Is this a legitimate concern? I can kinda see how it might be, since for instance Java forbids things like uninitialized objects (though I vaguely recall some kind of exception to that), which Ada permits. I suspect I could probably come up with some other potential problems if I dug into it. If the Ada to JBC compilers do not introduce the security risks that the I&RTS warns about, some educating is clearly called for. Marc A. Criley -------------------------------------------------------------------- After getting the hoped-for raising of wrath and ire, I followed up with this: -------------------------------------------------------------------- > Given the resounding repudiation of this prohibition against Ada (or > other language) to Java compilers, I'd like to try to get it removed. > > Though I'm not working on a DII COE compliant program, I'm going to try > to look at and work the process to get it removed. If anyone > (particularly among those responding) has any technical material, white > papers, etc., with which to buttress this effort, I would be happy to > incorporate those into this drive. > > Alternatively, if someone feels they're in a better position to attack > this issue now that it's been identified, I'll defer to and support > them. > > Thanks for the responses. > > Marc A. Criley > Software Architect > Lockheed Martin M&DS > [log in to unmask] >