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

Paweł Baczyński

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 

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

Java Runtime Environment

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.

Migration from java 7

Don't be scared of Java migration. Read our article to do this in a nice and easy way.

Generally, most companies avoid migrations. That's mostly because they often don't offer any clear and instant advantages, while the risk is substantial. Also, developers performing migration are blocked from delivering value to the customers. It has become increasingly complicated to perform the migration. In this article, we will focus on migrating from Java 8 to the newest version since it's still the most popular one in the world of developers.

 - have changed their release policy. Now one "small" release is scheduled every six months, rather than having a "big" one released every 3 years. According to 

Mark Reinhold, the Chief Architect of Java Platform

, that's because Java needs to be more competitive compared to other platforms that evolve faster.

It may sound like bad news for companies that want to be up to date with the newest version of this programming language. That may require more migrations than before. However, smaller changes aren't so difficult to introduce, and the process becomes less and less laborious after some 2 or 3 migrations.

In the beginning, let's take a closer look at the advantages of migrating to a newer version of Java. Previously, the introduction of lambdas and functional programming in Java 8 was a massive change that created a revolution in the Java code. Subsequent releases didn't bring similar changes, however, there are still some handy features that are worth mentioning - and considering to use after migration. I would especially point to:

Better API for the Optional class that makes it easier to use.

Improvements in Predicate classes to allow making Predicates chains easier.

Some convenience factory methods for collections - especially for creating collections.

Ability to collect unmodifiable collections from streams.

Introducing of JShell - the REPL that allows running some individual lines of code. It's very useful when we test code quickly.

Embedded HttpClient - most applications use HTTP today, and developers were previously forced to use third-party libraries.

JLink, which is a fantastic tool to package and deploy only the selections of JDK that are necessary for deployment.

Text blocks - very helpful when working with big multiline strings.

Reimplementation of the legacy socket API.

The secondary benefit is better performance. Generally, every release performs better than the previous one. We can observe improvements in startup time, memory consumption, and fewer CPU cycles. Also, some significant changes in memory management were introduced, like improvements in GC. All of these improvements can bring some significant code reduction because of smaller artifact size and a decrease in cloud computing power and costs.

The last benefit that I want to highlight is more organizational rather than technological. In general, ambitious developers want to improve their skills and develop professionally at their company. It may be hard to improve their skills when using some legacy, outdated codebase. Using an outdated version of JDK could discourage many talented developers from joining your company - while having the newest version can encourage them to become part of your team.

Compilation warnings look rather harmless and are often ignored by developers because the project is already compiled, so why bother? However, before migrating to a newer version of JDK, it's a good idea to address most of the compiler warnings. Usually, they're about some deprecated methods that have eventually disappeared in the newest version of Java. It's worth solving them before use a newer version of JDK to compile the project.

Second, you should check for usages on the internal APIs that were hidden, starting from Java 9. This may require some significant changes in your codebase if you are using classes from sun.misc.* package. There is a very useful tool called jdeps that will scan your codebase and generate a report on whether and where you use internal APIs, also with some hints on how to solve found issues. It's also a good occasion to check if our application performs operations that are not safe.

The next step is upgrading your build tool and compiler level. If you are using Maven, then you need to use the newest version of the Maven plugin (

). Configure it to support Java 13 and provide the following configuration:

For Gradle you need to use the plugin in version 6.0 or above. It should be 

 (mid October 2019). You have to adjust the configuration of the source and target compatibility version as follow:

Also, you may face some issues while migrating to a higher version of Java due to the fact that most libraries and frameworks use the reflection or internal API to fulfill their functionalities. The use of the internal API is not possible. Most libraries already support Java 9+, and so you need to make sure that your libraries are up to date. Unfortunately, some libraries will have to be replaced. So you need to carefully check all your dependencies and see whether they are working correctly. It might sound harsh, but there is some good news as well - it's a one time job, and repeating it won't be necessary for further releases.

In this article, we wanted to encourage you to make a quick migration once the new version of JDK is released. Your company will gain some substantial benefits, and consecutive migrations will go smoother. At Solidstudio Software House, we performed a migration to the new version of JDK for our projects 2-3 months after the JDK's release. It took us several person-days, but we believe that we have gained a substantial benefit - and that it's worth performing that operation on a regular basis.

Java 14 new features

11 MARCH 2020 • 13 MIN READ