Let’s switch to Russian Java. What is it and why is it needed?
One of the most difficult tasks this year is adapting to new conditions of working with foreign vendors and the open-source community as a whole. Open-source does not solve all problems; in some cases it only creates them. At the same time, Russian development has features related to import substitution. All together, this left its mark on most classical software platforms and programming languages.
In 2023, UNITED TsUPIS transferred information services to the domestic Java platform with the support of its supplier. Currently, Axiom JDK Pro is used as the Java development and execution environment in the UNITED CUPI. Let’s look at the problems of this year through the eyes of the developers of the Java platform, and Oleg Chirukhin, a developer on the team of this distribution, will help us with this.
Open-source problems
Java is one of the best open-source development platforms. By going to Maven Central, you can find thousands of libraries that are installed with a couple of lines in pom.xml: their code is instantly available on GitHub and other hosting sites. All kinds of server software are located on Docker Hub and are launched with one command via docker run hello-world.
Unfortunately, this simplicity does not come for free. Most free software projects are not developed with security in mind. Even if they have their own security council, there is no guarantee that it will solve your specific problems. This does not matter when developing your own pet project, but it is very painful when developing large-scale projects on which the lives of millions of people depend.
When it comes to Java, there are many different horror stories to tell. Many people know about the Log4Shell vulnerability, which, when exploited in a certain way, to expand strings like ${prefix:name} can lead to the execution of arbitrary code from an arbitrary location on the Internet. But not everyone knows that only in CVE Database more than two and a half thousand vulnerabilities related to Java technologies have been registered, and about one and a half hundred of them connected with OpenJDK. Even fewer developers are aware that the number of issues in the OpenJDK project continues to grow, and the ratio of created to solved issues is heavily tilted toward unsolved ones.
Other technologies have no less problems. Hackers have gotten into the habit of deleting or corrupting files on the computers of developers who installed “infected” packages, and displaying propaganda or spam in text logs. Activists are removing support for Russian hardware platforms, closing the ability for Russian-speaking developers to commit upstream, and so on. Strictly speaking, there is no guarantee even that an arbitrary binary from the Internet corresponds to its source.
Sometimes problems arise not because of malicious intent, but because it “has happened historically.” For example, many people still use a base image like FROM openjdk in their Dockerfiles. If you look at official page this image on Docker Hub, it turns out that the first line there is: DEPRECATION NOTICE. In other words, this image is updated once every hundred years.
Anticipating the question: “Does this mean that Java is unsafe and should be abandoned?” No, that doesn’t mean it. Almost any successful project that has clients looks just like the picture with divergent solved and unsolved problems in OpenJDK. It’s just that someone needs to deal with all these nuances and respond in a timely manner to emerging problems.
Previously, such problems were solved by foreign vendors such as Oracle and IBM, but many of them stopped working with Russia. This in itself could be a huge problem if we didn’t have committers to the major software platforms: Java, Python, JavaScript, etc. Fortunately, such committers exist. There are even entire companies and teams dedicated to the development, support and security of software platforms.
One of these teams is the developers of the Russian Java distribution called Axiom JDK Pro. They have their own code base based on OpenJDK, which they develop and support for use in Russia (separate from the main open source OpenJDK project). The Axiom JDK team makes not only the JDK itself, but also a number of other products that together form an ecosystem for convenient and secure development. These same engineers have in the past ported OpenJDK to ARM processors, launched OpenJDK on Alpine, and done a lot of other useful work for the community.
State systems and CII
Critical information infrastructure (CII) is information systems that are critical for the state and society. They work in healthcare, industry, communications, transport, energy, financial sector and municipal facilities. These are the areas where software security requirements are most important.
In Russia there is a fairly developed system that allows us to talk about the use of software in such areas. For example, GOST R 54593-2011 defines the term “free software”, and Article 1286.1 of the Civil Code of the Russian Federation regulates the use of open licenses.
Programs are registered in several registries. In information systems of public authorities and at critical information infrastructure facilities, it is allowed to use only programs included in Unified register of Russian software or Unified register of Eurasian software.
Requiring the use of software from registries is a good idea to help meet government objectives. And this is well monitored. For example, if a CII entity is a financial organization and does not comply with the requirements of the law, then after an inspection by the Bank of Russia, measures may be taken against it, including the revocation of its license.
But switching to Russian software is necessary not only due to the formal requirements of regulators. Imagine that your production JVM crashes with an error and the message core dumped, and Oracle does not want to fix this error. What will you do next? This is not the class of problems that can be easily and simply solved by full-time Java developers. They need special JVM engineers, and while you are looking for them, the company will suffer losses. In the case of medicine, these are someone’s lives. Such problems happen extremely rarely, but even once can be very expensive for a CII facility.
Ecosystem Components
A Java application can be run as a standalone JAR file on a JVM as part of an application server, or compiled into an executable file using the Native Image utility. This can be done both on bare metal and inside a container or full virtual machine.
Ecosystem developers need to develop and support all these technologies: add features, fix bugs, monitor usability, ensure security, and so on. Application Java developers need to put them into practice and switch to the right solutions in a timely manner.
Axiom JDK
The most important element of the ecosystem for developers is the JDK, Java Development Kit.
Because all core Java technologies are strictly defined by working documents like the JEP and JSR, or ready-made language and virtual machine specifications, the process of migrating to Axiom JDK Pro is as simple as possible. You install the Axiom JDK on the system instead of the JDK from some foreign vendor (for example, Oracle JDK), and everything just works. When you upgrade to Axiom JDK Pro, you receive commercial support and timely security and functionality updates.
At the same time, Axiom JDK Pro works on both foreign and Russian processors (Baikal, SKIF, MCST SPARC, developments on RISC-V) and operating systems (Rosa, Alt Linux, RED OS, Astra Linux). All major LTS versions are supported: currently 8, 11, 17 and the recently released 21. In addition, you can even agree to support legacy versions: 6 and 7 (but it’s better to run your software on 8+).
Whatever subsystem you are developing, maximum security is a must. Axiom JDK Pro is developed in accordance with the SDL (Secure Development Lifecycle) concept and before each release goes through strict quality control, including structural, static, dynamic analyses, regression and PoC testing and other tests.
The most important tool is the Svace static analyzer from ISP RAS, thanks to which hundreds of thousands of analyzer detections are found in the OpenJDK code, from which engineers manually select the most important ones and those that require more thorough analysis. Using this approach, 26 defects were discovered and fixed in JDK 8, and 22 in JDK 11. Defects continue to be found in recent versions of Java.
Of course, regression tests are used that can run for tens of hours, sanitizers like ASan (memory leaks) or UBSan (undefined behavior). For fuzzing For native code, AFL++ is used, and for Java code, JQF and Jazzer are used. In general, a full range of tools and approaches are used that allow you to find even the most cunning bugs.
As a result of this work, a separate product appeared called Axiom JDK Certified, which is certified by FSTEC at level 4 of trust, which allows it to be used at CII facilities where an increased level of security is required in accordance with FSTEC requirements.
The Axiom JDK team advises all developers of security-critical infrastructure to organize an SDL process (Secure Development Lifecycle) and implement similar technologies. It’s not easy, but you can start moving towards your goal in small steps.
Application server: Libercat
The application server is a classic Java Enterprise Edition. Application servers enabled ideal DevOps even before Kubernetes was born. Shared configuration, shared libraries, shared deployment, shared start/stop control – very convenient. More precisely, it was convenient until the vendors of the main application servers left Russia.
In response, the Axiom JDK team released the Libercat application server in two flavors: Libercat and Libercat EE. The first is a servlet container (analogous to Tomcat), the second is a Java EE application server (analogous to TomEE +). Libercat EE supports more than 40 Java EE and Jakarta EE specifications.
These are Russian application servers that solve the problem that Oracle and IBM products have left the Russian market. If you’ve written your application strictly according to these specifications, then migrating to Libercat can be quick and easy.
If you delve deep into private APIs or use proprietary technologies without open source, this can lead to significant amounts of code being rewritten. There is nothing you can do about this; the painful rejection of vendor lock-in is a feature of working with proprietary technology, but Axiom JDK engineers will support you with migration.
Containers
Here I would like to talk about three elements of the ecosystem at once:
Axiom Runtime Container,
Axiom Linux
Axiom Native Image Kit.
The transition to the cloud, Docker, Kubernetes and related technologies radically simplifies infrastructure support, but there are nuances. The clouds are not free. Docker images take up an impressive amount of disk space, RAM, and load the network. They interfere both on production and on developer computers. No one likes a long image pull and a hard drive full of Docker cache.
Reduce image size There are two ways: either reduce the size of the base image, or the size of the application inside it. What can we do if we take the first path? Should I use a smaller image like Debian Slim? But here’s the problem: although Debian Slim is significantly smaller than the full version of Debian, it is still quite massive. We can go ahead and try distroless image. Unfortunately, this is the other extreme: they are very difficult to debug because there are no debugging tools and setting them up can be hell. For example, for distroless from Google you need to edit tricky configs in bazel.
Axiom Runtime Container base images were developed specifically to solve this problem. These are some of the smallest Java containers on the market (about 40 megabytes, size depends on distribution and Java versions). They can also provide improved performance compared to classic Java container images. According to test results, an application running in the Axiom Runtime Container can use up to 30% less RAM than in a container with vanilla Debian Slim and the “official” Docker Hub image (remember, do not use it, it is outdated and not supported) .
Migration to these containers is usually very simple: you just need to replace the name of the base image in the FROM field. Problems can only arise if you used some additional packages and settings, and here Axiom Linux’s own package repositories will come to your aid, very close to Alpine in structure and package names.
All this became possible precisely because Axiom JDK engineers were once involved in porting OpenJDK to Alpine. Unfortunately, Alpine itself was not the best system, because it is supported by an open community that does not particularly care about security and optimization of Java code execution. This is how Axiom Linux was born – a dedicated Linux server distribution initially based on the Alpine codebase. It is the world’s first distribution that is specifically optimized to run Java. The secret of how it saves memory and CPU is very simple to explain, but very difficult to implement. The Axiom JDK engineers looked at what musl libc functions were used in Java and optimized all the important parts of musl for them. The result is a modified musl called musl-perf, which is included with the Axiom Runtime Container.
The second way to reduce the size of an application and speed up its launch is to use Native Image technology. This is a compiler that turns Java code into executable files (on Windows these will be .exe files). Such files do not need to warm up the JVM; they are launched instantly along with the container. In the Russian Java ecosystem, the implementation of such a compiler is Axiom Native Image Kit, built on the basis of GraalVM CE with some modifications. It is important that acceleration from Native Image involves the need to change the application code. Most importantly, such applications cannot use Java Reflection and similar APIs. Rewriting legacy without Reflection is extremely difficult, so Native Image is usually used for new code, especially using modern frameworks like Spring Native, Micronaut, Quarkus.
conclusions
Despite the difficult challenges of this year, Russian developers have every opportunity to be well prepared for the near future. The Java platform ecosystem is well designed, which allows for a relatively painless transition of the infrastructure to solutions from domestic vendors, including Axiom JDK.
The Russian Java ecosystem has the most important technologies for migration: JDK, application server, base images for Docker, Native Image compiler, and even its own containerized Linux, optimized for running Java code.
In the future, we plan to share details of the use of various aspects of the Russian Java ecosystem and tips on their use, as well as on migration from foreign products.
Of course, you can go both ways at the same time and put the application built by Native Image directly into the Axiom Linux container.
