Paweł Baczyński

The Java platform comes with three key components: the Java Development Kit (JDK), the Java Virtual Machine (JVM), and the Java Runtime Environment (JRE). They’re a must-have in any project based on developing and running 

The Java Runtime Environment is software designed to help developers run other pieces of software. When developers need to execute a software program, they need an environment to run in. The runtime environment is responsible for loading class files and ensuring that the program can access memory and other system resources.

The Java Runtime Environment is a software layer that runs on top of a device’s operating system and provides additional services that are specific to Java. The runtime environment for Java includes the Java class libraries, Java class loader, and Java Virtual Machine (JVM).

The class loader helps to correctly load classes and connect them to the core Java class libraries. Developers use the JVM for ensuring that their applications have the resources they require to run and perform well in devices or cloud environments. What about the JRE? It mainly acts as a container for the other components (and orchestrates their activities).

Thanks to JRE, developers can blur the diversity between different operating systems, ensuring that their software runs on any OS without modification.

One of the most important value-added services of JRE is automatic memory management. This ensures that developers don’t need to control the allocation and reallocation of memory manually.

The JRE includes integration libraries such as Java Database Connectivity and Java Naming and Directory Interface.

Java memory is made of three components: the heap, stack, and metaspace (called permgen until Java 8). The metaspace is where Java keeps the program's unchanging info (for example, class definitions). Heap space is where you’ll find variable content. Java stores function execution and variable references in the stack space.

Since Java 8, developers can take advantage of metaspace which introduced a significant change in how developers interact with the memory space of this programming language. Before, they would have to use the command java -XX:MaxPermSize to monitor the size of the space available in permgen. From Java 8, the technology is able to automatically increase the size of the metaspace to accommodate the meta-needs of software. Java 8 also introduced a brand-new flag called MaxMetaspaceSize, which development teams can use to limit the metaspace size.

Application monitoring is primarily a function of the Java Virtual Machine. However, the JRE also provides a range of configuration options that form the foundation for monitoring. Developers can use a variety of tools for monitoring Java applications, from simpler ones like the Unix command top to sophisticated solutions for remote monitoring (such as Oracle's infrastructure monitoring).

Moreover, programmers also get to benefit from visual profilers like VisualVM that allow inspecting a running JVM. Thanks to all of these tools, a development team can identify and track down hotspots and memory leaks, and monitor the overall memory consumption of your system.

Are you looking for an experienced team of Java developers for your project? Do you need help in expanding your product with extra Java skills on board? Get in touch with us. We help companies all over the world to make the most of this incredibly powerful technology and realize their business goals efficiently.

Read about the benefits of Java Runtime Environment

See what's coming with the newest update of Java.

Java 14 release is scheduled for general 

 14 introduces three changes to the language and one useful feature for runtime:

Introducing Records to reduce the number of boilerplate code (preview)

Better debugging with more descriptive stack traces

In this article, we take a closer look at these new features to show you what to expect in Java 14. Two of them are preview features which means that they’re not permanent and may be changed or removed in future releases. You can enable preview features by using the following compiler flags:

There are several problems with the design of the existing switch statements which were taken from C and C++ languages. A new form of switch called switch expression was created to mitigate them.

The first problem with the old switch statement is that it uses fall through semantics. This means that the break statement must be used in the code..

By the way, did you notice a bug in the code? There is a missing break statement for the third quarter. When a programmer forgets the “break;” statement, they’re going to face a nasty bug. The switch expression uses an arrow notation (->) instead of the color (:) used by the older form. The above example can be rewritten to the new form like this:

Another issue is the scoping of variables. A variable declared in one case is in the scope of the entire switch statement.

This problem doesn’t exist in switch expression.

Also, until version 14 switch statements couldn't yield a value leading to constructs where a variable declaration is separated from the code that assigns a value.

In the case where more than one line is needed, all of them have to be included in curly braces. As all cases need to yield a value, we need to use the newly introduced yield statement. It must be the last statement in the block (similar to return in methods).

Note that yield is not a new keyword. It’s rather what we call a restricted identifier (similar to var). It can only exist at the end of the case branch. If it was a new keyword, a lot of the existing code would be broken - including the JDK itself -> Thread. yield().

From time to time, a Java developer needs to use the intanceof operator. If this is the case, usually a cast to a given type follows right away:

This is too verbose (note that BigDecimal is repeated three times). Pattern matching allows declaring a binding variable (big) that relates to a predicate (number instanceof BigDecimal)

Isn't it cleaner? The binding variable can also be used in the same if condition:

 14, the only predicate supported for pattern matching is instanceof check, but future releases are expected to extend the set of supported predicates.

Java Records to get rid of boilerplatecode

Did I mention verbose code? Imagine that you need a class that groups just two fields (first and last name). To make this class complete, you’d have to generate an enormous amount of code.

Records to the rescue! With a simple declaration like this:

We can omit all of the required boilerplate code. The Java compiler will generate a constructor, private final fields, accessors, equals/hashCode and toString methods automatically. We could also solve this issue by using 

 @Value annotation. It will be great when it will be possible to do it in the JDK itself without resorting to third party libraries.

The generated class can be examined with javap:

There are two differences between the class and the record from the example above.

First, the accessors are named exactly as the fields, so it's firstName() instead of getFirstName(). Not much can be done about this. To accommodate it, a number of libraries need to be updated.

Second, the record implementation does no checks in the generated constructor. Here some things can be changed. It’s possible to modify the generated constructor like in this example:

Note that the construction declaration doesn’t declare any parameter list, not even empty parentheses.

You can also add other methods like constructors as well as initialization blocks or static fields. However, you can use no member fields other than in the record declaration. Also, records must not extend any class. They implicitly extend java.lang.Record.

A perceptive reader may have noticed that the Person record wasn’t declared as final while the class was final. There’s no difference here. In the case of records, they are final by default.

The purpose of records is to serve as value classes. Please don’t abuse them by declaring a service class as record. ;)

