Beyond Java and C++
We are happy to announce the first release of Bytedeco in this new Japanese era! Version 1.5 is available for JavaCPP, JavaCPP Presets, JavaCV, ProCamCalib, and ProCamTracker. This release comes with new presets for NumPy (yes, the Python library, more on that below), NCCL, nGraph, Qt (providing an alternative to AWT, Swing, and JavaFX), and cpu_features, as well as updates for FFmpeg (now also including the ffmpeg and ffprobe programs themselves), libfreenect, HDF5, MKL, MKL-DNN, LLVM, Leptonica, ARPACK-NG, CUDA, cuDNN, MXNet, TensorFlow, TensorRT, ONNX, LiquidFun, and Skia. Many thanks to all contributors! Since the previous post just 3 months ago, according to
git shortlog 1.4.4..1.5 --summary, they were:
Alex Merritt, Arnaud Jeansen, Greg Hart, HGuillemet, k3rnL, Samuel Audet, Simon Harris
However, as usual, this list does not contain anyone who very generously helped fix CI settings, test builds, debug code, file suggestions, make corrections, report bugs, propose ideas, update wiki pages, etc. One can find more detailed information about all these changes and fixes on the repositories listed above in the
CHANGELOG.md files, among other places.
As hinted previously though, the most important update concerns the modularization of all the artifacts to comply with the Java Platform Module System (JPMS). In theory, we simply have to add irritating
module-info.java files everywhere (we are grateful to ModiTect for the help with that), but one major restriction of JPMS is that we cannot split a Java package across multiple modules, so we had to update the packages of all the presets to comply, thus the minor version bump from 1.4.x to 1.5.x. In no small part thanks to Hervé Guillemet, we eventually managed to come up with a satisfactory naming scheme that not only complies with JPMS, but also produces top-level classes that are closer to typical Java APIs and that Javadoc can render more clearly into HTML. Instead of putting all classes in the
org.bytedeco.javacpp package, all modules now have their own packages based on the names of their artifacts, for example,
org.bytedeco.opencv in the case of OpenCV. Inside such a package we have top-level classes, further divided into subpackages when the artifact contains multiples native libraries, as well as a
global subpackage containing, you guessed it, classes with native declarations for global C/C++ functions and variables. For most downstream projects, upgrading requires modifications to the import statements only. In the case of OpenCV and TensorFlow, for example, we would typically have statements like the following:
import static org.bytedeco.javacpp.opencv_core.*; import static org.bytedeco.javacpp.opencv_imgproc.*; import static org.bytedeco.javacpp.opencv_calib3d.*; import static org.bytedeco.javacpp.opencv_objdetect.* import static org.bytedeco.javacpp.tensorflow.*;
Given these exact statements, to migrate to the new API, the only change required would be to replace them with the following:
import org.bytedeco.opencv.opencv_core.*; import org.bytedeco.opencv.opencv_imgproc.*; import org.bytedeco.opencv.opencv_calib3d.*; import org.bytedeco.opencv.opencv_objdetect.*; import org.bytedeco.tensorflow.*; import static org.bytedeco.opencv.global.opencv_core.*; import static org.bytedeco.opencv.global.opencv_imgproc.*; import static org.bytedeco.opencv.global.opencv_calib3d.*; import static org.bytedeco.opencv.global.opencv_objdetect.*; import static org.bytedeco.tensorflow.global.tensorflow.*;
To prevent conflicts with the old API, we also changed the
groupId of all artifacts to
org.bytedeco, so no more annoyingly long names containing
org.bytedeco.javacpp-presets, which also reflects our evolving technical understanding of the world where the JVM cannot rule them all.
If you would like to participate in this effort, please communicate via the mailing list from Google Groups, issues on GitHub, or the chat room at Gitter. In any case, stay tuned for more exciting developments later this year!