The missing bridge between Java and native C++

Overview

JavaCPP

Gitter Maven Central Sonatype Nexus (Snapshots) Build Status Commercial support: xscode

Introduction

JavaCPP provides efficient access to native C++ inside Java, not unlike the way some C/C++ compilers interact with assembly language. No need to invent new languages such as with SWIG, SIP, C++/CLI, Cython, or RPython. Instead, similar to what cppyy strives to do for Python, it exploits the syntactic and semantic similarities between Java and C++. Under the hood, it uses JNI, so it works with all implementations of Java SE, in addition to Android, Avian, and RoboVM (instructions).

More specifically, when compared to the approaches above or elsewhere (CableSwig, JNIGeneratorApp, cxxwrap, JNIWrapper, Platform Invoke, GlueGen, LWJGL Generator, JNIDirect, ctypes, JNA, JNIEasy, JniMarshall, JNative, J/Invoke, HawtJNI, JNR, BridJ, CFFI, fficxx, CppSharp, cgo, pybind11, rust-bindgen, Panama Native, etc.), it maps naturally and efficiently many common features afforded by the C++ language and often considered problematic, including overloaded operators, class and function templates, callbacks through function pointers, function objects (aka functors), virtual functions and member function pointers, nested struct definitions, variable length arguments, nested namespaces, large data structures containing arbitrary cycles, virtual and multiple inheritance, passing/returning by value/reference/string/vector, anonymous unions, bit fields, exceptions, destructors and shared or unique pointers (via either try-with-resources or garbage collection), and documentation comments. Obviously, neatly supporting the whole of C++ would require more work (although one could argue about the intrinsic neatness of C++), but we are releasing it here as a proof of concept.

As a case in point, we have already used it to produce complete interfaces to OpenCV, FFmpeg, libdc1394, PGR FlyCapture, OpenKinect, videoInput, ARToolKitPlus, Leptonica, Tesseract, GSL, LLVM, HDF5, MKL, CUDA, Caffe, MXNet, TensorFlow, System APIs, and others as part of the JavaCPP Presets subproject, also demonstrating early parsing capabilities of C/C++ header files that show promising and useful results.

Please feel free to ask questions on the mailing list or the discussion forum if you encounter any problems with the software! I am sure it is far from perfect...

Downloads

Archives containing JAR files are available as releases.

We can also have everything downloaded and installed automatically with:

  • Maven (inside the pom.xml file)
  <dependency>
    <groupId>org.bytedeco</groupId>
    <artifactId>javacpp</artifactId>
    <version>1.5.4</version>
  </dependency>
  • Gradle (inside the build.gradle file)
  dependencies {
    implementation group: 'org.bytedeco', name: 'javacpp', version: '1.5.4'
  }
  • Leiningen (inside the project.clj file)
  :dependencies [
    [org.bytedeco/javacpp "1.5.4"]
  ]
  • sbt (inside the build.sbt file)
  libraryDependencies += "org.bytedeco" % "javacpp" % "1.5.4"

Another option available to Gradle users is Gradle JavaCPP, and similarly for Scala users there is SBT-JavaCPP.

Required Software

To use JavaCPP, you will need to download and install the following software:

To produce binary files for Android 4.0 or newer, you will also have to install:

And similarly to target iOS, you will need to install either:

To modify the source code, please note that the project files were created for:

Finally, because we are dealing with native code, bugs can easily crash the virtual machine. Luckily, the HotSpot VM provides some tools to help us debug under those circumstances:

Getting Started

To understand how JavaCPP is meant to be used, one should first take a look at the Mapping Recipes for C/C++ Libraries, but a high-level overview of the Basic Architecture is also available to understand the bigger picture. The repository of the JavaCPP Presets further provides complex examples that we can use as templates, but it also includes a wiki page on how to Create New Presets that explains their structure in detail along with a small but complete sample project from which one can start experimenting with.

Key Use Cases

To implement native methods, JavaCPP generates appropriate code for JNI, and passes it to the C++ compiler to build a native library. At no point do we need to get our hands dirty with JNI, makefiles, or other native tools. The important thing to realize here is that, while we do all customization inside the Java language using annotations, JavaCPP produces code that has zero overhead compared to manually coded JNI functions (verify the generated .cpp files to convince yourself). Moreover, at runtime, the Loader.load() method automatically loads the native libraries from Java resources, which were placed in the right directory by the building process. They can even be archived in a JAR file, it changes nothing. Users simply do not need to figure out how to make the system load the files. These characteristics make JavaCPP suitable for either

In addition to the few examples provided below, to learn more about how to use the features of this tool, please refer to the Mapping Recipes for C/C++ Libraries as well as the source code of the JavaCPP Presets for examples. For more information about the API itself, one may refer to the documentation generated by Javadoc.

As a matter of course, this all works with the Scala language as well, but to make the process even smoother, it should not be too hard to add support for "native properties", such that declarations like @native var could generate native getter and setter methods...

Accessing Native APIs

The most common use case involves accessing some native library written for C++, for example, inside a file named NativeLibrary.h containing this C++ class:

#include <string>

namespace NativeLibrary {
    class NativeClass {
        public:
            const std::string& get_property() { return property; }
            void set_property(const std::string& property) { this->property = property; }
            std::string property;
    };
}

To get the job done with JavaCPP, we can easily define a Java class such as this one--although one could use the Parser to produce it from the header file as demonstrated by the JavaCPP Presets subproject, following the principles outlined in the Mapping Recipes for C/C++ Libraries:

import org.bytedeco.javacpp.*;
import org.bytedeco.javacpp.annotation.*;

@Platform(include="NativeLibrary.h")
@Namespace("NativeLibrary")
public class NativeLibrary {
    public static class NativeClass extends Pointer {
        static { Loader.load(); }
        public NativeClass() { allocate(); }
        private native void allocate();

        // to call the getter and setter functions 
        public native @StdString String get_property(); public native void set_property(String property);

        // to access the member variable directly
        public native @StdString String property();     public native void property(String property);
    }

    public static void main(String[] args) {
        // Pointer objects allocated in Java get deallocated once they become unreachable,
        // but C++ destructors can still be called in a timely fashion with Pointer.deallocate()
        NativeClass l = new NativeClass();
        l.set_property("Hello World!");
        System.out.println(l.property());
    }
}

After compiling the Java source code in the usual way, we also need to build using JavaCPP before executing it, or we can let it do everything as follows:

$ java -jar javacpp.jar NativeLibrary.java -exec
Hello World!

Using Complex C++ Types

To demonstrate its relative ease of use even in the face of complex data types, imagine we had a C++ function that took a vector<vector<void*> > as argument. To support that type, we could define a bare-bones class like this:

import org.bytedeco.javacpp.*;
import org.bytedeco.javacpp.annotation.*;

@Platform(include="<vector>")
public class VectorTest {

    @Name("std::vector<std::vector<void*> >")
    public static class PointerVectorVector extends Pointer {
        static { Loader.load(); }
        public PointerVectorVector()       { allocate();  }
        public PointerVectorVector(long n) { allocate(n); }
        public PointerVectorVector(Pointer p) { super(p); } // this = (vector<vector<void*> >*)p
        private native void allocate();                  // this = new vector<vector<void*> >()
        private native void allocate(long n);            // this = new vector<vector<void*> >(n)
        @Name("operator=")
        public native @ByRef PointerVectorVector put(@ByRef PointerVectorVector x);

        @Name("operator[]")
        public native @StdVector PointerPointer get(long n);
        public native @StdVector PointerPointer at(long n);

        public native long size();
        public native @Cast("bool") boolean empty();
        public native void resize(long n);
        public native @Index long size(long i);                   // return (*this)[i].size()
        public native @Index @Cast("bool") boolean empty(long i); // return (*this)[i].empty()
        public native @Index void resize(long i, long n);         // (*this)[i].resize(n)

        public native @Index Pointer get(long i, long j);  // return (*this)[i][j]
        public native void put(long i, long j, Pointer p); // (*this)[i][j] = p
    }

    public static void main(String[] args) {
        PointerVectorVector v = new PointerVectorVector(13);
        v.resize(0, 42); // v[0].resize(42)
        Pointer p = new Pointer() { { address = 0xDEADBEEFL; } };
        v.put(0, 0, p);  // v[0][0] = p

        PointerVectorVector v2 = new PointerVectorVector().put(v);
        Pointer p2 = v2.get(0).get(); // p2 = *(&v[0][0])
        System.out.println(v2.size() + " " + v2.size(0) + "  " + p2);

        v2.at(42);
    }
}

Executing that program using this command produces the following output:

$ java -jar javacpp.jar VectorTest.java -exec
13 42  org.bytedeco.javacpp.Pointer[address=0xdeadbeef,position=0,limit=0,capacity=0,deallocator=null]
Exception in thread "main" java.lang.RuntimeException: vector::_M_range_check: __n (which is 42) >= this->size() (which is 13)
	at VectorTest$PointerVectorVector.at(Native Method)
	at VectorTest.main(VectorTest.java:44)

Optimizing Code Performance

