jextract is a tool which mechanically generates Java bindings from a native library headers.

Related tags

JVM jextract
Overview

Jextract

jextract is a tool which mechanically generates Java bindings from a native library headers. This tools leverages the clang C API in order to parse the headers associated with a given native library, and the generated Java bindings build upon the Foreign Function & Memory API. The jextract tool was originally developed in the context of Project Panama (and then made available in the Project Panama Early Access binaries).

Getting started

jextract depends on the C libclang API. To build the jextract sources, the easiest option is to download LLVM binaries for your platform, which can be found here (a version >= 9 is required). Both the jextract tool and the bindings it generates depend heavily on the Foreign Function & Memory API, so a suitable jdk 18 distribution is also required.

jextract can be built using gradle, as follows (on Windows, gradlew.bat should be used instead):

$ sh ./gradlew -Pjdk18_home=<jdk18_home_dir> -Pllvm_home=<libclang_dir> clean verify
Using a local installation of LLVM

While the recommended way is to use a release from the LLVM project, extract it then make llvm_home point to this directory, it may be possible to use a local installation instead.

E.g. on macOs the llvm_home can also be set as one of these locations :

  • /Library/Developer/CommandLineTools/usr/ if using Command Line Tools
  • /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/ if using XCode
  • $(brew --prefix llvm) if using the LLVM install from Homebrew

After building, there should be a new jextract folder under build. To run the jextract tool, simply run the jextract command in the bin folder:

build/jextract/bin/jextract 
WARNING: Using incubator modules: jdk.incubator.foreign
Expected a header file

The repository also contains a comprehensive set of tests, written using the jtreg test framework, which can be run as follows (again, on Windows, gradlew.bat should be used instead):

$ sh ./gradlew -Pjdk18_home=<jdk18_home_dir> -Pllvm_home=<libclang_dir> -Pjtreg_home=<jtreg_home> jtreg

Note however that running jtreg task requires cmake to be available on the PATH.

Using jextract

To understand how jextract works, consider the following C header file:

//point.h
struct Point2d {
    double x;
    double y;
};

double distance(struct Point2d);

We can run jextract, as follows:

jextract --source -t org.jextract point.h

We can then use the generated code as follows:

import jdk.incubator.foreign.*;
import static org.jextract.point_h.*;
import org.jextract.Point2d;

class TestPoint {
    public static void main(String[] args) {
        try (ResourceScope scope = ResourceScope.newConfinedScope()) {
           MemorySegment point = MemorySegment.allocateNative(Point2d.$LAYOUT(), scope);
           Point2d.x$set(point, 3d);
           Point2d.y$set(point, 4d);
           distance(point);
        }
    }
}

As we can see, the jextract tool generated a Point2d class, modelling the C struct, and a point_h class which contains static native function wrappers, such as distance. If we look inside the generated code for distance we can find the following:

static final FunctionDescriptor distance$FUNC =
    FunctionDescriptor.of(Constants$root.C_DOUBLE$LAYOUT,
                          MemoryLayout.structLayout(
    	                      Constants$root.C_DOUBLE$LAYOUT.withName("x"),
                              Constants$root.C_DOUBLE$LAYOUT.withName("y")
                          ).withName("Point2d"));

static final MethodHandle distance$MH = RuntimeHelper.downcallHandle(
    "distance",
    constants$0.distance$FUNC, false
);

public static MethodHandle distance$MH() {
    return RuntimeHelper.requireNonNull(constants$0.distance$MH,"distance");
}
public static double distance ( MemorySegment x0) {
    var mh$ = RuntimeHelper.requireNonNull(constants$0.distance$MH, "distance");
    try {
        return (double)mh$.invokeExact(x0);
    } catch (Throwable ex$) {
        throw new AssertionError("should not reach here", ex$);
    }
}

