A Java application is deployed in a platform-independent deployment format called Byte Code. Byte Code is commonly packaged and shipped as a collection of “.jar” files. The compilation and packaging of Java source code into JAR files is a comparatively lightweight process that does not create a classical CPU and OS dependent binary. To run a Java application, a platform-specific Java Runtime Environment (JRE) or Java Virtual Machine (JVM) is required.

The vendor or creator of a Java application may choose to bundle the application with a JRE for a specific platform or ship only the platform-independent Byte Code and leave the choice of JVM to the operator.

As Java is fully standardized, the JVM (within a major version) is interchangeable and the Java application OS and CPU independent for a correctly designed and standard compliant Java application. No recompilation is required in any case.

Key concepts of Java

• Java. The programming language as standardized in the Java SE standard.
• Java source code. A collection of files with the .java extension. Java source code is compiled into Byte Code.
• Byte Code. Platform independent code which can be run on a JVM. The most common package format is “.jar” files. Other languages like Scala or Kotlin can run on the JVM when compiled into Byte Code.
• JDK (Java Development Kit). The collection of standardized tools, such as the Java compiler, to write Java applications.
• JRE (Java Runtime environment). The smallest type of JVM bundle. Used to run Java applications.
• JVM (Java virtual machine). A runtime environment to execute Java applications shipped in “.jar” files. The smallest Java SE compliant JVM bundle is the JRE.

JDK

Java Development Kits (JDKs) are implementations of the Java SE platform specification by different vendors and groups of people, such as the open source community. Some of them are built from the OpenJDK code on GitHub. JDKs include the Java Runtime Environment (JRE), as well as other tools that help you develop Java.

JRE

The Java Runtime Environment (JRE) is the minimal component of the JDK that is required to run Java.  Since Java 11 the JRE is a part of the JDK itself rather than a separate entity meaning you can no longer download it separately.

JVM

The JVM is the core of the runtime environment. Although colloquially use as a synonym to JRE, strictly speaking the JVM does not include the API libraries.

The JVM defines a consistent object, memory, garbage collection and threading model for executing the semantics defined in byte code. Other languages have been defined making use of the JVM semantics relying on the Java APIs more or less. E.g the Android Runtime follows the JVM model but is not Java SE compliant (also it tries to be, to make the life of Java developers easier on Android).

Other articles

https://foojay.io/blog/openjdk-jdks-and-every-java-acronym-in-between/

The post Basic Java Concepts appeared first on foojay.

Introduction

A compact profile is a subset of the full OpenJDK. Because they have smaller storage footprints, compact profiles allow many Java applications to run on resource-constrained devices. Choosing a profile that closely matches an application's functional needs minimizes the storage devoted to unused functions.

Compact profiles address API choices only and are not related to the Java virtual machine, the language itself, or its tools.

Three compact profiles exist: "compact1", "compact2", and "compact3". Each compact profile includes the APIs of the lower-numbered profiles. For example, "compact2" is a superset of "compact1". The full OpenJDK is a superset of the "compact3" profile.

The table below shows the high-level composition of each compact profile:

<sup>1. Adds kerberos, acl, and sasl to compact1 Security.
2. Adds crypto to compact2 XML JAXP.</sup>

JDK 8 tools with explicit support for compact profiles are the following:

• The javac compiler: The -profile profile option directs the compiler to flag usage of an API not present in profile.
• The jdeps static dependency analyze: The -profile option shows the profile or file containing a package.

Details

The table below lists the API packages in each of the compact profiles.

The post Compact Profiles appeared first on foojay.

Overview

Almost all Java users have been used to regular public updates being made available for the JDK, by Oracle, free of charge. These have always been for the current release and often for the previous release as well. This was thanks to an overlap to ease migration to the latest version.

