Twelve reasons to use Ada 95
for Java applet development

  1. Ada 95 is an ISO standard. The language definition has been stable for some time. This means, there is a large body of existing Ada code available for reuse in applet development. Also, as a standard Ada 95 potentially isolates applet developers from the still-evolving Java VM definition.

  2. True compilers for Ada 95 are available for many hosts and targets, allowing easy reuse of code developed outside the Ada/Java world for applets, and reuse of code developed under Ada/Java in other environments.

    For example, if you develop a sophisticated game in Ada/Java, one could then compile it into machine code for an existing game machine for delivery in a game cartridge. Similarly, if you develop a graphically-oriented client/server front end in Ada/Java, one could compile it into machine code for delivery on a floppy disk to run full-speed on a PC that has no Java capability.

  3. Ada was developed with many of the same language design principles that led to Java. Although the developers of Java started with C++ as their "base language" they made changes where they found C++ to be lacking. Many of these changes are right in line with Ada's own design philosophy. [Language Comparison]

    Like Ada, Java adopts the philosophy that detecting errors is best done early:

    One reason that dynamic languages are good for prototyping is that they don't require you to pin down decisions early on. Java has exactly the opposite property; it forces you to make choices explicitly... [1]

  4. Ada has high-level features not found in Java which can improve productivity and reuse. Ada 95 already has generic templates and enumeration types, two higher-level features programmers seem to miss when using Java.

  5. Ada 95 supports value semantics for object declarations, assignment, and equality, which minimizes the chance of unintended aliasing, and simplifies the programmer's job.

  6. Ada 95 was designed with first-class arrays and records in mind. In constrast, the Java syntax for treating arrays and records as "first-class" data types is not ideal, due in part to Java's C++ heritage.

  7. The Ada 95 data-oriented synchronization building block, protected types, is significantly easier to use correctly than the wait/signal paradigm provided by Java.

  8. Ada supports more "informative" interfaces:

    Ada has an excellent track record for supporting the development of complex systems. As Web-based applications grow, the advantages of separate, informative, strongly type-checked interfaces should become increasingly obvious.

  9. User-defined operators are available, so the developer can create complex-number packages, matrix arithmetic packages, etc., and use a natural infix operator notation for binary operations.

  10. Ada is well-known as one of the most readable and "humanly-engineered" of programming languages. Few abbreviations or special-character combinations are used. All compound constructs have an appropriate "end" bracket, such as if ... end if, loop ... end loop, procedure P ... end P. Single token errors rarely go undetected by the compiler; an extra or missing ";" or "=" will not produce a legal program with a completely different meaning. Case statement alternatives do not require a "break" to end the alternative, thereby reducing the chance for error.

  11. There is a body of available, mature Ada tools to use.

  12. Existing Ada 95 training materials and expertise are immediately reusable in the Ada/Java world.

Java, C++, Ada:
A Brief Comparison

Java C++ Ada/Java
Inheritance Single Multiple Single (some MI)
Preprocessor No Yes No
Header files No Yes Yes (interface specs)
Garbage Collection Yes No Yes
Operator Overloading No Yes Yes
Pointers No Yes No
Template No Yes Yes (generic units)
Exception handling Yes Yes Yes
Native multi-threading Yes No Yes

Based on a January 1996 Borland Java World List Server Message. Bill Beckwith added the Ada column.

References

[1] Java White Paper.
Contributors to this page: Bill Beckwith, Rich Hilliard (rh@mitre.org), Tucker Taft.

Back to Home Page