Java Web Applications in Fedora

Fedora and Debian play the role where many chaotic projects get a degree of charm school: they learn to play nice with a lot of other projects. In Fedora, as near as I can tell, there is only one Java based web application packages as part of the distribution: Dogtag, the Public Key Infrastructure server. As we look at how PKI should look in the future, the dearth of comparable applications packaged for Fedora leaves us with the opportunity for defining a logical and simple standard packing scheme. While I am not there yet, this post is the start of my attempts to organize my thoughts on the subject. I’m looking for input.

Continue reading

Finding Java Classes

I’m back on a Java project. Been a while, and I want to capture some of the tricks I’m using.

Right now, I’m just trying to import the project into eclipse.  Seems that the current team members don’t use it.  I’m an IDE kind of guy, at least when it comes to Java.

Building the .classpath file can be tricky.  However, since I know that I have a good build, and that this project it a good participant in the Fedora build process, I have the advantage of knowing that my packages reside in /usr/share/java.  Still, all eclipse gives me is a set of classes that it can’t find.  how to find them?

This project uses CMake.  I could look for all of the Jar files in the CMakeLists.txt files, and I might do that in the future.  However, a trick I’ve developed in the past has come in handy.


echo $1 | sed 's!\.!\/!g'


for JAR in `find /usr/share/java -name \*.jar -type f ` 
	do for CLASS in `jar -tf $JAR |  grep \.class` 
		do echo $JAR $CLASS  
done > /tmp/alljars.txt


First, the make_alljars function creates a map in (value key) order. The value is the Jar file name, and the key is the class name. To fine a Jar file that contains a given class (in this example netscape.ldap.LDAPConnection) , run:


grep `class2path  netscape.ldap.LDAPConnection` /tmp/alljars.txt

And the output is

/usr/share/java/ldapjdk.jar netscape/ldap/LDAPConnection$ResponseControls.class
/usr/share/java/ldapjdk.jar netscape/ldap/LDAPConnection.class

This works really well with eclipse, in that the error messages have the name of the class. You can then just highlight the class name, paste it into the command line in place of the class I have above, and when you get the Jar file name, you can highlight to save to the clipboard. From The right click context menu pick Java Build Path and then Add External Archive and then paste the whole path in.

What Jar File

When working a with a new project, I often find I am searching for the Jar files that fulfill a dependency. Sometimes they come from maven, sometimes from the Fedora RPMS. My approach has been to make a cache of the Jar files in the directories that I care about that contains a map from jar file name to class name:



echo > $CACHE_FILE

for DIR in /usr/share/java /usr/lib/java
    for JAR in `find $DIR -name \*.jar`
        #only do the non-symlinked versions
        if [ -f $JAR ]
            for CLASS_FILE in `jar -tf $JAR | grep \.class`
                CLASS=`echo $CLASS_FILE | sed 's!/!.!g'`
                echo $JAR $CLASS >> $CACHE_FILE

Then call it this way:

grep "org.mozilla.jss.ssl" /tmp/jarcache

Removing empy comment blocks

Eclipse can automate a lot of stuff for you. One thig is did for me was automating the serialVersionId generation for all the serializable classes in my tree.
They look like this:

     private static final long serialVersionUID = -9031744976450947933L;

However, it put an empty block comment in on top of them, something I didn’t notice until I had mixed in this commit with another. So, I want to remove those empty comment blocks.


for JAVAFILE in `find . -name \*.java`
     sed -n '1h;1!H;${;g;s! */\*\*\n *\* *\n *\*/ *\n!!g;p;}' \
         < $JAVAFILE > $
     mv $ $JAVAFILE

Thanks to this article for how to do the multiline search and replace.

Binary Java Runner

I’ve been recently thinking about the scripts that are used to run Java processes. Firing a script interpreter and running a slew of processes before running your program seems really inefficient. Additionally, programs meant to run on a Fedora system can make a few assumptions that general Java programs can’t.

Jar files should be in /usr/share/java or /usr/lib/java.We don’t want people putting files all over the place. Most of the scripts are doing classpath related operations.

Here is my Sample code

