Early in 2020, Oracle put the finishing touches on Java 14 – the latest version of the Java Development Kit, used to create applications with the open-source programming language the developer has owned and overseen since 2010. Upon its release to the public in mid-March, JDK 14 was almost immediately showered with considerable praise by its supporters, and even some of its former critics joined in the feting of the coding kit: In a sponsored post for Forbes, Oracle quoted Agile Developer founder Venkat Subramaniam complimenting the more streamlined nature of the latest JDK version.
"I am one of those folks who constantly complained that Java is verbose," Subramaniam said, according to the financial news and commentary provider. Referring to new JDK additions like Records, a function added to improve the language's data modeling capabilities, he added, "Java 14 removes so much noise in code … These features remove boilerplate code and make code highly expressive, and intuitive – easy to both write and maintain."
In keeping with the habit of releasing a new JDK every six months (which has been standard operating procedure since Java 9 in 2017, as noted by ZDNet), Oracle already has gotten the ball rolling on Java 15, and plans to release it in September 2020, according to InfoQ. But when considering it as a tool for legacy application modernization, it's important to ask: Does JDK 14 address the issues of security that have dogged numerous Java tools in the last several years – and even if it does, is this indicative of a major shift in the code for other products?
Improved focus on security
Taking a closer look at the new additions to the JDK framework within the 14 release, it does appear that developers took time to address operational security with some of the kit's specific new features.
For example, InfoWorld noted that the addition of pattern matching to the development kit's instanceof operator allows for the conditional extraction of components in objects within a program to be handled more concisely, avoiding some of the repetition of certain coding tasks that had been necessary in the past. This change within the operator, through its streamlining of processes, reduces opportunities for errors to be made, which inherently benefits overall security by reducing the likelihood that a programmer will make a mistake in the code that can later be subject to an exploit. (Pattern matching is a preview feature for now, slated to be finalized in future JDK releases.)
Another of the JDK's major new features in this release is the ability to handle foreign-memory access via a new API. Ordinarily, the development kit's forays into memory outside of the core Java repository (elsewhere in the host machine, or on the network) could be a somewhat dangerous process, carrying with it the potential for damage to the heap and the Java Virtual Machine at the JDK's core. Revisions to the source code have perfectly delineated memory deallocation so that foreign memory won't interrupt JVM processes at any critical juncture.
Certain vulnerabilities remain an issue
Most of the excitement around the latest JDK release has nothing to due with its security. Additionally, the true believers of Java – those who have made it the most popular programming language, per ZDNet – have always considered it a secure coding framework as long as it is regularly patched.
The question of security becomes more complicated when you look at the coding language's Standard Edition, which is what many of the most common Java applications among personal and enterprise users are made up of. As reported by ThreatPost, Oracle's Critical Patch Update Advisory for April featured 405 vulnerabilities across more than 20 products, including 15 in Java SE (up to and including its most recent versions). While most of the SE flaws patched in this bug were minor, it still noted two vulnerabilities with an 8.3 rating on the CVSS Version 3.0 scale, one with an 8.1 score and another with 7.5. (Numerous other Oracle products, including Oracle Financial Services, Fusion Middleware and MySQL, were far worse off with multiple 9.8 vulnerabilities).
The two most critical flaws in Java SE were with the coding platform's libraries – which have long been a source of frustration to programmers using Java. Jaxenter pointed out that external libraries are essential to the operation of most Java platforms, but often do not get audited by developers for vulnerabilities as soon as they're added. But other, bigger problems with Java also go unaddressed in these SE updates and JDK releases, ranging from ramshackle encryption libraries that hackers can easily compromise to lax management of application secrets. Organizations with a mind for digital transformation may be best off opting out of Java altogether.