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.5</version>
  </dependency>
  • Gradle (inside the build.gradle file)
  dependencies {
    implementation group: 'org.bytedeco', name: 'javacpp', version: '1.5.5'
  }
  • Leiningen (inside the project.clj file)
  :dependencies [
    [org.bytedeco/javacpp "1.5.5"]
  ]
  • sbt (inside the build.sbt file)
  libraryDependencies += "org.bytedeco" % "javacpp" % "1.5.5"

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
  • How to replace deprecated

    How to replace deprecated "new Context(Device.TYPE_GPU)"

    I used the constructor "new Context(int dtype)" to get information about installed GPU devices. However, in current version this constructor is deprecated. How can I replace this call in modern API?

    help wanted question 
    opened by Daniel-Alievsky 5
  • [SECURITY] Fix Temporary File Information Disclosure Vulnerability

    [SECURITY] Fix Temporary File Information Disclosure Vulnerability

    Security Vulnerability Fix

    This pull request fixes a Temporary File Information Disclosure Vulnerability, which existed in this project.

    Preamble

    The system temporary directory is shared between all users on most unix-like systems (not MacOS, or Windows). Thus, code interacting with the system temporary directory must be careful about file interactions in this directory, and must ensure that the correct file posix permissions are set.

    This PR was generated because a call to File.createTempFile(..) was detected in this repository in a way that makes this project vulnerable to local information disclosure. With the default uname configuration, File.createTempFile(..) creates a file with the permissions -rw-r--r--. This means that any other user on the system can read the contents of this file.

    Impact

    Information in this file is visible to other local users, allowing a malicious actor co-resident on the same machine to view potentially sensitive files.

    Other Examples

    The Fix

    The fix has been to convert the logic above to use the following API that was introduced in Java 1.7.

    File tmpDir = Files.createTempFile("temp dir").toFile();
    

    The API both creates the file securely, ie. with a random, non-conflicting name, with file permissions that only allow the currently executing user to read or write the contents of this file. By default, Files.createTempFile("temp dir") will create a file with the permissions -rw-------, which only allows the user that created the file to view/write the file contents.

    :arrow_right: Vulnerability Disclosure :arrow_left:

    :wave: Vulnerability disclosure is a super important part of the vulnerability handling process and should not be skipped! This may be completely new to you, and that's okay, I'm here to assist!

    First question, do we need to perform vulnerability disclosure? It depends!

    1. Is the vulnerable code only in tests or example code? No disclosure required!
    2. Is the vulnerable code in code shipped to your end users? Vulnerability disclosure is probably required!

    Vulnerability Disclosure How-To

    You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:

    1. Request a CVE number from GitHub by creating a repository-level GitHub Security Advisory. This has the advantage that, if you provide sufficient information, GitHub will automatically generate Dependabot alerts for your downstream consumers, resolving this vulnerability more quickly.
    2. Reach out to the team at Snyk to assist with CVE issuance. They can be reached at the Snyk's Disclosure Email.

    Detecting this and Future Vulnerabilities

    This vulnerability was automatically detected by GitHub's CodeQL using this CodeQL Query.

    You can automatically detect future vulnerabilities like this by enabling the free (for open-source) GitHub Action.

    I'm not an employee of GitHub, I'm simply an open-source security researcher.

    Source

    This contribution was automatically generated with an OpenRewrite refactoring recipe, which was lovingly hand crafted to bring this security fix to your repository.

    The source code that generated this PR can be found here: SecureTempFileCreation

    Opting-Out

    If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called .github/GH-ROBOTS.txt to your repository with the line:

    User-agent: JLLeitschuh/security-research
    Disallow: *
    

    This bot will respect the ROBOTS.txt format for future contributions.

    Alternatively, if this project is no longer actively maintained, consider archiving the repository.

    CLA Requirements

    This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

    It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

    The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).

    - Git Commit Signoff documentation

    If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

    Sponsorship & Support

    This contribution is sponsored by HUMAN Security Inc. and the new Dan Kaminsky Fellowship, a fellowship created to celebrate Dan's memory and legacy by funding open-source work that makes the world a better (and more secure) place.

    This PR was generated by Moderne, a free-for-open source SaaS offering that uses format-preserving AST transformations to fix bugs, standardize code style, apply best practices, migrate library versions, and fix common security vulnerabilities at scale.

    Tracking

    All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/security-research/issues/18

    enhancement help wanted 
    opened by JLLeitschuh 1
  • Using std::variant

    Using std::variant

    Could you please explain how create mapping for std::variant? As I see in changelog it's already supported, but I didn't find an examples of usages in tests or in javacpp-presets. I've added an example class

    class MyVariant {
    public:
        std::variant<
                bool,
                float,
                double> value;
    };
    

    And new class was created automatically, but std::variant was not converted:

    public static class MyVariant extends Pointer {
        static { Loader.load(); }
        /** Default native constructor. */
        public MyVariant() { super((Pointer)null); allocate(); }
        /** Native array allocator. Access with {@link Pointer#position(long)}. */
        public MyVariant(long size) { super((Pointer)null); allocateArray(size); }
        /** Pointer cast constructor. Invokes {@link Pointer#Pointer(Pointer)}. */
        public MyVariant(Pointer p) { super(p); }
        private native void allocate();
        private native void allocateArray(long size);
        @Override public MyVariant position(long position) {
            return (MyVariant)super.position(position);
        }
        @Override public MyVariant getPointer(long i) {
            return new MyVariant((Pointer)this).offsetAddress(i);
        }
    
        public native @ByRef std::variant<bool,float,double> value(); public native MyVariant value(std::variant<bool,float,double> setter);
    }
    
    bug help wanted 
    opened by ValentinaBaranova 3
  • Problem with enum with function as a value

    Problem with enum with function as a value

    I've got stuck with such cpp enum:

    enum MyErrorResponse_ErrorCode {
      MyErrorResponse_ErrorCode_kServerError = 0,
      MyErrorResponse_ErrorCode_kOk = 1,
      MyErrorResponse_ErrorCode_ErrorResponse_ErrorCode_INT_MIN_SENTINEL_DO_NOT_USE_ = std::numeric_limits<std::int16_t>::min()
    };
    

    It's parsed to

    public enum MyErrorResponse_ErrorCode {
      MyErrorResponse_ErrorCode_kServerError(0),
      MyErrorResponse_ErrorCode_kOk(1);
      MyErrorResponse_ErrorCode_ErrorResponse_ErrorCode_INT_MIN_SENTINEL_DO_NOT_USE_(MyErrorResponse_ErrorCode_ErrorResponse_ErrorCode_INT_MIN_SENTINEL_DO_NOT_USE_());
    
        public final int value;
        private MyErrorResponse_ErrorCode(int v) { this.value = v; }
        private MyErrorResponse_ErrorCode(MyErrorResponse_ErrorCode e) { this.value = e.value; }
        public MyErrorResponse_ErrorCode intern() { for (MyErrorResponse_ErrorCode e : values()) if (e.value == value) return e; return this; }
        @Override public String toString() { return intern().name(); }
    }
    

    The problem is with MyErrorResponse_ErrorCode_ErrorResponse_ErrorCode_INT_MIN_SENTINEL_DO_NOT_USE_. I've tried to replace std::numeric_limits<std::int16_t>::min() to specific value with javaText or just skip it, but failed. How it can be fixed?

    bug help wanted 
    opened by ValentinaBaranova 4
  • The same function pointer set more than 10 times will always pass in a NULL pointer to C/C++

    The same function pointer set more than 10 times will always pass in a NULL pointer to C/C++

    Hi @saudet ,

    As the subject mentioned, I suspect this is a bug. In C, the code is like:

    #include <iostream>
    #include "RpcImpl.h"
    
    using namespace std;
    namespace client {
        rpc_handler_t handler;
    
        void ClientSetMessageHandler(rpc_handler_t userHandler) {
            RPC_INFO("ClientSetMessageHandler userHandler:%p", userHandler);
            handler = userHandler;
        }
    }
    

    In Java/Kotlin we got:

    @RunWith(AndroidJUnit4::class)
    class TestShotSync {
    
        @Test
        fun testFunctionPointer() {
            for (i in 1..20) {
                val handler = ShotSync.rpc_handler_t()
                println("ClientSetMessageHandler No. $i $handler")
                ShotSync.ClientSetMessageHandler(handler)
            }
        }
    }
    

    And after we run the code, the output is like:

    2022-09-29 10:03:55.010 9271-9294 I/System.out: ClientSetMessageHandler No. 1 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe4433170,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe4433170,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.011 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0xced1ecdd
    2022-09-29 10:03:55.011 9271-9294 I/System.out: ClientSetMessageHandler No. 2 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe4433180,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe4433180,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.011 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0xced1f015
    2022-09-29 10:03:55.012 9271-9294 I/System.out: ClientSetMessageHandler No. 3 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe4433188,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe4433188,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.012 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0xced1f035
    2022-09-29 10:03:55.013 9271-9294 I/System.out: ClientSetMessageHandler No. 4 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe4433190,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe4433190,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.013 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0xced1f055
    2022-09-29 10:03:55.013 9271-9294 I/System.out: ClientSetMessageHandler No. 5 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe4433198,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe4433198,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.013 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0xced1f075
    2022-09-29 10:03:55.014 9271-9294 I/System.out: ClientSetMessageHandler No. 6 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe44331a0,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe44331a0,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.014 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0xced1f095
    2022-09-29 10:03:55.015 9271-9294 I/System.out: ClientSetMessageHandler No. 7 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe44331a8,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe44331a8,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.015 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0xced1f0b5
    2022-09-29 10:03:55.015 9271-9294 I/System.out: ClientSetMessageHandler No. 8 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe44331b0,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe44331b0,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.015 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0xced1f0d5
    2022-09-29 10:03:55.016 9271-9294 I/System.out: ClientSetMessageHandler No. 9 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe44331b8,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe44331b8,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.016 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0xced1f0f5
    2022-09-29 10:03:55.017 9271-9294 I/System.out: ClientSetMessageHandler No. 10 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe44331c0,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe44331c0,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.017 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0xced1f115
    2022-09-29 10:03:55.018 9271-9294 I/System.out: ClientSetMessageHandler No. 11 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe44331c8,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe44331c8,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.018 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0x0
    2022-09-29 10:03:55.018 9271-9294 I/System.out: ClientSetMessageHandler No. 12 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe44331d0,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe44331d0,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.018 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0x0
    2022-09-29 10:03:55.020 9271-9294 I/System.out: ClientSetMessageHandler No. 13 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe44331d8,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe44331d8,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.020 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0x0
    2022-09-29 10:03:55.020 9271-9294 I/System.out: ClientSetMessageHandler No. 14 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe44331e0,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe44331e0,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.020 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0x0
    2022-09-29 10:03:55.021 9271-9294 I/System.out: ClientSetMessageHandler No. 15 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe44331e8,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe44331e8,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.021 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0x0
    2022-09-29 10:03:55.022 9271-9294 I/System.out: ClientSetMessageHandler No. 16 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe44331f0,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe44331f0,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.022 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0x0
    2022-09-29 10:03:55.023 9271-9294 I/System.out: ClientSetMessageHandler No. 17 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe44331f8,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe44331f8,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.023 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0x0
    2022-09-29 10:03:55.024 9271-9294 I/System.out: ClientSetMessageHandler No. 18 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe4433200,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe4433200,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.024 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0x0
    2022-09-29 10:03:55.025 9271-9294 I/System.out: ClientSetMessageHandler No. 19 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe4433208,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe4433208,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.025 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0x0
    2022-09-29 10:03:55.026 9271-9294 I/System.out: ClientSetMessageHandler No. 20 com.senter.shotsync.ShotSync$rpc_handler_t[address=0xe4433210,position=0,limit=1,capacity=1,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0xe4433210,deallocatorAddress=0xced1f8d1]]
    2022-09-29 10:03:55.026 9271-9294 I/[STC-RPC]: ClientSetMessageHandler userHandler:0x0
    
    

    As we can see, after 10 times of setting the function pointer, we always got a NULL one in C.

    The patch to reproduce it is here.

    Is this because we have only 10 instances of the function pointer in JNI?

    enhancement help wanted question 
    opened by lancewoo 7
