A JNI code generator based on the JNI generator used by the eclipse SWT project

Related tags

Native hawtjni
Overview

HawtJNI

Description

HawtJNI is a code generator that produces the JNI code needed to implement java native methods. It is based on the jnigen code generator that is part of the SWT Tools project which is used to generate all the JNI code which powers the eclipse platform.

Maven Central

Features

  • jni code generated from annotations on your java code
  • maven integration

Synopsis

There are many open source JNI code generators available, but if you're performance sensitive, the code generator used by the eclipse SWT project is by far the best option. The biggest problem is that it was not developed to be reused by other projects. It was tightly coupled to producing the SWT jni libraries and it could only be run within the eclipse platform.

HawtJNI takes that code generator and makes it more generally accessible to any project.

Example Usage

Your JNI methods must be defined as static native methods in a class annotated with @JniClass. The following example will expose the C open function as a java method:

@JniClass
public class Platform {
    public static native long open (String file, int flags, int mode);
}

You will also need to tell the JVM to load the native library when your class is loaded. You can do this using the standard System.loadLibrary method:

@JniClass
public class Platform {
    static {
        System.loadLibrary("hawtjni-example");
    }
    public static native long open (String file, int flags, int mode);
}

If you want to bundle the native library in as a resource of your jar, so that it can be automatically unpacked if it cannot be be found in your java library path. Then a better option is to use the Library helper class that HawtJNI provides:

@JniClass
public class Platform {
    private static Library library = new Library("hawtjni-example", 1, 0, 0);
  	static {
  	    library.load();
  	}
    public static native long open (String file, int flags, int mode);
}

To generate the JNI code, first compile your annotated class, then use the hawtjni-generate.jar runnable jar as follows:

java -jar hawtjni-generate.jar -o target/native target/classes

The above example expects your compiled java classes to be in the target/classes directory. The generated JNI classes will be placed in the target/native directory.

More Docs:

http://fusesource.github.io/hawtjni/documentation/developer-guide.html