In other words, the jextract tool has generated all the required supporting code (MemoryLayout, MethodHandle and FunctionDescriptor) that is needed to call the underlying distance native function. For more examples on how to use the jextract tool with real-world libraries, please refer to the samples folder (building/running particular sample may require specific third-party software installation).

Command line options

The jextract tool includes several customization options. Users can select in which package the generated code should be emitted, and what the name of the main extracted class should be. A complete list of all the supported options is given below:

Option Meaning
-D define a C preprocessor macro
--header-class-name specify the name of the main header class
-t, --target-package specify target package for the generated bindings
-I specify include files path for the clang parser
-l specify a library that will be loaded by the generated bindings
--output specify where to place generated files
--source generate java sources instead of classfiles
--dump-includes dump included symbols into specified file (see below)
--include-[function,macro,struct,union,typedef,var] Include a symbol of the given name and kind in the generated bindings (see below). When one of these options is specified, any symbol that is not matched by any specified filters is omitted from the generated bindings.

Additional clang options

Users can specify additional clang compiler options, by creating a file named compile_flags.txt in the current folder, as described here.

Filtering symbols

To allow for symbol filtering, jextract can generate a dump of all the symbols encountered in an header file; this dump can be manipulated, and then used as an argument file (using the @argfile syntax also available in other JDK tools) to e.g. generate bindings only for a subset of symbols seen by jextract. For instance, if we run jextract with as follows:

jextract --dump-includes=includes.txt point.h

We obtain the following file (includes.txt):

#### Extracted from: point.h

--include-struct Point2d    # header: point.h
--include-function distance # header: point.h

This file can be passed back to jextract, as follows:

jextract -t org.jextract --source @includes.txt point.h

It is easy to see how this mechanism allows developers to look into the set of symbols seen by jextract while parsing, and then process the generated include file, so as to prevent code generation for otherwise unused symbols.