class Hello{
    public static void main(String[] args){
        for (int i =0 ; i < args.length; i++){
            System.out.println ("Hello "+args[i]);

Which I can compile into a Jar file pretty easily. I'll cll the jar hello.jar

int main()

char *const argv[] = {"/usr/bin/java","-cp","hello.jar","Hello"};
char *newenviron[] = { NULL };

execve(argv[0], argv,newenviron);
return 0;

This serves as a starting point.

But, really, do we want to have to ship a Jar file and a separate executable? For command line utilities, the basic classes that it requires should be statically bound into the application. We can convert the Jar file into data an link it into the application:

ld -r -b binary -o ant-launcher.o /usr/share/java/hello.jar
cc     runjava.c hello.o   -o runjava

Now is where things get interesting.

First, we need a way to load this Embedded Jar file in as a class. As a proof of concept, the C program can read the data section and spit it out to a jar file.

const char * temp_file_template = "hello.jar.XXXXXX";
char * temp_file = "hello.jar.XXXXXX";

void build_jar(){
  temp_file = malloc(strlen(temp_file_template)+1);
  memset(temp_file, 0, strlen(temp_file_template)+1);
  strcat(temp_file,  temp_file_template);

  int retval  = mkstemp(temp_file);

  int fd = open(temp_file,
                O_WRONLY | O_CREAT |  O_TRUNC
                ,S_IRWXU  );
  if (fd < 0){
  ssize_t sz =
    write (

  if (sz < 0){


This produces the same output as if we had run it from the initial example.

But, this is wasteful. This example will litter a copy of the jar file into your directory. You can't delete it when you are done; exec does not return to your code.

So the next step is, instead of running using exec, run using JNI.

/*run the executable using an embedded JVM*/
void run_embedded(){
  JNIEnv          *env;
  JavaVM          *jvm;
  JavaVMInitArgs  vm_args;
  JavaVMOption    options[2];
  int             option_count;
  jint            res;
  jclass          main_class;
  jobject         javaGUI;
  jmethodID       main_method;
  jthrowable exception;
  jobjectArray ret;
  int i;

  const char * classpath_prefix = "-Djava.class.path=";
  int classpath_option_length =
    strlen(classpath_prefix) + strlen(temp_file) + 1;

  char * classpath_option =

  memset(classpath_option, 0, classpath_option_length);

  strcat(classpath_option, classpath_prefix);
  strcat(classpath_option, temp_file);

  option_count=1; //set to 2 for jni debugging
  options[0].optionString = classpath_option;

  options[1].optionString = "-verbose:jni";

  /* Specifies the JNIversion used */
  vm_args.version  = JNI_VERSION_1_6;
  vm_args.options  = options;
  vm_args.nOptions = option_count;
  /* JNI won'tcomplain about unrecognized options */
  vm_args.ignoreUnrecognized = JNI_TRUE;
  res = JNI_CreateJavaVM(&jvm,(void **)&env,&vm_args);

  if (res < 0 ){
  const char * classname =   "Hello";
  main_class   = (*env)->FindClass(env, classname);
  if (check_error(main_class,env)) {

  main_method = (*env)->GetStaticMethodID(env,main_class,"main",

  if (check_error(main_method,env)) {

  char *message[5]= { "first", "second", "third", "fourth", "fifth"};

  jstring blank = (*env)->NewStringUTF(env, "");

  jobjectArray arg_array = (jobjectArray)(*env)->NewObjectArray
  if (check_error(arg_array,env)) {

  for(i=0;i<5;i++) {
    jstring str = (*env)->NewStringUTF(env, message[i]);
      ( env,arg_array,i,str);

  jobject result =
    (*env)->CallStaticObjectMethod(env, main_class, main_method, arg_array );

  if (check_error(result,env)) {

Note that we have now linked against a version of the JVM, and that commits us to a given JDK. This is just a proof-of-concept; This whole copy the Jar approach is just a stepping stone.

What we really want is a classloader which plays by the following rules:

  • lets the rt.jar classloader safely load the basic java, javax, and other JRE classes as a normal executable
  • makes sure that all the classes for our application get loaded from our specified jar file
  • reads our specified jar file directly out of the elf section of our binary executable
    • I appears to me that the standard classloading approach is fine for our needs with one exception: we can't treat an ELF file as if it were a Jar file. If we could do that, we could throw argv[0] on the front of the -Djava.class.path command line switch and be off and running. This would have the added benefit of creating a classloader extension that could be used from other Java programs as well. I'm currently thinking it should be of the form: file+elf://path-to-file/linked_jarfile_name

      as that format would allow us to link in multiple jar files.

      However, to be really efficient, we don't want to have to pay the price for the OS file operations (open, read) again, since the jar file is already loaded into memory. We should be able to create a protocol which tells the classloader: use this InputStream to load the class, and the JNI code can then pass the input stream.