TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Proportional Font
Show HTML Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Criley, Marc A" <[log in to unmask]>
Thu, 6 Apr 2000 11:12:55 -0400
text/plain (56 lines)
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]
>

ATOM RSS1 RSS2