Releases(1.5.8)
  • 1.5.8(Nov 2, 2022)

    November 2, 2022 version 1.5.8

    • Add static long Pointer.getDirectBufferAddress(Buffer) method for convenience (pull #629)
    • Fix UniquePtrAdapter incorrectly deallocating pointers on callbacks (issue #613)
    • Fix Generator incorrectly casting @ByVal or @ByRef annotated FunctionPointer arguments (issue bytedeco/javacpp-presets#1244)
    • Fix Generator compiler errors for FunctionPointer with @UniquePtr arguments (issue #613)
    • Fix Generator compiler errors on Mac for Clang without Objective-C support (pull #610)
    • Prevent Parser from outputting cast methods for base classes that are Info.skip (pull #607)
    • Ensure Generator and Parser process header files from cinclude before include (issue #580)
    • Remove sun.misc.Unsafe config incompatible/unneeded with GraalVM Native Image 22.x (issue bytedeco/sample-projects#63)
    • Define default SHARED_PTR_NAMESPACE, UNIQUE_PTR_NAMESPACE, OPTIONAL_NAMESPACE to std on supported compilers (issue #577)
    • Let Generator treat long arguments and return values @ByVal or @ByRef with @Cast("...*") (issue #576)
    • Add BytePointer.getUnsigned() and putUnsigned() methods for convenience (pull #574)
    • Let Parser consider alignas as an explicit attribute to be ignored by default (issue bytedeco/javacpp-presets#1168)
    • Add "org.bytedeco.javacpp.findLibraries" system property to disable search for libraries (pull #565)
    • Fix Generator causing memory leaks for String parameters on callback (issue bytedeco/javacpp-presets#1141)
    • Add Loader.new/access/deleteGlobalRef() methods to store JNI Object references in Pointer (issue bytedeco/javacpp-presets#1141)
    • Make Loader.findLibrary() also search in "sun.boot.library.path" for jlink (pull #565)
    • Add __int8, __int16, __int32, and __int64 to InfoMap as "basic/types" to support combinations allowed by Visual Studio
    • Add "org.bytedeco.javacpp.cacheLibraries" system property to disable cache for libraries (pull bytedeco/gradle-javacpp#21)
    • Add public getters for the address fields of Pointer.NativeDeallocator (discussion bytedeco/javacpp-presets#1160)
    • Add support for std::function basic container instances with corresponding FunctionPointer (issue bytedeco/javacpp-presets#1051)
    • Fix Builder parsing of command line options for platform properties (issue #564)
    • Use thread local in Generator to detach automatically native threads on exit for Windows as well (pull #562)
    • Add compiler options for C++14 and C++17 to platform properties files for Visual Studio
    • Fix Parser incorrectly shortening type names for nested class template instances
    • Make Parser output boolean has_value() methods for basic containers like std::optional
    • Add OptionalAdapter and corresponding @Optional annotation for containers like std::optional
    • Switch to AttachCurrentThreadAsDaemon() when attaching native threads on callback (pull #561)
    • Add to InfoMap default pointer and value types for integer types in std:: namespace
    • Fix Android platform properties for NDK r23b
    Source code(tar.gz)
    Source code(zip)
    javacpp-platform-1.5.8-bin.zip(3.55 MB)
    javacpp-platform-1.5.8-src.zip(457.20 KB)
  • 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
Java Native Access

Java Native Access (JNA) The definitive JNA reference (including an overview and usage details) is in the JavaDoc. Please read the overview. Questions

Java Native Access 7.6k Jan 1, 2023
Compile Java byte-code to native CPU's.

Java Grinder Compile Java bytecode to microcontroller assembly. Currently supporting MSP430, dsPIC, 6502/6510, 68000, MIPS, TMS9900, and Z80 with plat

Michael Kohn 396 Dec 23, 2022
Jssembly is a library that allows you to execute native assembly from Java.

jssembly Jssembly is a library that allows you to execute native assembly from Java via a JNI bridge. The goal is to provide wrappers and parsers for

David Titarenco 121 Jun 3, 2022
Java Abstracted Foreign Function Layer

jnr-ffi jnr-ffi is a Java library for loading native libraries without writing JNI code by hand, or using tools such as SWIG. Example package hellowor

The Java Native Runtime Project 1.1k Dec 31, 2022
Java Bindings for V8

J2V8 J2V8 is a set of Java bindings for V8. J2V8 focuses on performance and tight integration with V8. It also takes a 'primitive first' approach, mea

EclipseSource 2.3k Jan 4, 2023
Low-overhead, non-blocking I/O, external Process implementation for Java

NuProcess NuProcess is proud to power Facebook's Buck build. A low-overhead, non-blocking I/O, external Process execution implementation for Java. It

Brett Wooldridge 644 Dec 29, 2022
The new bridge between Ghidra and Frida!

ghidra2frida ghidra2frida is a Ghidra Extension that, working as a bridge between Ghidra and Frida, lets you create powerful Ghidra scripts that take

null 92 Dec 5, 2022
KakaoSDK Bridge for React, React-Native, RNW

KakaoSDK for React, React-Native Use Dependencies iOS Android Web 2.5.0 2.5.0 1.39.14 처음 설치 시 주의 사항 (React-Native 만) 해당 모듈은 Swift로 되어있어서 그냥 가동 시 작동이 안

actbase 21 May 2, 2022
Resconstruct is a java library to infer missing information vectors of java classes.

Reconstruct Resconstruct is a java library to infer missing information vectors of java classes. Features Phantom classes Inheritance solving Dummy fi

Nowilltolife 14 Nov 17, 2022
Spring Native provides beta support for compiling Spring applications to native executables using GraalVM native-image compiler.

Spring Native provides beta support for compiling Spring applications to native executables using GraalVM native-image compiler.

Spring Projects Experimental 2.8k Jan 6, 2023
JCTools - Concurrency tools currently missing from the JDK.

JCTools Java Concurrency Tools for the JVM. This project aims to offer some concurrent data structures currently missing from the JDK: SPSC/MPSC/SPMC/

null 3.1k Dec 28, 2022
Dremio - the missing link in modern data

Dremio Dremio enables organizations to unlock the value of their data. Documentation Documentation is available at https://docs.dremio.com. Quickstart

Dremio 1.2k Dec 31, 2022
Stetho is a debug bridge for Android applications, enabling the powerful Chrome Developer Tools and much more.

Stetho Stetho is a sophisticated debug bridge for Android applications. When enabled, developers have access to the Chrome Developer Tools feature nat

Meta 12.6k Jan 3, 2023
Simple Design for Java bridge with Javascript. Also can get javascript console.log.

SDBridgeKotlin is here. If your h5 partner confused about how to deal with iOS and Android. This Demo maybe help. 最常见的问题. WebViewJavascriptBridge is n

null 25 Dec 18, 2022
Bridge Home Assistant with Minecraft

HomeAssistantMC is a Minecraft mod that integrates Home Assistant to Minecraft, allowing retrieval of entity states and calling of services. This allo

Muhd Hakim 25 Dec 24, 2022
Literally just adds milk, to act as a bridge for any other mods that want to do the same.

Milk lib Literally just adds milk, to act as a bridge for any other mods that want to do the same. See the Milk class for customisation; It allows for

null 5 Oct 17, 2022
Velocity global chat/discord bridge

VelocityDiscord Velocity global chat/discord bridge Default config generated on startup: # Don't change this config_version="1" [discord] # Bot token

Foo 8 Dec 18, 2022