How can I learn JVM well

Java Virtual Machines (JVM) are software programs that abstract hardware and operating systems by providing programs with a virtual operating system and hardware-independent layer. “Write once, run everywhere” was once the slogan.

A JVM is thus a piece of software. But is a Java Virtual Machine also a SOUP? You can find answers in this post.

JVM: The original idea

A Java Virtual Machine allows application programs to be developed and compiled largely independently of the hardware and the operating system. Developers write source code in one of the programming languages ​​for the JVM such as Java, Jython, JRuby, Scala or Kotlin. You compile the source code into class files. This so-called bytecode is then interpreted by a Java Virtual Machine (JVM). JVMs are available for many different operating systems, which in turn run on specific hardware.

The Java Virtual Machine thus serves as an abstraction layer between the operating system and your own software.

The most important manufacturers of Java Virtual Machines include:

  • Oracle
  • IBM
  • JRockit
  • Android runtime

Is a JVM a SOUP?

Whether a Java Virtual Machine is a SOUP depends on whether it is part of the medical device or part of the required runtime environment.

Whether the JVM is a SOUP according to IEC 62304 depends on whether the manufacturer places it on the market as part of his product.

A JVM is only a SOUP if it is part of the (delivered) medical device. This applies in the following cases:

  • The manufacturer delivers the product including hardware and operating system as well as JVM (case 4 in the figure above). This is the case with physical medical devices.
  • The manufacturer delivers everything except the hardware (case 3). This means that the manufacturer only requires "bare" hardware.
  • The manufacturer only requires the hardware and the operating system and delivers its software including the JVM (case 2).

As soon as the manufacturer leaves it to the customer to get the hardware and the operating system including the Java Virtual Machine and does not deliver the JVM to the customer, this virtual machine is not a (!) SOUP, but part of the runtime environment (case 1). This does not change anything if the manufacturer specifies the requirements for the runtime environment, e.g. in the form of hardware requirements, minimum version of an operating system or JVM version or manufacturer. The Java Virtual Machine is then not a SOUP.

Requirements for SOUPs (possibly also for JVM)

The requirements of IEC 62304 for SOUPs also apply to Java virtual machines. In particular, you should

  1. Specify the requirements for the JVM: Here it is advisable to specify which functions of the JVM are particularly relevant, such as access to the network stack, file access or the abstraction of screen control. These requirements are relatively generic. Determine which of these requirements are particularly important in order to avoid risks for patients and users. The requirements can also relate to the behavior under high load or the handling of many threads.
  2. Specify the prerequisites from which the JVM must be based: These are in particular the operating system (type, versions) and the hardware configurations.

Finally, you need to test that the requirements are met under the given conditions.

Typical mistakes when dealing with Java Virtual Machines

We regularly encounter the following problems in audits and when submitting product files:

  • The requirements for the JVM are not specified.
  • The manufacturers have not specified the hardware and operating system on which the virtual machine should run.
  • The JVM does not appear in the list of SOUPs and / or is not tracked in the downstream phase.
  • This virtualization layer is not described in the software architecture.
  • Manufacturers allow auditors to get involved in discussions that are not very effective as to whether the use of a JVM would not cause unnecessary risks.
  • The JVMs are not patched and thus become a problem for IT security.
  • The manufacturers do not have an overview of which version of a Java virtual machine is running in which product or for which customer.
  • The developers develop and test on different versions than those used by the customers.