Novell is now a part of Micro Focus

Porting Java applications to SUSE Linux

Novell Cool Solutions: Feature
By Simon Nattrass

Digg This - Slashdot This

Posted: 2 Jun 2004


Moving Java applications from another platform to Linux is quite straightforward, with a few caveats. Even though Java is a write once, run anywhere language, there are still some configuration and platform specific requirements to be understood. This paper is designed to aid developers and consultants in understanding where these requirements lie and approaches to be considered in porting Java applications to SUSE Linux.

Table of Contents

1. Java on the Linux Platform
2. Installing Java SDK on SUSE
3. Setting up Java SDK on SUSE
4. Development Environments
5. Executing and Building Java applications
6. Java Native Interface (JNI)
7. Threading
8. GUI Applications -- AWT and Swing
9. Running Server-Side Java
10.Packaging Java applications

Java on the Linux platform

When most people think of Java they think of the "official" distribution from Sun Microsystems1, but there are other flavours available for the Linux platform:

  • IBM developer kit for Linux2
  • Blackdown -- a Java environment specifically for Linux3
  • Kaffe - a clean room implementation of the Java virtual machine, plus the associated class libraries needed to provide a Java runtime environment4

For a fuller list see "Marco Schmidt: List of Java virtual machines, Java development kits and Java runtime environments"5. In this document we will be using the Sun distributions.

Installing Java SDK on SUSE

The latest version of Java SDK is available on Sun's Java web site1, and is available in rpm and self-extracting versions. The distinction between the two being that the rpm version replaces the system version supplied with the SUSE distribution, while the self-extracting package provides flexibility to install multiple Java environments.

The SUSE distributions all include one of the Sun Java Runtime Environments (JRE) as part of a default installation, with SUSE Linux Enterprise Server additionally installing the IBM Java SDK. As expected, each distribution also complements these defaults with further development kits and Java tools as part of the available software.

Setting up Java SDK on SUSE

SUSE has the ability to support multiple Java runtime and development environments for those applications which have specific runtime requirements or for development across multiple Java SDKs.

For more information see the How-To document15.

Development Environments

There is a variety of commercial and Open Source development environments available for Java development on the Linux platform, ranging from open, multi-faceted tools with Java plug-in capabilities to those specially designed only for Java development.

One such tool is Eclipse6 which is of the open, multi-faceted type in that it "is a kind of universal tool platform - an open extensible IDE for anything and nothing in particular". To be more specific, the Eclipse Platform is designed for building integrated development environments (IDEs) that can be used to create applications as diverse as web sites, embedded Java programs, C++ programs, and Enterprise JavaBeans.

Other tools you may wish to explore include Borland JBuilder7, JetBrains IDEA IntelliJ8, Java Development Environment for Emacs (JDEE)9 etc...

Executing and Building Java applications

As stated earlier, you can build and execute Java applications by invoking the 'javac' and 'java' commands in a shell. However, for more complicated Java applications which require many jar files to be included in the classpath, a script file would ease the repetitive typing whenever the application is run. SUSE Linux fully supports bash and other command shells so you can build any type scripts to your preference.

For larger projects with many Java files, Apache Ant10 is the recommended build tool. Apache Ant is a Java and XML based build tool, hence it can run on many platforms including SUSE Linux. Ant performs a similar role to the ubiquitous the Linux/Unix Make tool without suffering from the same drawbacks.

Conventional compilation translates Java source to byte-code, however with the GCJ compiler from GNU11, developers have the choice of the former standard compilation or may compile the source code directly to native machine code. GCJ compiled applications are linked with the GCJ runtime, libgcj, which provides the core class libraries, a garbage collector, and a bytecode interpreter. Most of the APIs specified by the Java Class Libraries are supported except the Abstract Window Toolkit (AWT). Debugging is supported using recent versions of GNU debugger, GDB12.

Java Native Interface (JNI)

