Is Linux a good platform for running server-side Java applications? I'm not surprised when I'm asked this question because, frankly, Java isn't a language normally associated with Linux, the bastion of C and Perl programmers. You are unlikely to find hordes of Java programmers (or even Java admirers) at Linux conferences--trust me on this one. Thus, the body of knowledge and mindshare surrounding this language and operating system combination just isn't all that large. This month, I'll investigate the viability of Linux as a host for your Java applications.
The Executive Summary
As you may recall from last month's article, I have a database server (an IBM pSeries running the Oracle DBMS on AIX) that dishes out data to an application server (an IBM xSeries running the open-source J2EE server JBoss on SuSE Linux).
I have had no problems (the prime metric I use for evaluation) with the application server. Linux is a superbly stable operating system for which commercial support is readily available. Choosing Linux as an operating system is no longer considered the risky choice that it once was. As for Java on Linux, a number of Java Virtual Machines (JVMs) are available for the platform--the two prime choices being IBM's JVM and Sun Systems' JVM. (Sun is the originator of Java and continues as its benevolent dictator.)
Thus, the simple answer to my initial question is "yes." Linux makes a fine platform for hosting Java applications. If all you want is the executive summary, then there you have it. Linux-hosted Java is stable and enterprise-ready.
Java on Linux--A Condensed History
Java on the Linux platform has had an interesting history. As I stated earlier, Java doesn't have the same level of acceptance to the average Linux programmer that other languages have in the *nix world. While a good deal of this situation can be attributed to the usual religious wars over which language is the "one true way," another major factor is the general distrust by the Linux community of anything not open-source. While Sun has made the language specifications readily available to any interested party, it has also kept tight control over the direction that the language can take. That kind of control is a double-edged sword. It has kept large monopolies from directly co-opting the language to make it platform-specific (a good thing that enforces the write-once, run-anywhere aspect of Java), but it also has precluded individuals from adding their own features (a bad thing, since the Linux programmer is accustomed to having that kind of control).
The original Java Software Development Kit (SDK) for Linux was produced not by Sun Systems but, instead, by a group who formed what is known as the Blackdown project. (A JVM is supplied in an SDK, with which you can compile Java code, or in a Java Runtime Environment, with which you can run only pre-compiled Java code. You need the SDK to deploy most server-side Java applications.) Blackdown's mission was to make Java run on the Linux platform, and the group had some success fulfilling that mission. Blackdown's JVM worked well but suffered from what I perceive to be the project's lack of resources. You could always depend on Blackdown to be behind the current Java version. The version that Blackdown did support was sometimes incomplete in implementation and while that wouldn't be much of an issue to a mature language, it was a major irritation to the Java developer during the language's formative years. The features being added to Java weren't just niceties; they were darned near requirements to make the language useful. Back then, neither development nor deployment of Java applications on a Linux machine was particularly feasible. Thus, when I wanted to write Java code, I booted into OS/2 (a whole other story) and when IBM orphaned OS/2, Windows. So did most other Linux users who were also Java developers. How things have changed since then! Instead of one SDK, we now have a number of SDKs from which to choose, three of which I'll mention here.
Given IBM's enthusiasm for Java, it should come as no surprise that the company supplies its own SDK, and it is superb. The compiler produces fast and efficient code and the JVM performs well. Certainly, if you are going to be using WebSphere, it makes sense for you to use IBM's SDK, which is included with Red Hat Enterprise Linux (the distribution I use) as well as SuSE Enterprise Linux (now owned by Novell). Even if your favored distribution doesn't provide the IBM SDK, you can download it directly from IBM and install it yourself. It's a fairly trivial task to do.
Despite Sun Systems' on-again, off-again love affair with Linux, the company does produce an SDK for the platform. I use Sun's SDK on my non-Red Hat systems, which are not hosting WebSphere. I've never benchmarked IBM versus Sun to see which JVM performs better, but performance has never been an issue on my systems, either. As they say, your mileage may vary. If you have demanding requirements, then I'm sure you will want to invest the time to find out which works better for you.
What about Blackdown? Even with the appearance of commercially available SDKs, the Blackdown project continues to exist. In fact, they are relatively current through Java Version 1.4.2, and their site states: "Blackdown is working on Java 1.5 for x86, AMD64, SPARC and PPC architectures." The question of the relevancy of the Blackdown project gets to the heart of open-source software. You can't redistribute Java runtime environments from IBM or Sun unless you are willing to jump through the necessary licensing hoops. You can, however, redistribute Blackdown's JRE (but not the SDK) with your own software. I haven't used Blackdown's SDK for years and currently have no interest in the project. Your particular circumstances may make this an attractive alternative. If you really need an implementation of the Java language that is totally unencumbered (but not as complete), then I suggest that you check out Kaffe and some of the other projects listed on the Kaffe links page.
Application Server Components
If you were hoping for an extensive treatise on the specifics of running a Linux-based application server for Java, then I'm afraid you'll be sorely disappointed. There is absolutely nothing remarkable about implementing a Java application server or servlet container on a Linux machine, once you get an SDK loaded and properly configured. That's the beauty of Java. If you have even a modicum of knowledge of a UNIX-like operating system (or for that matter have played extensively on the iSeries in the Qshell environment), you will have no trouble getting things set up.
In my case, the application server uses JBoss and Tomcat, both open-source projects, to do the heavy lifting. These projects provide extensive documentation to make installation and configuration simple for any common operating system, Linux included. The clients (which I'll discuss shortly) are totally unaware of the operating system to which they are communicating, so which platform you choose for a host is irrelevant.
My experience with this system has been pleasant. It has been virtually pain-free, reliable, and easy to manage. And once you get one of these running, cloning it to multiple systems can be done easily with products such as Mondo Rescue (another open-source project), using something simple like a Linux rescue CD and tar, or something more interesting, such as rsync. No expensive software is required for cloning these servers! Your backup and recovery choices are also extensive and include the aforementioned open-source alternatives or commercial software, such as IBM's Tivoli. Which choice you make depends on your needs, budget, and creativity.
Things That Need Work
If I have to complain about one component of our n-tier system, I'll pick the client software, which is also written in Java. The clients communicate via Web Services, and the software works fairly well. Using the Java "Web Start" architecture, the client software and any updates can be pushed to the clients easily. For the most part, it works. But two major glitches occasionally crop up and drive me insane.
First, there are the usual random application crashes. Since I haven't run this product extensively on any operating system other than Windows 2000 and Windows XP, I can't point to either the JVM or the operating system as the source of these crashes. Frequent readers of my column can already guess which component I'm likely to blame.
Second, there are some serious bugs in the client software that demonstrate the difficulty of writing GUI software. Those of us who do not recoil in horror at the thought of green-screen applications can appreciate the relative ease of writing green-screen apps compared to the complexity of writing GUI apps. The difference? Green-screen applications allow the programmer to strictly control the code path the user will take. In fact, the same can be said of browser-based applications. On the other hand, GUIs have many different possible paths for the code to take, depending on the actions that their users take. And given the incredible number of screens (thus the incredible number of possible code paths) involved in this particular application, it is unlikely that the vendor could possibly exorcise them all, regardless of the tools they have at their disposal. I draw this conclusion based on some of the nonsense displayed to my users, such as the same information appearing on two different screens with two different values. When I find one of these irritations, all I can do is report the error and wait for the inevitable response: "We're unable to duplicate this error." Oh well, such is progress....
Fear Not
I know that some people resist using Linux and will not even consider it. After many years of using something else, they get too comfortable to switch. That's a shame. There are so many benefits to using Linux, and now that IBM has made it clear that it takes both Java and Linux seriously, you have all of the resources at your disposal to take advantage of both. Whether you do it on an Intel box or an i5 makes no difference because the software and administrative skills are identical on both. Linux continues to gain market share, and I think that eventually you'll be using it in one form or another.
That's it for this month. I welcome your comments, questions, and smart remarks. Feel free to drop me an email or post your comments into the forums discussion associated with this article.
Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 21 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online