Comments
  • 7903136: Don't require jdk18_home to be set in jextract gradle build

    7903136: Don't require jdk18_home to be set in jextract gradle build

    Drop the requirement to set jdk18_home in the gradle build, and rely instead on JAVA_HOME being set to JDK 18.

    I've also updated the build instructions. The -Pjtreg_home flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed libclang_dir -> llvm_dir which was missed in an earlier change.


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed

    Issue

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.java.net/jextract pull/9/head:pull/9
    $ git checkout pull/9

    Update a local copy of the PR:
    $ git checkout pull/9
    $ git pull https://git.openjdk.java.net/jextract pull/9/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 9

    View PR using the GUI difftool:
    $ git pr show -t 9

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.java.net/jextract/pull/9.diff

    ready rfr 
    opened by JornVernee 17
  • Update Readme with macOs specifics

    Update Readme with macOs specifics

    The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with app-image type, but the macOs .app layout different enough on macOs.


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed

    Reviewers

    • Jorn Vernee (@JornVernee - no project role) ⚠️ Review applies to baf128b7f0443225c000ed9c527ea9b71a461901
    • Maurizio Cimadamore (@mcimadamore - Committer)

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.java.net/jextract pull/10/head:pull/10
    $ git checkout pull/10

    Update a local copy of the PR:
    $ git checkout pull/10
    $ git pull https://git.openjdk.java.net/jextract pull/10/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 10

    View PR using the GUI difftool:
    $ git pr show -t 10

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.java.net/jextract/pull/10.diff

    integrated 
    opened by bric3 16
  • 7903202: Enable macOS in Github Action CI config

    7903202: Enable macOS in Github Action CI config

    This adjustment modifies the build config by introducing strategy matrix in order to enable builds from both Ubuntu and macOS.


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed (no review required)

    Issue

    Reviewers

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.java.net/jextract pull/45/head:pull/45
    $ git checkout pull/45

    Update a local copy of the PR:
    $ git checkout pull/45
    $ git pull https://git.openjdk.java.net/jextract pull/45/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 45

    View PR using the GUI difftool:
    $ git pr show -t 45

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.java.net/jextract/pull/45.diff

    integrated 
    opened by denismakogon 15
  • 7903139: avoid jpackage in build.gradle

    7903139: avoid jpackage in build.gradle

    Using jlink with launcher option instead of jpackage. This ensures uniform layout of app dir ($app/bin/jextract script) on all platforms. Also this avoids the use of third-party jpackage grade plugin.


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed

    Issue

    Reviewers

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.java.net/jextract pull/11/head:pull/11
    $ git checkout pull/11

    Update a local copy of the PR:
    $ git checkout pull/11
    $ git pull https://git.openjdk.java.net/jextract pull/11/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 11

    View PR using the GUI difftool:
    $ git pr show -t 11

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.java.net/jextract/pull/11.diff

    integrated 
    opened by sundararajana 14
  • 7903284: jextract should infer platform specific include path for Mac OS

    7903284: jextract should infer platform specific include path for Mac OS

    Using xcrun --show-sdk-path to find the SDK installation path


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed (no review required)

    Issue

    Reviewers

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.org/jextract pull/69/head:pull/69
    $ git checkout pull/69

    Update a local copy of the PR:
    $ git checkout pull/69
    $ git pull https://git.openjdk.org/jextract pull/69/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 69

    View PR using the GUI difftool:
    $ git pr show -t 69

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.org/jextract/pull/69.diff

    integrated 
    opened by sundararajana 13
  • 7903181: port jextract for foreign-preview changes

    7903181: port jextract for foreign-preview changes


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed (no reviews required)

    Issue

    Reviewers

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.java.net/jextract pull/35/head:pull/35
    $ git checkout pull/35

    Update a local copy of the PR:
    $ git checkout pull/35
    $ git pull https://git.openjdk.java.net/jextract pull/35/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 35

    View PR using the GUI difftool:
    $ git pr show -t 35

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.java.net/jextract/pull/35.diff

    integrated 
    opened by sundararajana 12
  • 7903271: Add sample of libzstd

    7903271: Add sample of libzstd

    This PR adds a sample using libzstd, a high-performance compression library.


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed (no review required)

    Issue

    Reviewers

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.org/jextract pull/66/head:pull/66
    $ git checkout pull/66

    Update a local copy of the PR:
    $ git checkout pull/66
    $ git pull https://git.openjdk.org/jextract pull/66/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 66

    View PR using the GUI difftool:
    $ git pr show -t 66

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.org/jextract/pull/66.diff

    integrated 
    opened by minborg 11
  • gradle buildscript improvements

    gradle buildscript improvements

    Some improvements based on suggestions I made in an email [1]. Since then, the buildscript has a evolved quite a bit so some of my suggestions became obsolete or easier. This PR generally implements suggestions 2 and 3 from my email.

    Use Gradle incremental builds and up to date checks:

    • The createJextractImage and createRuntimeImageForTest tasks now use Gradle task input and ouputs to enable up to date checks.
    • The cmake tasks could theoretically also have inputs and outputs added, however cmake has incremental builds already and these tasks are only run when running jtreg and take little time compared to the test suite.

    I made a few minor style changes and fixed the comment on the jtreg task.

    I would like feedback on one change, which is making the assemble task automatically run the jextractapp task to build a jextract binary. Do you think it is best if the assemble task automatically runs the verify task as well? Or should things just be left as they are and require running verify or jextractapp manually? For some brief insight into Gradle lifecycle tasks for those not familiar: The build task should build and test everything so it depends on assemble and check. The assemble task is responsible for building everything, it depends on jar in a default configuration. The check task is responsible for running tests. For more information see the Gradle docs [2].

    [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-March/016665.html [2] - https://docs.gradle.org/current/userguide/base_plugin.html#sec:base_tasks


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed (no reviews required)

    Reviewers

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.java.net/jextract pull/25/head:pull/25
    $ git checkout pull/25

    Update a local copy of the PR:
    $ git checkout pull/25
    $ git pull https://git.openjdk.java.net/jextract pull/25/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 25

    View PR using the GUI difftool:
    $ git pr show -t 25

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.java.net/jextract/pull/25.diff

    integrated 
    opened by danieljarabek 11
  • 7903132: Replace casts with type test pattern

    7903132: Replace casts with type test pattern

    Replaces a handful of casts following type tests with the equivalent pattern syntax.

    I cannot create a matching issue, as I do not have an account on the bug tracker.


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed

    Issue

    Reviewers

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.java.net/jextract pull/5/head:pull/5
    $ git checkout pull/5

    Update a local copy of the PR:
    $ git checkout pull/5
    $ git pull https://git.openjdk.java.net/jextract pull/5/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 5

    View PR using the GUI difftool:
    $ git pr show -t 5

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.java.net/jextract/pull/5.diff

    integrated 
    opened by bowbahdoe 11
  • 7903129: jextract does not handle @argfile

    7903129: jextract does not handle @argfile

    Missed CommandLine.parse call in JextractTool.run method.


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Commit message must refer to an issue
    • [x] Change must be properly reviewed

    Issue

    Reviewers

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.java.net/jextract pull/4/head:pull/4
    $ git checkout pull/4

    Update a local copy of the PR:
    $ git checkout pull/4
    $ git pull https://git.openjdk.java.net/jextract pull/4/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 4

    View PR using the GUI difftool:
    $ git pr show -t 4

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.java.net/jextract/pull/4.diff

    integrated 
    opened by sundararajana 11
  • Add section on pre-built binaries to README

    Add section on pre-built binaries to README

    I've added a short section on where to find the pre-built binaries. I think building jextract is less important than the information on usage if people can get binaries, so I've moved the section on building and testing to the bottom.


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed (no review required)

    Reviewers

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.org/jextract pull/84/head:pull/84
    $ git checkout pull/84

    Update a local copy of the PR:
    $ git checkout pull/84
    $ git pull https://git.openjdk.org/jextract pull/84/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 84

    View PR using the GUI difftool:
    $ git pr show -t 84

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.org/jextract/pull/84.diff

    integrated 
    opened by JornVernee 10
  • Add third-party sample list to README, populate with java-vulkan.

    Add third-party sample list to README, populate with java-vulkan.

    I made a more complex example (1000 lines, mostly because setting up a boilerplate Vulkan program is super lengthy) of using jextract on Vulkan and Win32 APIs.

    I think it may be too lengthy and too much of a maintenance burden to commit to the /samples directory, so I thought maybe including a section on third-party samples would be better.

    If this is not something you want to entertain that's totally understandable, but thought I would put it out there a bigger sample that interfaces with a pretty complex API may be helpful to others.


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed (no review required)

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.org/jextract pull/93/head:pull/93
    $ git checkout pull/93

    Update a local copy of the PR:
    $ git checkout pull/93
    $ git pull https://git.openjdk.org/jextract pull/93/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 93

    View PR using the GUI difftool:
    $ git pr show -t 93

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.org/jextract/pull/93.diff

    ready rfr 
    opened by brcolow 5
  • Release binaries to GH releases

    Release binaries to GH releases

    Hello and thanks for the amazing project!

    Now that Java 19 has been officially released, I believe that releasing binaries for this project would reduce the friction in its adoption. This was low-hanging fruit and you can check the outcome here: https://github.com/andreaTP/jextract/releases


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed (no review required)

    Error

     ⚠️ OCA signatory status must be verified

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.org/jextract pull/76/head:pull/76
    $ git checkout pull/76

    Update a local copy of the PR:
    $ git checkout pull/76
    $ git pull https://git.openjdk.org/jextract pull/76/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 76

    View PR using the GUI difftool:
    $ git pr show -t 76

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.org/jextract/pull/76.diff

    oca 
    opened by andreaTP 2
  • Add Dockerfile, zero-dep reproducible builds

    Add Dockerfile, zero-dep reproducible builds

    As title says, adds a Dockerfile that will fetch all necessary deps and build jextract for you on Ubuntu 22.10

    It would be nice if some official JDK organization could put this on their Dockerhub, so that users could just do:

    $ docker run --rm -it openjdk/jextract:latest
    

    I've pushed it to my personal Dockerhub, so if anyone would like to test it out, you can use the README directions but prepend gavinray/ before the image name:

    $ echo "struct Foo { int a; long b; }; int use_foo(struct Foo foo);" >> sample.h
    
    $ docker run --rm -it -v ${PWD}:/tmp/jextract \
        gavinray/jextract:latest \
        -I /tmp/jextract \
        --source \
        -l libfoo \
        --output /tmp/jextract/generated \
        --target-package com.example \
        /tmp/jextract/sample.h
    
    $ tree ./generated
    generated/
    └── com
        └── example
            ├── Constants$root.java
            ├── Foo.java
            ├── RuntimeHelper.java
            ├── constants$0.java
            └── sample_h.java
    

    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed (no review required)

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.org/jextract pull/74/head:pull/74
    $ git checkout pull/74

    Update a local copy of the PR:
    $ git checkout pull/74
    $ git pull https://git.openjdk.org/jextract pull/74/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 74

    View PR using the GUI difftool:
    $ git pr show -t 74

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.org/jextract/pull/74.diff

    ready rfr 
    opened by GavinRay97 11
  • Add path independence

    Add path independence

    This small PR incorporated feedback from the original PR: https://github.com/openjdk/jextract/pull/66 made after it was integrated.


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed (no review required)

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.org/jextract pull/68/head:pull/68
    $ git checkout pull/68

    Update a local copy of the PR:
    $ git checkout pull/68
    $ git pull https://git.openjdk.org/jextract pull/68/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 68

    View PR using the GUI difftool:
    $ git pr show -t 68

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.org/jextract/pull/68.diff

    ready rfr 
    opened by minborg 6
  • 7903239: ofAddress factory of function pointer type is wrong for struct returns

    7903239: ofAddress factory of function pointer type is wrong for struct returns

    When generating the lambda inside the ofAddress factory, it is missing the SegmentAllocator needed when the function returns a struct. This is implemented for regular functions, but not for function pointers.


    Progress

    • [x] Change must not contain extraneous whitespace
    • [x] Change must be properly reviewed (no review required)

    Issue

    • CODETOOLS-7903239: ofAddress factory of function pointer type is wrong for struct returns

    Reviewers

    • Maurizio Cimadamore (@mcimadamore - Committer) 🔄 Re-review required (review was made when pull request targeted the master branch)

    Reviewing

    Using git

    Checkout this PR locally:
    $ git fetch https://git.openjdk.org/jextract pull/58/head:pull/58
    $ git checkout pull/58

    Update a local copy of the PR:
    $ git checkout pull/58
    $ git pull https://git.openjdk.org/jextract pull/58/head

    Using Skara CLI tools

    Checkout this PR locally:
    $ git pr checkout 58

    View PR using the GUI difftool:
    $ git pr show -t 58

    Using diff file

    Download this PR as a diff file:
    https://git.openjdk.org/jextract/pull/58.diff

    ready rfr sponsor 
    opened by lost-illusi0n 13
Owner
OpenJDK
OpenJDK
A Java Virtual Machine - running on a Java Virtual Machine - running on a (jk).

Javaception A Java Virtual Machine - running on a Java Virtual Machine - running on a (jk). Goals JVMS compliant Java Virtual Machine Somewhat fast Re

null 33 Oct 10, 2022
Eclipse Foundation 3k Dec 31, 2022
Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput.

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.

null 3k Jan 3, 2023
ReleaseFab is a Java client application which automatically generates Release Notes for any project.

ReleaseFab is a Java client application which atomatically generates Release Notes for any project. The information can be gathered from multiple different sources including the source code itself, the Git repository and an Application Lifecycle Management System of your choice.

comlet Verteilte Systeme GmbH 7 Jun 10, 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
SynchronizeFX - a library for JavaFX 2 and later that enables property bindings between different JVMs

SynchronizeFX - a library for JavaFX 2 and later that enables property bindings between different JVMs, both on a local computer and over the network.

Manuel Mauky 8 Jul 24, 2020
Restler is a library that automatically generates a client for a web service at run time, by analyzing the respective annotated Spring controller interface

Restler Overview Restler is a library that automatically generates a client for a web service at run time, by analyzing the respective annotated Sprin

Excelsior LLC 29 Oct 24, 2022
A library that automatically generates and manages configuration files based on classes.

sc-cfg SC-CFG is a simple, yet powerful library that automatically generate configuration files based on your classes. Compatible with Java 8+ and Kot

null 10 Nov 28, 2022
Jaeger Bindings for Java OpenTracing API

Jaeger's Tracing Instrumentation Library for Java Intended to be used with Jaeger backend, but can also be configured to send traces to Zipkin. Implem

Jaeger - Distributed Tracing Platform 485 Dec 5, 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
Java/JNI bindings to libpostal for for fast international street address parsing/normalization

jpostal These are the Java/JNI bindings to libpostal, a fast, multilingual NLP library (written in C) for parsing/normalizing physical addresses aroun

openvenues 94 Oct 15, 2022
Java Foreign Linker bindings to Lua

jpanlua Java bindings to liblua using JEP 398: Foreign Linker API. Requires JDK 16 or above. Requires -Dforeign.restricted=permit JRE flag. Exports pa

Aly Cerruti 5 Dec 24, 2021
React native wrapper for Jitsi Meet SDK Library that rely on the native view (Activity / ViewController)

react-native-jitsi-meet-sdk React native wrapper for Jitsi Meet SDK Library. This Library implements the Jitsi SDK with a native activity on the Andro

null 7 May 2, 2022
With react-native-update-in-app library you can easily implement in-app updates in your React Native app using CDN or any other file server

React Native In-App update With react-native-update-in-app library you can easily implement in-app updates in your React Native app using CDN or any o

Nepein Andrey 7 Dec 21, 2022
Generates a Proguard mapping file for use in obfuscating your Java projects.

Reaper Generates a Proguard mapping file for use in obfuscating your Java projects. Features Automatically checks for duplicate names. Interactive, in

Nox 12 Dec 29, 2022
Auto-Unit-Test-Case-Generator automatically generates high-level code-coverage JUnit test suites for Java, widely used within the ANT Group.

中文README传送门 What is Auto-Unit-Test-Case-Generator Auto-Unit-Test-Case-Generator generates JUnit test suites for Java class just as its name. During te

TRaaS 108 Dec 22, 2022
RxJava bindings for JavaFX

RxJavaFX: JavaFX bindings for RxJava Read the free eBook Learning RxJava with JavaFX to get started. RxJavaFX is a lightweight library to convert Java

ReactiveX 513 Dec 27, 2022
Custom JavaFX bindings made easy with lambdas.

EasyBind EasyBind leverages lambdas to reduce boilerplate when creating custom bindings, provides a type-safe alternative to Bindings.select* methods

Tomas Mikula 146 May 29, 2022
Clojure bindings for the Chromium Embedded Framework

clj-cef Clojure bindings for the Chromium Embedded Framework Dependency: Rationale From https://bitbucket.org/chromiumembedded/cef/src/master/ Some us

Adrian 45 Nov 2, 2022
🍏 A collection of partial JNA bindings for various macOS frameworks. (e.g. Foundation, AppKit, etc.)

JNApple ?? A collection of partial JNA bindings for various macOS frameworks. (e.g. Foundation, AppKit, etc.) Usage These are just some common example

Iridescent 3 Jun 19, 2022