There are now a number of providers of OpenJDK binaries. However, Oracle only upstreams the source code for each update’s security patches and bug fixes into the current OpenJDK project repository. How these changes get into older versions requires other members of the OpenJDK community to do the work of backporting. To make things more complicated, we have to deal with two three-letter acronyms for the updates: CPU and PSU. Both of these are terms used specifically by Oracle and are used across their whole product range, not just for Java.

CPU

A CPU is a Critical Patch Update, and the key term here is "critical". Java SE Critical Patch Updates (CPU) contain fixes to security vulnerabilities and critical bug fixes.

On foojay, fixes to security vulnerabilities and critical bug fixes are visualized and analyzed:

Go here for further details.

PSU

A PSU is a Patch Set Update and is a superset of the CPU. Java SE Patch Set Updates (PSU) contain all of the fixes in the corresponding CPU, as well as additional non-critical fixes.

On foojay, the quarterly non-critical fixes are visualized and analyzed:

Go here for further details.

The CPU has an odd number, and the PSU is even. This explains why there was JDK 8u201 (CPU) and JDK 8u202 (PSU).

What is the release cadence of CPUs and PSUs?

CPU releases are scheduled for release on the Tuesday closest to the 17th day of January, April, July, and October under the normal Oracle Critical Patch Update schedule.

What does this mean for deploying updates for your Java applications?

If you want to ensure that your systems are as secure as possible, it is crucial to deploy the CPU as quickly as possible (assuming it contains fixes for security vulnerabilities with high CVSS scores). Since this includes a smaller number of changes, it should be safe to deploy the CPU with minimal testing (essentially ensuring that this does not prevent an application from starting up).

Having ensured the security of your applications is up to date, the PSU can then be used for more rigorous, full regression testing to ensure stability before deploying into a production environment.

The post CPU and PSU appeared first on foojay.

Java champions are nominated and voted for inclusion by the community of Java Champions.

Requirements for acceptance are focused on contributions to the Java community over a number of years, including writing articles, books, teaching, sharing, and speaking at conferences.

Java Champions are well positioned to influence the direction of future upgrades and versions of Java by offering suggestions and feedback and are considered to be industry-approved experts.

The full list of Java Champions is found here.

The post Java Champion appeared first on foojay.

The TCK is used for official compatibility and performance tests. jtreg is used for all other tests, for example, for functional tests. As jtreg is open source, it can be used as a regression test by developers contributing to or customizing OpenJDK.

jtreg was developed by Sun starting in 1997 before Junit, ANT, and other common tools were available. jtreg is specific to the OpenJDK project and not commonly used in other projects.

Number of tests in jtreg: 24.758 for Java 8, and 43.731 for Java 11

See also:

• https://openjdk.java.net/jtreg/index.html
• https://openjdk.java.net/projects/code-tools/jtreg/intro.html

The post jtreg Test Suites appeared first on foojay.

In the realm of software, there are many types of latency. No application can possibly be truly real-time (that is, zero latency: zero time elapses between the initiation of the procedure and the delivery of the result). Still, the objective of all high-performance applications is to be as close to real-time as possible.

Types of Latency

An interesting article in InfoWorld defined 4 sources of latency:

• Network I/O
• Disk I/O
• The operating environment
• Your code

Network I/O can be a big problem especially if your application needs to traverse the Internet to gather data from external sources. The time required to even connect to the remote server can vary widely, producing very different latencies for an application. Even an internal network’s performance can vary, altering the performance of your application if it calls an internal service.

Disk I/O is an obvious problem, which is why modern applications use memory as much as possible to lower latency; but sometimes disk I/O is required, for example in the case where data is arriving from a satellite for processing within a data center. The data may arrive as a file which has to be stored on disk then read by the analysis application.

Different operating environments provide different performance: “The operating environment in which you run your real-time application—on shared hardware, in containers, in virtual machines, or in the cloud—can significantly impact latency.”

