Life In Javaland

April 14, 2014 Dan Burger

Not every business problem is solved by the cloud or managed service providers or social media. That’s just like saying not all IBM i application development is dependent on a single language. Both statements are more true than false, but as has often been pointed out to me, each case is different. However, the commonalities are still to be found despite the ever present differences of opinion. How about application development from the Java point of view? Is it better or just different?

Last week I talked with Paul Holm about Java development and how he would describe the typical Java development environment in IBM midrange shops. Holm’s company, PlanetJ, helps companies solve business problems with Java. He works with a lot of IBM i shops, but not exclusively with IBM i shops. He recognizes it is a multi-platform world and is recognized as a Java subject matter expert. His qualifications are 12-hour days, six-day weeks, and 15 years in and out of shops around the world. Most of the companies Holm works with have the intent of trading green-screen, text-based applications for apps graphical user interfaces. That would be the same target as a lot of IBM i shops that don’t live in Javaland.

Rather than talking about the differences among languages like Java, RPG, CGI, PHP, and COBOL, let’s look at the similarities. For example, Holm sees a lot of JavaScript, HTML, and jQuery taking on the tasks of connecting back end logic with the front end popular interface.

Does that sound familiar whether you develop in Java or not?

JavaScript, HTML and jQuery don’t care what language was used to develop the backend logic. That’s why they are popular. And that’s one reason why Java programmers have some commonality with all other programmers in IBM i environments. It is a good thing when Java programmers are knowledgeable in JavaScript, HTML and jQuery. But guess what? They usually aren’t. Just like any other IBM i developer who has been building backend applications, these technologies have to be learned. And just like any other IBM i developer, it can be a struggle. This sounds pretty similar to what is happening with RPG developers.

“It’s a big challenge for Java shops to get the new skills,” Holm says based on his observations. “What I see is a division of labor that is common in green-screen to GUI projects. The backend developers concentrate on business logic and database connections. The front end UI developer is a different person with different skills.”

In many of the companies where Holm and PlanetJ are brought in, it’s because they are providing the front end skills. “That technology is where all the action is in the Java Web development world,” he says. “People are pouring a lot of energy into utilizing newer technologies to produce advanced IBM i applications.”

The top priority for Java green-screen developers is the backend, Holm observes, because there is a lot of work to be done on the backend.

“We are seeing the size of databases grow dramatically and we are dealing with many times the number of records that we used to see. And in a lot of cases,” he says, “there are no database administrators in IBM i shops. So in Java shops it’s a Java back-end guy who has to learn about things such as SQL optimization, index creation, and access path reuse. Often these guys put together their first SQL statement and wonder why it rakes 30 seconds to run. He finds out quickly that the database needs to be optimized.”

Java developers need to know how to optimize the database, Holm emphasizes. They have to handle the front-end requirements by building backend to serve the data dynamically in a multi-threaded fashion. They are doing a lot of work with Web services serving JSON to the client.

“It used to be more of an XML world,” Holm says, “but JSON has overtaken XML from what we’re seeing. JSON is a lot cleaner, easier to work with, and less bulky. JSON has become the preferred encoding, but going from XML to JSON is not a huge conceptual leap.”

Another lesson learned by Java developers who are taking their first voyage from green screens to GUIs is the expectations that Java apps will have multiplatform capabilities.

“We see a lot of need for cross-database access. Java excels at this,” says the Java evangelist. “It’s common for us to go into multi-database companies that have DB2 for i, SQL Server, and MySQL. Having applications that access data from more than just DB2 on i happens all the time.”

That is a business process that becomes increasingly important as the tentacles of IT sprawl reach out in every direction. Although Java’s reputation is founded on the capability to execute on any platform, it has also been dogged by many IBM i advocates for its unsatisfactory performance on the platform that dates back to the AS/400 days. Performance has improved with each version of Java, the Java Virtual Machine (JVM) and with the more potent Power Systems servers that have rolled out in the Power7 and Power7+ era.

That doesn’t help companies that aren’t on the latest and greatest hardware and software though, which is where many IBM i shops do their work. That means tales of workloads being shifted off the i abound. On the other hand, in shops that have the new goods are, in some cases, moving workloads from underutilized X86 servers to the IBM i platform.

In theory, a shop should be able to move apps across servers whenever and wherever the workload can be handled best. The JVM, where the app is executing, has its own attributes of optimization and will handle most of what is necessary when moving apps from one platform to the other.

The difference between theory and action is sometimes a great leap–possible but it would be wise to get a running start.

It is surprisingly easy to move apps from one OS to another, Holm says. But there are some considerations to take into account. For instance, it may be necessary to change JDBC drivers, so it is operating natively rather than in toolbox mode. Also, there are considerations based on the version of Java and the JVM being used.

“You do have to have parallel environments,” Holm notes. “If you are using Java 7 on a Windows platform and utilizing APIs from Java 7, you will need that same Java JVM and JDK on the IBM i.”

Holm sees the great majority of IBM i shops where he works using JDK 6. Other platforms tend to be ahead of IBM i because they get the JVMs quicker, so on Windows and Linux platforms Java 7 is more common than 6. And very shortly Java 8 will be introduced.

IBM currently markets two JVM options, but an older version, commonly referred to as Classic JVM, is also in use at many shops. It is not supported on IBM i 7.1. The two JVMs with IBM support are a 32-bit version and a 64-bit version. Both run in the PASE (AIX) runtime environment that has been bundled into the operating system for many years. The Classic JVM ran as a native program.

There is an open source JVM, called OpenJDK, but Holm says he doesn’t know of any shops that use it.

In terms of Web serving, the IBM i is capable, but rarely used in that capacity.

“Seven out of ten times a company will do its Web serving on Intel not IBM i,” Holm says. “IBM i customers can be reluctant about putting their systems on the Internet. They’ll set a Windows server in the DMZ and lock down the ports so only this one server can access the IBM i. Then they set up a firewall and it’s a secure architecture without putting the IBM i system on the Internet.”

This leads to the topic of WebSphere, where seldom is there heard a discouraging word–but that’s only if you are talking to an IBMer. In the user community, it’s a different story. WebSphere has disappointed a great many users who have been plagued by quality issues and poor performance.

Holm will not dispute that.

“IBM WebSphere has been a poor product,” he says without hesitation. “Usability and quality has left a lot to be desired and IBM has struggled with it. It is difficult to work with. It’s buggy and performance can be bad. We have had tremendous success with Apache Tomcat, an open source option that can be installed directly on IBM i. It performs well and has for 15 years.”

After the smoke and mirrors are put away and the marketing promises have had time to be proved or disproved, it seems the day-to-day duties of a Java programmer in an IBM i shop is not appreciably different than the RPG programmer or any other member of any development team. It’s not nearly as much “us versus them” as you might have been led to believe or that you believe on your own accord.

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search