Java — Cappuccino for the corporate programmer?

Can a programming language named after a conversation-inducing liquid find love and happiness in the IS division of a large, conservative corporation? It sure can. In fact, it may be every bit as important in the network-driven corporation as anywhere else. Let’s take a look at the problems faced by the typical large corporation, and see how relevant Java turns out to be.

For years, large companies have realized that the corporate “network” is the artery that carries the lifeblood of the business. Whether it’s operating on a hulking, creaking mainframe or stitching together a bazillion PCs and Sun workstations throughout the company, information flow rules. For many corporations, the Network is the Company.

Without a healthy corporate network, orders are not taken, inventory is not watched, software is not deployed properly, customers are not kept satisfied, and basically, money is not made. Diagnoses to reduce this network arteriosclerosis have information staffs constantly injecting new methodologies to improve the well-being of the enterprise.

How do we keep the corporation in the pink and out of the red? Time to call Java/Intranet-911.

Is Java a cure?

With the onslaught of Java-animated tooth fairies, 3-D boxing lizards, and funky cat bands in Java applets, it’s clear that Java is a great programming language for leveraging the whiz-bang of the Internet. But is it a good technology choice for corporate applications where network computing is critical? Let’s answer that question by matching up Java’s capabilities against a list of the key issues for corporate IT.

• Rapid application development
• Effective and efficient applications
• Program and programmer portability
• Development costs
• Maintenance and support
• Technical training

Rapid application development

Years ago, it was projected that programmers would soon be moot. Pure software program generators would totally eliminate the human program generators and the world would be a better place. Unfortunately this belief did not account for an accelerating demand for variable types of quality software. However, object technology soon put a spin on program generators by adopting a “generated-part-of-a-program” model. Previously generated base parts of a program (that is, “objects”) can now be connected together to provide some utility for a user.

The C++ programming language tried to be such a tool, but really didn’t fulfill the promise. Visual Basic and NEXTSTEP, regardless of religious preferences, were more indicative of the power of active objects. Java facilitates the creation of similar innovative application-development environments by also being flexible, powerful, and effective, and adds a few spins of its own. Corporate programmers now have beta-quality tools such as SunSoft’s Java Workshop, Borland’s Java environment, Symantec’s Cafe, RogueWave’s Jfactory, and soon, more sophisticated Javanese tools like Netcode and FutureTense (see the Resources section at the end of this article for links to these and other relevant Web sites). Given the progression of Java development environments, I would imagine that a NEXTSTEP-like rapid application development environment for Java is not that far away. So much for Steve Job’s advantage. (Weep not for Steve: He still has Pixar.)

(A personal plea to those entrepreneurs out there: Please do not name your innovative, whiz-bang, Java user, interface development environment, Intranet-based, five-tiered RAD product “espresso.” Einstein said, “Imagination is more important than Knowledge.” Say no to more products named Espresso!)

Effective and efficient applications

Large corporate applications stress effectiveness over efficiency; for the most part, getting the work done is more important than getting the work done efficiently. This is not a criticism: Getting it done is just a reality of corporate computing. Being a simpler language than the former programmatic diva of corporate computerdom, C++, Java allows programmers to concentrate on the application instead of the mechanics of building the application (what a novel idea!). Instead of worrying about convoluted ways of incorporating procedural windowing API’s, meticulously managing memory, dealing with seemingly endless name-mangling issues, header file synchronization, and agonizing linker woes, Java adds to the object-programmer toolkit by simply subtracting. Java has its own user interface toolkit, it self-manages application memory, it doesn’t mangle identifier names to provide type-safety, it does not rely on separate header files (for pure Java applications), and it only uses dynamic linking.

Most of the implementations of Java are pure interpreters. Currently, Java bytecodes are interpreted by the Java runtime system, that is, the Java Virtual Machine (JVM), on the subscriber’s computer (let’s call them subscribers and not users). In the near term, certain vendors will offer Just-In-Time (JIT) native compilers. If the JVM has a JIT compiler installed, incoming sections (classes) of the application bytecode will be compiled to the native architecture embedded in the subscriber’s computer. Java programs will then rival C++ for program performance. Note that the JIT back-end compilers are not used in the conventional compiler manner; programmers do not compile and distribute Java binaries to users. JIT compilation takes place on the subscriber’s system, as an (optional) part of the local Java runtime environment.