The Java Native Interface (JNI) enables Java code running inside a Java Virtual Machine (VM) to interoperate with applications and libraries written in other programming languages, such as C, C++, and assembly. Typically JNI will be employed when the standard Java class library does not support the platform dependent features needed by the application, where legacy code exists that needs to be made available to Java, or to leverage the benefit of time critical code written in a low level language (assembly).

An alternative (and more efficient) to JNI in the C++ space is the Cygnus Native Interface (CNI)13 which provides a convenient way to write native Java methods in C++. CNI uses C++ name spaces to implement Java packages, leading to an intuitive class naming convention (example, the Java class java.lang.String maps to java::lang::String in C++). While CNI does make it easier to write native Java methods, it has the major drawback of not being portable. If a developer wishes to use CNI, then there is a dependency on a CNI-aware compiler such as g++14.


The underlying Java Virtual Machine (JVM) implementation of threading has proven to be a confusing issue on the Linux platform. Historically there are two types of threads, "green" and "native" with JVM distributions supporting one or both.

Green threads emulate multi-threaded environments without dependence on the multi-threaded capability of the underlying Operating System (OS), which has been the approach from Sun in the past to provide multi-threaded functionality for Java in OS environments without native thread support.

Native threads take advantage of the Operating System's capability to provide native thread support, thus delegating thread scheduling and management to the kernel. This can be seen with ps showing multiple entries, since Linux threads are implemented as cloned processes.

Sun Java version 1.3 supports both threading models, native by default and green via the -classic flag to the JVM. Java version 1.4 has since dropped green thread functionality.

For further information please see the How-To document15.

GUI Applications -- AWT and Swing

Java GUI development is largely platform-agnostic with a couple of small caveats between environments.

Firstly the trigger event for pop-up menus are platform-specific and differ between Windows and Linux, thus developers must write code to account for this.

Secondly, Linux supports an alternative approach to cut and paste between applications known as "selection," which is not supported for older AWT applications.

For further information please see the How-To document15.

JRunning Server-Side Java

Apache Tomcat16 is the one of the most popular choices for running server-side Java. Tomcat is the servlet container that is used as the official Sun reference implementation for Servlet and JavaServer Pages (JSP) technologies. The Personal and Professional distributions of SUSE ship with a version of Tomcat, and developers can use the SUSE YaST utility for installation. SUSE Linux Enterprise Server requires that developers download the latest version of the Tomcat from the Apache web site.

In a production environment, the Apache web server17 is normally used to serve static content with Tomcat serving the dynamic content. The Apache web server is designed to scale far better for serving static pages while Tomcat may be left to handle the server side Java, with the two components using the mod_jk connector18 for communication. The home versions of the SUSE Linux also include the mod_jk connector. Developers just need to change the configuration files for Apache and Tomcat to enable the connector.

For true Enterprise Java applications that require Enterprise Java Bean (EJB) functionality and other J2EE features, many of the popular Java Application Servers like JBoss19, BEA Weblogic20, IBM WebSphere21 and Novell exteNd22 are supported on the SUSE platform.

Novell Nterprise Linux Services (NLS)23 contains both the Apache 2 web server and Tomcat 4.1 servlet container with the mod_jk connector already pre-configured.

Packaging Java applications

A common way to install a product on a Linux platform is using the RPM packaging format, which SUSE fully supports. Currently, there is an ongoing project, JPackage24 which attempts to employ the benefits of rpm installation with popular Java tools, thus easing installation for the end user. JPackage Project has two primary goals:

  • To provide a coherent set of Java software packages for Linux, satisfying all quality requirements of other applications.

  • To establish an efficient and robust policy for Java software installation.

The RPMs produced by JPackage are generic; they should work in any RPM based Linux distribution.


Linux has become the choice for running Java applications because of its performance and stability. This white paper provides some guidance of running Java applications on the SUSE Linux. For more detailed information, please refer to other HOW-TO documents.


(15) Linux Threading How-To document

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Micro Focus