Contribute

Depending on how much time and effort you are willing to spend, there are a few different ways in which you could help make this community grow. They are listed below, ordered from the easiest to the most demanding: answering questions, reporting bugs, writing documentation, providing hardware, and submitting code. Thank you for your interest in contributing!

Answer Questions

To ask for support, users can post their questions on a mailing list. There are currently two mailing lists:

The latter is intended for higher-level questions regarding JavaCV and its usage, while the first one deals with more lower-level questions regarding JavaCPP. To help others directly, please subscribe to either one or both of the mailing lists, and start answering to questions!

Report Bugs

When using the software, if you encounter any problems that you believe require fixing, please make sure to create new issues for the affected projects, providing as part of your reports as much detail as possible, at least as much as is required to reproduce the incorrect behavior:

Write Documentation

User guides, tutorials, and other supporting documentation play an essential role in reaching a wider audience of developers. New articles can be added directly to the set of wiki pages of the projects to which you would like to contribute:

APIs also need to be documented, but unlike the above, it is written with the help of Javadoc, so we need to modify the source code instead. To contribute API documentation as part of the source code, please refer to the Submit Code section below.

Provide Hardware

Since we need to deal with multiple platforms, having dedicated hardware for builds and tests can be of great relief to developers. Right now, there is not much of anything concrete with respect to automated builds, but this is something that we will eventually require, so knowing where the hardware is will be of great help.

That said, providing builds of JavaCPP Presets for more platforms, most notably linux-arm, is already something you could contribute.

In either case, please be sure to contact us personally to discuss arrangements, thank you!

Submit Code

Last but not least, contributions of new code to add features, provide samples, clarify comments, fix bugs, or enhance the functionality of the software are highly welcome! After forking a project you are interested in, please make sure to send “pull requests” as required:

Project Ideas

Here is a list of coding tasks in no particular order that, in all likelihood, would be most welcome by users:

Improving the Parser of JavaCPP
Replacing the Bash/Maven build combo of JavaCPP Presets by something better (Gradle?)
Creating JavaCPP Presets for more C/C++ libraries (FFTW, GSL, LLVM, OpenNI, OpenMesh, PCL, Tesseract, etc.)
Expanding FFmpegFrameGrabber and FFmpegFrameRecorder in JavaCV to support more features of FFmpeg, such as metadata and filtering
Designing and building a framework for continuous integration that could provide builds for multiple platforms and test for regression

After determining an interesting feature that you would like to implement, please make sure to create an “issue”. This lets everyone know who is working on what. It also creates the occasion to have a discussion about the design before starting to code. Thank you for your cooperation!

New Wrappers

Specific targets for wrapping, that we have in mind:

V8

A V8 wrapper should including the ability for JS to call back to Java code, and Java to be able to observe JS object lifecycle events so it can release resources.

SQLite

Many developers are hugs fans of SQLite, not just for embedded solutions but as an embeddable engine for creating custom distributed big data stores. There’s already a JDBC interface but it only exposes a fraction of the power of the sqlite API. For example, it would be cool to be able to register custom function / aggregate by passing a Java lambda. Or define our own virtual tables in Java, allowing custom data-structures/data-sources to be participate in SQL joins.

Berkeley / POSIX Sockets API

Refer the wikipedia page, but there are others too.

Many of use, over time, have become more and more frustrated with Java’s general networking and IO APIs. They are so over-abstracted and are lowest common denominator to support all operating systems. We would rather get much closer to the OS and be able to use all its features. The basics like open(), socket(), read(), write(), select(), poll(), etc. In addition to those, the OS specific enhancements like SO_REUSEPORT which was introduced in Linux 3.9 is amazingly useful and not available to Java users. Also unix domain sockets including their extended capabilities like being able to find information about the process on the other end and being able to pass open file descriptors over them.

We know that Oracle are looking into this too.

libgit2

Manipulate git repositories. Build versioned data-stores directly on the git model. Using version control backends directly in apps is an exciting application direction, but accessing git from Java is incredibly painful, and libgit2 capability would be great.

Browser engines

Namely Blink, WebKit and/or WebCore, Gecko. Allow Java apps to run complete headless or visible browsers in their apps and fully watch and manipulate the live DOM, provide services to web-pages, etc without complicated inter-process coordination.

Alternate windowing frameworks

Swing is controversial. Even with advanced look & feels it always looks out of place on a native desktop and doesn’t fit just right with other things. SWT uses native platform libraries that tightly integrate with desktop, but it is a gigantic beast. We would be interested to see if other native but lightweight widget libraries would excite the Java community such as wxWidgets, Fox Toolkit or FLTK. Qt too, but that could be another gigantic beast, and has some wrappers already.

LLVM

It would be cool to be create a Java API for generating and compiling LLVM IR. There are lots of Java libraries that create bytecode on the fly (e.g. ASM), but imagine if you could generate native performance libraries on the fly too.

Sam has already mapped the C API of LLVM to Java (a subset of the larger task) and it actually works.

libusb

Libwb C library for interop with USB. Not a job for JavaCPP, but a worthy deliverable given the cross-platform nature of it.

libffi

Though OpenJDK uses libffi to implement foreign-function interfaces, there’s no general linkable library for this, that would be for all JavaSE versions.

libcap

From their website: libpcap is a system-independent interface for user-level packet capture. libpcap provides a portable framework for low-level network monitoring. Applications include network statistics collection, security monitoring, network debugging, etc. Super-cool huh?

Lua

Lua is everyone’s favoring game-centric embeddable scripting language. It would be great to see it more interacting on a sort of peer-to-peer basis, like Haskell.