Other times, we may wish to code in C++ (including CUDA) for performance reasons. Suppose our profiler had identified that a method named Processor.process() took 90% of the program's execution time:

public class Processor {
    public static void process(java.nio.Buffer buffer, int size) {
        System.out.println("Processing in Java...");
        // ...
    }

    public static void main(String[] args) {
        process(null, 0);
    }
}

After many days of hard work and sweat, the engineers figured out some hacks and managed to make that ratio drop to 80%, but you know, the managers were still not satisfied. So, we could try to rewrite it in C++ (or even assembly language for that matter via the inline assembler) and place the resulting function in a file named say Processor.h:

#include <iostream>

static inline void process(void *buffer, int size) {
    std::cout << "Processing in C++..." << std::endl;
    // ...
}

After adjusting the Java source code to something like this:

import org.bytedeco.javacpp.*;
import org.bytedeco.javacpp.annotation.*;

@Platform(include="Processor.h")
public class Processor {
    static { Loader.load(); }

    public static native void process(java.nio.Buffer buffer, int size);

    public static void main(String[] args) {
        process(null, 0);
    }
}

It would then compile and execute like this:

$ java -jar javacpp.jar Processor.java -exec
Processing in C++...

Creating Callback Functions

Some applications also require a way to call back into the JVM from C/C++, so JavaCPP provides a simple way to define custom callbacks, either as function pointers, function objects, or virtual functions. Although there exist frameworks, which are arguably harder to use, such as Jace, JunC++ion, JCC, jni.hpp, or Scapix that can map complete Java APIs to C++, since invoking a Java method from native code takes at least an order of magnitude more time than the other way around, it does not make much sense in my opinion to export as is an API that was designed to be used in Java. Nevertheless, suppose we want to perform some operations in Java, planning to wrap that into a function named foo() that calls some method inside class Foo, we can write the following code in a file named foo.cpp, taking care to initialize the JVM if necessary with either JavaCPP_init() or by any other means:

#include <iostream>
#include "jniFoo.h"

int main() {
    JavaCPP_init(0, NULL);
    try {
        foo(6, 7);
    } catch (std::exception &e) {
        std::cout << e.what() << std::endl;
    }
    JavaCPP_uninit();
}

We may then declare that function to a call() or apply() method defined in a FunctionPointer as follows:

import org.bytedeco.javacpp.*;
import org.bytedeco.javacpp.annotation.*;

@Platform(include="<algorithm>")
@Namespace("std")
public class Foo {
    static { Loader.load(); }

    public static class Callback extends FunctionPointer {
        // Loader.load() and allocate() are required only when explicitly creating an instance
        static { Loader.load(); }
        protected Callback() { allocate(); }
        private native void allocate();

        public @Name("foo") boolean call(int a, int b) throws Exception { 
            throw new Exception("bar " + a * b);
        }
    }

    // We can also pass (or get) a FunctionPointer as argument to (or return value from) other functions
    public static native void stable_sort(IntPointer first, IntPointer last, Callback compare);

    // And to pass (or get) it as a C++ function object, annotate with @ByVal or @ByRef
    public static native void sort(IntPointer first, IntPointer last, @ByVal Callback compare);
}

Since functions also have pointers, we can use FunctionPointer instances accordingly, in ways similar to the FunPtr type of Haskell FFI, but where any java.lang.Throwable object thrown gets translated to std::exception. Building and running this sample code with these commands under Linux x86_64 produces the expected output:

$ java -jar javacpp.jar Foo.java -header
$ g++ -I/usr/lib/jvm/java/include/ -I/usr/lib/jvm/java/include/linux/ foo.cpp linux-x86_64/libjniFoo.so -o foo
$ ./foo
java.lang.Exception: bar 42

In this example, the FunctionPointer object gets created implicitly, but to call a native function pointer, we could define one that instead contains a native call()/apply() method, and create an instance explicitly. Such a class can also be extended in Java to create callbacks, and like any other normal Pointer object, must be allocated with a native void allocate() method, so please remember to hang on to references in Java, as those will get garbage collected. As a bonus, FunctionPointer.call()/apply() maps in fact to an overloaded operator() of a C++ function object that we can pass to other functions by annotating parameters with @ByVal or @ByRef, as with the sort() function in the example above.

It is also possible to do the same thing with virtual functions, whether "pure" or not. Consider the following C++ class defined in a file named Foo.h:

#include <stdio.h>

class Foo {
public:
    int n;
    Foo(int n) : n(n) { }
    virtual ~Foo() { }
    virtual void bar() {
        printf("Callback in C++ (n == %d)\n", n);
    }
};

void callback(Foo *foo) {
    foo->bar();
}

The function Foo::bar() can be overridden in Java if we declare the method in the peer class either as native or abstract and annotate it with @Virtual, for example:

import org.bytedeco.javacpp.*;
import org.bytedeco.javacpp.annotation.*;

@Platform(include="Foo.h")
public class VirtualFoo {
    static { Loader.load(); }

    public static class Foo extends Pointer {
        static { Loader.load(); }
        public Foo(int n) { allocate(n); }
        private native void allocate(int n);

        @NoOffset public native int n(); public native Foo n(int n);
        @Virtual  public native void bar();
    }

    public static native void callback(Foo foo);

    public static void main(String[] args) {
        Foo foo = new Foo(13);
        Foo foo2 = new Foo(42) {
            public void bar() {
                System.out.println("Callback in Java (n == " + n() + ")");
            }
        };
        foo.bar();
        foo2.bar();
        callback(foo);
        callback(foo2);
    }
}

Which outputs what one would naturally assume:

$ java -jar javacpp.jar VirtualFoo.java -exec
Callback in C++ (n == 13)
Callback in Java (n == 42)
Callback in C++ (n == 13)
Callback in Java (n == 42)

Instructions for Android, Avian, and RoboVM

The easiest one to get working is Avian compiled with OpenJDK class libraries, so let's start with that. After creating and building a program as described above, without any further modifications, we can directly execute it with this command:

$ /path/to/avian-dynamic -Xbootclasspath/a:javacpp.jar <MainClass>

However, in the case of Android, we need to do a bit more work. For the command line build system based on Ant, inside the directory of the project:

  1. Copy the javacpp.jar file into the libs/ subdirectory, and
  2. Run this command to produce the *.so library files in libs/armeabi/:
$ java -jar libs/javacpp.jar -classpath bin/ -classpath bin/classes/ \
> -properties <android-arm|android-x86> -Dplatform.root=/path/to/android-ndk/ \
> -Dplatform.compiler=/path/to/<arm-linux-androideabi-g++|i686-linux-android-g++> -d libs/<armeabi|x86>/

To make everything automatic, we may also insert that command into the build.xml file. Alternatively, for integration with Android Studio, we can use Gradle JavaCPP.

Similarly for RoboVM, assuming that the compiled classes are in the classes subdirectory:

  1. Copy the javacpp.jar file into the project directory, and
  2. Run the following commands to produce the native binary file:
$ java -jar javacpp.jar -cp classes/ -properties <ios-arm|ios-x86> -o lib
$ /path/to/robovm -arch <thumbv7|x86> -os ios -cp javacpp.jar:classes/ -libs classes/<ios-arm|ios-x86>/lib.o <MainClass>

And instead of Loader.load(), the library should be loaded with System.load("lib.o"), in this case, and might not be required at all.


Project lead: Samuel Audet samuel.audet at gmail.com
Developer site: https://github.com/bytedeco/javacpp
Discussion group: http://groups.google.com/group/javacpp-project