Most times corporate programmers, anxious to squeeze the most performance out of an application, start optimizing way too early in the application’s life. Java allows for some very innovative optimization techniques. For instance, Java is inherently multithreaded. Besides offering multithreading features such as the Thread class and an easy-to-use synchronization mechanism, Java itself uses threads. Clever compiler writers can utilize this feature of Java to spin off a thread that watches how an application is being used. More specifically, this thread can detect which methods of a class are the most used and invoke successive levels of optimization on those methods while the application is running! The longer a particular application or applet runs, the more optimized its methods will become. (Softway’s Guava is one such program.)

If such a JIT compiler is embedded in the Java runtime environment, the corporate application programmer does no work to make the application run optimally. I always felt that operating systems should adapt to the user in a similar fashion; a progressive language optimizer is one more step towards that ideal.

Program and programmer portability

Most large corporations have a heterogeneous mixture of computing machines. There are probably some Sun workstations for software development, hordes of PCs for deployment, some Macintoshes for the graphic arts department, HP workstations for the number crunchers, a bazillion PDAs for the sales force, and an SGI workstation for the long-haired guy in the mailroom. Development of corporate applications for such a diverse group of users is understandably complex and expensive. Up until now, it was extremely difficult to convince each disparate programmer community to use a common API to reduce the costs of corporate applications.

With a ported Java runtime environment for every machine architecture and a rich set of class libraries (called “packages” in Java lingo), programmers are finding it fun and interesting to work with Java. This “fun” factor has really drawn all these programmers towards Java, where previous attempts with universal GUI and non-GUI API’s (such as, Galaxy, XVT) disenchanted the techies. These APIs were simply inadequate, not network-centric, and just plain boring.

Greco Axiom #531: A boring tool bears no fruit.

Once programs are written in Java, an interesting side benefit is that all your programmers are now portable as well as the programs! This is probably just as valuable as having portable code — maybe more so! The corporate applications group can now develop programs for any architecture. The client and server parts of an application can be both written in the same language. It’s no longer the Solaris C++ group in research and the PC Visual Basic programmers in document distribution and the GNU developers on special projects; it’s now just the corporate IT Java applications group.

And the terminology is much easier with Java.

[Scene I : The Acme Widget Corporation Deals with Development]

Bob, the corporate C++ developer: “… it’s the abstract polymorphism that’s really the benefit here.”

Bill, the VB guy: “Jeez! Sounds worse than the heartbreak of psoriasis.”

Mary, the C developer: “By the way, who the heck named us ‘Acme Widget’?”

Bob: “Some MIT graduate student intern. He’s the nephew of the CEO and he’s planning on using C++ multiple inheritance and X Window in our accounting system as part of his thesis on genetically defective algorithms…”

[Scene II: Downsizing Acme Widget — details left to your imagination.]

So much for impressing your social circle with empowering C++ terminology. Explaining the difference among the Java keywords “final, finalize, and finally” will not exactly make you the hit of the party.

Development costs

In contrast to the traditional high cost of developing software on a workstation, the cost of creating an application in Java is similar to the relative cost of creating an application on a PC.

Development using expensive software for an inexpensive Sun workstation is a problem for many corporations. The overall hardware and long-term maintenance costs of a Sun Solaris workstation are very attractive to big businesses, but the additional cost of software development with C++ is prohibitive to all but the largest of corporations. Thankfully, the Intranet and Java development have brought the costs of corporate computing downward. Java tools do not cost thousands and thousands of dollars per seat like some big-name software toolsmith vendors. They are priced at comfortable PC levels. And with the growing public-domain and shareware tools community that graciously include source code, corporate programmers have a rich field that will yield a variety of resources and learning opportunities.

