Free jni software for linux

PBJ::JNI is a Perl module with full access to and from Java virtual machine from Perl.

SYNOPSIS

use PBJ::JNI::JavaVM;

my ($env, $jvm, @vm_opts);
my ($cls, $fid, $mid, $out);

# Create the Java VM
@vm_opts = ("-Xrs", "-Xcheck:jni");
$jvm = new PBJ::JNI::JavaVM();
$env = $jvm->get_env(@vm_opts);

$env->PushLocalFrame(16) == 0 or die;
$cls = $env->FindClass("java/lang/System") or die;
$fid = $env->GetStaticFieldID($cls, "out", "Ljava/io/PrintStream;") or die;
$out = $env->GetStaticObjectField($cls, $fid) or die;
$cls = $env->GetObjectClass($out) or die;
$mid = $env->GetMethodID($cls, "println", "(I)V") or die;
$env->CallVoidMethod($out, $mid, $env->cast("I", 12345));
$env->PopLocalFrame(0);

WARNING

This software is still in alpha stage. It may not be reliable and its features and APIs may change in the future releases.

The PBJ::JNI package allows you to link with your Java virtual machine and directly access Java classes from Perl. It also allows a mechanism to create callbacks from Java program to Perl subroutines.

The package focuses on providing a set of APIs that closely resemble the native JNI interface. This basically means that you can write an ordinary JNI program in Perl instead of in C or C++. This provides a quicker way to writing wrappers to invoke programs written in Java and therefore introduce Java libraries to the Perl without the trouble of writing low level C/C++ programs.

You will need to know how JNI works in order to use this package. This package is by definition very primitive. If you dont understand thoroughly on how JNI works and try to use the feature of this package, you can easily crash your program or create memory leaks. So dont do that.

It is my hope that somebody with proper skills in JNI and Perl can write wrappers for a set of popular Java libraries, such as JDBC, XML parser, JMS (that I am working on), and other useful Java packages so that a Perl programmer can use them directly in a pure Perl environment without knowing anything about JNI.

NativeCall is a Java toolkit that lets you call operating system methods from whithin Java without JNI code.
The current version 0.4.0 supports structs, Strings, primitive types (ints and booleans), byte and char arrays and output parameters.
NativeCall 0.4.0 implements some minor changes to make the API more consistent and easier. NativeCall project also features more unit tests.
Enhancements:
- The previous release could not create multiple pointers correctly.
- Javadoc for Win32Verifier#verifyModuleName(String) was corrected.
- Using a new Holder(null) now means new Holder(new Integer(0)).
- Constructor method IDs are now cached.
- int hashCode() methods have been optimized.

TIJmp is a memory profiler for java. TIJmp is made for java/6 and later, it will not work on java/5 systems. If you need a profiler for java/5 or earlier try the jmp profiler.
TIJmp is written to be fast and have a small footprint, both memory- and cpu-wise. This means that the jvm will run at almost full speed, until you use tijmp to find some information.
TIJjmp uses C code to talk to the jvm and it uses swing to show the the tables of information. So tijmp is written in C (using jvmti and jni) and Java.
TIJmp runs in the same jvm as the program being profiled. This means that it can easily get access to all things jvmti/jni has to offer.
This project is distributed under the General Public License, GPL.
Enhancements:
- Owner information now shows correct field names for static variables and array indexes show the correct position.
- The classpath setup was improved.
- It now installs files in the correct Linux directories.

mod_gcj is a project aimed to serve dynamic pages from Apache using libgcj, the free Java implementation that is part of GCC. Setting up Apache with servlet engines has been a cumbersome task for many years. Still today, it isnt very easy to set up the Apache Foundationss own Tomcat servlet container with Apache.

Also, traditional servlet containers do not feel very well integrated with Apache or the rest of the OS platform. Of course, this kind of non-integration is part of Javas culture. One could even say it is one of Javas pillars. But is it always a good thing for server applications?

In contrast, the GCC compiler suite treats Java as just another language that is compiled down to native code. Static compilation obviously is a nice fit for server applications, where code can immediately optimized for the platform without going through the intermediate bytecode level and than compiling the code at runtime.

Another benefit is that Java code compiled with GCJ can be easily linked with other native resources and thus becomes much less isolated than Java traditionally is, and more of an equal citizen of the platform it runs on. GCJ provides its own interface for coupling Java code with C++ called CNI. In contrast to JNI, CNI is very sleek, performs well and is suiteble for use by ordinary people.

To summarize, mod_gcj aims to provide a way to serve dynamic Java Web content that is closer to the Apache Httpd and the platform it runs on.