Comments
  • shared_ptr support is not present

    shared_ptr support is not present

    shared_ptr support is missing in hawt jni so we made changes . verified it with librocksdbjni and raised the pull request

    https://github.com/fusesource/hawtjni/pull/50

    opened by ossdev07 6
  • Depends on field order reported through reflection

    Depends on field order reported through reflection

    The StructsGenerator class in hawtjni-generator artifact assumes that the field order reported through reflection is the source code order. But the Java API explicitly states that "The elements in the array returned are not sorted and are not in any particular order." [1]

    The fix is to write an annotation processor (which, when running on source code, receives the fields in source code order), or inspect the class file, require debugging information, and sort the fields by line number.

    Component: hawtjni-generator Versions: latest (1.7-SNAPSHOT) Originally reported by Florian Weimer [2]

    See also: [1] http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getDeclaredFields%28%29 [2] https://bugzilla.redhat.com/show_bug.cgi?id=957131

    opened by mizdebsk 5
  • Improve FreeBSD support

    Improve FreeBSD support

    • Detect JAVA_HOME automatically as advised by man javavm if not set
    • Avoid a compile-time error on FreeBSD 10.3-RELEASE along with clang if the OS-specific include directory is not passed to the preprocessor, BSD/OS is dead for 15 years+ and does not correspond to modern BSDs like FreeBSD or OpenBSD. See config.sub.

    Both compiles now perfectly on FreeBSD 9 and 10 in 32 bit and 64 bit, Java 7 and Java 8.

    Error with clang (FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512, Target: x86_64-unknown-freebsd10.3, Thread model: posix):

    configure:11640: JAVA_HOME was set, checking to see if it's a JDK we can use...
    configure:11645: checking if '/usr/local/openjdk8' is a JDK
    configure:11706: cc -c -g -O2  -I/usr/local/openjdk8/include conftest.c >&5
    In file included from conftest.c:21:
    /usr/local/openjdk8/include/jni.h:45:10: fatal error: 'jni_md.h' file not found
    #include "jni_md.h"
             ^
    1 error generated.
    configure:11706: $? = 1
    

    Working library:

    $ file ./target/native-build/target/lib/libjansi-1.7-SNAPSHOT.so
    ./target/native-build/target/lib/libjansi-1.7-SNAPSHOT.so: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, not stripped
    
    opened by michael-o 4
  • Extended search

    Extended search

    Extended search in library.$name.path to do the same as in META-INF/native: this will enable scenario where a distribution extracts native libraries to avoid temp file creation if the lib auto-extracts on each run see https://issues.apache.org/jira/browse/MNG-6186 for a use case in Maven

    opened by hboutemy 3
  • Updated to work with JDK11

    Updated to work with JDK11

    Java 11 is the current LTS version of Java. I've upgraded all the Maven dependencies and a few simple code modifications to make this happen. Please consider upgrading to the current Java LTS version.

    opened by sgjava 2
  • hawtjni-maven-plugin throws exception when processing classes compiled with -parameters

    hawtjni-maven-plugin throws exception when processing classes compiled with -parameters

    Classes compiled with -parameters of

                <plugin>
                  <groupId>org.apache.maven.plugins</groupId>
                  <artifactId>maven-compiler-plugin</artifactId>
                  <configuration>
                    ...
                    <parameters>true</parameters>
                    ...
                  </configuration>
                </plugin>
    

    cause hawtjni-maven-plugin:generate to throw an Exception

    [INFO] --- hawtjni-maven-plugin:1.17:generate (default) @ ball-util ---
    [INFO] Analyzing classes...
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD FAILURE
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time:  6.855 s
    [INFO] Finished at: 2019-09-23T16:24:21-07:00
    [INFO] ------------------------------------------------------------------------
    [ERROR] Failed to execute goal org.fusesource.hawtjni:hawtjni-maven-plugin:1.17:generate (default) on project ball-util: Native source code generation failed: java.lang.RuntimeException: java.lang.RuntimeException -> [Help 1]
    org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.fusesource.hawtjni:hawtjni-maven-plugin:1.17:generate (default) on project ball-util: Native source code generation failed: java.lang.RuntimeException: java.lang.RuntimeException
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
        ...
    Caused by: org.apache.maven.plugin.MojoExecutionException: Native source code generation failed: java.lang.RuntimeException: java.lang.RuntimeException
        at org.fusesource.hawtjni.maven.GenerateMojo.generateNativeSourceFiles (GenerateMojo.java:234)
        ...
    Caused by: java.lang.RuntimeException: java.lang.RuntimeException
        at org.fusesource.hawtjni.generator.HawtJNI.findClasses (HawtJNI.java:299)
        at org.fusesource.hawtjni.generator.HawtJNI.generate (HawtJNI.java:211)
        at org.fusesource.hawtjni.maven.GenerateMojo.generateNativeSourceFiles (GenerateMojo.java:232)
        at org.fusesource.hawtjni.maven.GenerateMojo.execute (GenerateMojo.java:199)
        ...
    Caused by: java.lang.RuntimeException
        at org.objectweb.asm.MethodVisitor.visitParameter (Unknown Source)
        at org.objectweb.asm.ClassReader.b (Unknown Source)
        at org.objectweb.asm.ClassReader.accept (Unknown Source)
        at org.objectweb.asm.ClassReader.accept (Unknown Source)
        at org.apache.xbean.finder.AbstractFinder.readClassDef (AbstractFinder.java:581)
        at org.apache.xbean.finder.AbstractFinder.readClassDef (AbstractFinder.java:576)
        at org.apache.xbean.finder.AbstractFinder.readClassDef (AbstractFinder.java:562)
        at org.apache.xbean.finder.ClassFinder.<init> (ClassFinder.java:122)
        at org.fusesource.hawtjni.generator.HawtJNI.findClasses (HawtJNI.java:296)
        at org.fusesource.hawtjni.generator.HawtJNI.generate (HawtJNI.java:211)
        at org.fusesource.hawtjni.maven.GenerateMojo.generateNativeSourceFiles (GenerateMojo.java:232)
        at org.fusesource.hawtjni.maven.GenerateMojo.execute (GenerateMojo.java:199)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
        at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
        at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
        at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
        at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
        at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
        at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
        at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
        at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke (Method.java:498)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
    [ERROR] 
    [ERROR] Re-run Maven using the -X switch to enable full debug logging.
    [ERROR] 
    [ERROR] For more information about the errors and possible solutions, please read the following articles:
    [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
    
    Compilation exited abnormally with code 1 at Mon Sep 23 16:24:21
    

    <parameters>false</parameters> compiles without issue.

    opened by allen-ball 2
  • hawtjni standard-template files broken on arm64 (though has warnings on others) in latest Android NDK (10)

    hawtjni standard-template files broken on arm64 (though has warnings on others) in latest Android NDK (10)

    Somehow the callback tables are being considered as having values not known at compile time on arm64. Only pasting a few because the pattern is the same and results in a ton of error output...

    .../jni/hawtjni-callback.c:352:3: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
       (jintLong)FN(0, args), \
       ^
    .../jni/hawtjni-callback.c:486:3: note: in expansion of macro 'FN_A_BLOCK'
       FN_A_BLOCK(0)    
       ^
    .../jni/hawtjni-callback.c:486:3: error: initializer element is not constant
    .../jni/hawtjni-callback.c:486:3: error: (near initialization for 'fnx_array[0][0]')
    .../jni/hawtjni-callback.c:353:3: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
       (jintLong)FN(1, args), \
    

    If I inject (long) in between "(jintLong)" and "FN" in FN_A_BLOCK(args) I get rid of the cast from pointer to integer of different size... but that is a somewhat disturbing result. With that I still get the 'initializer element is not constant' error...

    I'm not quite sure what is going on with that platform... I suspect jintLong is 32-bits which is causing the pointer-to-int-cast issue when attempting to store function pointers in 32-bit form... very frightening because I think that the most common use of jintLong is to store pointers that need to get passed 'safely' into Java land.

    A fix that removes the errors is to modify the FN_A_BLOCK segment to remove the (jintLong) cast of the function pointer and to change the actual array itself to be 'void*' instead of jintLong typed (really, function pointers should be stored as raw pointers, I would think... and at barrier points (and as I see, in the jni-call function I see return (jintLong) fnx_array[argCount][i] ... which raises warnings at build time.

    The (void **) casts of the env variable is causing issues in hawtjni.c and hawtjni-callback.c because the compiler is being more type-strict.

    .../jni/hawtjni.c: In function 'hawtjni_attach_thread':
    .../jni/hawtjni.c:54:12: warning: passing argument 2 of '(*JVM)->AttachCurrentThread' from incompatible pointer type
         return (*JVM)->AttachCurrentThread(JVM, (void**)env, &args);
                ^
    .../jni/hawtjni.c:54:12: note: expected 'const struct JNINativeInterface ***' but argument is of type 'void **'
    .../jni/hawtjni-callback.c: In function 'callback':
    .../jni/hawtjni-callback.c:710:7: warning: passing argument 2 of '(*jvm)->AttachCurrentThreadAsDaemon' from incompatible pointer type
           (*jvm)->AttachCurrentThreadAsDaemon(jvm, (void **)&env, NULL);
           ^
    .../jni/hawtjni-callback.c:710:7: note: expected 'const struct JNINativeInterface ***' but argument is of type 'void **'
    .../jni/hawtjni-callback.c:716:5: warning: passing argument 2 of '(*jvm)->AttachCurrentThread' from incompatible pointer type
         (*jvm)->AttachCurrentThread(jvm, (void **)&env, NULL);
         ^
    .../jni/hawtjni-callback.c:716:5: note: expected 'const struct JNINativeInterface ***' but argument is of type 'void **'
    

    Fix for those - drop the void** cast.

    Sorry for the long-winded ticket, attempting to get lmdbjni building fully for Android w/ all platforms to test out some optimized handling and running into trouble.

    opened by harningt 2
  • Addressing issue for jline/jansi where same name for dll is used regardless of bit model

    Addressing issue for jline/jansi where same name for dll is used regardless of bit model

    Adding bit model to the name of the extracted library to support hosts running both 32 and 64 bits JVM. See Issue #2.

    (this is related to https://issues.scala-lang.org/browse/SI-4703)

    opened by huynhjl 2
  • Fix file extraction of

    Fix file extraction of "one platform" libraries

    Search directories for library:

    • ${platform}/${arch} to enable platform JNI library for different processor archs
    • ${platform} to enable platform JNI library
    • ${os} to enable OS JNI library
    • no directory (".")

    In the last case, the following fails to locate the file inside the JAR (in some JVMs?): URL resource = ClassLoader.getResource("META-INF/native/./lib<name>.so");

    When the classpath is not a JAR it works as expected.

    $ java --version
    openjdk 11.0.10 2021-01-19
    OpenJDK Runtime Environment (build 11.0.10+9-Ubuntu-0ubuntu1.18.04)
    OpenJDK 64-Bit Server VM (build 11.0.10+9-Ubuntu-0ubuntu1.18.04, mixed mode, sharing)
    
    opened by eliaskoromilas 1
  • How to get 'long' point of object o call c++ class/object binding

    How to get 'long' point of object o call c++ class/object binding

    This may be stupid but I am so confused how to call a native method with 'long' pointer to the object under neath.

    For example, the c++ binding code could be

    ABC.java
    public class ABC {
        @JniMethod(flags={MethodFlag.CPP_METHOD)
        public static final native void Read(long self, @JniArg(cast="uint8_t*") byte[] buffer, int length);
    ...
    }
    

    in another caller .java file the c++ binding is called by

    ABC abc = new ABC();
    abc.Read(buffer, length);
    

    And the compile will report error on missing argument 'long' self. Is there a common way to get the 'long' pointer to a specific object(make a method return this)?

    opened by chaorunrun 1
  • Build fails

    Build fails

    [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadocs) on project hawtjni-runtime: MavenReportException: Error while generating Javadoc: [ERROR] Exit code: 1 - javadoc: error - The code being documented uses modules but the packages defined in http://docs.oracle.com/javase/8/docs/api/ are in the unnamed module. [ERROR] /home/servadmin/eclipse-workspace/hawtjni/hawtjni-runtime/src/main/java/org/fusesource/hawtjni/runtime/Library.java:32: warning: empty <code> tag [ERROR] * <li> "<code></code>"

    Using Java 11 and Maven 3.6.3.

    opened by sgjava 1
  • How to access extern const struct

    How to access extern const struct

    I want to access the following global struct:

    extern const struct MDBX_build_info { ... }

    what is the syntax to access it, via JniField with flag constant, or ?

    Thanks

    opened by castortech 0
  • Dependency org.apache.commons:commons-compress, leading to CVE problem

    Dependency org.apache.commons:commons-compress, leading to CVE problem

    Hi, In hawtjni/hawtjni-maven-plugin,there is a dependency org.apache.commons:commons-compress:1.20 that calls the risk method.

    CVE-2018-11771

    The scope of this CVE affected version is [,1.18-RC1)

    After further analysis, in this project, the main Api called is <org.apache.commons.compress.archivers.zip.ZipArchiveInputStream: int readStored(byte[],int,int)>

    Risk method repair link : GitHub

    CVE Bug Invocation Path--

    Path Length : 7

    <org.apache.commons.compress.archivers.zip.ZipArchiveInputStream: int readStored(byte[],int,int)>
    at <org.apache.commons.compress.archivers.zip.ZipArchiveInputStream: int read(byte[],int,int)> (org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.java:[486]) in /.m2/repository/org/apache/commons/commons-compress/1.20/commons-compress-1.20.jar
    at <org.codehaus.plexus.archiver.util.Streams: void copyFullyDontCloseOutput(java.io.InputStream,java.io.OutputStream,java.lang.String)> (org.codehaus.plexus.archiver.util.Streams.java:[139]) in /.m2/repository/org/codehaus/plexus/plexus-archiver/4.2.2/plexus-archiver-4.2.2.jar
    at <org.codehaus.plexus.archiver.tar.TarArchiver: void tarFile(org.codehaus.plexus.archiver.ArchiveEntry,org.apache.commons.compress.archivers.tar.TarArchiveOutputStream,java.lang.String)> (org.codehaus.plexus.archiver.tar.TarArchiver.java:[339]) in /.m2/repository/org/codehaus/plexus/plexus-archiver/4.2.2/plexus-archiver-4.2.2.jar
    at <org.codehaus.plexus.archiver.tar.TarArchiver: void execute()> (org.codehaus.plexus.archiver.tar.TarArchiver.java:[169]) in /.m2/repository/org/codehaus/plexus/plexus-archiver/4.2.2/plexus-archiver-4.2.2.jar
    at <org.codehaus.plexus.archiver.AbstractArchiver: void createArchive()> (org.codehaus.plexus.archiver.AbstractArchiver.java:[1042]) in /.m2/repository/org/codehaus/plexus/plexus-archiver/4.2.2/plexus-archiver-4.2.2.jar
    at <org.fusesource.hawtjni.maven.PackageJarMojo: void execute()> (org.fusesource.hawtjni.maven.PackageJarMojo.java:[135]) in /detect/unzip/hawtjni-master/hawtjni-maven-plugin/target/classes
    
    
    

    Dependency tree--

    [INFO] org.fusesource.hawtjni:hawtjni-maven-plugin:maven-plugin:1.19-SNAPSHOT
    [INFO] +- org.fusesource.hawtjni:hawtjni-generator:jar:1.19-SNAPSHOT:compile
    [INFO] +- org.apache.maven:maven-plugin-api:jar:3.6.3:compile
    [INFO] |  +- org.apache.maven:maven-model:jar:3.6.3:compile
    [INFO] |  +- org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.3.4:compile
    [INFO] |  |  +- javax.enterprise:cdi-api:jar:1.0:compile
    [INFO] |  |  |  +- javax.annotation:jsr250-api:jar:1.0:compile
    [INFO] |  |  |  \- javax.inject:javax.inject:jar:1:compile
    [INFO] |  |  +- org.eclipse.sisu:org.eclipse.sisu.inject:jar:0.3.4:compile
    [INFO] |  |  \- org.codehaus.plexus:plexus-component-annotations:jar:1.5.5:compile
    [INFO] |  \- org.codehaus.plexus:plexus-classworlds:jar:2.6.0:compile
    [INFO] +- org.apache.maven:maven-project:jar:2.0.11:compile
    [INFO] |  +- org.apache.maven:maven-settings:jar:2.0.11:compile
    [INFO] |  +- org.apache.maven:maven-profile:jar:2.0.11:compile
    [INFO] |  +- org.apache.maven:maven-plugin-registry:jar:2.0.11:compile
    [INFO] |  \- org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile
    [INFO] |     +- junit:junit:jar:3.8.1:compile
    [INFO] |     \- classworlds:classworlds:jar:1.1-alpha-2:compile
    [INFO] +- org.codehaus.plexus:plexus-utils:jar:3.3.0:compile
    [INFO] +- org.codehaus.plexus:plexus-interpolation:jar:1.26:compile
    [INFO] +- org.apache.maven:maven-artifact-manager:jar:2.0.11:compile
    [INFO] |  +- org.apache.maven:maven-repository-metadata:jar:2.0.11:compile
    [INFO] |  \- org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-2:compile
    [INFO] +- org.apache.maven:maven-artifact:jar:2.0.11:compile
    [INFO] +- org.apache.maven:maven-archiver:jar:2.4:compile
    [INFO] +- org.codehaus.plexus:plexus-archiver:jar:4.2.2:compile
    [INFO] |  +- org.apache.commons:commons-compress:jar:1.20:compile
    [INFO] |  +- org.iq80.snappy:snappy:jar:0.4:compile
    [INFO] |  \- org.tukaani:xz:jar:1.8:runtime
    [INFO] +- org.codehaus.plexus:plexus-io:jar:3.2.0:compile
    [INFO] |  \- commons-io:commons-io:jar:2.6:compile
    [INFO] \- org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.6.0:provided
    

    Suggested solutions:

    Update dependency version

    Thank you very much.

    opened by CVEDetect 2
  • Support newer Visual Studio build tools

    Support newer Visual Studio build tools

    VS2010 is rather old now, and e.g. VS2017 cannot build hawtjni's projects

    C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Platform.targets(65,5): error MSB8020: The build tools for Visual Studio 2010 (Platform Toolset = 'v100') cannot be found. To build using the v100 build tools, please install Visual Studio 2010 build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution".

    Being able to generate newer projects would be very helpful. I can't even find a way to get the 2010 (or 2008) build tools any more. https://visualstudio.microsoft.com/vs/older-downloads/ only goes back to 2012.

    opened by OrangeDog 3
  • Guide for android project

    Guide for android project

    Is there any guide or example to apply this library on an android project based on gradle build system? The maven-plugin seems not compatible with it.

    Plugin with id 'hawtjni-maven-plugin' not found.
    
    opened by kyze8439690 0
The New Official Aparapi: a framework for executing native Java and Scala code on the GPU.

A framework for executing native Java code on the GPU. Licensed under the Apache Software License v2 Aparapi allows developers to write native Java co

Syncleus 425 Dec 29, 2022
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
Eclipse Foundation 3k Dec 31, 2022
GS Collections has been migrated to the Eclipse Foundation, re-branded as Eclipse Collections. https://www.eclipse.org/collections/

GS Collections is now Eclipse Collections We are pleased to announce that GS Collections has been migrated to the Eclipse Foundation, re-branded as Ec

null 1.8k Dec 30, 2022
GS Collections has been migrated to the Eclipse Foundation, re-branded as Eclipse Collections. https://www.eclipse.org/collections/

GS Collections is now Eclipse Collections We are pleased to announce that GS Collections has been migrated to the Eclipse Foundation, re-branded as Ec

null 1.8k Dec 30, 2022
QuickShell is an Eclipse plugin to use Java JShell inside the Eclipse IDE.

QuickShell is an Eclipse plugin to use Java JShell (REPL) inside Eclipse IDE. JDK 9+ is not installed on your system? No worries, you can still use Qu

Nilesh Khaire 8 Oct 3, 2022
A hotel management system desktop application, built with java SWT/Swing

A hotel management system desktop application, built with java SWT/Swing, with tabs to manage bookings, rooms, customers, payments, cancellations, hotel inventory orders, catering and a plan to visualize all the reservations for the month.

null 1 Jan 12, 2022
The respository of a student group called 'Bombenstimmung' at the University of Wuppertal during the SWT-Praktikum 2021/22

Bomberfrau The respository of a student group called 'Bombenstimmung' at the University of Wuppertal during the SWT-Praktikum 2021/22 Installation: Vo

BEJOSCHR 7 Jan 10, 2022
Twitter Text Libraries. This code is used at Twitter to tokenize and parse text to meet the expectations for what can be used on the platform.

twitter-text This repository is a collection of libraries and conformance tests to standardize parsing of Tweet text. It synchronizes development, tes

Twitter 2.9k Jan 8, 2023
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
Facsimile - Copy Your Most Used Text to Clipboard Easily with Facsimile!. It Helps You to Store You Most Used Text as a Key, Value Pair and Copy it to Clipboard with a Shortcut.

Facsimile An exact copy of Your Information ! Report Bug · Request Feature Table of Contents About The Project Built With Getting Started Installation

Sri lakshmi kanthan P 1 Sep 12, 2022
cglib - Byte Code Generation Library is high level API to generate and transform Java byte code. It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access.

cglib Byte Code Generation Library is high level API to generate and transform JAVA byte code. It is used by AOP, testing, data access frameworks to g

Code Generation Library 4.5k Jan 8, 2023
Win32 and DirectX mappings for java using Project Panama. Ignore the C# tag, it's just reference code used for decompilation

JWin32 A Project Panama-based mapping + wrapper generator for win32 headers. IMPORTANT As of 0.5.0, no prebuilt jars will be provided. You must genera

FalsePattern 9 Nov 27, 2022
Zero is a core test automation project that can be used as a basis for any kind of test automation project (API, Browser, Mobile)

Zero Zero is our feature rich, core test automation framework, that can be used as an underlying automation framework for any/and all kind of test aut

Pramod Kumar Yadav 10 Dec 16, 2022
SBSRE is an eclipse plugin for extract method refactoring based on the single responsibility principle(SRP)

SBSRE is a slice-based single responsibility extraction approach supported by an eclipse plugin for identifying Single responsibility violations in the methods.

null 4 Jul 8, 2022
Eclipse Yasson project

Eclipse Yasson Yasson is a Java framework which provides a standard binding layer between Java classes and JSON documents. This is similar to what JAX

Eclipse EE4J 183 Aug 31, 2022
Team 5468's 2022 FRC robot code. This code is written in Java and is based off of WPILib's Java control system and utilizes a command based system

FRC 2022 Team 5468's 2022 FRC robot code. This code is written in Java and is based off of WPILib's Java control system and utilizes a command based s

null 4 Oct 4, 2022
An assistance platform made using Spring framework that analyses your code, and helps you either to start a devops project, or to turn an existing project into a devops project using open source software (Git, Docker, Jenkins..)

DevOpsify Description An assistance platform made using Spring framework that analyses your code, and helps you either to start a devops project, or t

obaydah bouifadene 14 Nov 8, 2022
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