Java just turned 25 – and continues to encounter major roadblocks

On May 23, 1995, Sun Microsystems – then a company reasonably well-known within tech circles but obscure from the average person's perspective – introduced the Java programming language into its product catalog. Now, just over 25 years later, the code – which has been available for open-source use since 2006, according to InfoWorld – has been used by enterprises and independent developers all over the world to create countless applications.

Of the major programming languages still in use, only C, C++ and the earliest versions of Python predate it, and developers have certainly made many successful programs with it for multiple operating systems. But it's also critical to acknowledge how Java and many of the apps it's been used to make have been plagued by glitches and flaws throughout its entire life span. (This is why Sun's original slogan for the language – "write once, run anywhere" – is often snarkily altered to "write once, debug everywhere," as far back as in Electronic Design magazine articles from 2002, and likely before that.) It's critical to examine both recent and longtime Java problems before using it as part of any legacy modernization projects your company might be planning.

Cisco call-center system security failure illustrates recent Java issues

For the sake of immediate relevance, let's start with a very recent Java flaw. According to ZDNet, Cisco Systems announced on May 21, 2020, that its Unified Contact Center Express platform, intended for small- or medium-sized call centers of 400 or fewer agents, had a major vulnerability in its remote management interface, which runs on Java. The telecommunications giant urged all Unified CCX users to immediately update their software to version 12.0(1)ES03 or an even newer release to rectify the issue, as no workarounds were available. It elaborated on the matter in an official statement:

Woman in black sleeveless top working in call center, wearing telecom headset and typing on keyboardUsers of a popular Cisco call-center platform are among the latest to be put at risk by flaws stemming from Java code.

"The vulnerability is due to insecure deserialization of user-supplied content by the affected software," Cisco explained. "An attacker could exploit this vulnerability by sending a malicious serialized Java object to a specific listener on an affected system. A successful exploit could allow the attacker to execute arbitrary code as the root user on an affected device."

At the time of that statement, Cisco had not learned of any cyberattacks mounted against organizations that were actively using Unified CCX. However, even though the window may have closed for malicious online actors to exploit that particular vulnerability, it once again reflects poorly on the security of Java-based apps. Per the criteria within the most recent version of the Common Vulnerability Scoring System, the glitch scored a 9.8 out of 10.

Historic problem areas

Matters of the code's security typically command the biggest Java-related headlines throughout media outlets focused on the tech sector – with good reason, due to the urgency of cybersecurity and the tendency for developers and security consultants to find exploitable flaws in Java-based apps. But throughout its history, users have also noted several other major issues with Java-created programs: sluggish start-up, slow time to peak performance and a problematically large memory footprint, as noted in a separate InfoWorld article. 

The piece did point out that a hypothetical update, proposed in late April on the message board for Java Development Kit Users, could significantly mitigate these issues, simply by ensuring that Java Standard Edition and the JDK would create programs only as standalone entities known as "static images." Doing so would, in theory, cut down on startup time and improve runtime. Mark Reinhold, Oracle's chief architect for its Java platform group, devised this framework, known as Project Leyden.

It remains unclear if Leyden will be integrated into Java SE and the latest JDK. The earliest this could occur is September, when Oracle plans to release JDK 15. Additionally, by Reinhold's own admission, the "static image" program development style is not suitable across the board, so plenty of coders will still have to deal with these limitations of the language.

An uncertain future

Hanging over every Java issue is the language's place at the center of a years-long copyright dispute between Oracle, which acquired Java alongside the now-defunct Sun in 2010, and Google, which used various Java APIs in its creation of the Android mobile operating system. Per the Electronic Frontier Foundation, the case now sits with the U.S. Supreme Court after Google's petition for certiorari was granted in November 2019. (Various state and federal court decisions veered back and forth in favor of either party, dating back to 2012.)

Facade of Supreme Court building entrance.The Supreme Court will ultimately decide whether Java is truly open source.

Actual case arguments, however, will not take place until October 2020, according to SCOTUSBlog, as most Supreme Court business is on hold due to the COVID-19 pandemic. Google will likely maintain its claim that use of an open-source code's APIs constitutes fair use, which Oracle contests; if the latter is ultimately victorious, Java's utility to developers could be significantly reduced. 

Here at the Inventu Corporation, we equip organizations of all sizes with a revolutionary terminal emulation tool called the Inventu Viewer, a high performance emulation solution that is built with C at its core. This solution allows developers to craft reliable and safe software using clean HTML and JavaScript hosted on secure Windows servers. All in all, the Inventu Viewer supports streamlined IT modernization and meets employer and staff expectations in a way that feels both familiar and simple. Contact us today or review our extensive product catalog to see how Inventu can help you rid your servers of unsafe Java with a server product built over decades in the ever-reliable C language.