Comments
  • Maven release

    Maven release

    Will it be possible to do a new release of JavaCPP? Last one was on Oct, 2015 and I was hoping to use the latest changes for my project, but I'm inside an environment that doesn't allow to use SNAPSHOT of libraries (so I can't use Sonatype Snapshot).

    Also, have you thought about moving to semantic versioning? (http://semver.org/)

    Thanks

    enhancement 
    opened by Arcnor 65
  • [WIP] Add support for Java's module system

    [WIP] Add support for Java's module system

    Overview

    Splits the project into two subprojects: core and maven-plugin. The plugin has dependencies that cannot be modularized, which prevents downstream applications from using jlink to create native runtime images. The core project has no such dependencies, and can be used with jlink

    Loader now looks for property files with absolute paths (/properties/...) instead of relative ones (properties/...)

    Bumps the version to 2.0.0-SNAPSHOT. This might not be necessary, since the artifact name has been changed from javacpp to javacpp-core and javacpp-maven-plugin for the two projects

    How the projects in javacpp-presets will be modularized remains TBD. However, they will also need to be modularized (and moved to different packages) to avoid exporting the org.bytedco.javacpp package from multiple modules

    TODO

    • [ ] Ensure that applications built on Java 9 and above still work; in particular, make sure Loader will still be able to resolve and load native binaries bundled inside the JAR
    • [x] Release a multi-release JAR that can be used by both Java 7 and Java 9 consumers
    • [ ] Update README with instructions for the new artifacts
    enhancement help wanted 
    opened by SamCarlberg 56
  • Improve Indexer to allow an hyper-rectangular selection

    Improve Indexer to allow an hyper-rectangular selection

    What about improve the Indexer classes to use the same concert of "hyper-rectangular" selection that HDF5 library is using? See https://portal.hdfgroup.org/display/HDF5/Reading+From+or+Writing+To+a+Subset+of+a+Dataset

    enhancement 
    opened by matteodg 50
  • hello,i have some issue to access on loader.class it maybe cause some particular path or filename

    hello,i have some issue to access on loader.class it maybe cause some particular path or filename

    java.lang.UnsatisfiedLinkError: no jniGen in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:702) at org.bytedeco.javacpp.Loader.load(Loader.java:500) at org.bytedeco.javacpp.Loader.load(Loader.java:417) at org.bytedeco.javacpp.GenICam3.(Gen.java:25) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at org.bytedeco.javacpp.Loader.load(Loader.java:472) at org.bytedeco.javacpp.Loader.load(Loader.java:417) at org.bytedeco.javacpp.Pylon5.(Py.java:41)

    bug 
    opened by suguna-mother 45
  • depthai 2.7.2 led java coredump. But depthai 2.6.0 is fine.

    depthai 2.7.2 led java coredump. But depthai 2.6.0 is fine.

    Environment:

    • OS: Ubuntu 20.04 Desktop 64bit LTS
    • JDK: GraalVM JDK 21.1.0.r11-grl
    • Micronaut 2.5.9
    • JavaCPP: 1.5.6-SNAPSHOT
    • OpenCV: 4.5.3
    • Depthai: 2.7.2
    • test code: depthai-java-test

    Reproduce steps:

    rm -rf ~/.m2/repository/org/bytedeco/*
    rm -rf ~/.javacpp
    cd ~/tmp/
    git clone https://github.com/bytedeco/javacpp-presets
    cd javacpp-presets
    mvn install --projects openblas,opencv,depthai -Djavacpp.platform=linux-x86_64
    cd ~/tmp/
    git clone https://github.com/wureka/depthai-java-test
    cd depthai-java-test
    sh gradlew shadowJar
    java -Djava.library.path=~/tmp/javacpp-presets/depthai/target/native/org/bytedeco/depthai/linux-x86_64:~/tmp/javacpp-presets/openblas/target/native/org/bytedeco/openblas/linux-x86_64:~/tmp/javacpp-presets/opencv/target/native/org/bytedeco/opencv/linux-x86_64 -jar build/libs/depthai-java-test-0.1-all.jar
    

    The actual output is:

    18:29:22.118 [main] INFO  i.m.context.env.DefaultEnvironment - Established active environments: [cli]
    #
    # A fatal error has been detected by the Java Runtime Environment:
    #
    #  SIGSEGV (0xb) at pc=0x00007f3512c716e8, pid=704492, tid=704493
    #
    # JRE version: OpenJDK Runtime Environment GraalVM CE 21.1.0 (11.0.11+8) (build 11.0.11+8-jvmci-21.1-b05)
    # Java VM: OpenJDK 64-Bit Server VM GraalVM CE 21.1.0 (11.0.11+8-jvmci-21.1-b05, mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, g1 gc, linux-amd64)
    # Problematic frame:
    # C  [libdepthai-core.so+0x1836e8]  tcpip_get_devices+0x148
    #
    # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alexji/java-projects/depthai-projects/depthai-java-test/core.704492)
    #
    # An error report file with more information is saved as:
    # /home/alexji/java-projects/depthai-projects/depthai-java-test/hs_err_pid704492.log
    #
    # If you would like to submit a bug report, please visit:
    #   https://github.com/oracle/graal/issues
    # The crash happened outside the Java Virtual Machine in native code.
    # See problematic frame for where to report the bug.
    #
    Aborted (core dumped)
    
    

    If I checkout below code. image

    And modify build.gradle implementation('org.bytedeco:depthai:2.6.0-1.5.6-SNAPSHOT')

    Re-do the above steps. the same code will work. The correct output is:

    17:46:11.664 [main] INFO  i.m.context.env.DefaultEnvironment - Established active environments: [cli]
    Detect 3 camera(s), USB speed: SUPER 
        Camera 0 is ready!
        Camera 1 is ready!
        Camera 2 is ready!
    
    Process finished with exit code 0
    
    bug 
    opened by wureka 36
  • Can any one tell me how to use javacpp in android studio?

    Can any one tell me how to use javacpp in android studio?

    I have spend some time on this, but I just cannot make it work.

    I can't find enough reference material on google. And finally I do it as this: https://www.snip2code.com/Snippet/271596/gradle-build-file-for-JavaCPP

    And I changed it to something like this:

    android.applicationVariants.all { variant ->
        variant.javaCompile.doLast {
            println 'Hello world!'
            javaexec {
                main "org.bytedeco.javacpp.tools.Builder"
                classpath files('path/to/javacpp.jar')
                args '-cp', "variant.javaCompile.destinationDir",
                        '-properties', 'android-arm',
                        '-Dplatform.root', 'path/to/ndk',
                        '-Dplatform.compiler', 'path/to/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++',
                        '-d', 'libs/armeabi'
            }
        }
    }
    

    But the gradle build failed. The error says that 'org.bytedeco.javacpp.tools.builder' not found. And the 'command '/path/to/java'' return nono zero (return 1).

    Can any one helps me. Appreciate!

    question 
    opened by shekmun 36
  • JavaCv Mat to Opencv Mat

    JavaCv Mat to Opencv Mat

    Hi guys

    First of all I would like to apologize to create a label almost similar to Issue #4. I am not a expert in Java as well as c++. However I have been spent last 4 days to take a solution and I got frozen.

    I have rewrite c++ code of Mastering Opencv book , chapter 5, regard Licence plate detecting to java code. But the original c++ code uses filestorage that is not yet implemented in opencv wrapper. So I found FileStorage for javacv (javacPP-presets) that is working fine and can be used to return a CvMat class.

    The issue is the CvMat data should reflect in opencv.Mat instance. But I know they are not compatible and I really dont know how to build a parser to them.

    I tried to run all CvMat data and use "put" method to pass it to opencv.mat. But data got wrong.

    if someone can help with a tip. Source code is really great, but if shows me the way to take would be really helpful.

    thanks in advance

    question 
    opened by kleberbueno 34
  • Significant performance improvements to Pointer.deallocator

    Significant performance improvements to Pointer.deallocator

    This improves thread contention when locking on the global lock for Pointer allocations in most cases. The global lock can be a performance killer in highly parallel operations, even when memory pressures are not high. In this change we do optimistic provisioning using Atomic operations, and only fall back to locking when there is memory pressure.

    For the totalBytes and the internal linked list this was an easy change. Switching to an AtomicLong and ConcurrentLinkedQueue helps in us being able to do those common actions without needing to lock. The handling of the "PhysicalBytes" however is a bit different in this implementation. We use an AtomicLong to approximate the size based off the internally stored bytes. However on de-allocations this is NOT decremented (while totalBytes is decremented). This means that one of two other methods will need to sync the physicalBytes back to reality. The first (hopefully most likely) would be a sync that occurs every 1000 allocations. The second would be that if we fail to allocate, we will do a trim which will sync this state as well.

    @saudet give me your thoughts on this to resolve #231

    My biggest concerns are around how I am approximating the physical bytes. If there is a better way to estimate the size, or if you think the sync interval needs to be different, let me know. For my use case I could be syncing every million or two. That said, these changes DRAMATICALLY speed up deeplearning4j's kmeans implementation for me.

    opened by jentfoo 33
  • Local repo with include files and libs

    Local repo with include files and libs

    Prototype of the repository we discussed. It is located in ~/.javacpp and has the same structure as Maven's ~/.m2 folder. The build process now packages include files, so that libraries are self-sufficient. E.g. it is not necessary to build native versions of a library's dependencies, and inter-project references to cppbuild/../include and lib can be removed. They are now discovered from the pom definition and fetched to the repo. I only tested on Opencv and Caffe on Linux-64.

    enhancement 
    opened by cypof 33
  • NullPointerException in Parser and poor Unicode support

    NullPointerException in Parser and poor Unicode support

    With JavaCPP 1.1:

    import org.bytedeco.javacpp.*;
    import org.bytedeco.javacpp.annotation.*;
    
    @Properties(target="org.sqlite.SQLite", value={
    @Platform(include="sqlite3.h")
    })
    public class SQLite {
    }
    
    javac -cp javacpp.jar SQLite.java
    java -jar javacpp.jar SQLite
    
    Targeting org/sqlite/SQLite.java
    Parsing sqlite3.h
    Exception in thread "main" java.lang.NullPointerException
        at org.bytedeco.javacpp.tools.Parser.declarator(Parser.java:913)
        at org.bytedeco.javacpp.tools.Parser.function(Parser.java:1245)
        at org.bytedeco.javacpp.tools.Parser.declarations(Parser.java:2347)
        at org.bytedeco.javacpp.tools.Parser.group(Parser.java:1985)
        at org.bytedeco.javacpp.tools.Parser.declarations(Parser.java:2346)
        at org.bytedeco.javacpp.tools.Parser.extern(Parser.java:2272)
        at org.bytedeco.javacpp.tools.Parser.declarations(Parser.java:2345)
        at org.bytedeco.javacpp.tools.Parser.parse(Parser.java:2421)
        at org.bytedeco.javacpp.tools.Parser.parse(Parser.java:2517)
        at org.bytedeco.javacpp.tools.Builder.parse(Builder.java:67)
        at org.bytedeco.javacpp.tools.Builder.build(Builder.java:624)
        at org.bytedeco.javacpp.tools.Builder.main(Builder.java:773)
    
    enhancement 
    opened by gwenn 31
  • How to use my own compiled library?

    How to use my own compiled library?

    I want use gsl library on my android phone. I've tried the gsl of javacpp-presets but it didn't work. The error said that some .so library did not found. So I want to compile the gsl library myself. I've download the gsl library and do as the gsl presets's cppbuild.sh. The main three line:

    ./configure --prefix=*** .... arm-linux-androideabi-gcc ....
    make -j4
    make install-strip
    

    It works fine. And now I have a gsl library compiled with arm-linux-androideabi-gcc. Now I'm using this C++ code:

    // JavacppDemo.h
    #include "gsl/gsl_sf_bessel.h"
    class Demo {
    public:
        int get() {
            double x = 5.0;
            double y = gsl_sf_bessel_J0(x);
            return (int) y;
        }
    };
    

    And the java code:

    @Platform(include={"JavacppDemo.h"}, link={"gslcblas", "gsl"})
    public class JavacppDemo {
    ****
    }
    

    And I've added the header file path and library path of my newly compiled gsl library to the gradle file. So now I can completely rebuild the project and no errors come out. But when I run it, it says that "could not load library "libgsl.so.19"". I unzip the generated apk file and libgsl.so is not there(only my libjniJavacppDemo.so).

    If I copy the libgsl.so to the armeabi folder, it won't package into the apk file automatically. So how to fix this? Please help me.

    bug 
    opened by shekmun 29
  • Race condition in org.bytedeco.javacpp.Loader with multiple JVMs on the same machine

    Race condition in org.bytedeco.javacpp.Loader with multiple JVMs on the same machine

    Hi,

    We recently hit this race condition issue with javacpp.Loader class. The issue happens when you have multiple JVMs running on the same machine, like in Spark.

    It manifests as errors like below when trying to load models using the library.

    Caused by: java.lang.UnsatisfiedLinkError: no jnitensorflow in java.library.path
    	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1875)
    	at java.lang.Runtime.loadLibrary0(Runtime.java:872)
    	at java.lang.System.loadLibrary(System.java:1124)
    	at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:1738)
    	at org.bytedeco.javacpp.Loader.load(Loader.java:1345)
    	at org.bytedeco.javacpp.Loader.load(Loader.java:1157)
    	at org.bytedeco.javacpp.Loader.load(Loader.java:1133)
    	at org.tensorflow.internal.c_api.global.tensorflow.<clinit>(tensorflow.java:12)
    	at java.lang.Class.forName0(Native Method)
    	at java.lang.Class.forName(Class.java:348)
    	at org.bytedeco.javacpp.Loader.load(Loader.java:1212)
    	at org.bytedeco.javacpp.Loader.load(Loader.java:1157)
    	at org.bytedeco.javacpp.Loader.load(Loader.java:1149)
    	at org.tensorflow.NativeLibrary.load(NativeLibrary.java:48)
    	at org.tensorflow.TensorFlow.<clinit>(TensorFlow.java:140)
    	at java.lang.Class.forName0(Native Method)
    	at java.lang.Class.forName(Class.java:264)
    	at org.tensorflow.Graph.<clinit>(Graph.java:1341)
            ....
    Caused by: java.lang.UnsatisfiedLinkError: /user/home/.javacpp/cache/jarname/org/tensorflow/internal/c_api/linux-x86_64/libjnitensorflow.so: libtensorflow_cc.so.2: cannot open shared object file: No such file or directory
    	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1950)
    	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1832)
    	at java.lang.Runtime.load0(Runtime.java:811)
    	at java.lang.System.load(System.java:1088)
    	at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:1685)
    	... 104 more
    

    Looking at the Loader code, the file lock only lock within cacheResource method: https://github.com/bytedeco/javacpp/blob/master/src/main/java/org/bytedeco/javacpp/Loader.java#L571-L697 And there are logics like deleting the file within the cacheResource method. (although I still don't understand why it enters into the code block at all if others already cached the file)

                            file.delete();
                            extractResource(resourceURL, file, null, null, true);
                            file.setLastModified(timestamp);
    

    If another JVM on the same machine using the same cacheDir (by default /user/home/.javacpp/cache) try to loadLibrary, it may find the file got deleted by another JVM since there is no file lock here.

    opened by fanyang-dotcom 8
  • Problem with std::string_view as callback parameter

    Problem with std::string_view as callback parameter

    I have an error during creation jni lib by javacpp in case I have function with callback with std::string_view parameter

    greeter-jni.cpp:1858:9: error: no matching function for call to 'testStringView'
            testStringView(*ptr0);
    

    In my case I created several c++ functions in my lib:

    void testStringView(std::function<void(std::string_view message)> callback) {
        callback("hello");
    }
    
    void testBoolean(std::function<void(bool success)> callback) {
        callback(true);
    }
    
    void plainStringView(std::string_view message) {
    std::cout << message;
    }
    

    Also I created java helper class for javacpp:

    public class GreeterHelper extends GreeterConfig {
    
        public static class BooleanCallback extends FunctionPointer {
            static { Loader.load(); }
            protected BooleanCallback() { allocate(); }
            private native void allocate();
    
            public native void call(boolean success);
        }
    
        public static class StringCallback extends FunctionPointer {
            static { Loader.load(); }
            protected StringCallback() { allocate(); }
            private native void allocate();
    
            public native void call(@StdString String error_message);
        }
    }
    

    And config:

    @Properties(
            value = @Platform(
                    compiler = "cpp11",
                    define = {"SHARED_PTR_NAMESPACE std", "UNIQUE_PTR_NAMESPACE std"},
                    includepath = {"../greeter/include/acvp/"},
                    include = {"make_cloud_agent.h"},
                    library = "greeter-jni",
                    link = {"acvp-cloud-agent-cpp", "acvp-core"},
                    linkpath = {
                            "../greeter/build/",
                            "../greeter/build/module/acvp-core/"
                    }
            ),
            target = "arrival.Greeter",
            helper = "arrival.GreeterHelper"
    )
    public class GreeterConfig implements InfoMapper {
        public void map(InfoMap infoMap) {
            infoMap.put(new Info("std::function<void(boolsuccess)>").pointerTypes("BooleanCallback").define());
            infoMap.put(new Info("std::function<void(std::string_viewmessage)>").pointerTypes("StringCallback").define());
            infoMap.put(new Info("std::string_view").pointerTypes("@StdString String").define());
        }
    }
    

    Here is generated file:

    public static native void testStringView(@ByVal StringCallback callback);
    
    public static native void testBoolean(@ByVal BooleanCallback callback);
    
    public static native void plainStringView(@ByVal @StdString String message);
    
    public static native void plainBoolean(@Cast("bool") boolean success);
    

    With these settings it works ok for plainStringView function (plain function which receives string_view) and testBoolean function (function which receives callback with bool parameter), but I have an error for testStringView - function which receives callback with string_view parameter. How it can be fixed? Also this is strange but initial file which generates javacpp contains missed space symbol between callback parameter type and parameter name: std::function<void(boolsuccess)>.

    bug enhancement help wanted 
    opened by ValentinaBaranova 6
  • Error message for why org.bytedeco.javacpp.cachedir could not be created

    Error message for why org.bytedeco.javacpp.cachedir could not be created

    The cache dir can be set via the system property org.bytedeco.javacpp.cachedir The Loader.getCacheDir() method will try this path, plus some others, and if creating all of these fails, it throws the error IOException("Could not create the cache: Set the \"org.bytedeco.javacpp.cachedir\" system property.");

    If org.bytedeco.javacpp.cachedir has been set, but could not be created, then this error message is misleading, as it suggests the system property wasn't set properly

    If org.bytedeco.javacpp.cachedir has been set, then it should be checked on its own and an error thrown explaining why this specific path could not be used

    enhancement help wanted 
    opened by Robbie-Palmer 1
  • UnsatisfiedLinkError: no jniopencv_core on NVIDIA Jetson TX2

    UnsatisfiedLinkError: no jniopencv_core on NVIDIA Jetson TX2

    I am building a process for OpenSensorHub on Jetson TX2 using Gradle and I am getting an error when initializing the process: UnsatisfiedLinkError: no jniopencv_core

    My build.gradle dependencies are setup as follows:

    dependencies {
        implementation 'org.sensorhub:sensorhub-core:' + oshCoreVersion
        implementation project(':sensorhub-driver-videocam')
        embeddedImpl 'org.jcodec:jcodec-javase:0.1.9'
        embeddedImpl group: 'org.bytedeco', name: 'javacv-platform', version: '1.5.7'
        embeddedImpl group: 'org.bytedeco.javacpp-presets', name: 'opencv', version: '4.0.1-1.4.4'
        embeddedImpl group: 'org.bytedeco', name: 'cuda', version: '11.6-8.3-1.5.7', classifier: 'linux-arm64'
        testImplementation('junit:junit:4.13')
    }
    

    I have also tried, with the same effect, no jniopencv_core

    dependencies {
        implementation 'org.sensorhub:sensorhub-core:' + oshCoreVersion
        implementation project(':sensorhub-driver-videocam')
        embeddedImpl 'org.jcodec:jcodec-javase:0.1.9'
        embeddedImpl group: 'org.bytedeco', name: 'javacv-platform', version: '1.5.7'
        embeddedImpl 'org.bytedeco:javacpp-presets:1.5.7'
        embeddedImpl group: 'org.bytedeco.javacpp-presets', name: 'opencv', version: '4.0.1-1.4.4'
        embeddedImpl group: 'org.bytedeco', name: 'cuda', version: '11.6-8.3-1.5.7', classifier: 'linux-arm64'
        testImplementation('junit:junit:4.13')
    }
    

    The packaging of dependencies is working correctly, however I cannot seem to get the jniopencv_core issue resolved. I read that it was necessary to include the org.bytedeco:javacpp-presets as I did above. As an aside, is there currently no classifier for this package to only select the jars for a particular architecture?

    The full error log is given:

    2022-09-01 12:00:15.594 ERROR SMLProcessImpl:d3b84935 [ForkJoinPool.commonPool-worker-3] - Error initializing SML process
    java.util.concurrent.CompletionException: java.lang.UnsatisfiedLinkError: no jniopencv_core in java.library.path: [/usr/local/cuda-10.2/lib64, ., /usr/java/packages/lib, /usr/lib/aarch64-linux-gnu/jni, /lib/aarch64-linux-gnu, /usr/lib/aarch64-linux-gnu, /usr/lib/jni, /lib, /usr/lib]
            at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
            at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
            at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1739)
            at java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728)
            at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
            at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
            at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
            at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
            at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
    Caused by: java.lang.UnsatisfiedLinkError: no jniopencv_core in java.library.path: [/usr/local/cuda-10.2/lib64, ., /usr/java/packages/lib, /usr/lib/aarch64-linux-gnu/jni, /lib/aarch64-linux-gnu, /usr/lib/aarch64-linux-gnu, /usr/lib/jni, /lib, /usr/lib]
            at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2670)
            at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:830)
            at java.base/java.lang.System.loadLibrary(System.java:1873)
            at NativeClassLoader//org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:1800)
            at NativeClassLoader//org.bytedeco.javacpp.Loader.load(Loader.java:1402)
            at NativeClassLoader//org.bytedeco.javacpp.Loader.load(Loader.java:1214)
            at NativeClassLoader//org.bytedeco.javacpp.Loader.load(Loader.java:1190)
            at NativeClassLoader//org.bytedeco.javacpp.opencv_core.<clinit>(opencv_core.java:10)
            at java.base/java.lang.Class.forName0(Native Method)
            at java.base/java.lang.Class.forName(Class.java:398)
            at NativeClassLoader//org.bytedeco.javacpp.Loader.load(Loader.java:1269)
            at NativeClassLoader//org.bytedeco.javacpp.Loader.load(Loader.java:1214)
            at NativeClassLoader//org.bytedeco.javacpp.Loader.load(Loader.java:1190)
            at NativeClassLoader//org.bytedeco.javacpp.opencv_core$Algorithm.<clinit>(opencv_core.java:15354)
            at NativeClassLoader//com.botts.process.image.FeatureDetectionProcess.loadClassifiers(FeatureDetectionProcess.java:196)
            at NativeClassLoader//com.botts.process.image.FeatureDetectionProcess.init(FeatureDetectionProcess.java:125)
            at NativeClassLoader//org.vast.process.ExecutableChainImpl.init(ExecutableChainImpl.java:263)
            at NativeClassLoader//org.vast.sensorML.AbstractProcessImpl.init(AbstractProcessImpl.java:223)
            at NativeClassLoader//org.sensorhub.impl.processing.SMLProcessImpl.initChain(SMLProcessImpl.java:125)
            at NativeClassLoader//org.sensorhub.impl.processing.SMLProcessImpl.lambda$doInit$0(SMLProcessImpl.java:107)
            at NativeClassLoader//org.sensorhub.utils.Lambdas.lambda$checked$0(Lambdas.java:66)
            at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
            ... 6 common frames omitted
    Caused by: java.lang.UnsatisfiedLinkError: Could not find jniopencv_core in class, module, and library paths.
            at NativeClassLoader//org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:1767)
            ... 24 common frames omitted
    

    What am I missing?

    Thank you!

    enhancement help wanted question 
    opened by nickgaray 9
  • Unexpected token '::' in namespace name

    Unexpected token '::' in namespace name

    Hello,

    The first line of the following is raising org.bytedeco.javacpp.tools.ParserException saying : Unexpected token '::'.

    Exception in thread "main" org.bytedeco.javacpp.tools.ParserException: "thefileconcerned.h":Unexpected token '::'
            at org.bytedeco.javacpp.tools.Token.expect(Token.java:114)
            at org.bytedeco.javacpp.tools.Parser.namespace(Parser.java:3954)
            at org.bytedeco.javacpp.tools.Parser.declarations(Parser.java:4077)
            at org.bytedeco.javacpp.tools.Parser.parse(Parser.java:4167)
            at org.bytedeco.javacpp.tools.Parser.parse(Parser.java:4322)
            at org.bytedeco.javacpp.tools.Builder.parse(Builder.java:95)
            at org.bytedeco.javacpp.tools.Builder.build(Builder.java:1095)
            at org.bytedeco.javacpp.tools.Builder.main(Builder.java:1450)
    
    namespace namespace1::namespace2
    {
        // Some code ...
    }
    

    I don't know if it is a bug or a limitation ?

    enhancement help wanted 
    opened by Toxlen 3
  • Show some information if user didn't add javacpp-platform

    Show some information if user didn't add javacpp-platform

    Hello.

    I would like to suggest some enhancment that I think can make javacpp a little bit more user-friendly. I mean when user tries to use javacpp in some Gradle project he can forget to add javacpp-platform dependency and therefore some stuff won't work. For now if I don't add javacpp-platform I don't see any error or warning message because javacpp logs it in debug level and I don't know how to turn it on. Anyway there might be a situation when user forgot to turn on debug level for logger and also forgot to add javacpp-platform so some java.lang.UnsatisfiedLinkError: no jnijavacpp in java.library.path will happen and never be shown to user. It can be hard to debug what is wrong. I would suggest to add some informative message saying that javacpp-platform dependency is missed or something like that

    public class Loader {
      //...
      static {
          try {
              Loader.load();
          } catch (Throwable t) {
              if (logger.isDebugEnabled()) {
                  logger.debug("Could not load Loader: " + t);
              }
          }
      }
      
      public static String load(Class cls, Properties properties, boolean pathsFirst, String executable) {
        try {
            //...
        } catch (UnsatisfiedLinkError e) {
            Throwable t = e;
            while (t != null) {
                if (t instanceof UnsatisfiedLinkError &&
                        t.getMessage().contains("already loaded in another classloader")) {
                    librarySuffix++;
                    continue tryAgain;
                }
                t = t.getCause() != t ? t.getCause() : null;
            }
            if (preloadError != null && e.getCause() == null) {
                e.initCause(preloadError);
            }
            if (!checkPlatform(cls, properties, false)) {
                // this is an optional library
                return null;
            } else {
                throw e;
            }
        }
      }
      //...
    }
    
    enhancement help wanted 
    opened by bepopov 2
Releases(1.5.7)
  • 1.5.7(Feb 10, 2022)

    February 11, 2022 version 1.5.7

    • Add Loader.clearCacheDir() along with new ClearMojo and -clear command line option
    • Speed up Loader on Windows when there are no symbolic links or library versions (pull #512)
    • Enhance Pointer.physicalBytes() by excluding shared pages from memory-mapped files, etc (issue #468)
    • Fix Parser not correctly encoding files of top-level classes produced with @Properties(target=..., global=...)
    • Add Pointer.interruptDeallocatorThread() method to make JavaCPP classes eligible for GC (discussion bytedeco/javacpp-presets#1115)
    • Let Parser output the content of Info.javaText in the case of FunctionPointer as well
    • Fix TokenIndexer failure on macros using the concat ## operator with empty arguments (issue #525)
    • Let Parser support arrays of anonymous struct or union containing another one (discussion #528)
    • Prevent Parser from outputting duplicate Pointer constructors for basic containers
    • Fix Generator compiler errors on callback functions returning objects without default constructors
    • Ensure Builder copies resources only from the first directories found in the paths
    • Add Loader.getCanonicalPath() to work around bugs in File.getCanonicalPath() on Windows (pull #519)
    • Add FunctionPointer and @Virtual methods missing from config files required by GraalVM Native Image
    • Let Tokenizer convert characters using ASCII escape sequences '\x...' to normal hexadecimal values 0x...
    • Fix Parser incorrectly mapping default function arguments containing multiple template arguments
    • Fix Parser failures on variadic templates calling sizeof...() and on variables initialized from template values
    • Prevent Parser from failing on nonexistent header files contained in @Platform(exclude=...)
    • Add classOrPackageNames parameter to CacheMojo (pull #510)
    Source code(tar.gz)
    Source code(zip)
    javacpp-platform-1.5.7-bin.zip(3.44 MB)
    javacpp-platform-1.5.7-src.zip(451.09 KB)
  • 1.5.6(Aug 2, 2021)

    August 2, 2021 version 1.5.6

    • Add missing export to module-info.java file for presets package (pull #508)
    • Add @NoException(true) value to support overriding virtual noexcept functions
    • Bundle more DLLs from UCRT to fix the systems presets on Windows
    • Fix Pointer.sizeof() method for subclasses of subclasses for primitive types (issue bytedeco/javacpp-presets#1064)
    • Throw more accurate UnsatisfiedLinkError when Loader.load() fails to find JNI libraries
    • Let Parser check Info.skipDefaults also for types to ignore default constructors (issue #493)
    • Fix Parser failure on enum declarations without enumerators
    • Let Generator use the third element of @Cast(value) on return values passed to adapters (issue tensorflow/java#345)
    • Prevent Generator from swallowing exceptions caught on Buffer.array() (pull #504)
    • Add enum classes as well as resources missing from config files required by GraalVM Native Image
    • Let Parser annotate && parameters with new @ByRef(true) value used by Generator to call std::move()
    • Fix Parser overlooking anonymous class, struct or union with comments after } (issue #501)
    • Add Info.beanify to have Parser generate JavaBeans-style getters and setters (pull #495)
    • Allow Parser to use Info.javaNames for function names containing parameters as well (issue #492)
    • Fix Parser producing incorrect calls to function templates with non-type parameters (issue #491)
    • Add missing presets/package-info.java required for OSGi and add profile for M2Eclipse (pull #490)
    • Remove unnecessary mutex lock for pthreads on callbacks in Generator (pull #489)
    • Fix @AsUtf16 handling for setter methods paired with getters in Generator (pull #488)
    • Allow defining NO_JNI_DETACH_THREAD to avoid overhead from pthreads on callbacks (issue #486)
    • Pick up @Allocator, @CriticalRegion, @NoException in Generator from @Properties(inherit=classes) as well (issue #484)
    • Add support for Deleter of pointer types to UniquePtrAdapter
    • Add @Platform(pattern=...) annotation value to allow matching with regular expressions as well
    • Allow Parser to consider function pointers declared with using but without indirections
    • Let Parser map to annotations whole expressions starting with the __attribute__ keyword
    • Fix Parser sometimes failing to create template instances with default arguments (issue #478)
    • Enhance Parser to handle typedef correctly in the case of enum as well (issue #477)
    • Upon Pointer.getPointer(Class<P>) scale position, limit, and capacity with sizeof() (pull #476)
    • Fix Parser incorrectly translating non-documentation comments as part of documentation comments (issue #475)
    • Set Pointer.maxPhysicalBytes to 4 * Runtime.maxMemory() by default as workaround for Android, memory-mapped files, ZGC, etc (issue #468)
    • Ensure synchronized code in Pointer gets skipped with "org.bytedeco.javacpp.nopointergc" (issue tensorflow/java#313)
    • Add protected Pointer.offsetAddress() and use it for getPointer() instead of position()
    • Fix potential infinite loop in Parser when processing class, struct, or union declarations
    • Have Parser wrap the erase() methods of basic containers with iterators to allow removing from maps
    • Let Parser output the content of Info.javaText in the case of basic containers as well
    • Fix Parser failure on arguments containing multiple array accesses ending with ]]
    • Fix Parser incorrectly considering some array definitions with expressions as multidimensional
    • Log loading errors of optional jnijavacpp as debug messages instead of warnings (issue tensorflow/java#189)
    • Fix memory leak in Pointer.releaseReference() with "org.bytedeco.javacpp.nopointergc" (issue awslabs/djl#690)
    • Fix Parser not stripping annotations from Info.pointerTypes when creating Java peer classes
    • Fix Parser not inheriting constructors with existing Info or with nested templates
    • Add support for std::tuple, std::optional, and std::variant basic containers and fix various Parser failures
    • Add parameter for Loader.load() to return path of a specific executable (pull #466)
    • Use std::uninitialized_copy in VectorAdapter to make sure copy constructors get called (pull #465)
    Source code(tar.gz)
    Source code(zip)
    javacpp-platform-1.5.6-bin.zip(3.41 MB)
    javacpp-platform-1.5.6-src.zip(450.94 KB)
  • 1.5.5(Mar 8, 2021)

    March 8, 2021 version 1.5.5

    • Ensure System.gc() never gets called with "org.bytedeco.javacpp.nopointergc" (issue tensorflow/java#208)
    • Add Info.immutable to disable generating setters for public data members (pull #461)
    • Map String to char* with Charset.forName(STRING_BYTES_CHARSET) when that macro is defined (pull #460)
    • Fix Loader.ClassProperties not always getting overridden correctly when defined multiple times
    • Allow Loader.load() to also rename executables on extraction to output filenames specified with the # character
    • Add @AsUtf16 annotation to map java.lang.String to unsigned short* (array of UTF-16 code units) (pull #442)
    • Add BasicStringAdapter and corresponding @StdBasicString, @StdU16String, and @StdU32String annotations (pull #448)
    • Fix Parser failures on try blocks as function body, nested class templates, and aliases to namespaces starting with ::
    • Prevent Loader from failing to find, load, or link libraries multiple times
    • Fix Pointer.getPointer() methods sometimes calling the wrong constructor (issue bytedeco/javacv#1556)
    • Prevent Android from trying to load PointerBufferPoolMXBean by using it via reflection (pull #447)
    • Fix Android build properties for NDK r22 and move legacy to android-*-gcc.properties (pull #444)
    • Add support for Mac on ARM processors
    • Fix Loader not searching for libraries in more than one package
    • Prevent Builder from linking with -framework JavaVM when a path to the JVM library is found
    • Replace requires with requires static in JPMS .platform module (pull #436)
    • Let Parser output Info.javaText even for template declarations with no instances
    • Prevent Tokenizer from using long literals for unsigned integers of 16 bits or less
    • Ensure Parser considers >= and <= as single tokens to prevent failures
    • Make Parser use Info.cppTypes to override the type of enum values
    • Fix Parser not using the correct Info.pointerTypes for const& declarations
    • Use pthreads in Generator to detach automatically native threads on exit for Linux and Mac as well
    • Let Loader.load() always succeed on optional libraries only available with extensions
    • Fix Builder.addProperty() incorrectly appending values together
    Source code(tar.gz)
    Source code(zip)
    javacpp-platform-1.5.5-bin.zip(3.63 MB)
    javacpp-platform-1.5.5-src.zip(444.55 KB)
  • 1.5.4(Sep 9, 2020)

    September 9, 2020 version 1.5.4

    • Fix Parser not producing PointerPointer parameters for FunctionPointer subclasses
    • Let Builder copy even those platform.executable files without prefix or suffix
    • Add missing declaration for GetCurrentThreadId() in Generator when NO_WINDOWS_H is defined
    • Process #undef directives to allow redefining macros with Parser (issue bytedeco/javacpp-presets#935)
    • Pick up in Parser methods specified with override, in addition to virtual (issue #419)
    • Let Parser create a separate Java peer class when Info.pointerTypes is different for types prefixed with const
    • Fix Generator for @Virtual methods protected in subclasses by casting to superclass (issue #419)
    • Add missing values to Info.Info(Info) and fix incorrect Info.skipDefaults(boolean) (issue #420)
    • Add PointerBufferPoolMXBean to track allocations and deallocations of Pointer (pull #413)
    • Change the @Platform(executable=... property to an array and allow bundling multiple files per class
    • Prevent Builder unnecessarily linking with -framework JavaVM to fix GraalVM Native Image on Mac (issue #417)
    • Add Pointer.getPointer() methods as shortcuts for new P(p).position(p.position + i) (issue #155)
    • Fix Generator for cases when a FunctionPointer returns another FunctionPointer
    • Fix Parser failure with auto keyword of C++11 used as placeholder type specifier or for trailing return type (issue #407)
    • Add Builder.configDirectory option to let Generator output files that GraalVM needs for AOT compilation (issue eclipse/deeplearning4j#7362)
    • Fix Parser error on template<> containing non-type parameters without names (issue bytedeco/javacpp-presets#889)
    • Bundle also the vcruntime140_1.dll and msvcp140_1.dll redist files from Visual Studio
    • Fix Builder for different "java.home" path returned by latest JDKs from Oracle (pull #400)
    • Refactor Builder a little to work around issues with Gradle
    • Log as warnings SecurityException thrown on Loader.getCacheDir() instead of swallowing them
    • Fix memory leak that occurs with "org.bytedeco.javacpp.nopointergc" (issue bytedeco/javacpp-presets#878)
    • Take into account platform.library.path when extracting executables and their libraries on Loader.load() (issue bytedeco/javacv#1410)
    • Move init code for Loader.getPlatform() to Detector to avoid warning messages (issue #393)
    • Add HyperslabIndex class with offsets, strides, counts, and blocks parameters (pull #392)
    • Add Index class to allow overriding how the index is calculated in Indexer (issue #391)
    Source code(tar.gz)
    Source code(zip)
    javacpp-platform-1.5.4-bin.zip(3.60 MB)
    javacpp-platform-1.5.4-src.zip(434.43 KB)
  • 1.5.3(Apr 14, 2020)

    April 14, 2020 version 1.5.3

    • Deprecate but also fix Indexer.rows(), cols(), width(), height(), and channels() (pull #390)
    • Fix Parser producing invalid wrappers for basic containers like std::set<std::pair<...> >
    • Add compiler options for C++98, C++03, C++14, and C++17 to platform properties files (pull #389)
    • Remove default compiler options from linux-armhf.properties that work mostly only for Raspberry Pi
    • Add Generator support for enum classes with boolean values (issue #388)
    • Fix Parser outputting invalid Java code for enum of boolean, byte, and short types (issue #388)
    • Pick up in Generator the @Namespace annotation from paired method too for global getters and setters (issue #387)
    • Add presets for jnijavacpp and javacpp-platform artifact to fix issues at load time (issue bytedeco/javacv#1305)
    • Prevent potential NullPointerException in Loader.checkVersion() (pull #385)
    • Allow using Charset to avoid UnsupportedEncodingException from BytePointer (pull #384)
    • Add static Pointer.isNull(Pointer p) helper method, for convenience
    • Add MoveAdapter and corresponding @StdMove annotation to support objects that require std::move from C++11
    • Always use File.pathSeparator when passing multiple paths via the BUILD_PATH environment variable
    • Fix Parser not picking up Info for declarations with decltype() specifier
    • Fix Pointer losing its owner when mistakenly ignoring deallocators for const values returned from adapters
    • Remove unnecessary declared Exception from Indexer.close() signature (pull #382)
    • Make sure Parser recognizes base classes of struct as public by default
    • Fix Parser error on initializer lists containing C++11 style { ... } for template instances
    • Change the default mapping of jboolean to BooleanPointer instead of BoolPointer
    • Fix Parser error on function declarations with ... varargs as single parameter
    • Make Parser skip over &&-qualified functions automatically since they cannot be supported
    • Fix Parser annotating pointer cast operator methods with incorrect @Cast (issue #379)
    • Allow Parser to inherit constructors from template classes with using
    • Make Parser honor Info.skip for anonymous struct or union as well
    • Optimize Pointer.sizeof() method of subclasses for primitive types
    • Let users override Info.enumerate on a per-enum basis and allow attributes after enum class
    • Fix Parser not considering identifiers as type names when placed directly after friend or in template<>
    • Check for defined NO_WINDOWS_H macro in Generator to skip #include <windows.h>
    • Provide UIntIndexer and ULongIndexer, treating array and buffer data as unsigned 32- or 64-bit integers, for convenience (issue #376)
    • Fix Parser not evaluating using namespace with respect to the current block (issue #370)
    • Fix exception in Loader when running jlink image with JDK 13+ (pull #375)
    • Fix errors with @Virtual @Name("operator ...") in Generator by using Java names for C++ (issue #362)
    • Apply in Parser missing const to parameters of @Virtual functions using adapters
    • Use in Generator C++11 override keyword for @Virtual functions (pull #373)
    • Speed up Loader.load() by caching results returned from Loader.findLibrary() (issue #287)
    • Pick up Info correctly in Parser also for anonymous function pointers with const parameters
    • Make Parser apply Info.translate in the case of enumerators as well
    • Fix compiler failures in Builder with platform properties containing relative paths
    • Let Parser rename types using Info.javaNames in addition to valueTypes and pointerTypes (pull #367)
    • Include in the defaults of InfoMap mappings missing for the std::array and jchar types
    • Fix various Parser failures with attributes on constructors, empty macros, enum classes, friend classes, inherited constructors, and keywords in parameter names
    • Add to Parser support for C++11 attributes found within [[ and ]] brackets
    • Consider Pointer values maxBytes or maxPhysicalBytes suffixed with % as relative to Runtime.maxMemory() (pull #365)
    • Prevent Parser from considering constexpr operator declarations as const types
    • Fix on Loader.load() the default library name of classes without @Properties(target=..., global=...)
    • Prevent Parser from outputting asPointer() cast methods with multiple inheritance (issue #360)
    • Add CacheMojo to help extract binaries and resources used by command line tools outside of the JVM
    • Fix Android build properties for NDK r20b (pull #357)
    Source code(tar.gz)
    Source code(zip)
    javacpp-platform-1.5.3-bin.zip(3.50 MB)
    javacpp-platform-1.5.3-src.zip(418.90 KB)
  • 1.5.2(Nov 5, 2019)

    November 5, 2019 version 1.5.2

    • Provide ByteIndexer with value getters and setters for unsigned byte or short, half, bfloat16, and boolean types as well
    • Introduce PointerScope.extend() to prevent deallocation on the next call to close()
    • Make Generator avoid ambiguous conversion errors from UniquePtrAdapter to std::unique_ptr (pull #353)
    • Fix Parser using fully qualified names for @Name annotations of nested classes (issue #352)
    • Add Parser support for macro expansion of __VA_ARGS__
    • Fix Builder not processing all classes when given .** as input (issue bytedeco/javacv#1311)
    • Introduce reference counting in Pointer and retrofit PointerScope to use it
    • Fix Parser incorrectly inheriting default constructors multiple times with using
    • Allow in Parser fully qualified names as Info.valueTypes for enumerators as well
    • Perform template substitution in Parser also for default argument values (pull #343)
    • Introduce PointerScope.forClasses to limit the Pointer classes that can be attached to a given instance
    • Add support for custom Allocator to VectorAdapter and custom Deleter to UniquePtrAdapter
    • Enable support for OSGi bundles (pull #332)

    September 5, 2019 version 1.5.1-1

    • Use the native thread ID as name on AttachCurrentThread() (pull #339)
    • Make sure we canRead(), canWrite(), and canExecute() what Loader.getCacheDir() returns
    • Prevent Generator from copying data unnecessarily when returning Java arrays from adapters (issue #317)
    • Fix Parser issues when casting const pointers or enumerating anonymous enum declarations
    • Add Info.objectify to map global functions without using the static modifier, similarly to Scala companion objects
    • Allow once more abstract subclasses of FunctionPointer (issue #318)
    Source code(tar.gz)
    Source code(zip)
    javacpp-1.5.2-bin.zip(417.47 KB)
    javacpp-1.5.2-src.zip(387.63 KB)
  • 1.5.1(Jul 9, 2019)

    July 9, 2019 version 1.5.1

    • Make sure Generator ignores deallocators on const values returned from adapters (issue #317)
    • Accelerate Loader.extractResource() for directories already cached, also preventing failures (issue #197)
    • Avoid Parser writing allocateArray() when single int, long, float, or double constructor already exists (issue bytedeco/javacv#1224)
    • Expose all platform properties to process executed with Builder.buildCommand via environment variables, with names uppercase and all . replaced with _
    • Let Parser add @Name or @Namespace annotations to non-translated enumerators as well
    • Make Parser pick up the names of type aliases for function pointers declared with using and prevent NullPointerException
    • Fix Parser failing on lambda expressions found inside member initialization lists of constructors
    • Add special support for constexpr variables in Parser by disabling their member setters automatically
    • Fix Parser not placing & and * at the right place inside template arguments containing function declarations
    • Support more basic containers in Parser by comparing their names in a case-insensitive manner and add annotations missing from index types
    • Fix Generator taking the @By* annotation of the paired method for the index instead of the value argument of a setter
    • Fix Parser sometimes considering global C++ identifiers starting with :: as if they were local
    • Change default value for Pointer.maxPhysicalBytes to Pointer.maxBytes + Runtime.maxMemory() (pull #310)
    • Add Loader.getVersion() and checkVersion() to get versions of Maven artifacts and check against JavaCPP
    • Fix compile errors caused by Generator occurring with callback functions returning a value by reference
    • Make Builder expand entries from the user class path with * as basename to all JAR files in the directory
    • Prevent Loader from creating symbolic links pointing to themselves by comparing with Path.normalize() (pull #307)
    • Fix Loader.cacheResource() with the "jrt" protocol as used by jlink (pull #305)
    • Fix compiler error with SharedPtrAdapter and UniquePtrAdapter in callback functions (pull #304)
    • Start Pointer.DeallocatorThread with setContextClassLoader(null) as required by containers (issue deeplearning4j/deeplearning4j#7737)
    • Add -print command line option to access platform properties externally, for example, inside build scripts
    • Add to InfoMap default pointer and value types for ssize_t, char16_t, char32_t, std::u16string, and std::u32string
    • Support multiple instances of FunctionPointer subclasses, up to the value in @Allocator(max=...) (issue bytedeco/javacpp-presets#683)
    • Allow suffixing library names with : to specify exact relative paths to libraries, ignoring any additional prefix or suffix
    • Prevent Loader.load() from trying to load library files that do not exist or to create symbolic links to them
    • Let Loader.load() extract libraries suffixed with ##, but still ignored for copying by Builder
    • Make sure Loader.load() also initializes classes that are passed explicitly
    • Fix Loader.createLibraryLink() incorrectly truncating library versions when there is one before and another after the suffix
    • Iterate extensions of libraries or executables on Loader.load() in reverse to be consistent with properties overriding
    • Allow prefixing library names with : to have Loader consider them as filenames with prefix and suffix already included
    • Add Loader.loadGlobal() to load symbols globally as often required by Python libraries (issue ContinuumIO/anaconda-issues#6401)
    Source code(tar.gz)
    Source code(zip)
    javacpp-1.5.1-bin.zip(408.69 KB)
    javacpp-1.5.1-src.zip(374.55 KB)
  • 1.5(Apr 10, 2019)

    April 11, 2019 version 1.5

    • Have Parser output setter as dummy parameter name for setter methods to clarify usage
    • Add Indexer.strides(long... sizes) and use as default strides when not specified by the user
    • Add long... constructors, getters, and setters to CLongPointer and SizeTPointer for convenience
    • Fix some Generator issues with FunctionPointer passed or returned @ByPtrPtr
    • Use ModiTect to compile module-info.java with JDK 8 and preserve backward compatibility
    • Add platform.executable and platform.executablepath properties to bundle executables and extract them with Loader.load()
    • Create symbolic links for all libraries preloaded by Loader as they get loaded to satisfy libraries like MKL
    • Prevent ClassCastException in Loader on illegal system properties (issue #289)
    • Fix Parser not replacing all type names of the base class with Info.flatten (issue #288)
    • Let BuildMojo return to the Maven project the detected host platform as ${javacpp.platform.host}
    • Have BuildMojo output a JPMS friendly name for the platform and extension back to the Maven project as ${javacpp.platform.module}
    • Add Builder.clean option to delete the outputDirectory before generating files
    • Let Parser pick up Info explicitly for all constructors by considering their names as functions (issue #284)
    • Fix Parser not always generating files using the simple names of classes
    • Add a BuildMojo.targetDirectories parameter to allow setting multiple directories where to find generated Java files
    • Add Parser support for attributes appearing after struct declarations (issue bytedeco/javacpp-presets#685)
    • Fix Parser overlooking Info for constructors inside namespaces or templates (issue #284)
    • Fix Parser applying some Info.annotations at the wrong place (issue #284)
    • Make Parser behave the same with @Properties having only one out of global or target value set
    • Enhance UniquePtrAdapter with the ability to move pointers out with the && operator
    • Let Parser map constructors also for abstract classes with Info.virtualize
    • Fix Parser taking the global package as the target package even when both are set
    • Consider @Properties(global=..., helper=...) class names without "." as relative to target (pull bytedeco/javacpp-presets#669)
    • Use regex in Parser to translate more Doxygen commands into Javadoc tags (pull #278 and pull #281)
    • Do not let Parser map operator=() when prefixing container name with const (pull #280)
    Source code(tar.gz)
    Source code(zip)
    javacpp-1.5-bin.zip(402.69 KB)
    javacpp-1.5-src.zip(369.57 KB)
Owner
Bytedeco
Bringing compute-intensive science, multimedia, computer vision, deep learning, etc to the Java platform
Bytedeco
Seamless operability between C++11 and Python

pybind11 — Seamless operability between C++11 and Python Setuptools example • Scikit-build example • CMake example Warning Combining older versions of

pybind 11.6k Sep 22, 2022
Sol3 (sol2 v3.0) - a C++ <-> Lua API wrapper with advanced features and top notch performance - is here, and it's great! Documentation:

sol2 sol2 is a C++ library binding to Lua. It currently supports all Lua versions 5.1+ (LuaJIT 2.0+ and MoonJIT included). sol2 aims to be easy to use

The Phantom Derpstorm 3.1k Sep 13, 2022
Structy is an irresponsibly dumb and simple struct serialization/deserialization library for C, Python, and vanilla JavaScript.

Structy Structy is an irresponsibly dumb and simple struct serialization/deserialization library for C, Python, and vanilla JavaScript. You can think

Stargirl Flowers 48 Sep 13, 2022
Libraries and examples to support Pimoroni Pico add-ons in C++ and MicroPython.

Pimoroni Pico Libraries and Examples Welcome to the brave new world of Pico! This repository contains the C/C++ and MicroPython libraries for our rang

Pimoroni Ltd 620 Sep 22, 2022
Tools and libraries to glue C/C++ APIs to high-level languages

CppSharp is a tool and set of libraries which facilitates the usage of native C/C++ code with the .NET ecosystem. It consumes C/C++ header and library

Mono Project 2.4k Sep 19, 2022
A tool for generating cross-language type declarations and interface bindings.

Djinni Djinni is a tool for generating cross-language type declarations and interface bindings. It's designed to connect C++ with either Java or Objec

Dropbox 2.8k Sep 5, 2022
Duktape - embeddable Javascript engine with a focus on portability and compact footprint

Duktape ⚠️ Master branch is undergoing incompatible changes for Duktape 3.x. To track Duktape 2.x, follow the v2-maintenance branch. Introduction Dukt

Sami Vaarala 5.4k Sep 18, 2022
SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages.

SWIG (Simplified Wrapper and Interface Generator) Version: 4.1.0 (in progress) Tagline: SWIG is a compiler that integrates C and C++ with languages

SWIG 4.7k Sep 15, 2022
A minimalist and mundane scripting language.

Drift Script A minimalist and mundane scripting language. I like all simple things, simple and beautiful, simple and strong. I know that all developme

Drift 11 Apr 3, 2022
sc-ble-bridge is a utility that for every connected Steam Controller creates a virtual one acting as a bridge between SC and Steam

sc-ble-bridge The main goal of this utility is to provide workaround for steam-for-linux issue which makes Valve's Steam Controller unusable in BLE mo

null 5 Apr 19, 2022
Pico-uart-bridge - Raspberry Pi Pico UART-USB bridge

Raspberry Pi Pico USB-UART Bridge This program bridges the Raspberry Pi Pico HW UARTs to two independent USB CDC serial devices in order to behave lik

Álvaro Fernández Rojas 130 Sep 19, 2022
✔️The smallest header-only GUI library(4 KLOC) for all platforms

Welcome to GUI-lite The smallest header-only GUI library (4 KLOC) for all platforms. 中文 Lightweight ✂️ Small: 4,000+ lines of C++ code, zero dependenc

null 6.4k Sep 21, 2022
Another try to re-create Project Astoria , or some bridge between A and W...

Bridge 1.0.10.0 Forked from: https://github.com/DroidOnUWP/Bridge Abstract Another "Project Astoria" remake (UWP) Original status: Forgotten (?) My ac

Media Explorer 5 Sep 10, 2022
This calculator attempts to bridge the gap between qualitative and quantitative data in societal interactions

This calculator attempts to bridge the gap between qualitative and quantitative data in societal interactions. This will help you determine how long you should take before replying to a message from a friend/acquaintance. Use these calculations at your own risk.

Ethan Bores 1 Jan 20, 2022
Simple hook that prevent to halt Java Virtual Machine (mostly used in hacking java programs)

JavaExitHook Simple hook that prevent to halt Java Virtual Machine (mostly used in hacking java programs) What is used for? Idea to create that simple

null 13 Jul 23, 2022
Inter-process communication library to enable allocation between processes/threads and send/receive of allocated regions between producers/consumer processes or threads using this ipc buffer.

This is a relatively simple IPC buffer that allows multiple processes and threads to share a dynamic heap allocator, designate "channels" between processes, and share that memory between producer/consumer pairs on those channels.

RaftLib 8 Aug 20, 2022
⛵ The missing small and fast image decoding library for humans (not for machines).

Squirrel Abstract Image Library The missing fast and easy-to-use image decoding library for humans (not for machines). Target Audience • Features • Im

Dmitry Baryshev 191 Sep 4, 2022
All the missing SQLite functions

SQLite Plus: all the missing SQLite functions SQLite has very few functions compared to other DBMS. SQLite authors see this as a feature rather than a

Anton Zhiyanov 1.5k Sep 20, 2022
📦 CMake's missing package manager. A small CMake script for setup-free, cross-platform, reproducible dependency management.

Setup-free CMake dependency management CPM.cmake is a CMake script that adds dependency management capabilities to CMake. It's built as a thin wrapper

CPM.cmake 1.3k Sep 21, 2022
SQLean: all the missing SQLite functions

SQLite has very few functions compared to other DBMS. SQLite authors see this as a feature rather than a bug, because SQLite has extension mechanism in place.

Anton Zhiyanov 1.5k Sep 20, 2022