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!
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!
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:
- JavaCPP Issues
- JavaCPP Presets Issues
- JavaCV Issues
- JavaCV Examples Issues
- ProCamCalib Issues
- ProCamTracker Issues
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:
- JavaCPP Wiki
- JavaCPP Presets Wiki
- JavaCV Wiki
- JavaCV Examples Wiki
- ProCamCalib Wiki
- ProCamTracker Wiki
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.
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!
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:
- JavaCPP Pull Requests
- JavaCPP Presets Pull Requests
- JavaCV Pull Requests
- JavaCV Examples Pull Requests
- ProCamCalib Pull Requests
- ProCamTracker Pull Requests
Here is a list of coding tasks in no particular order that, in all likelihood, would be most welcome by users:
- Improving the
- 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.)
FFmpegFrameRecorderin 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!
Specific targets for wrapping, that we have in mind:
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.
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.
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.
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.
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.
Libwb C library for interop with USB. Not a job for JavaCPP, but a worthy deliverable given the cross-platform nature of it.
Though OpenJDK uses libffi to implement foreign-function interfaces, there’s no general linkable library for this, that would be for all JavaSE versions.
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?