Java technology trends offer renewed promise for portable ...

Softwaremore os options open upJava technology trends offer renewed promisefor portable embedded applicationsBy Dave WoodBecause of the promise of increasedproductivity and reduced error incidence,achieving program portability hasalways been an important goal insoftware engineering. The goal ofportability has been met with mixedsuccess because of varying approachesto portability from one programminglanguage to another. Further, the specialcharacteristics of embedded, real-time,and safety-critical applications presentadditional challenges to portability. Daveexamines the characteristics of C++,Ada, and Java and their implications forportability in embedded development.Creating highly portable code is animportant mechanism for increasingsoftware development productivity whileimproving software maintenance andlongevity. Today’s primary languages formilitary embedded systems – C++ andAda – along with emerging embeddedJava technology, each provide their ownportability characteristics.Not all portability is created equalC and C++ programs often are presumedto be portable. Consider the followingcode:This piece of code will compile andrun on practically every commercialprocessor/operating system combinationin existence. The fact that it will do sois not a reflection of anything inherentlyportable about the language itself, butrather it is a reflection of the fact that C orC++ compilers are available on essentiallyevery platform. As such, C qualifies as aportable language, at least so long as theprograms adhere to commonly supportedcore syntax. Thus C/C++ are portable inthe sense of platform pervasiveness.On the other hand, Ada was designedspecifically to promote code portabilitywith an emphasis on tightly controlledinternational standardization and rigorousconformance test suites. Although Adaincludes many implementation-dependentfeatures, its portability features providesubstantial built-in standard librariesand a standard multi-threaded executionmodel. As such, Ada also qualifies as aportable language. Yet, although Adacompilers are available on a wide array ofplatforms, they are not nearly as widelyavailable as C/C++ compilers. Therefore,we consider Ada portable in the sense ofplatform independence.C/C++ is portable thanks to ubiquityrather than design. Ada is portable thanksto design rather than ubiquity. These kindsof distinctions form a rich basis for “mylanguage is better than your language”debates among advocates.Defining portabilityClearly, portability means different thingsto different people. By evaluating themerits of various portability paradigmsagainst the actual needs of a particularaudience, we can make value judgmentsabout the suitability of a given language’sportability characteristics. Table 1 listscross-platform portability factors, andtheir relative importance is dependentupon individual needs.Choosing between C++ and Ada offers atrade-off between a more portable design(Ada) and a wider potential pool ofavailable platforms (C++). A third option,Java, offers the promise of both platformpervasiveness and platform independenceat the same time.ForSinglePrintOnlyIn the nonembedded software community,Java has already emerged as the favorite.Studies indicate that Java popularity has#include main(){printf (“This code isportable!\n”);}ComponentCompilerLibrariesSource CodeRuntimePossible Cross-platform Portability RequirementsCompilers for language exist on required platformsCompilers exist and conform to same standardCommon library types are commercially availableCommon libraries inclusive in language standardCompatible across platforms and OS versionsCompatible across variants of language and librariesGUI code same across platforms without changeNo exposed OS or hardware dependenciesSame runtime API across platformsConsistent runtime behavior across platformsTable 1Military Embedded Systems©2007 OpenSystems Publishing. Not for Distribution

