Java to C+ + What could be done

1. Java to C++What could be done LC Software Workshop, 28-29 May 2009,CERN P. Mato /CERN

2. Introduction • What could be done depends strongly on what are the real needs and use cases (previous discussion by Norman Graf) and what we are ready to invest • Basic assumptions • Existing Java code needs to be preserved • Development of Java applications will continue • Interoperability • Until now the interoperability has been achieved by throw persistent ‘data’ (LCIO, xml files, etc.) • True interoperability implies collaboration of Java and C++ classes in the same running program LC Software Workshop -- P. Mato/CERN

3. Calling C++ from Java • Most of the flow from is from Java to C++ • ‘The main program is Java program’ • Using existing C++ libraries from Java • Leverage from existing code (e.g. Geant4) • Producing C++ data structures that can be then used by C++ • HepMC, Geant4 Geom, LCIO event, ROOT trees and histograms, etc. • Little reverse flow should also be possible • C++ callbacks written in Java • Implementation of C++ interfaces in Java (framework interfaces) LC Software Workshop -- P. Mato/CERN

4. Equivalent Experience with Python • Developed PyROOT to enable the usage of any C++ class from Python • Making use of dictionaries (non intrusive!) • generated by rootcint or gccxml • Dynamic • Python classes are created when needed • Mapping of the C++ constructs to Python equivalent • Found an adequate solution for each situation • Additional useful ‘pythonizations’ LC Software Workshop -- P. Mato/CERN

5. What can be done? • Julius Hrivnac provided me with very useful information and pointers • The most promising is a solution based on JNI (Java Native Interface) • E.g. JavaRoot from SubirSarkar • Automatically generating Java classes from the C++ definitions (header files) at ‘build-time’ • Java objects are ‘proxies’ to C++ objects Java C++ JNI(generated) Callback LC Software Workshop -- P. Mato/CERN

6. Code generation and language mapping issues • Positive experience with GCCXML • Using it to generate Reflex dictionaries (any C++ can be ‘digested’ by GCCXML) • Some reasonable mappings of C++ to Java have already be found • E.g. namespaces, operator overloading, default method arguments, abstract classes, etc. • Some of the C++ constructs need to be further studied • True multiple-inheritance, templated classes/methods, function pointers, void*, etc. • For the object ‘ownership’ the same strategy as PyROOT can be applied • Objects ‘constructed’ by the Java side are ‘owned’ by Java (garbage collected). Fine tuning is always possible. LC Software Workshop -- P. Mato/CERN

7. Summary • Extending what exists of JavaRoot (based on JNI) to any C++ class seems feasible • This would enable Java applications to use C++ libraries and/or produce C++ objects  runtime interoperability • Automated code generation using well known tools • It would require some sizable effort • A toy-prototype could be done rather quickly (weeks) • A proper and complete implementation would require 1-2 FTE years effort • Is this worth? LC Software Workshop -- P. Mato/CERN