About

Bytedeco is a name that Samuel came up with to give a home to his personal projects of JavaCPP, JavaCPP Presets, JavaCV, ProCamCalib, and ProCamTracker, some of which had become quite popular (now over 20000 downloads per month for JavaCPP and JavaCV). Given their proven growth potential, we hope this way to extend their scope. The name reflects a few things not only about the projects, but also about our beliefs and philosophy. It could at first be interpreted as a typo of “bytecode”, a technology used by Java, among others, to create portable binary executable files that, when dropped in a virtual machine, was designed to provide real gains in productivity. Alternatively, it could be regarded as the stylization of a phrase like “byte decoder”, hinting at some sort of process to convert data into a more usable form. It also suggests binary code decorated in a way, for example, with Java annotations, to support extra features either at build time or at runtime. Finally, one could infer an artistic desire for minimalist and elegant design, all the while accepting engineering necessities, such as thorough support for parallelization and efficient execution, absolute requirements when solving compute-intensive problems, for example, in the fields of graphics, multimedia, computer vision, or machine learning where applications require heavy processing of audio, video, physics, text, etc., coinciding once again with the original governing principles behind Java technology. To be clear, we are not referring to the Java language, but the Java platform. Many other languages, for instance, BeanShell, COBOL, Clojure, Groovy, JavaScript, Perl, Python, R, Ruby, REXX, Scala, Scheme, or even MATLAB, can take advantage of a Java virtual machine (JVM).

That said, we have an open mind. Microsoft has since made .NET open source, potentially creating a credible alternative to Java, so we are closely following its development. The HTML5/JavaScript combo could, alternatively, be considered as the new Java. However, because it does not support multithreading and features no other portable language than JavaScript, where neither bytecode nor an equivalent to the Java Native Interface (JNI) have been standardized, and for multiple other reasons as well, that is not an entirely valid comparison. Still, if HTML5 is to become an alternative to Java, we will need some way to access native C/C++ libraries easily and efficiently. In that sense, with properly standardized native functionality, there is value in implementing something similar to JavaCPP on other platforms. Given the strong worldwide demand for talented software engineers, and the time they could save developing on more productive platforms, we hope that JavaCPP becomes a catalyst to help steer the world ever so slightly in a better direction, but this can only become a reality if it succeeds itself, first. In any case, our belief is that Java will continue to dominate a large part of the industry, for the same reasons that C/C++ still do, but at a slightly different level of abstraction.