more os options open upSoftwareLanguage UsageUsage Trends of Ada, C, C++, and JavaC/C++CC++AdaJAVAovertaken that of C/C++ in enterprise anddesktop computing (see Figure 1), and isavailable on most computing platforms.At the same time, Java’s design featuresmirror and even exceed many of thehigh-portability characteristics of Ada.This is a reflection of the “Write Once– Run Anywhere” philosophy that drovethe design of the Java language, the Javalibrary set, and the Java virtual machine.As seen in Table 2, C++, Ada, and Javaeach offers its own strengths. For militaryembedded applications, the question iswhich of these options presents the bestmatch to priorities. To help answer thatJAVA1993 1998 2003 2008Data Source: Programming Language Trends, An EmpiricalStudy of Programming Language Trends, Yaofei Chen, PhDdissertation, New Jersey Institute of Technology, August 2003.Figure 1question, three key areasto consider are sourcecode portability, libraryportability, and behavioralportability.Source code portabilityAt the source code level,it is certainly possible towrite portable C/C++ code,C/C++given careful attentionto coding practices.C++ However, C/C++ presentsmany opportunities forAdamaking nonportable code.C An example of some ofthe thought processesrecommended for C/C++programmers to improveportability can be foundin The C++ PortabilityGuide (see sidebar).This publication identifies a number ofareas where C and C++ programmersneed to tread carefully in order to achievehigher portability.In contrast to C++, Ada is a rigorouslyspecified language with very welldefinedand longstanding internationalstandardization. Even so, Annex M of thelanguage standard identifies more than100 implementation-dependent aspectsof the language that should be carefullyencapsulated to facilitate portability.An example of an area where a programmerneeds to take extra care with C/C++Portability Factor Ada C++ Javais with the type system. C/C++ typing iscomparatively loose and implementationdependent. Details of atomic types suchas type size (for example, the numberof bits in shorts, ints, and longs) as wellas “endianness” are implementationspecific.Other nonportable behaviorincludes the value of uninitializedvariables and the results of accessingmemory that has been freed. For Java,details and behaviors of this sort areeither explicitly defined and abstractedaway from the programmer or simply notapplicable.Library portabilityBuilding complex systems is not practicalwithout the availability of off-the-shelflibraries. Many such libraries exist for allthree of the languages discussed herein,but not all are equally portable. Librariescan be considered most portable if theyare defined as part of the standard, ifthe content of the standard libraries iscomprehensive, and if the standard iswidely adopted across implementations.In this regard, Java clearly excels tolevels far beyond any competing offering.The core Standard Edition libraries aloneconsist of 166 packages and 3,279 classes.Although the C/C++ ecosystem providesan extensive collection of open sourceand commercial libraries, the librariesthat are inclusive in the language standardare comparatively Spartan. Library supportcan vary from implementation toimplementation and from platform toplatform, with the consequence of havingan impact on portability.ForSinglePrintOnlyPlatforms moderate pervasive growingStandardization high moderate highBuilt-in Libraries moderate minimal extensiveThird Party Libraries moderate extensive extensiveCommercial Use minimal extensive extensiveRuntime Behavior defined undefined definedSafe Programming yes no yesTable 2The standard Ada library set is consistentacross implementations and very welldefined.In comparison, the scope ofthe standardized set of Java libraries isstaggering and growing because of theparticipation of a large, cooperative, andvibrant development community. LikeC/C++, Java enjoys a very large ecosystembeyond the standard such as APIsfor 3-D graphics, OpenGL, compression,and numerical analysis. Some librarieshave achieved quasi-standard status andubiquitous availability. An example ofthis is the SWT graphics library from theEclipse Foundation.Military Embedded Systems©2007 OpenSystems Publishing. Not for Distribution

