Java, Linux, and Open Source Integration Better Living through Open Source Introduction: Can we offer a new model for using Java, Linux, and Open Source? There are features and philosophies behind the Java and the Open Source communities that are not necessarily aligned. Yet the merger of Java and Open Source using Linux as the focal point, can offer something new to developers and hopefully end users as well. Java offers "Write Once Run Anywhere". Linux offers flexibility unmatched and the most visible element of the Open Source community. The rest of the Open Source community offers, well..., source! The Java development tools certainly work better on some systems than others and the versions available are definitely selective. The Blackdown Java-Linux porting group has taken on a monstrous task and done an outstanding job of porting Java to Linux. But it is difficult and it takes time. Sun offers new versions of Java on a small number of favored platforms before the last port can even be completed. The primary Linux platform is Intel. While Linux is supported on other processors it is often found to be lagging in the latest versions of many programs for non-Intel platforms. Yet these applications can be ported to other platforms when someone gets interested in doing the port. Maybe we should consider a change from a skills certification validation to a "show us your hacks" approach. The potential to do the port is always there because of the source. There is never a shortage of hacks needing to be written. Linux is the most visible project among the various groups in the Open Source community and is often considered the Poster Child. Linux is also a wonderful development platform as is any Unix. The Open Source community offers yet other perspectives. While Linux is generally considered to be part of the Open Source community as are many other communities that often overlap and might be considered fellow travelers. For example, the GNU community is one of the most visible groups producing Open Source code, many other developers of Open Source exist with a variety of licensing techniques. GNU, Berkley, X, and others have helped to "Share the Wealth". Not all Open Source people are Linux people and many Java folks are involved in Open Source development many others are not involved in Open Source. We argue, have different interests, but most important we hack code. Open Source is not exclusively in the domain of one operating system or any one community. GNU is not Unix and GNU is not exactly Open Source. GNU is part of the Open Source community but it is specifically the "Free Software" community. Open Source covers a broader community that does stop at one processor, operating system, or philosophy. Therefore open Source code can be ported anywhere and run on anything. This is definitely in line with the goals of the Java community. The Mix With "Write Once Run Anywhere", being a major goal of Java and Open Source having a totally different goal how do we find a common frame of reference? The goals are not mutually exclusive but they are not aligned either. What can Open Source offer to the Java community? In one word, options. Linux users have become used to the idea that they have options. From the desktop to the CPU, Linux users enjoy a level of flexibility that is unique among software developers and computer users. In the Java community much of the Write Once Run Anywhere capability depends heavily on the choices that Sun makes for Java development. While the decisions have often been good we have limited recourse when we don't like one of these decisions. For example, in the area of GUI I have never been completely happy with the options offered. AWT was too limited using a lowest common denominator to decide which features would be supported. Then Sun introduced Swing but it was too slow and overrode the window-manager look and feel. How can I fix it? I have no source and no way to get the source without some formal license agreement that I may or may not like. There are open source versions of Java but there are limitations there as well. One way to approach a fix for this is to start mixing Java and Open Source. This can be accomplished through the JNI (Java Native Interface). The JNI allows you to integrate code and APIs from your underlying platform into your Java applications. The Approach: One thing about JNI development is that Sun gave us a back door to extend Java. Then Sun cautions us not to use it unless absolutely necessary. The reason is that this breaks the Write Once Run Anywhere feature of Java. Arguably the most important single feature of Java. The ability to write an application once and run it in a different platform is not perfect but it is very real. Building something on Linux and moving it to MVS and running it without even a re-compile is impressive the first time you see it. So if the JNI breaks this feature what are our options? Well, how about using JNI and Open Source. JNI becomes the glue that connects Java to the system. With Open Source you can build the Java extensions you like on Linux and then you only have to port the JNI code to get it running on other platforms. This presumes that the particular piece of Open Source has been ported to all the platforms you are interested in. But then, when they aren't, you do have the source. Open Source allows us build new extensions to Java and still be able to run anywhere. To see how this works think of something that is important and unavailable in Java. I just looked in the Java API and was unable to find some of the traditional Unix IPC (Inter-Process Communication) mechanisms. No shared memory, semaphores, or message queues. This is truly a travesty of unmeasurable proportion. How is a developer to survive without these simple necessities? Just to make ourselves feel more at home in Java we will have to implement one of them. Which one? Well, Shared Memory will be tough without pointers so lets take a whack at Message Queues. First look at the thing you want to implement. From an OOAD approach we want to know what kinds of things are needed to make this work. Those "Kinds of Things" tend to be Classes. How about: MessageQueue MessageQueueReader MessageQueueWriter MessageQueueControls Architectural issues are decided next. How is the data passed to and from other processes? Java is likely to send the world Unicode characters. This works in an all Java world but there is nothing stopping us from talking to C, C++, or other language based applications. If we plan to speak Unicode to everyone we may want to be sure that the other applications are Unicode compliant. Next examine how those kinds of things are used. Instances of Classes are Objects so this is the Object Model. How do the things interact and what are their APIs. After we figure out more or less how this thing will hang together we code the Java side of the JNI to get the framework in place to connect to the C' side of our JNI. Use the "javah" program to generate C' header information including function prototypes. These headers will define how data is passed back and forth across the Java and C code. The C' side of our JNI is built from the prototypes and will actually connect to the message queue API. With the Message Queue Java API constructed we write some test code to validate the operation of the message Queue from Java. This simple example has shown how to implement a Java and Open Source integration. This little piece of coding works well as a model for Java and Open Source integration. The Benefits: This approach to extending Java preserves the original goals of Java. We also have more options for adding functionality to Java that can be moved to any platform. This model for extending Java gives the developer more control over the direction that Java extensions will take. Sun will notice extensions that are popular. When developers rally around a particular Open Source product the industry will notice. By using the JNI we can create bindings to any platform API available. By using Open Source we get bindings that introduce a new model of Java portability. There are simply no limits to how Java can be transformed to help us solve our problems. Conclusion: I am currently adding GTK+ bindings to Java so I can play with GTK+. These bindings allow the developer of Java applications to explore an alternative GUI development option. Remember I didn't like the other offerings. As these bindings solidify I plan to offer them for peer review and hope to have a third approach to GUI development under Java. The Linux community has enjoyed a wide array of choices available from languages to GUI look and feel. Some people will see the model I advocate as heretical ravings of someone bent on destroying the Java Write Once model. I disagree and believe that this model simply offers another, more open, approach to Write Once and Run Anywhere. Tony Dean 20 University Cir. Longmont CO. 80503 (303) 678-5958