What you, as a developer, have most control over is your code. But, even here, there are differences: different languages have different latency for the same computations. For example, the performance of C/C++ differs from the performance of Python. Unlike C/C++ and Python, which provide generally static performance, Java Virtual Machine (JVM) languages are unique: second-level Just-In-Time (JIT) compilers can re-optimize the byte code based on which code paths are being used most at a given time; however, the JVM also includes Garbage Collection (GC), which in most algorithms results in application threads being paused while different aspects of GC are performed.

In addition, input data sets can affect latency, particularly in cases where the software is performing mathematical analysis of a data stream. Sometimes the input data set has an easy solution, and complex code is never entered. Other times the input data requires a much more complex path through the software, resulting in significantly higher software processing time. This can be the case, for example, in financial trading systems or scientific data analysis systems like weather forecasting or analyzing military satellite data streams. Here is where second-level JVM JIT compilers excel. Languages like C/C++ and Python cannot adapt and optimize for changing data conditions. JVMs that use adaptive compilation strategies can.

Software Latency Example

Here is a simple graphical example of what latency can look like for a typical high-performance application. We have a process being initiated repeatedly over time, with latency results that are mostly small, mostly within a narrow range; but occasionally very high latency occurs. For high-performance applications, grouping latency by percentile often produces a plot similar to this:

The Y-axis represents some arbitrary units of time that represent your application’s typical performance. The X-axis is the result of grouping all the latency results over a period of time into percentiles. The blue line is the latency for each percentile. The orange line is the average latency over the entire time span.

Looking at the average latency, you might think “Our application does pretty well, doesn’t it? Our latency is lower than its average value 76% of the time!”

Here’s the problem. If your application has acceptable latency the great majority of the time, but extreme latency some of the time, you might go out of business. Why? Because one of your competitors’ applications might almost never exhibit ultra high latency.

If your customers need your product’s result very quickly in every instance when they use it, but sometimes they are left stranded with long waits, they’ll switch to your competitor, even though the competitor’s average latency might be higher than yours. Your tail latency is much higher than your competitor’s tail latency, so it’s safer from a business point of view for your customers who need very consistent service to switch to your competitor’s product.

The Cost of High Tail Latency: Use Cases

Let’s consider a few use cases where high tail latency is totally unacceptable, even intolerable.

• Financial Trading: The markets change very quickly. If your application delivers the right data to enable the correct trade to be made quickly, that’s good. But one long wait when a trade needed to be made could wipe hours or even days (or worse) of successful trading.
• Military Satellite Data Analysis: Military commanders rely on near-real-time analysis of incoming data streams from satellites (for example applications that analyze measurements of the ionosphere) to determine whether soldiers on the ground or in the air will have viable and reliable communications and navigation systems. A sudden long delay in receiving the needed result creates uncertainty that puts soldiers’ lives in danger.
• E-Commerce: There are many sites where the same product can be purchased. If your service is normally quick, that’s fine; but if sometimes customers have to wait for a very long time after clicking a button, and they get very frustrated, they’ll leave you and find a more reliable vendor.
• Phone-Based Apps: Users of phone-based apps understand that sometimes there are issues with networks. But, if they notice that even when the network appears fine, your app is randomly highly unresponsive (due to your own application’s high tail latency), they are unlikely to keep using your app for very long.

Low latency is critical for any application to succeed in the marketplace. However, tail latency can be a much greater determinant to the possibility of success for an application than average latency. Java itself very well illustrates the problem of high tail latency, through garbage collection.

The post Latency appeared first on foojay.

To use an analogy, this is like Linux. Linux is an extremely popular open-source operating system kernel. To run applications on Linux, you require a binary installable distribution like Red Hat, Ubuntu or SUSE. The same applies to OpenJDK.

There are multiple OpenJDK distributions from which to choose. Although built from the same initial source code, these distributions vary by the features they offer as well as levels of maintenance and support.

Check out Foojay's download page for a long list of OpenJDK distributions.

