LC Software Workshop, May 2009, CERN P. Mato /CERN

 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 28/5/09LC Software Workshop -- P. Mato/CERN2

 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) 28/5/09LC Software Workshop -- P. Mato/CERN3

 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’ 28/5/09LC Software Workshop -- P. Mato/CERN4

 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 Subir Sarkar ◦ Automatically generating Java classes from the C++ definitions (header files) at ‘build-time’ ◦ Java objects are ‘proxies’ to C++ objects 28/5/09LC Software Workshop -- P. Mato/CERN5 Java JNI (generated) C++ Callback

 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. 28/5/09LC Software Workshop -- P. Mato/CERN6

 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? 28/5/09LC Software Workshop -- P. Mato/CERN7