It’s interesting that this time, Java architects didn’t introduce a new keyword (like they did when enums were added). So, no existing code using the record as an identifier will be broken.

. Rather, it’s a change to the runtime environment. It allows for easier spotting of a cause to a 

. It's disabled by default (for performance reasons, among other things). The feature can be useful in debugging. To enable it, the Java process has to be started with option

Let’s see it in action. There is a line of code that causes 

It shows which line caused the exception, but which method call? Not that helpful. Using the new feature we can get this stack trace:

Now everything is clear. The value of object.a().b().c() is null and this is the reason for error. This also works for arrays of arrays.

Currently stacktrace would look like this:

And with descriptive stack traces enabled:

Again, this is a lot more useful as it clearly points to the part of the code that causes the problem.

The features added to respond to programmers' needs. They’ll make working with Java easier as they allow to reduce the need for boilerplate code. Pattern matching for instanceof doesn’t seem like an important change but it’s a start to adding pattern matching to other places. Records look like a little revolution that should have been added a long time ago. I hope these features will soon move out of the preview stage and into the stable set of features.

The release of Java 14 brings some other changes as well. Some of them affect garbage collection, removing deprecated tools, etc. For a full list of features, visit this 

Java 14 new features

Getting access to Java applications inside Docker.

Being an eMobility leader in various projects across multiple startups, Piotr was responsible for OCPI and OCPP integration as well as EMP and CPO platforms development. With extensive expertise in the open standards field and eMobility tech solutions, he is leading teams of experienced developers and contributing with invaluable knowledge and experience.

Piotr Majcher

Docker is a great tool that allows developers not to worry about servers, Ops/DevOps not to think about the servers they maintain. It’s also useful for developers who just want to run dependent components without digging into the details of those dependencies.

But Docker comes at a price. It creates an extra level of abstraction and makes accessing the internals of running code more complicated.

 in an environment that is really close to what we usually have in production.

Introduction - debugging a Java application

In order not to stick to any specific IDE, I’m going to use jdb for debugging. It’s a Java debugger which is a part of jdk. Let’s assume we have an executable fat jar with a Spring Boot application called app.jar.

If we want to run the application without debugging it all we need is:

In order to debug it, we need to add few additional parameters (I’m using a specific setup here):

Since we set the suspend parameter to ‘yes’, the application is hanging waiting for debugger.

In another console we can try to attach the debugger to a running application by using the following command:

After few seconds, we can see all the known logs from Spring:

Attaching the debugger to a Java app running inside Docker container