The post OpenJDK appeared first on foojay.

An incomplete development guide can be found here:

• https://openjdk.java.net/guide/
• https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code
• https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews

Some organizational guides and style guides can be found here:

• https://openjdk.java.net/contribute/
• https://wiki.openjdk.java.net/display/HotSpot/StyleGuide
• https://wiki.openjdk.java.net/display/OpenJFX/Code+Style+Rules

Code Reviews and Code Quality

Quality of code contributions is controlled by Reviewers in charge of the code repository of a given OpenJDK subproject. Up-streamed changes from contributors must pass through those gatekeepers who apply the processes defined by the JCP (Java Community Process, https://jcp.org/) for approving changes and new features.

Overall quality and compatibility are assured through the TCK suite. All new features, compatibility breaking changes and reproduceable bugs must be submitted with TCK tests cases.

The post OpenJDK Coding Guidelines and Code Reviews appeared first on foojay.

The OpenJDK contributors have been working hard to maintain backwards compatibility of Java 8 on older Windows versions. Windows 7 and Server 2008 have seen support until the end of 2020 (with a bit of care and effort the current version could be built to run on XP) but all things see an end as Microsoft has ended support for those version earlier in 2020.

Conservatively using Visual C++ 10 for compiling OpenJDK has been part of this strategy. This may seem counterintuitive to developers trying to be on the leading (and bleeding edge), but for complex C software packages, a compiler version jump is a major quality assurance hassle.

The Visual C(C++) compiler and the corresponding C runtime libraries do not update with every Visual Studio release. Since VS 2015, the compiler is maintained on major version 14.

Impact on the OpenJDK

The most noticeable aspect of this is the bundling of some VC runtime libraries with the OpenJDK. You will find msvcr100.dll or vcruntime140.dll in <JRE>/bin as the Java tools are dynamically linked (while the JVM is statically linked). This helps skipping the “Windows DLL hell” issues.

All versions of VC++ since 10 have been in active maintenance, receiving security and bug fixes when required. Visual Studio 2010/VC++10 has been retired in July 2020, in line with retiring Windows 7/Server 2008 earlier that year.

Since summer 2020 OpenJDK 8 is slowly switching to VC++14. As VC++10 is still (end of 2020) considered stable and safe, each OpenJDK distribution is making the move at its own pace.

OpenJDK 11 started out with VC++14 from the start, but consequently many distributions only supported it from Server 2012 onward.

On the DLL Hell

Microsoft has been publishing updates to supported versions runtime libraries (e.g. msvcr100.dll and msvcp100.dll) from time to time, but to the dismay of developers and Windows admins those are often lost in the “Windows DLL hell” with little transparency as to when which version was published and where to obtain it.

To obtain the exact version of a DLL use the Powershell command:

• (Get-Command C:\Path\To\msvc100.dll).FileVersionInfo.FileVersion

You will most likely find up to three versions of VC Runtime libraries in your system, often different ones in the same software package.

Summary

1. Maintaining backwards compatibility means making compromises, being conservative when updating the compiler. Using the latest tools is a quality assurance challenge and sacrifices platform support.
2. Old versions of runtime libraries do impact security as long as those runtime libraries are being patched. VC++10 was maintained until July 2020.
3. The OpenJDK contributors are constantly monitoring all tool and platform changes for impact on the OpenJDK. Security and patch levels of compilers and third-party libraries are constantly being reviewed

The post OpenJDK with Visual C++ appeared first on foojay.

Unlike all other activities in OpenJDK which are public (mailing lists and archives are accessible here), the Vulnerability Group works behind closed doors.

Security vulnerabilities are only disclosed at the time that an OpenJDK update, which fixes those vulnerabilities, is publicly released. On foojay, for each release and update, the list of vulnerabilities are listed, as shown below, click here for details.

The Vulnerability Group has about 20 members.

The post Security and Vulnerability Management appeared first on foojay.