The success of the Internet has given corporate computing a great gift. Software pricing is now the same on high-powered Unix workstations as well as on PCs. Even Netscape has priced the Unix version of their SuiteSpot Web server products the same as the PC/NT version. This is a pricing philosophy that should become considerably more prevalent with Java-based software tools.

Maintenance and support

A well-known problem with corporate software is the ongoing demand for care and feeding. Java is certainly no cure-all solution for every maintenance headache. However, Java has several features that make life easier for the corporate code-wrassler.

One component of the Java Development Kit (JDK) is javadoc. If you use certain commenting conventions (like, start with /** and end with */) in your Java source code, javadoc will scan your code for these comments and create complete HTML pages fit for a browser. The Java API documentation was created in this manner. It makes the job of creating programmer documentation for new Java classes less painful.

Another big headache for the corporate developer is the creation and management of makefiles. Reading a makefile in the typical information-technology shop is like reading the history of the corporation itself. They typically are often handed down from programmer to programmer, picking up nonessential dependencies along the way. Talk about lint — this one picks up bits of fluff and doesn’t let them go. Most large applications groups have to deal with makefiles that contain a dozen libraries, myriad header files, arcane deployment mechanisms, and confusing make macros. It’s like looking into the stomach of a large shark.

Java reduces the dependency on complex makefiles significantly. First, there are no header files. Why have your source code split into separate parts so they can get out of sync? Java wants all the source code for a class in one file. If you want to separate the method interface from the details of its implementation for any reason, write a simple Perl script that separates them.

Java has a make-like intelligence built into the language (more accurately the Java compiler) to dramatically simplify the compilation to bytecodes. For example.

public class frank {        // File: frank.java
    Guitar lespaul;
 }
public class guitar {       // File: guitar.java
 }
% javac -verbose frank.java
[parsed frank.java in 720ms]
 [loaded C:JAVABIN..classesjavalangObject.class in 220ms]
 [checking class frank]
 [parsed .Guitar.java in 50ms]
 [wrote frank.class] 
[checking class Guitar]
 [wrote .Guitar.class]
 [done in 2300ms]

The Java compiler is smart enough to recognize that it needs to compile guitar.java. Now if we forced a recompile of frank.java without changing guitar.java, we would see that the Java bytecode compiler did not unnecessarily recompile guitar.java.

% javac -verbose frank.java
 [parsed frank.java in 440ms]
 [loaded C:JAVABIN..classesjavalangObject.class in 160ms]
 [checking class frank]
 [loaded .Guitar.class in 0ms]
 [wrote frank.class]
 [done in 1860ms]

Now if we now modify guitar.java (like, add another member to the class) and compile frank.java, the Java compiler is smart enough to recompile guitar.java as well as frank.java.

% javac -verbose frank.java
[parsed frank.java in 710ms]
 [loaded C:JAVABIN..classesjavalangObject.class in 220ms]
[checking class frank]
 [parsed .Guitar.java in 0ms]
 [wrote frank.class]
 [checking class Guitar] 
[wrote .Guitar.class] 
[done in 2640ms]

Peter van der Linden’s book Just Java has an excellent section on the Java compiler. I strongly suggest picking this book up.

Technical training

If the corporation is full of C++ programmers who have some experience programming with a GUI library, they will learn the essentials of Java rapidly. If the IT staff doesn’t know C++, but knows another object- oriented programming language, it might take them a few weeks to learn the essentials of Java. But it is certainly not necessary to learn C++ first before learning Java.

If the IT developers do not know any object-oriented language, they must learn the essentials of object-oriented technology before anything else, then apply this knowledge to the Java programming language. Object-oriented analysis and design (either a formal treatment or a common sensible one) should be taught before the syntax of Java is covered. Java programmers without a fundamental rooting in OOA/D will likely produce poor code. (That’s equally true of C++ programmers and Smalltalk programmers without a proper grounding.) Also, Java books are growing faster than political activism in Montana. At last count, there were 25 books out there, with 40 more expected to be available by July. There are also (at last count) 312 Web sites that cater to “Programming in Java,” with over 30 of these dedicated to “Learning Java.”