Now, let’s wrap our sample application and run it inside a Docker container. We can do it manually by using the following Dockerfile:

Then we can add the same debug parameters as previously:

Once we build the image and start the container, we can see the same log as before:

Can we now attach the debugger to the Spring application running inside the Docker? Yes, but first we need to expose port 8000 from the container. For instance, we can run a Docker container with the following command:

Now you should be able to attach the debugger without any problems.

Shell and Exec form of CMD and ENTRYPOINT

CMD and ENTRYPOINT are two commands that may be used to tell Docker what tasks need to be executed when starting the container. Both instructions may be used in two ways:

exec form - <instruction> [<executable>, <param1>, <p>, ...]

For instance, we could rewrite the initial docker file I showed you above using exec from:

It’s a small trap when it comes to passing the debugging parameters to exec form of instruction, as

consists of two separate parameters. To make it work, we need to pass it separately:

It’s important to remember that when working with tools like docker-maven-plugin from Spotify as they use exec form of ENTRYPOINT instruction in their documentation by default and it’s easy to just take “debug string” and pass it as a single parameter.

Summary - how to solve common problems with debugging a Java application on Docker

It’s very easy to connect the debugger to a Java application running inside a Docker container. There are two things we have to remember here:

the exposing port we are going to use for debugging,

properly passing parameters to the JVM, having in mind differences between exec and shell forms of CMD and ENTRYPOINT instructions.

Once we have those two things set up, we can debug our code locally in almost the same environment as the production environment.

Learn the easiest way to debug your Java application by reading this piece of content.

Debugging Java applications running on Docker.

Being a co-founder of Solidstudio, Paweł has got to see all the development phases. He’s a skilled professional with years of experience, both in the software and in the eMobility worlds.

Paweł Głogowski

In many companies, migration to new technologies is a taboo topic. The management would rather avoid it, and developers often complain about outdated stack between each other. That situation usually lasts for a long time, and no one wants to change anything, especially if the project is live and profitable. In that case, the decision to perform a migration looks like an unnecessary risk.

, I offered a guideline to migrate from Java 8 to 13. In this article, I will focus on the migration from Java 7 since the differences between Java 7 and 8 are much more significant than between 8 and 13.

I will start to elaborate on why migration from 

 7 is extremely important, and you should not postpone it anymore.

There were significant changes between Java 7 and its further versions. Besides some "standard" changes like optimized performance or extending some existing API, it includes changes in the syntax itself.

 8 is no longer forward compatible. Long story short, the code written in the newer version may not work on the previous version. This also means that the whole further Java ecosystem will not work with Java 7.

Also, it means that most libraries that support Java 8 will no longer work with previous versions. This includes some frameworks required to build modern, enterprise applications like 

. Since the frameworks evolve and modern solutions for new problems emerge, it's become one of the main reasons why you should consider a migration.

The second important reason is developers' performance. The new Java features bring huge changes in collection processing, and since it's one of the most common problems, developers need to handle it to significantly boost their performance. Also, other improvements like Optional make code less error-prone.

What's more, talented developers usually want to work with the newest technologies. So, if your project has a legacy stack, it makes you a less attractive employee. At some point, it will be quite unlikely to get good people from the market. Losing good people is usually the beginning of a much bigger problem that could eventually lead to the death of your project. So you need to act now!

Each new version of Java brings some optimization and security fixes. It is not visible at first glance, but it will help you to boost the performance and security of your application.

So here are some other benefits that come with bumping the language version:

Performance - each newer Java version optimizes the memory management in terms of Garbage Collector, also CPU operations are more and more optimal.

Security - Oracle advises moving from Java 7 to avoid 

Even though migrating to a newer Java version is a smart move, companies, especially the big ones, postpone migration and leave legacy projects. I will try to explain why.

When the project is very big and has an enormous number of dependencies on external and internal libraries, it may be extremely difficult to perform the migration. So, even having all the benefits in mind, the risk is too high, and no one wants to make the call to migrate. Business people don't want to touch the existing solution - at least it's working. Later on, in this article, we will provide guidelines that can be used even in some tough cases.

In many cases, there is pressure from clients to implement new features as soon as possible, and usually, that's a priority over improving the existing codebase. That's probably one of the hardest cases since convincing clients might be pretty hard. You need to use very convincing data and explain how it may be valuable to him. But that's a huge topic, and I'm not going to get into it in this article.

