Apps

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.

Conclusion

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.

About

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 an education major at Wichita State University in Kansas.

15 comments
flotsam70
flotsam70

<sarcasm>Thanks for doing the community a service by spreading this misinformation.</sarcasm>

mikes
mikes

Consider a project with the following requirements: 1) Must run on Windows, Mac, and Linux, with a GUI. 2) Must be able to connect directly to MS SQL Server. 3) Must maintain a single codeset for all platforms. I would be interested in hearing from readers, and perhaps the author, what language other than Java meets these requirements.

kschroiff
kschroiff

First of all a project propagating an architectural change for little reason will usually not get any funding from the stakeholders. Nicer architecture is no business benefit. No benefit, no money. Java security is not a sufficient argument for most if the fix is as easy as an automated update. A viable migration approach (assuming that there is a business benefit from new features or whatever) is not so much a different technology but moving the Java business logic to a server and do a new front web end. Java is then where it belongs and where it's good - on the server side.

wdewey@cityofsalem.net
wdewey@cityofsalem.net

Flash has as bad as a reputation as Java. Why do you think this would be an improvement? Bill

thisaintmyemail
thisaintmyemail

Fantastic suggestions on how to migrate from a Java app to alternate solution!

JamesAltonSanders
JamesAltonSanders

My intent in the article is to highlight a variety of migration paths from Java applets to other solutions, for web interfaces / SaaS. This is why I'm discussing things such as Flash, NPAPI, and NaCl. Handling applications, particularly with extreme requirements such as the ones you have outlined, is beyond the scope of the article. The only thing I can think of that isn't Java to be able to handle your stated requirements would be handling the problem in a browser, with the heavy lifting done in C++ on the server side, with a web interface employing jQuery, Enyo, or whatever else you prefer. But now you've piqued my interest, what are you doing that requires a program to run with a GUI on Linux to interact with a MS SQL server?

333239
333239

C++? Qt? JavaScript? Mono? Delphi? There is always a choice, Java may be best for your application but all of these have their pros and cons.

kcs
kcs

If you ignore #2: C, C++, Python, Perl, etc. #2 seems a bit contrived to me. If I really had to be cross platform and use MS SQL I would have a middle layer and expose everything via web services.

JamesAltonSanders
JamesAltonSanders

Your claim that Java security is an insufficient argument is intriguing, as on at least one occasion this year, a vulnerability is found on the same day that Oracle pushes the update. If patching was a sufficient solution, DHS wouldn't be advocating for disabling Java in the browser. However, containing Java to the server side of the equation is commendable; Java EE really isn't the problem, and the poor handling of security on the desktop contaminating the reputation of Java EE is regrettable.

kcs
kcs

> Java security is not a sufficient argument for most if the fix is as easy as an automated update. Well, not necessarily true. It all depends how much testing you have to (are forced to) do. If you have to deal with compliance issues and you have testing requirements it can be a lot of work especially when patches are released back-to-back like they have been recently. Agree 100% to keep Java in the back and redo the front end.

Matt Nawrocki
Matt Nawrocki

The only reason that Flash would make sense is if you wanted to target a somewhat larger install base. Obviously, the other options listed before Flash are superior choices, as the author states.

mikes
mikes

Our company's ERP system is from a Microsoft parter and is written to run on Windows only, with a SQL Server back end. Many of our users, however, especially executives, are insisting on using Mac desktops and laptops. Many of our servers are Novell SLES. We've written a lot of supporting applications over the years in a variety of languages. There is a push now to consolidate all these supporting applications into a single codeset using proper MVC patterns. The next step is to extend the capabilities of the ERP system by allowing the Mac users to perform their tasks with a native client as opposed to being forced to run through a remote desktop. The Linux portion is more icing on the cake as for as the GUI is concerned, as most of the server tasks would be headless or console applications; however, there has been some chatter about deploying Raspberry Pi in the warehouses. There are a number of languages that support FreeTDS to connect to SQL Server; but few of them do so natively or seamlessly. The Mac GUI requirement is also quite limiting. I was going to use Carbon, which has been wrapped by a number of lanugages, but the latest versions of MacOS have eliminated support for it, leaving only Objective-C or a browser as an option. The browser option is less preferable because the MacBook users want to be able to do their work off the network and sync up when they get to the office or VPN. This may sound crazy to the IT crowd, but executives don't want to be bothered with the details. They just want to work in the way that's most efficient for them, and everybody has competing requirements. Java was really the only answer I could find that could satisfy everybody.

wdewey@cityofsalem.net
wdewey@cityofsalem.net

The point of moving off of Java is that it was insecure. If your going to another insecure platform why spend the time, effort and money to move? To be quite honest your better off with an insecure platform that you know then an insecure platform that you don't know.

kcs
kcs

I don't know your environment and what you have to deal with but it sounds like you are still thinking about doing things the "old" way were an app talks to the database directly. I would build a web services middle layer. That way the new front end can be whatever you want, PHP, ASP.Net, thick app, etc., and just consume and call web services. The front end does not need to know or care about that the underlying database is and doe snot need to have any sort of driver to talk to SQL. We did this for a client, were the databases are SQL and an old proprietary Unix system. The middle web services layer is in .Net. We have a web site on Ubuntu/Apache/PHP, a new Windows based ERP system, custom thick utilities written and internal web site in .Net. Everything passes through web services "proxy" and it removes all the work and nonsense about what platform you communicating to/from. So then you can focus on the data and the GUI. You should be able to do a nice web app that way that can run a modern browser make the MAC users are happy. Especially since executive types are usually more concerned about reports not data entry. Look at MVC, jQuery, Bootstrap for that aspect.

Editor's Picks