Migration paths: Replacing Java for internally developed programs

Keep these options in mind so you can make an informed decision on the best path forward to modernize your Java program.

Due to the recent concerns with the inherent security problems in Java, and new vulnerabilities popping up days after patches are issued, Java's reputation has taken several critical hits this year. Many organizations, such as the Department of Homeland Security, are advocating disabling Java in the browser; others are uninstalling Java altogether. These measures are sensible for organizations that do not have an extensive reliance on Java, but Java is very much entrenched in IT. One program integral to a business may be standing in the way of uninstalling Java from workstations; however, with the growing concerns about Java, it may be cheaper to port the program and uninstall Java than to continue spending time applying security patches.

It can be cumbersome to find a proper one-size-fits-all solution for converting Java applets to a more scalable platform. With the varied uses of Java that currently exist, the following proposed migration paths away from Java are best handled on a case-by-case basis.

Tool-assisted porting saves time and frustration

Many new programmers cut their teeth on Java, and bearing that in mind, it is reasonable to expect that desktop applications may be written in Java out of convenience. Fortunately, this is the easiest scenario to work around.

If you have a Java application that doesn't need to go anywhere near a web browser, the Java to C++ converter from Tangible Software Solutions can translate your existing code from Java to C++. It outputs a comprehensive list of things it cannot translate, and combined with your IDE of choice, you can make quick work of where the converter left off. The downside to this path is that the converter can generate an excessive amount of code to perform a task, though these issues tend to reflect the original code, and can be far worse between programming languages that share less in common than Java and C++. Additionally, the cost of the program ($119 USD) may send users into sticker shock, but this is a far cry from the cheap (and often useless) mobile apps we plunk down a dollar for without a second thought.

Maybe you don't really need an applet after all

In all fairness, if your business has a dependence on any Java applet, it was probably designed years ago in a world where Internet Explorer 6 reigned supreme. Since then, JavaScript has made a great deal of progress in the variety of features it possesses and performance inside of a browser. With advancements such as HTML5, and frameworks like jQuery and Enyo, you can do more in a basic webpage than ever before. Abandoning plugins altogether also allows for greater flexibility of devices, as browsers for iOS, Android, Windows RT, and BlackBerry 10 are all capable of supporting these technologies.

Best case scenario: Google Chrome and Native Client

Google Native Client (NaCl), the initiative to provide a secure sandbox for C++ code, is showing considerable promise. As an example, popular programs such as Quake and Quickoffice have been ported to NaCl, and operate as swiftly as they would outside of a browser, besting the performance of Java applets by far. In addition, it supports hardware-accelerated 3D graphics using OpenGL ES 2.0.

Combined with the Java to C++ converter, you can make a seamless transition from Java to NaCl, with your code operating in the same way it does now, without the intensive task of re-engineering everything to HTML5, jQuery, and Enyo. Plus, NaCl apps work perfectly on Chromebooks, even ARM-based Chromebooks, which could then be used as an inexpensive, mobile workstation replacements.

A downside to this strategy is Google Chrome and the open-source variant Chromium are the only browsers at present that support NaCl. Advocating for a solution that only works in Chrome, while it is standards-compliant, is no better than locking users in to Internet Explorer 6. Another drawback is the project is new and somewhat experimental, though it is stable enough for a production environment; customization to Chrome is needed to run applications directly at this time. As the technology matures, this restriction is likely to be lifted in the near future.

NaCl is a best case solution only for instances in which processor-intensive tasks must be run inside the browser. Although support for NaCl is limited to Chrome and the open-source Chromium variant, there is a possibility for other browsers to implement the feature. Among these is Opera, which recently stated an intention to transition from Presto (its internal rendering engine) to Blink, which is the fork of WebKit maintained by Google. The primary difference between NaCl and IE6-locked websites is that NaCl is just packaged C/C++, which is standardized and portable, and can be modified with ease to run on the desktop. IE6-locked websites are not based on a standard, but on the poorly documented behavior of IE6, which is itself not built to comply with standards, but to the whims of Microsoft.

The old standby: Netscape Plugin API

The Netscape Plugin API (NPAPI) is aging, it is not a great solution overall, and it has the potential for security issues, but if you need the computational power on workstations inside of a web browser and cannot be locked in to Google Chrome, it can be a serviceable solution. If the program being ported is intended for internal use only, with careful planning and cautious programming, you can make a secure and user-friendly plugin. To maintain compatibility with Internet Explorer, you can rely on this utility for using NPAPI via ActiveX.

Worst case scenario: Adobe Flash

The problem with Flash is the poor reputation of the platform. In spite of the bad PR for draining batteries on mobile devices, and the late Steve Jobs' dissertation on the shortcomings of the platform, it still has a wider install base than Java. While this makes Flash a legitimate target for desktops and laptops, the availability of Flash on tablets and phones is decidedly lacking. Windows RT added support for Flash in March 2013, except for websites blacklisted by Microsoft. Android dropped support for Flash after Ice Cream Sandwich, and the platform is unavailable for iOS and Windows Phone. The only platforms for which Flash is fully available are the BlackBerry PlayBook and the abruptly discontinued HP TouchPad. In addition, Adobe's support for the platform is waning across the board.


With these options in mind, you can make an informed decision on the best path forward to modernize your Java program. Oracle's stewardship of the platform has been markedly disappointing, but with the array of options presented in this article (excuse the pun), even management should be convinced by the easy and cost-effective solutions you recommend.

Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.


James Sanders is a Java programmer specializing in software as a service and thin client design, and virtualizing legacy programs for modern hardware. James is currently a student at Wichita State University in Kansas.

Editor's Picks