Having difficulties with the client or an enormous codebase may be a justified reason to avoid migration. But here's the problem: a lot of companies don't think about migration even during a quiet time when developers have some spare capacity and could easily spend some time performing the migration for future sake. Unfortunately, there is a massive tendency to stick to the status quo, especially during good times when clients are happy and we have some spare capacity and could migrate our application step by step. If your stack is "not so old" then it's really hard to motivate anyone to migrate from Java 8 to Java 9. But trust me, it's better to migrate one version than a bunch of versions at one time.

Migration from Java 7 step by step guideline

As I mentioned before, there are some major differences between Java 7 and later releases, and there is no forward compatibility. So besides upgrading the Java version, you need to update all of the related third-party libraries and frameworks. So basically, the migration plan should look like this.

Upgrade libraries, adjust the codebase, and build a new version.

Test as much as possible to make sure that it works as expected in the desired environment.

The first phase would be to analyze the current codebase and all of its dependencies. It's better to take a look at the big picture rather than blindly bump each library in the hope that it will start to work. It's worth reading the documentation of particular libraries to see which versions start to support your desired Java version.

So first, create a table with the following format. This is a good start for a migration plan.

LibraryCurrent versionTarget versionSpring Boot1.5.12.4

For example, Spring Boot 1.5.X supports Java up to version 7. Starting from version 2.0, Java 7 is no longer supported. So, if you want to migrate to Java 11 or above, you need to upgrade Spring Boot to version 2.1.

Bumping Spring Boot from 1.5.1 to 2.4 can be costly and will require some code and configuration changes, that's for sure. How costly this operation becomes will depend on the number of used libraries, but in general, upgrading most libraries to support Java 11 requires some substantial changes. Sometimes, you can find additional guidelines on official framework pages like Spring Boot that can be really helpful.

This also applies to any tools that are used by the application like static code analyzers, code style checked, etc. If you are using 

, you also need to change its version so you can make use of it with the new Java version.

Build your application in the new Java version

So, after the initial analysis, you need to bump each library one-by-one and try to compile your project. Usually, it will require a change to the existing codebase to adjust it to the new API, because in such a version usually, API changes aren't compatible. Sometimes, it will be an easy change like the method name change, but other times you will need to dig into the documentation and write equivalent code using the new API.

By its nature, Java is backward compatible, so there should be no problem with compiling the existing codebase (other than changes in third-party libraries described above). However, there are some cases when compilation errors happen with Java 7 code. These are usually due to some unresolved compilation warning around generics. These errors are usually easy to fix.

If your code compiles correctly, then you need to run an automated test to see if it works as expected. Also, if possible, you should try to run the application locally to check if it goes up. There are some cases where, besides the code, you need to adjust your application configuration properties. That's the place where your IDE can become really handy and will mark all of the properties that are obsolete. Make sure that your IDE version is up to date.

Test as much as possible to make sure that it works as expected in the desired environment

If your application is working locally, you may deploy it to a new test environment. You need to prepare servers to be able to deploy the newer version. The test environment should mimic the production environment to avoid further unexpected errors. The most important part is the test behavior of the application.

You should have a bunch of automated tests for your services and the Web Application. The more tests you have, the more confidence you'll gain that's nothing broken. When your test suite doesn't cover all of the flows, then some additional manual tests are required. Ideally test all the possible flows to search for unexpected behavior or errors. It's not always possible to test the whole application manually because it can be very large. However, you should definitely check some sanity tests for all positive flows. In general, perform as many tests as possible to make sure that there is no problem with the new version, and it works as expected.

At this point, it's also worth mentioning that keeping your test suite up to date can help during the migration to newer versions. For instance, the contracts of REST services will not change during the migration, so tests will be valid after the migration, as well as the web application flow. So that's another reason to keep your test suite up to date as part of the development process.

, we try to keep our tech stack up to date. We took advantage of writing tests as a part of the development process, and thanks to that, the migration process was smooth. If your project works on Java 7 or below, then you should definitely consider migrating to a newer version. I hope that this article helps you do that. Good luck!

Why do you need to migrate from Java 7? Read our article.