3

I've read a few articles where in jdk 9, .* APIs have been removed. By removed does this mean they are completely removed from the jdk 9 or are they marked as deprecated?

Given the above statement, if in case the project is jdk 8 compiled, would it run without any issues on jdk 17? I am trying this for the first time, and had issues with tomcat not being able to support jdk 8 because of modularity changes.

I am planning to compile in jdk 8 and then run on jdk 17 until the entire project is jdk 17 compliant (By jdk 17 compliant, I meant to use the updated APIs rather the the existing deprecated APIs of jdk8).

Am I headed in the correct direction? or should I follow a different migration approach?

Sai Kumar
  • 201
  • 2
  • 8
  • Not sure what you mean by *"until the entire project is JDK 17 compliant"*; if it isn't, then how will you run it on JDK 17? – kaya3 Nov 01 '21 at 05:15
  • @kaya3 By jdk 17 compliant, I meant to use the updated APis rather the the existing deprecated APIs – Sai Kumar Nov 01 '21 at 05:21
  • 3
    Why do you want to “compile in jdk 8 and then run on jdk 17”? If you don’t run with JDK 8, there is no point in using it to compile the code. Compiling with JDK 17 will tell you immediately whether your code uses a remove API (unless Reflection is involved), which is much better than to find out at runtime by chance. – Holger Nov 02 '21 at 07:52
  • "compile in jdk 8 and then run on jdk 17" makes it possible for a smooth transition as is not required to updates all instances at once – lalo Dec 21 '21 at 19:06

1 Answers1

2

By removed does this mean they are completely removed from the jdk 9 or are they marked as deprecated?

Some have been just marked as deprecated. Others have been removed entirely., though generally not in Java 9. Most of the removals were done later, and some are still to occur. If you look at elements that are now annotated as @Deprecated, the annotation in some cases will formally indicate that the element is going to be removed.


Given the above statement, if in case the project is jdk 8 compiled, would it run without any issues on jdk 17

Not necessarily. Another thing that has happened is that access to "internal" Java SE APIs has been progressively closed off. So if your application uses these APIs, in Java 9 you got warnings, by Java 11 you got errors by default, and by Java 17 some access has become (I think) impossible.

So ... there can be "issues".

The correct approach to migration is simply to do it. And test, test, test until you have ironed out all of the problems.

Obviously, that means that you need a test server, and you need to use an automated test framework with unit tests, functional tests, UI tests and so on. But those are just good Software Engineering practices. You should already be following them.


I am planning to compile in jdk 8 and then run on jdk 17 until the entire project is jdk 17 compliant (By jdk 17 compliant, I meant to use the updated APIs rather the the existing deprecated APIs of jdk8).

Am I headed in the correct direction? or should I follow a different migration approach?

No. As @Holger points out, you are liable to run into lots of runtime errors ... due to problems that the Java 17 compiler would have identified.

There is only one approach ... really. Compile on Java 17 until you have identified all of the compile time dependency problems; i.e. using APIs that have been removed or closed off. Then run on Java 17 and test, test and test until you have found all of the other problems.


Before you start, it would be advisable to check all of your project's dependencies (libraries, etc) to see if they are supported on Java 17. Then update them to the correct (probably latest) versions.

Java 17 has only been released for a few weeks, so there is a good chance that some of your dependencies haven't caught up yet. If that is the case, it may be a better idea to target Java 11 LTS at this stage.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216