Developing Applications with Multiple Programming Languages – an Investigation using C++ and Java

1. Developing Applications with Multiple Programming Languages – an Investigation using C++ and Java Paul Werbicki Supervisor: Dr. Robert C. Kremer Department of Computer Science University of Calgary

2. Agenda • Problem Statement • Problem Scope • Integration Approaches • A Hybrid Approach • The Java/C++ Class Library • Investigation • Results and Current Limitations • Contributions and Future Work

3. Problem Statement • How can a single object-oriented application written in one programming language integrate code from another language? • What approaches have been used to integrate multiple programming languages? • What requirements should an approach meet in order to provide benefit to a developer? • To what level is it possible to integrate separate languages, and what limitations currently exist?

4. Process App C++ Java Problem Scope • Programming languages used include: C++, Java and Visual Basic (.NET) • Integration occurs between native and virtual programming languages • C++ integrating Java • Java integrating C++ • Visual Basic integrating Java • Integration occurs between programming languages contained in a single application running within a single process

5. Library JNI Proxy Class Integration Approaches • Enhancement Libraries (MIIK Ltd., 2005; Trewhella, 2002; Gabrilovich & Finkelstein, 2001) • Simplifies use of the Java Native Interface (JNI) • Reduces developer effort by encapsulating common functionality • Proxy Classes (Gamma, Helm, Johnson, & Vlissides, 1995) • Transforms code from one programming language to another, providing a level of seamless integration

6. App RPC Integration Approaches • Remote Procedure Calls (Intrinsyc Software International Inc., 2005; JNBridge LLC, 2005) • Uses Inter-Process Communication and Wire Protocols such as Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA) • “Out-of-process” only solution, not usable within the context of a single application running within a single process • Requires additional resources such as an RPC server

7. JVM Microsoft JVM • Microsoft directly modified the Java Virtual Machine (JVM) to support programming language integration (Gilbert, 2004) • Raw Native Interface and J/Direct • Java and Component Object Model (COM) Callable Wrappers • Sun vs. Microsoft • Microsoft’s JVM enhancements failed to deliver a Java-compatible product • Sun’s litigation forced Microsoft to remove the JVM from the market, to be replaced by their .NET framework

8. Proxy COM Library JNI A Hybrid Approach • Combines the benefits of the Microsoft approach without modifying the JVM • Uses COM as an intermediate interface between C++ and Java • Implements as an Enhancement Library • Provides a Proxy Compiler Tool for greater level of programming language syntax integration

9. Code A COM Library Code B Java/C++ Class Library • Written in C++ and Java (using the JNI) • Based on the object-oriented programming paradigm • Uses standard COM interfaces as the contract between programming languages • Performs marshalling of all scalar types and most complex types • Proxy Compiler Tool allows secondary programming language code to conform to the syntax of the primary language

10. Accesses SMARTHOME API to control X10 Sends voice- devices based commands (Section 5.3.1) using CASA (Section 5.3.2) Queries physical devices using CASA to display in web-based interface (Section 5.3.3) Investigation • The Collaborative Agent System Architecture (CASA), A Multi Agent System (MAS) written in Java, was integrated with specialized devices using C++ and Visual Basic in an intelligent environment • X10 Physical Device Agent • Voice-Activated Light Switch • Web-Based Device Console Java C++ Visual Basic

11. Results • The Java/C++ Class Library successfully integrated multiple programming languages in most scenarios • Allowed the reuse of existing code without modification • Existing software with well-defined interfaces provided the highest level of integration • Inheritance across the native/virtual boundary required the use of a delegate class Interface Sub- system

12. CMyAgent inherits from casa.Agent, overrides handleMessage() Agent() CreateObject() AllocObject() regsiterWithLAC() joinCD() joinCD() joinCD() joinCD() sendMessage() sendMessage() sendMessage() sendCDMessage() handleMessage() ~Agent() Release() Message is received by casa.Agent::handleMessage, should be received by CMyAgent::handleMessage. Message is received from another agent Message does not propagate across the Native/Virtual Boundary. Inheritance Across theNative/Virtual Boundary C++ Java CMyAgent casa.Agent(C++ Proxy) JavaCOM casa.Agent CASA

13. Contributions • The Java/C++ Class Library is a combination of multiple integration approaches that is advantageous in many development scenarios • Provides a similar level of integration by containing the JVM, interfacing with it through the JNI • The complete source code is available to help with research projects that require applications written in multiple languages • Provides a basis on which further research into fully supporting the object-oriented programming paradigm may occur

14. Future Work • To fully support native/virtual inheritance an object-oriented interface is required, as the JNI provides only a procedural approach • Sun’s Java Research License offers the possibility of modifying the JVM to support such an interface without using COM • This interface could then be submitted to the Java Community Process (JCP) as a next generation interface of the JNI

15. References • Gabrilovich, E., & Finkelstein, L. (2001, January). JNI - C++ Integration Made Easy. C/C++ Users Journal, 10-21. • Gilbert, H. (2004). The Tragedy of Microsoft and Java. New Haven, CT, USA: Yale University. • MIIK Ltd. (2005). JNIWrapper. Kharkov, Ukraine: MIIK Ltd. • Trewhella, P. E. (2002). JNI++: SourceForge.net.

16. Additional Slides • Java Native Interface (2.1.2.2, pg. 11) • Component Object Model (4.1, pg. 38) • Class Diagram (4.2, pg. 45) • Ambient Intelligent Environment Diagram • Inheritance Expected (5.3.3, pg. 77) vs. Actual (5.4.2, pg. 83) • Delegate Class (5.3.2, Pg. 75)

17. Java Native Interface (2.1.2.2, pg. 11) • Based on the Netscape Java Runtime Interface (JRI) • Unlike Microsoft RNI and COM, it is not vendor specific • Standard native interface to the JVM • Used for embedding JVM into other applications • Avoids restrictions on JVM implementations • Binary compatibility between Java Virtual Machines • Exposes JVM internals • Remains open to future development

18. Java Native Interface (2.1.2.2, pg. 11) cont’d • Procedural-based library: • Invocation functions • Type and method mapping functions • Object and scalar array manipulation functions • Fields and methods are accessed by ID • Provides access to object references, garbage collection and exception handling

19. Component Object Model (4.1, pg. 38) • Component-based approach to software development • Allows components from independent vendors to work together • Allows components to be upgraded without recompiling the entire project • Programming language independence • Host environment independence

20. Component Object Model (4.1, pg. 38) cont’d • Procedural/interface-based library • Component/interface discovery functions • Standard interfaces for component/interface/method discovery • Dynamic interfaces for late-binding to interfaces/methods at run-time vs. early-binding during compile-time • Provides binary-compatibility • Methods are grouped into interfaces which are then grouped into components • Components and interfaces are uniquely identified • Dynamic discovery of interfaces and invocation of methods

21. Java/C++ Class Library (4.2, pg. 45)

22. Ambient Intelligent Environment

23. Inheritance Expected (5.3.3, pg. 77) vs. Actual (5.4.2, pg. 83)

24. Delegate Class (5.3.2, pg. 75)