And since there is no perfect substitute for a human instructor, there are a number of good technical training companies available to teach Java.

Coffee brakes

Given my arguments above, should a corporation fully commit to Java for corporate mission-critical applications? At this point, a phased approach to Java adoption is suggested. More important than choosing Java or any programming language is the overall architecture of the application. Design your application so that it is composed of a series of servers on the back end and a client-side front end. Trendy IT managers will fervently (and tediously) debate the advantages of three-tiered over two-tiered or vice-versa, but the bottom line is that the application should be (process) modular in design.

Here are some suggested steps in moving towards adopting Java as an corporate technology.

1. Use Java for the client-side user interface; Java is certainly stable enough for the portable user interface. Use the most stable programming tools for the back-end servers, since they are the critical modules.
2. Port or create a non-critical server in Java so that both the client and server are both written in Java.
3. Use Java for an important corporate project for both the client and server.

The Intranet is growing faster than the Internet. Corporate computing is adopting the Internet methodology of providing solutions to their users and subscribers. Java has all the right stuff to be an invaluable tool for corporate applications development.

Letters from the ether

Here’s a letter from Eric R. Williams (eric.r.williams@ksopk.sprint.com):

I really enjoyed reading your “Java in plain english” in the March 1996 issue of

JavaWorld

online magazine

(http://www.javaworld.com/jw-03-1996/jw-03-java.intro.html).

I really appreciated the humor that you injected into the subject. In fact, I liked it so much that I am using your article to help me prepare for an intro to Java talk I am giving next week. Although I liked the article a lot, I wanted to let you know of two factual errors contained in the article. First, you state:

” … the DataInputStream and DataOutputStream classes utilize eXternal Data Representation to normalize your data to a network canonical format (in other words, your data can be used by many different types of processors and machines)”

Thanks Eric for catching this typo. It should have read “.utilize eXternal Data Representation concepts to normalize your data.”

The second factual error has to do with monitors:

“…Code wrapped with the synchronized keyword can be accessed by only one object at a time.” Not quite true. Monitors do not mark Critical Sections. Monitors are associated with object instances — not with blocks of code. For any given object, only one thread of control may be executing a synchronized method on that object. Other threads will block if they try to call a synchronized method on the same object. However, if a thread calls the same synchronized method on a different object, that access is allowed (since the monitor is associated with the object, not the code segment).

I should have been more precise in my wording. The synchronized keyword can be used as a monitor to mark critical sections of code associated with an object instance. Most of the time, for simplicity, the synchronized keyword is used on a method. But you can wrap code with it by specifying which object you want to lock to prevent simultaneous thread access. The below sections of code are equivalent.

    public class MyCounter 
{       int numA, numB;
        synchronized public void bump() {
            numA++;
            numB++;
        }
    }

Is equivalent to:

    public class MyCounter {
        int numA, numB; 
        public void bump() {
            synchronized(this) {
                numA++; 
                numB++; 
            } 
        }   }

Here’s some code that Eric was kind enough to include demonstrating the synchronized keyword:

// SyncMain.java
public class SyncMain {
     public static void main(String[] args) {
         Thread t1 =3D new Thread(new SyncRunnable(new Sync()), "t1"); 
        Thread t2 =3D new Thread(new SyncRunnable(new Sync()), "t2");
        t1.start(); t2.start();
        try { 
            t1.join();
             t2.join();
         } catch (InterruptedException e) {
            //
         }
     } 
};
 class Sync extends Object {
     public synchronized void SynchronizedMethod() { 
        String tname =3D Thread.currentThread().getName() + ": "; 
        System.out.println(tname + "in SynchronizedMethod."); 
        System.out.println(tname + "about to sleep..."); 
        System.out.flush();
        try {
             Thread.sleep(10000);
         } catch (InterruptedException e) { 
            //
         }
     }
};
 class SyncRunnable implements Runnable { 
    private Sync sync; 
    public SyncRunnable(Sync sync) { 
        this.sync =3D sync; 
    } 
    public void run() {
         sync.SynchronizedMethod();
} };