JDBC Driver for SQLite is a thin layer on top of the SQLite 3.3.x C API. The native JNI library has SQLite compiled into it so all you need to do is include the two files packaged above in your project.
Usage:
Download the binary for the platform you are developing on. Open the tarball and copy the two files into your application directory:
sqlitejdbc.jar
[lib]sqlitejdbc.[dll, so, jnilib]
Reference the driver in your code:
Class.forName("org.sqlite.JDBC");
Connection conn = DriverManager.getConnection("jdbc:sqlite:filename");
// ... use the database ...
conn.close();
And call your program with the drivers JAR file in the classpath and the C library in the librarypath. E.g.
java -cp lib/yourprog.jar:lib/sqlitejdbc.jar
-Djava.library.path=lib
yourprog.Main
Enhancements:
- The driver is now thread-safe and fully supports UTF-16.
- There are binaries for Mac OS, Linux, and Windows, and instructions for compiling with MSVC.

SQLiteJDBC is a JDBC driver for SQLite which is written as a Java JNI layer over the SQLite 3.3.x API.

SQLiteJDBC supports the most commonly used features of JDBC that can be efficiently implemented on top of SQLite. Only a single native JNI library is required, and SQLite is compiled in.

Binaries are provided for Linux, Mac OS X, and Windows.

The Java Binary Enhancement Tool (JBET) is a general Java program analysis and manipulation tool. Existing class files can be disassembled, reassembled, or edited programmatically through the JBET API. JBET can also be used to create new Java class files from scratch. JBET uses a convenient internal representation of all the contents of Java binary (.class) files, allowing the user to edit the classes easily, in a structured manner.

JBET was developed as part of the DARPA Self-Protecting Mobile Agents project under the OASIS and Active Networks programs (contract number N66001-00-C-8602) in order to study automated software obfuscation.

The Java language was chosen for this project because of the (relative) ease of constructing binary editing tools provided by the large amount of type information present in the class files. Our two reports, the Obfuscation Techniques Evaluation Report, and the Obfuscation Report, are available from the download area. The obfuscation tool developed is not part of this release.

JBET was also used in the DARPA/AFRL Survivable Server project (contract number F30602-00-C-0183) to add additional security checks to the Java Standard Library. (The Java SecurityManager API does not support many desirable security checks, such as continued authorization of file accesses after opening.)

JBET was used to replace the native method references in the Java standard library with stubs that call a pluggable security policy. This tool, called Jpolicy, is also available for download at this website. Jpolicy is very incomplete at this time, but may be interesting to those working in Java security or changing the standard library themselves.

The internal representation of Java class files used by JBET is intented to make it easy for programmers to write Java binary code transforms. Each element of Java class files has a corresponding internal data structure: ClassInfo for entire classes, MethodInfo for methods, FieldInfo for fields, Snippit for code blocks, and Instruction for individual instructions. Snippit and Instruction understand Java opcode syntax and semantics, allowing automated creation of valid Java programs. A Java-compatible class verifier is also included.

Some code transforms are difficult to program directly by manipulating Java instructions. For those transforms, a directed acyclic graph (DAG) representation of code is available. In the DAG representation, each basic block has a corresponding DAG, with a set of input and output nodes. Edges in the graph connect "producer" nodes (such as constants, or the result of calculations) to "user" nodes (such as method calls or other calculations). Methods are divided into basic blocks and control flow is stored at the basic block level (possible because Java has only fixed jump targets)

JBET requires a Java 1.4 virtual machine to run, although it can operate on class files from earlier Java versions. The packaging and build environment supplied supports Linux and Windows with Cygwin; however, the build process is simple and could be performed manually on other platforms. Perl is required for regression testing.

Jpolicy requires a Java 1.4 virtual machine to build, either Linux or Windows NT/XP with Cygwin. gcc is required for building on Windows (supplied with Cygwin). The runtime system can be either Java 1.3 or 1.4 (with Suns JVM only), running on Linux or Windows NT/XP. Windows 9x and Windows 2000 may work as well, but have not been tested.

Installation

1. Install jdk 1.4.1.
2. Set CLASSPATH to jdk1.4.1/jre/lib/rt.jar
3. cd src; make
4. If that didnt work, examine the makefile. java or javac may not be in the path.
5. To build a jar file that can be used with "java -jar jbet.jar", run "make jar".
6. If you have perl installed, run the tests with "make test".
Optionally, run "make regen; make test".

Make a symbolic link from jbet3/bin/jbet to somewhere in your path.

Usage

JBET uses the JNI format for class names, and JNI type and method descriptors. For a summary of this syntax, use jbet help syntax. Suns JVM specification may also be helpful.

To look at a class disassembly, use jbet print. Try disassembling a class you have source for, and was built with debug info (-g): jbet -P < classpath > print < classname >. Suns JVM specification has an instruction reference.