Softwaremore os options open upBehavioral portabilityEven if portability is achieved at thesource code level and at the library level,the runtime behavior of a program maybe very different from one platform toanother. In the case of C/C++, runtimebehavior is undefined. C/C++ does notspecify mechanisms for execution threads,priorities, or even interprocess communications.Thus, these types of issues arerelegated to the operating system, and theinterfaces are application-specific.In contrast, both Java and Ada specifya clear runtime semantic. Java goesfurther than Ada in specifying not onlysemantics related to thread executionand communication, but also in definingan abstracted operating system completewith its own virtual machine code andmemory management known as byte codeand garbage collection, respectively.For a particular application, all ofthese runtime characteristics may befully implemented within the JavaVirtual Machine, or may be partiallymapped to underlying operating systemfunctionality where available. In anycase, the application code is unawareof the implementation layer, and so iscompletely portable.It is this sense of portability thatmakes Java so attractive for embeddeddevelopment: It is intrinsically mucheasier to move from one real-timeoperating system to another, makingmission-critical developers much lessdependent on, and less locked into, aparticular RTOS supplier.Even with Java’s high level of portability,there remain behavioral characteristicsthat are not consistent across platforms.Most notably, the Java standard doesnot specify thread timing behaviors,nor predictability of garbage collectionactivities. These deficiencies generallyare not a concern for desktop andenterprise applications but are a majorhindrance to the spread of Java to realtimeand embedded applications wheretiming and predictable runtime behaviorare critical.The C++ Portability Guide(www.mozilla.org/hacking/portable-cpp.html)1. Be very careful when writing C++ templates.2. Don’t use static constructors.3. Don’t use exceptions.4. Don’t use runtime type Information.5. Don’t use C++ standard library features, including iostream6. Don’t use namespace facility.7. main() must be in a C++ file.8. Use the common denominator between members of a C/C++compiler family.9. Don’t put C++ comments in C code.10. Don’t put carriage returns in XP code.11. Put a new line at end-of-file.12. Don’t put extra top-level semicolons in code.13. C++ filename extension is .cpp.14. Don’t mix varargs and inlines.15. Don’t use initializer lists with objects.16. Always have a default constructor.17. Be careful with inner (nested) classes.18. Be careful of variable declarations that require construction orinitialization.19. Make header files compatible with C and C++.20. Be careful of the scoping of variables declared inside for()statements.21. Declare local initialized aggregates as static.22. Expect complex inlines to be nonportable.23. Don’t use return statements that have an inline function in thereturn expression.24. Be careful with the include depth of files and file size.25. Use virtual declaration on all subclass virtual member functions.26. Always declare a copy constructor and assignment operator.27. Be careful of overloaded methods with like signatures.28. Type scalar constants to avoid unexpected ambiguities.ForSinglePrintOnly29. Always use PRBool for boolean variables in XP code.C++30. Use macros for C++ style casts.31. Don’t use mutable.32. Use nsCOMPtr in XPCOM code.33. Don’t use reserved words as identifiers.The C++ Portability Guide was made available for distribution under the CreativeCommons License (http://creativecommons.org/licenses/by-sa/2.0/).Military Embedded Systems©2007 OpenSystems Publishing. Not for Distribution

more os options open upSoftwareTechnologies such as real-time garbagecollection and predictable thread semantics,which are embodied in Aonix‘sPERC Virtual Machine, provide the behaviorrequired for mission-critical applicationswhile remaining fully portablethanks to syntactic compatibility withJava standards. In the realm of hard realtimebehaviors, new technologies havebeen developed that provide precisememory management and hard real-timeguarantees suitable for highly constrainedand safety-critical applications. Theseupdates to the Java standard are beingdeveloped under the umbrella of the JavaCommunity Process [JSR 302 – SafetyCritical Java Technology]. This effortis being directed by the Open Groupwith the cooperation of key companiesincluding Sun, Boeing, Aonix, RockwellCollins, and Siemens.Similarly, abstract interfaces for “closeto the silicon” activities such as interrupthandling, memory mapping, and devicecontrol are being developed based onspecifications that are friendly to crossplatformportability.Java’s portability reduces risk,increases productivityAs embedded applications becomeincreasingly complex, placing the burdenof source code, library, and behavioralportability on developers is increasinglyrisky and nonproductive. It also resultsin software that is more error-prone andmore costly to maintain. Although C++,Ada, and Java each have strengths in termsof portability, the capabilities offered byJava technologies are inherently moreproductive and scalable, and thereforerepresent a better long-term bet forembedded systems development .Graphics pose portability problemOne of the biggest obstacles to portability for desktop and enterpriseapplications is at the GUI level. Traditionally, GUIs have been applicationspecificboth in characteristics and in terms of the API. A measure ofportability can be achieved by building an abstraction layer that is consistentacross platforms. Underneath, the abstracted API binds to the underlyinggraphics engine, such as the Win32 API for Windows, or a flavor of X11on UNIX or Linux platforms. Traditionally, the GUI has been considered tobe tightly tied to the operating system because that operating systems’users are sensitive to a particular look and feel and expect a consistentfunctionality across applications on their platform.Neither C/C++ nor Ada provide a standard GUI API, leaving questions ofGUI-specific bindings outside the scope of the language. In contrast, Javaincorporates GUI APIs (Swing and AWT) directly in the standard. Applicationswritten to the Swing standard ought to have high portability betweenconforming platforms through the use of a common API. As mentionedpreviously, the SWT API, defined as part of the open-source Eclipse libraries,offers another portable graphics interface that is widely used by Javaprogrammers. Whereas the goal of Swing is to offer a consistent crossplatformlook and feel, the goal of SWT is to offer cross-platform portabilitywith a look and feel matching that expected on the target platform. Whichis better is a matter of opinion, but both offer a means to source codeportability.Increasingly, complex embedded applications require more sophisticatedgraphics capabilities, yet these applications continue to be demandingin terms of performance and footprint characteristics. Swing solutions,typically mapped to a native GUI such as X11, are usually too big, slow, andunpredictable for use in mission-critical embedded applications. Specializedembedded graphics engines such as PEG+ from Swell Software are a moreappropriate fit. SWT bindings to PEG+ exist, offering the high performanceneeded for multi-platform embedded applications while also accentuatingportability.Dave Wood has beeninvolved with realtimeand embeddedsoftware for more than25 years. His activitieshave included analysis,design, coding, testing,research, and marketing of technologyin commercial avionics, telecom,defense, multimedia, software tools,and consumer electronics applications.Dave has worked for Lear Siegler,General Electric, SofTech, ComLogic,and the Software Engineering Instituteat Carnegie Mellon University,and presently serves as marketingdirector for Aonix. He holds a BA fromKalamazoo College.Aonix5930 Cornerstone Court W, #250San Diego, CA 92121858-824-0254 • Fax: 858-824-0212dave.wood@aonix.comwww.aonix.comForSinglePrintOnlyMilitary Embedded Systems©2007 OpenSystems Publishing. Not for Distribution

Softwaremore os options open upSafety-critical Java enhancesreliability while reducing testand certification costsBy Ole N. Oest, DDC-IJava provides an excellent environment for developing embeddedsoftware. Until now, however, Java has been too big, complex,and unpredictable for safety-critical applications. To address thisshortcoming, the Safety-Critical Java Expert Group (JSR 302) (http://jcp.org/en/jsr/detail?id=302) is working on a subset of real-timeJava that will make it easier to develop reliable, deterministic codesuitable for safety-critical applications requiring FAA certification.The Java Community first addressed the real-time limitationsof Java when it convened the Real-Time for Java Expert Group(RTJEG) in 1999, which developed the Real-Time Specification forJava (RTSJ). This specification, an extension of The Java LanguageSpecification and The Java Virtual Machine Specification, enhancesreal-time responsiveness by introducing mechanisms for preemptivescheduling and priority inversion avoidance, and providing toolsthat allow tasks to avoid garbage collection delays.The Safety-Critical Java Expert Group will further refine the RTSJ,making it suitable for safety-critical applications with the mostdemanding testing requirements. In particular, the Safety-CriticalJava Expert Group will trim the RTSJ spec, ensuring that conformingsafety-critical applications can be run without requiring a garbagecollector or heap at all, and ensuring that the rigors of FAAcertification to DO-178B level A can be met.As a member of the Safety-Critical Java Expert Group, Phoenix-basedtool developer DDC-I, Inc. (www.ddci.com/pr) will be drawing onits pioneering work in developing the Ada 95 specification, whichis the “gold standard” for safety-critical programming languages.DDC-I will also bring to bear its extensive FAA DO-178B experience,which is the “gold standard” for certifying safety-critical systems.Ole N. Oest is the chief operating officer of DDC-I, Inc., amanufacturer of safety-critical software development tools formore than 20 years. Ole can be contacted at ooest@ddci.com.ForSinglePrintOnlyMilitary Embedded Systems©2007 OpenSystems Publishing. Not for Distribution