Chapter 3 Section 3
Upward Compatibility Risks
Ada 95 is highly upward compatible with Ada 83; PEOs and PMs will be
able to preserve their investment in Ada 83 software when transitioning to Ada
95. Nevertheless, some risks exist, as explained in this section. PEOs, PMs,
and their developers and/or contractors will be able to mitigate these risks
using actions defined in this section.
The brief answer to this question is - very compatible! Ada 95 is
almost a strict superset of the Ada 83 language. However, it should be
noted that there a few areas where upward incompatibilities cannot be avoided.
For example, to add new capabilities such as object-oriented programming and
improved real-time programming it was necessary to introduce new keywords into
the language. These keywords will make some Ada 83 programs incompatible with
Ada 95. Fortunately, it is possible to automatically detect this kind of
upward incompatibility by running the source code through an Ada 95 compiler.
Fixes can be made using automated tools.
Based on current analysis of Ada 83 and existing Ada 95 programs, it
is expected that a majority of existing Ada 83 programs will not have
to be significantly altered; the most common incompatibilities will be
detected when the software is recompiled with an Ada 95 compiler.
Based on early Ada 95 experiences, there are five upward incompatibilities
that most organizations need to be aware of:
- New reserved words - Ada 95 has six new reserved words. Any Ada 83 program
that uses these as identifiers is an illegal Ada 95 program. All Ada 95
compilers will diagnose this problem. It is straightforward to use an
editor's Search and Replace function or to write a script to change all of the
identifiers into ones that do not conflict with the keywords.
- Type Character has 256 values - Ada 95 will allow the use of international
characters by using the ISO Latin-1 character set (a superset of the common
ASCII characters). A few programs that depend on the fact that Ada 83's type
character has 128 values will be affected by this change. The ISO Working
Group maintaining Ada has already allowed this change in Ada 83. An Ada 95
compiler will not be able to automatically detect all cases of
this problem. Peer inspection and automated tools should be used to help
diagnose this situation.
- Generic Parameters - Ada 95 differentiates between two cases of generic
instantiations; Ada 83 does not. This change will require that some Ada 95
programs add the characters "(< >)" to some code. Ada 95
compilers will automatically detect this situation, and the change is very
straightforward. This change will detect some previously undetected errors
and will increase the portability of some Ada 83 software.
- Library Package Bodies - In Ada 95, it is now illegal to supply a body to
a package that does not require one. This change eliminates a class of
subtle errors that can occur in Ada 83 where a package specification - but not
the body - can be recompiled, and the error goes undetected. This will
automatically be detected by Ada 95 compilers.
- Numeric Error - In Ada 95, this exception has been changed
to be a renaming of Constraint_Error. This is consistent with
several official clarifications of the standard since 1983. This
will, however, create a few situations where old code must be
slightly modified to ensure that both exceptions are used consistently.
An Ada 95 compiler will detect these situations automatically.
Beyond these major upward incompatibilities there are approximately 25
"pathological cases" that, while technically upward
incompatibilities, are highly unlikely to occur in actual systems. Most
organizations will never encounter these and they can safely be the worry of
only the chief technical leader for the development project and not the PEO or
The most important upward compatibility issues have been summarized on
a one-page flyer that is available from AdaIC. More comprehensive details can
be found in the document Ada 95 Upward Compatibility Guide V6.0.
For more information, see Appendix A.
One of the first actions that PEOs and PMs must take, even
prior to first Ada 95 adoption, is to ensure that contractor/developers
working on Ada 83 development activities produce software that
is upwardly compatible with Ada 95. Existing Ada 83 code should
also be evaluated. To accomplish this, PEOs and PMs should:
- Supplement the contractor/developer's internal peer reviews with a step to
assess the upward compatibility of the project's software. (This review should
consist of both manual and automated checks.)
- Supplement formal Government software reviews with a step that reviews the
status of all code for Ada 95 upward compatibility.
Emphasis in these reviews should be on the cost-effective placement
of all Ada 83 software currently under review into three categories.
(Most Ada 83 software will fall into categories 1 or 2.)
1) Ada 83/Ada 95 Compatible - This software may be
recompiled using an Ada 95 compiler as is.
2) Potentially Compatible - This software contains one or more
simple incompatibilities but can be made Ada 83/Ada 95 compatible using a
combination of automated and manual means.
3) Vendor or Application Specific Implementation - Software in this
category is not Ada 95 compatible and it would not be cost
effective to make this software Ada 83/Ada 95 compatible. For example, the
software in question might make use of a vendor-specific run-time extension
that has been replaced by a standard Ada 95 feature. Additionally, if the
software is maintained by another organization, then it may remain Ada
83-specific until its owners migrate it to Ada 95. Software in this category
will typically be scheduled for future re-engineering into Ada 95. Projects
may encounter similar problems when porting Ada 83 code from vendor to
Eventually, projects moving to Ada 95 will begin to encounter
a fourth category of software:
4) Ada 95 Only - Software that makes use of new Ada 95
features (such as tagged types or hierarchical libraries). This
software will not be backward compatible with older Ada 83 compilers.
PEOs and PMs should be aware that creating this kind of software
represents their move away from Ada 83 compilers.
Once the software under review has been categorized, the PEO and PM
staff must then determine the disposition of "potentially
compatible" software. If funds become available and the payback
is judged sufficient, the software should be revised to make it upwardly
compatible. Typically this will be done as part of the project that creates
the "potentially compatible" Ada 83 software. However, if the
current project is resource constrained, then the software should be scheduled
for upgrade either as a separate project or as category 3, "Vendor or
Application Specific Implementation".
Ada 95 software needs no special effort to integrate,
communicate with or call Ada 83 software. In most cases, by simply
compiling the Ada 83 software along with new Ada 95 code, the Ada 83 code is
immediately available for reuse in the new Ada 95 environment. PEOs and
PMs should, therefore, ensure that the Ada 83 code is upwardly compatible
(see the previous section). Ada 95 is not a
new language, it is an incremental improvement on Ada 83.
Current evidence suggests that the majority of Ada 83 software will be
upwardly compatible and will run unchanged when compiled by an Ada 95
compiler. Of the fraction that is incompatible, the majority can be made
upwardly compatible by using simple automated tools such as text editors,
shell scripts or ".com" and ".bat" files. PEOs and
PMs should expect to continue using existing Ada 83 software both during and
after their transition to Ada 95.
PEOs and PMs should expect to make use of their existing
investment in Ada 83 tools. These tools will be useful
in two different ways:
- Continue to Use Ada 83 Tools Where Appropriate - During the
process of Ada 95 adoption, PEOs and PMs must consider two kinds of software:
Ada 83/Ada 95 compatible software and Ada 95 only software.
Ada 83/Ada 95 compatible software is both upwardly and downwardly
compatible and may be processed with both Ada 83 and Ada 95 tools. Ada 95
only software makes use of new Ada 95 features and may only be processed
with Ada 95 tools. By maximizing the use of Ada 83/Ada 95 compatible
software, PEOs and PMs can continue to make use of their existing Ada 83 tools
during the transition period. As Ada 95 only software becomes dominant
(i.e., as projects begin to make significant use of Ada 95), then projects can
incrementally increase the Ada 95 toolsets and support.
- Upgrade to "next version" Ada 95 tools -Since Ada 95 is
an incremental upgrade and not a new language, tool vendors are building on
their Ada 83 toolsets and experience. As a result, some tool vendors are
offering Ada 95 capabilities in the new versions of their Ada 83 tools, making
Ada 95 capabilities available under the standard maintenance license for the
product. Therefore, projects that have paid for maintenance or support may be
able to migrate to Ada 95 technology at a very low cost and with no loss of
their investment in Ada 83 tools and environments. PEOs and PMs should contact
tool vendors directly.
Ada 95 has been designed to help projects continue to get
maximum use from their legacy software as they incrementally migrate
to their new language, environment and/or platforms.
When transitioning from one language to another, it is necessary to
preserve the organization's investment in software that was written in the
previous language(s) - legacy software. PEOs and PMs are not
expected to convert all of their legacy software to Ada 95, this is
neither necessary nor cost effective. Developers should exploit Ada 95
features to interface their new Ada 95 software with the existing legacy code.
This will permit incremental upgrades and enhancements to be written in Ada
95, minimizing cost and project risk.
Ada 95 developers have several kinds of support for interfacing
with legacy code:
- "Pragma Interface" has been enhanced in Ada 95 to allow
developers greater control over the names generated by the programming
- Ada 95 now defines standard interfaces to C, FORTRAN, and COBOL within the
core standard. These packages help developers to more quickly create
interfaces to language-specific code by supplying standard types and
conversion routines. Compilers may provide any of the three packages. If
provided, they must conform to the standards definition.
- Ada 95 also provides enhanced interfacing primitives to smooth the
interface with other languages such as JOVIAL, CMS-2, and assembly languages.
PEOs and PMs should remember that it is still up to the vendors to provide
support for each particular compiler's language calling conventions. To ensure
that a project can interface with a specific language or compiler, project
staff should check with their Ada compiler vendor.
To maximize the use of legacy code within new software development or
re-engineering efforts, projects should:
- Examine the legacy software to determine the areas of maximum
- Make these areas available to the new system through
"wrappers". A wrapper is a layer of software (a binding) that
allows the new Ada 95 code to call on the old software (regardless of the
language it was written in or the platform on which it runs). This new
software layer will allow the project to make use of the legacy system until
it is replaced.
- When it is cost effective, replace the old legacy code with new software;
the wrapper layer serves to insulate the new Ada 95 code and ensure stability.
The old legacy code can be replaced with new Ada 95 code with little or no
Ada 95, with its language interfacing features, is ideally positioned as a
technology to help preserve a group's investment in legacy software and
minimize the risk of transition.
For more information see the section on COTS, Legacy
Software, and Multi-Language Software Development.
Previous Section - Tools and Environment Related Risks
Next Section - Technology Transfer Related Risks
Table of Contents