Browse Prior Art Database

Methodology for loading native libraries in a J2EE context Disclosure Number: IPCOM000124282D
Original Publication Date: 2005-Apr-14
Included in the Prior Art Database: 2005-Apr-14
Document File: 4 page(s) / 220K

Publishing Venue



This is a methodology for loading native libraries in a J2EE context.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 47% of the total text.

Page 1 of 4

Methodology for loading native libraries in a J2EE context

Problem description

A J2EE Application runs on the Application Server which is a technology framework that resides on a layer that goes on top of the hardware and the operating system. Hence the Application Server context hasn't got (or better should not have) any constraints relative to the surrounding low-level environment.


Data Source

Is deployed on the ApplicationServer and leverages on the all available features



EJB Deployer

Dynamic libraries

Figure 1

Listed below there are some specific scenarios that require the usage of native code embedded in a java runtime through a specific interfacing mechanism (JNI):

· communicate with other applications,
· dealing with proprietary technologies of native system features,
· performing os defined APIs on the deployed resources,

Those are a small part of the huge amount of cases where the usage of java bean with a native implementation achieves the overcome of the limited capabilities offered by a cross-interp programming language.

In a J2EE context, an Enterprise Application is still to be considered part of the above defined range of scenarios. In the next sub-sections an analysis of the existing solutions compared with the actually proposed invention will be described with more details.

File system

Application Server

Operating System


[This page contains 1 picture or other non-text object]

Page 2 of 4

Available solutions

Most of all ApplicationServer's vendors provide their own mechanism for achieving the dynamic linkage of JNI libraries within the java runtime environment. This is actually satisfying the link to the native implementation of the java beans embedded in the EAR but implies the following disadvantages:

· the mechanism is not standard but depends on the specific vendor,
· the proper ApplicationServer configuration is achieved only by applying a set of administrative operations,
· the deployment of the native library is performed in a separate step and needs a phase of packaging and description,
· the application maintenance goes across the ApplicationServer settings reconfiguration.

This means that the deployment of the EAR becomes more complex than it should be as there will be the need to deploy multiple elements and more importantly to keep them in synch. It will also imply that the application developed will no longer be cross-ApplicationServer compatible . In other terms the deployment code will be charged by an extra-effort that consists in dealing with the administrative scripting interfaces so as to enhance the standard configuration in order to meet the desired JNI linkage settings.

Description and Benefits

The idea consists in a solution that allows the application to embed native code by leveraging on the existing J2EE mechanisms for acquiring external java libraries (ClassLoader ). The Java System.loadLibrary method passes through the current application ClassLoader and finds o...