[00:00.000 --> 00:10.600]  So let's get started, so this session is about why and how to upgrade to Java 17 and Simon
[00:10.600 --> 00:16.160]  already talked about the great new stuff that's being developed in the last couple of years.
[00:16.160 --> 00:21.360]  But I was wondering like what version of Java are you currently using at your projects for
[00:21.360 --> 00:22.360]  your company?
[00:22.360 --> 00:24.360]  So who's already using Java 21?
[00:24.360 --> 00:26.360]  Release, raise your hand.
[00:26.360 --> 00:29.880]  Of course that was a quick question because that's already access, I guess you don't use
[00:29.880 --> 00:35.480]  that on a production machine, but who's using Java 17 already?
[00:35.480 --> 00:40.360]  Quite a few, so basically you can tell the rest how to do it now.
[00:40.360 --> 00:42.360]  Who's still using Java 11?
[00:42.360 --> 00:45.360]  Okay, quite a few as well.
[00:45.360 --> 00:47.360]  Java 8?
[00:47.360 --> 00:50.360]  Okay, older than Java 8?
[00:50.360 --> 00:51.360]  That's not too bad.
[00:51.360 --> 00:55.360]  So the interesting thing is, well, I mean Simon talked about Java almost existing for 30
[00:55.360 --> 00:59.360]  years, a lot of cool features come in in the last couple of years.
[00:59.360 --> 01:04.360]  Still a lot of people are on 8, which is almost like 10 years old, which is quite interesting,
[01:04.360 --> 01:05.360]  of course.
[01:05.360 --> 01:09.360]  You miss all the cool new stuff.
[01:09.360 --> 01:13.360]  And that's basically what this session is a bit about.
[01:13.360 --> 01:18.360]  So if you have any questions, it's a short session, so please ask me afterwards on Twitter,
[01:18.360 --> 01:20.360]  LinkedIn, or somewhere else.
[01:20.360 --> 01:25.360]  This session is based on the GitHub people story I created, so I collected all kinds
[01:25.360 --> 01:29.360]  of examples from projects where I did the upgrades to newer versions of Java, starting
[01:29.360 --> 01:35.360]  with Java 8 and open until Java 17, a little bit about 21 as well.
[01:35.360 --> 01:40.360]  So it basically gives examples, shows you error messages that you see when you upgrade,
[01:40.360 --> 01:41.360]  things like that.
[01:41.360 --> 01:46.360]  So you can use that when you do the upgrade yourself.
[01:46.360 --> 01:49.360]  So why actually this session?
[01:49.360 --> 01:53.360]  I think a lot of people see it as challenging to upgrade to a newer version of Java.
[01:53.360 --> 01:57.360]  And a lot of people also estimate it at really large amounts.
[01:57.360 --> 02:04.360]  To give a concrete example, one of the companies I worked at, one of the teams estimated that
[02:04.360 --> 02:09.360]  to just upgrade their application, which was like a one team effort, which was a couple
[02:09.360 --> 02:14.360]  of years old, they said it would take them a quarter with a couple of persons to upgrade
[02:14.360 --> 02:16.360]  from Java 8 to Java 11.
[02:16.360 --> 02:18.360]  You can guess what management then said.
[02:18.360 --> 02:21.360]  They said no, basically, so they couldn't upgrade.
[02:21.360 --> 02:24.360]  They already stayed with it for a couple of years.
[02:24.360 --> 02:29.360]  And why I am not basically trying to convince people to change their estimates, but that
[02:29.360 --> 02:31.360]  estimate was really high.
[02:31.360 --> 02:33.360]  In the end, I didn't want to have all the discussions.
[02:33.360 --> 02:36.360]  And I was lucky that my manager simply said, you do whatever you think is right.
[02:36.360 --> 02:39.360]  So I upgraded it myself in like two weeks.
[02:39.360 --> 02:43.360]  Of course, I had some previous experience, so maybe it takes a bit more if you haven't
[02:43.360 --> 02:49.360]  done many Java upgrades in the past, but still, I did it next to my normal job.
[02:49.360 --> 02:54.360]  Most of the time, you're waiting for the build to finish anyway and all the tests to run.
[02:54.360 --> 02:56.360]  So it's not like that much of work.
[02:56.360 --> 03:00.360]  And what I find interesting is we always blame management that we cannot upgrade our
[03:00.360 --> 03:04.360]  applications, but in the end, it's us who benefit most, because then we can use all those
[03:04.360 --> 03:05.360]  cool new features.
[03:05.360 --> 03:11.360]  So before I had the relaxed manager who said do whatever you want, I often did it on like
[03:11.360 --> 03:12.360]  Friday afternoon.
[03:12.360 --> 03:16.360]  I upgraded to a new version of Java, tried to compile stuff, tried to tweak it a little
[03:16.360 --> 03:21.360]  bit, and then I got a better idea like, hey, we need to fix only the test or maybe stuff
[03:21.360 --> 03:22.360]  that doesn't compile.
[03:22.360 --> 03:23.360]  We need to fix it.
[03:23.360 --> 03:27.360]  And then I could say to management like, hey, give me two days or give me a week.
[03:27.360 --> 03:30.360]  And then they often are like, okay, you're already working on it.
[03:30.360 --> 03:32.360]  We can give you a week and you can upgrade.
[03:32.360 --> 03:35.360]  And that's often beneficial to yourself as well.
[03:35.360 --> 03:39.360]  But there was also a good reason that you should do it for the company because the new
[03:39.360 --> 03:43.360]  versions of Java, they also offer you free performance improvements, security updates,
[03:43.360 --> 03:44.360]  things like that.
[03:44.360 --> 03:49.360]  So there are a lot of good reasons why you should upgrade to a new version.
[03:49.360 --> 03:52.360]  And I want you to actually upgrade.
[03:52.360 --> 03:56.360]  So something changes in Java and you build your application on top of it.
[03:56.360 --> 03:58.360]  Most applications have some dependencies.
[03:58.360 --> 04:01.360]  I only know a few who basically build everything themselves.
[04:01.360 --> 04:06.360]  But in general, you have some dependencies and if something changes in Java, those dependencies
[04:06.360 --> 04:12.360]  might break or your application might break or both of them.
[04:12.360 --> 04:15.360]  And then as they sometimes say, a lazy developer is a good developer.
[04:15.360 --> 04:22.360]  If you wait, those dependencies will automatically update their code to make sure that it compiles
[04:22.360 --> 04:24.360]  on the latest version of Java.
[04:24.360 --> 04:31.360]  Often already before the new version is released, sometimes shortly afterwards.
[04:31.360 --> 04:35.360]  And then what will actually be removed from Java?
[04:35.360 --> 04:41.360]  It's basically anything from tools like Java Mission Control to methods to all kinds of
[04:41.360 --> 04:42.360]  things.
[04:42.360 --> 04:46.360]  If you go to my GitHub, you can get some references where you can see in detail, for instance,
[04:46.360 --> 04:51.360]  on the Fuji website, you can see what methods are deprecated, removed, et cetera.
[04:51.360 --> 04:55.360]  You can get a lot of those details, which is quite interesting.
[04:55.360 --> 05:00.360]  But you can also simply try it out and upgrade to a new version and you get those compile
[05:00.360 --> 05:03.360]  errors for free.
[05:03.360 --> 05:07.360]  Then in order to upgrade your dependencies, because I noticed that if you keep your dependencies
[05:07.360 --> 05:10.360]  up to date, then it's relatively easy to update your Java version.
[05:10.360 --> 05:15.360]  If you have really old dependencies, it might be tricky, but then first you need to upgrade
[05:15.360 --> 05:18.360]  them before you can go to a new version in Java.
[05:18.360 --> 05:21.360]  And there are some interesting tools to help you there.
[05:21.360 --> 05:26.360]  For instance, the renovate project automatically creates pull requests for all your dependencies
[05:26.360 --> 05:27.360]  in your GitHub repository.
[05:27.360 --> 05:29.360]  So then you only have to merge it.
[05:29.360 --> 05:32.360]  You don't have to search for the version or anything like that.
[05:32.360 --> 05:37.360]  There are also maybe ungradable versions plugins that can show you the latest versions or can
[05:37.360 --> 05:42.360]  automatically update those versions for you.
[05:42.360 --> 05:47.360]  Now, one thing to keep in mind with that is sometimes your artifacts, they change their
[05:47.360 --> 05:48.360]  name.
[05:48.360 --> 05:52.360]  For instance, first we had Java EE, as was explained before.
[05:52.360 --> 05:58.360]  And then we had the Java API package inside the Java X place.
[05:58.360 --> 06:01.360]  Now it's Jakarta, so it basically changed.
[06:01.360 --> 06:05.360]  So make sure not only to use the latest version, but also to see if an artifact basically has
[06:05.360 --> 06:08.360]  a fork or some other name or whatever.
[06:08.360 --> 06:11.360]  And actually there are also some nice plugins for that.
[06:11.360 --> 06:15.360]  All group IDs, alerted plugins, names and gradle, they basically alert you that, hey,
[06:15.360 --> 06:19.360]  you're using some older project, there's a newer project available, you should change
[06:19.360 --> 06:20.360]  your dependencies.
[06:20.360 --> 06:26.360]  So again, most of it you can automate.
[06:26.360 --> 06:30.360]  If you then go and look completely at what changed in different versions of Java, which
[06:30.360 --> 06:33.360]  you will probably encounter when you upgrade to a newer version.
[06:33.360 --> 06:39.360]  When we started Java 11, one of the bigger changes was that Java X was being removed.
[06:39.360 --> 06:43.360]  However, there are still separate builds for Java X, like the one from Glue-On.
[06:43.360 --> 06:45.360]  You can use a maiden dependency.
[06:45.360 --> 06:50.360]  And what a lot of people are unaware of is that there are different versions of the JDK.
[06:50.360 --> 06:55.360]  So you have the open JDK, there's Oracle JDK, there's an Amazon JDK, there's a Microsoft JDK.
[06:55.360 --> 07:00.360]  Some vendors, they offer more than basically the standard JDK.
[07:00.360 --> 07:03.360]  They offer extra tools, like for instance, Java Vax included.
[07:03.360 --> 07:10.360]  So for instance, the Liberica JDK, they offer a build with Java Vax still included.
[07:10.360 --> 07:14.360]  I see all JDK builds that is mentioned here still.
[07:14.360 --> 07:17.360]  I forgot to remove that one, because that project basically stopped.
[07:17.360 --> 07:20.360]  So they don't release any new updates nowadays.
[07:20.360 --> 07:26.360]  Another interesting thing that was changed was that in the past, Java contained a few fonts.
[07:26.360 --> 07:28.360]  Just a really small set of fonts.
[07:28.360 --> 07:34.360]  If basically those fonts couldn't be found, and now they are removed,
[07:34.360 --> 07:37.360]  if you do that on a normal operating system, it doesn't matter,
[07:37.360 --> 07:40.360]  because then they will use the operating systems fonts.
[07:40.360 --> 07:45.360]  But if you use a really small operating system, like Alpine Linux, that also doesn't have any fonts.
[07:45.360 --> 07:48.360]  So then Java has no fonts, the operating system has no fonts,
[07:48.360 --> 07:52.360]  and you get some really weird errors about missing fonts.
[07:52.360 --> 07:57.360]  For instance, if you use tools like Apache Poi, which you can use to operate on office documents,
[07:57.360 --> 08:02.360]  that apparently use some fonts on Red Hood, and a colleague of mine got this issue,
[08:02.360 --> 08:09.360]  and then the solution is basically to install some Java packages with fonts.
[08:09.360 --> 08:13.360]  Some other stuff that's being removed is the Java Mission Control.
[08:13.360 --> 08:15.360]  You can now download that basically separately.
[08:15.360 --> 08:18.360]  If you want to do some profiling or monitoring of your application,
[08:18.360 --> 08:20.360]  I can highly recommend having a look at this one.
[08:20.360 --> 08:24.360]  It's really interesting, but it's no longer part of the JDK itself.
[08:24.360 --> 08:27.360]  It's like a separate tool to get done.
[08:27.360 --> 08:32.360]  And I think one of the bigger changes was that the Java EE and Corba modules have been removed.
[08:32.360 --> 08:39.360]  I hope Corba isn't used that widely anymore in your projects, but Java EE modules are often used.
[08:39.360 --> 08:44.360]  If you look at a complete example, for instance, jugs B, as mentioned before, before it was Java X,
[08:44.360 --> 08:48.360]  and now it's Jakarta, so basically you need to change the imports of your application,
[08:48.360 --> 08:55.360]  and you need to add the dependencies explicitly, as it's no longer part of the JDK.
[08:58.360 --> 09:03.360]  And that goes basically for all the ones that you see here, all the different modules on the left.
[09:03.360 --> 09:06.360]  You can see the replacement artifacts on the right.
[09:06.360 --> 09:13.360]  For jugs B and jugs W, as you need two dependencies, one for the API and one for the implementation.
[09:13.360 --> 09:17.360]  As you make the switch to Jakarta, you need to make these changes.
[09:17.360 --> 09:26.360]  Also, some people that didn't switch to Jakarta, they simply added the old Java EE dependencies explicitly.
[09:26.360 --> 09:30.360]  That's also possible, but I mean those, no one will receive any upgrades,
[09:30.360 --> 09:34.360]  so if you want to receive upgrades, you should move to the Jakarta versions.
[09:35.360 --> 09:41.360]  Java 15, who's using Nashor in here?
[09:41.360 --> 09:43.360]  Let's see a few hands.
[09:43.360 --> 09:45.360]  In the past, I only saw it at conferences.
[09:45.360 --> 09:48.360]  I always found it a really cool tool, but never encountered it in projects,
[09:48.360 --> 09:52.360]  and then I worked at a company and upgraded a lot of projects from various teams,
[09:52.360 --> 09:55.360]  and suddenly I got a Nashor, an exception.
[09:55.360 --> 09:59.360]  So there are some places where it's being used,
[09:59.360 --> 10:04.360]  and in those cases, you can simply add this dependency and then you can keep on using them.
[10:08.360 --> 10:11.360]  Java 16 has a very interesting one.
[10:11.360 --> 10:16.360]  They're basically strongly encapsulating the JDK internals, so what does that mean?
[10:16.360 --> 10:23.360]  In the past, there was some internal logic of Java, basically, like reflection APIs and things like that,
[10:23.360 --> 10:26.360]  and they were never meant to be used by end users.
[10:26.360 --> 10:32.360]  They were only meant to be used by the guys who built Java itself, but they couldn't hide it away.
[10:32.360 --> 10:38.360]  A couple of years ago, we got modules in Apple Pay, and now they can hide away that logic.
[10:38.360 --> 10:42.360]  But if they would have done that immediately, a lot of applications would break
[10:42.360 --> 10:44.360]  because they would use these internals.
[10:44.360 --> 10:48.360]  But gradually, they are making it a bit harder to use those internals.
[10:48.360 --> 10:51.360]  So what happens now if you use some of those internals?
[10:51.360 --> 10:53.360]  You get exceptions like this.
[10:53.360 --> 10:58.360]  For instance, Lombok uses lower-level Java logic, and it's also something like that.
[10:58.360 --> 11:01.360]  A module compiler does not export some stuff to an end module.
[11:01.360 --> 11:05.360]  Basically, it means Lombok doesn't have access to that anymore.
[11:08.360 --> 11:10.360]  So what's the solution?
[11:10.360 --> 11:12.360]  Again, a lazy developer is a good developer.
[11:12.360 --> 11:17.360]  You work it a little while, and then Lombok creates a new version, which you add as your dependency,
[11:17.360 --> 11:19.360]  and then you can simply continue.
[11:20.360 --> 11:26.360]  If that isn't the case, maybe you use some obscure older framework or library, which is no longer maintained,
[11:26.360 --> 11:30.360]  and they want updated, then there is still a workaround available,
[11:30.360 --> 11:33.360]  and that's basically by giving some compiler arguments.
[11:33.360 --> 11:38.360]  So, for instance, via the Maven compiler plugin, you can give these arguments,
[11:38.360 --> 11:41.360]  which of course is a little bit dirty, like someone puts a lock on their door,
[11:41.360 --> 11:47.360]  you remove the lock, and then you leave the home open so everyone can again access it.
[11:47.360 --> 11:50.360]  So it's not really a nice solution.
[11:50.360 --> 11:54.360]  So please, just update your dependencies whenever possible.
[11:54.360 --> 11:56.360]  And there is an even dirtier hack.
[11:56.360 --> 12:00.360]  That is, you can start the Java process with minus-minus-illegal-access,
[12:00.360 --> 12:02.360]  and everything is open anyway.
[12:02.360 --> 12:06.360]  So that's like the really smashing the door with a hammer.
[12:08.360 --> 12:10.360]  How long is that option going to stay?
[12:13.360 --> 12:15.360]  How long is that option going to stay?
[12:15.360 --> 12:16.360]  That's a good one.
[12:16.360 --> 12:18.360]  Thank you for, that's a hop to the next version,
[12:18.360 --> 12:22.360]  because now we have another strongly encapsulated JDK internals.
[12:22.360 --> 12:26.360]  So Java 17, so it stayed for six months, basically.
[12:28.360 --> 12:34.360]  So with Java 17, the launcher option minus-minus-illegal-access no longer works.
[12:35.360 --> 12:37.360]  So you had six months to fix your issue.
[12:39.360 --> 12:42.360]  Yeah, so then you'll get an exception like this if you try it.
[12:45.360 --> 12:49.360]  So again, by now I think you know what to do to resolve this.
[12:49.360 --> 12:51.360]  Make sure you upgrade your dependencies.
[12:51.360 --> 12:56.360]  Those lower level JDKs, JDK options, those methods and things,
[12:56.360 --> 12:58.360]  they have replacements that are higher level.
[12:58.360 --> 13:00.360]  So if you use those methods in your own code,
[13:00.360 --> 13:04.360]  make use of those higher level methods instead of those lower level methods.
[13:05.360 --> 13:07.360]  Unfortunately, there is still the last resort.
[13:07.360 --> 13:11.360]  You can still use that minus-minus-add opens to still open up stuff.
[13:11.360 --> 13:15.360]  As far as I know, there are still no plans on stopping that.
[13:15.360 --> 13:18.360]  So yeah, that might stay for a bit longer.
[13:18.360 --> 13:21.360]  That's like a workaround to make this work.
[13:25.360 --> 13:28.360]  Then when you look at the newer Java versions,
[13:28.360 --> 13:34.360]  so Java 18, 19, 20 and 21, they didn't announce any major removals.
[13:34.360 --> 13:38.360]  Although the full time for 21 is still a thing under debate.
[13:39.360 --> 13:44.360]  I tried with another repository that I have for another presentation,
[13:44.360 --> 13:47.360]  and I explained a lot of libraries and tools for Java.
[13:47.360 --> 13:53.360]  I tried upgrading all of those in Java 21, and then I still got a few issues.
[13:53.360 --> 13:59.360]  So not everything worked there, but that's mainly because the compiler doesn't support it yet
[13:59.360 --> 14:02.360]  by those frameworks, as we will see in a second as well.
[14:03.360 --> 14:05.360]  But no major things are being removed so far,
[14:05.360 --> 14:08.360]  so it should be a relatively easy upgrade.
[14:11.360 --> 14:15.360]  Then one thing that I encountered a couple of times in the beginning
[14:15.360 --> 14:20.360]  was that I often got the exception in support of cross-file major version 61.
[14:20.360 --> 14:22.360]  Does someone know what that means?
[14:26.360 --> 14:27.360]  Sorry though.
[14:27.360 --> 14:32.360]  So basically, cross-file major version 61 is used to describe Java 17.
[14:32.360 --> 14:38.360]  So it basically means your stop doesn't run on Java 17, but then with the number 61.
[14:38.360 --> 14:43.360]  If you see the same with the number 65, that means it doesn't run on Java 21.
[14:43.360 --> 14:49.360]  So if you get these kinds of weird errors, again upgrade your dependency and often it's fixed.
[14:49.360 --> 14:53.360]  So I tried running some examples on Java 21,
[14:53.360 --> 14:58.360]  and then Spring for instance, they don't support the cross-file format 65 yet,
[14:58.360 --> 15:00.360]  so you get this issue.
[15:01.360 --> 15:06.360]  Often that's resolved after a while by the people maintaining those dependencies.
[15:10.360 --> 15:16.360]  So in the past basically upgrading was a matter of find, replace, import, compile it,
[15:16.360 --> 15:18.360]  and then see what breaks and fix that.
[15:18.360 --> 15:23.360]  Nowadays they're basically becoming more and more tools available to help you with that.
[15:23.360 --> 15:26.360]  So there is the more generic open rewrite project,
[15:26.360 --> 15:29.360]  which I think you can use for changing almost anything.
[15:29.360 --> 15:32.360]  It's a really advanced find and replace engine, so to say.
[15:32.360 --> 15:34.360]  And there's a session about that topic a little bit later.
[15:34.360 --> 15:36.360]  Yeah, and a session later by Tim.
[15:36.360 --> 15:39.360]  So if you want to know more about that, stay seated here.
[15:39.360 --> 15:41.360]  There is the Spring Boot Migrator project,
[15:41.360 --> 15:45.360]  which is more focused on upgrading Spring applications to newer versions.
[15:45.360 --> 15:49.360]  And quite recently they introduced the Catch Migration Toolkit from Java,
[15:49.360 --> 15:54.360]  which is again a bit more generic toolkit to also upgrade to Java versions.
[15:55.360 --> 16:01.360]  I have to be honest, I tried some of them in like simple projects to play around
[16:01.360 --> 16:03.360]  with upgrades I did in the past.
[16:03.360 --> 16:06.360]  I mostly did it by hand, because mostly, like I explained,
[16:06.360 --> 16:10.360]  it was a matter of upgrading dependencies and then see what code changed.
[16:12.360 --> 16:15.360]  And maybe I was lucky, but in most cases that was relatively easy.
[16:17.360 --> 16:20.360]  So after you've done this work, you upgrade your dependencies,
[16:20.360 --> 16:23.360]  fix the code that's breaking in your own code base.
[16:23.360 --> 16:26.360]  Then basically you're happy again.
[16:26.360 --> 16:29.360]  You can finally use those cool new features from the last 10 years
[16:29.360 --> 16:32.360]  that a lot of people aren't using yet.
[16:32.360 --> 16:36.360]  So you can make use of records, seal classes, all those cool nice features.
[16:36.360 --> 16:38.360]  And I think that's really helpful.
[16:38.360 --> 16:42.360]  So to summarize, if you look at the amount of work,
[16:42.360 --> 16:47.360]  I think if you upgrade from 8 to 11 and you switch from Java EE to Jakarta,
[16:48.360 --> 16:51.360]  it's relatively a bigger task.
[16:51.360 --> 16:54.360]  It takes you a bit of time to upgrade everything,
[16:54.360 --> 16:57.360]  get the right packages that are compatible with each other,
[16:57.360 --> 16:59.360]  and then that to work.
[16:59.360 --> 17:01.360]  Still, it's not like a quarter with a lot of people.
[17:01.360 --> 17:07.360]  It's still a matter of, I would say, depending on your application days or maybe weeks.
[17:08.360 --> 17:12.360]  If you go from 11 to 17, that's a lot easier.
[17:13.360 --> 17:18.360]  For me, it was mainly updating a Lumbok and some test dependencies,
[17:18.360 --> 17:20.360]  because tests like mocking frameworks,
[17:20.360 --> 17:23.360]  they always use those internals of the JDK.
[17:23.360 --> 17:28.360]  So they tend to break when you upgrade to Java 17.
[17:28.360 --> 17:31.360]  So if you upgrade those, then most of it already works.
[17:31.360 --> 17:39.360]  So I did, I think, like six or seven projects from 11 to 17.
[17:40.360 --> 17:43.360]  And for all of them, that was basically all I had to do.
[17:43.360 --> 17:48.360]  Only one that used some, I think, reflection logic in one of the unit tests.
[17:48.360 --> 17:53.360]  So I had to rewrite it, but I could quite easily rewrite the same test case
[17:53.360 --> 17:56.360]  with higher level logic and test the same cases.
[17:56.360 --> 18:01.360]  So all in all, I would say from 11 to 17 is easier than from 8 to 11.
[18:01.360 --> 18:06.360]  And from what I see now from 17 to 21 is maybe even easier
[18:06.360 --> 18:09.360]  unless they introduce any big changes in 21.
[18:11.360 --> 18:14.360]  My advice is always to take incremental steps.
[18:14.360 --> 18:16.360]  So don't try to do everything at once.
[18:16.360 --> 18:18.360]  First, try to make everything compile.
[18:18.360 --> 18:22.360]  And you can also tell your teammates or manager, OK, now it compiles.
[18:22.360 --> 18:25.360]  So one step further, now I do my tests,
[18:25.360 --> 18:29.360]  and then we're basically, we can deploy it and run it.
[18:29.360 --> 18:31.360]  Instead of saying, add 80% done,
[18:31.360 --> 18:34.360]  because we all know how much 80% done means.
[18:34.360 --> 18:37.360]  It means 80% of the work that needs to be done.
[18:39.360 --> 18:40.360]  So that really helps.
[18:40.360 --> 18:41.360]  Make those small steps.
[18:41.360 --> 18:44.360]  So also for yourself, then you know what the progress is.
[18:44.360 --> 18:47.360]  And as I mentioned before, I mean, we can play management
[18:47.360 --> 18:49.360]  for not giving us the time to upgrade Java.
[18:49.360 --> 18:52.360]  But in the end, I think, for us, it's most beneficial,
[18:52.360 --> 18:55.360]  because then we can finally make use of those cool new features.
[18:55.360 --> 18:59.360]  Nowadays, also spring requires, for instance, Java 17,
[18:59.360 --> 19:01.360]  if you want to upgrade to the latest version.
[19:01.360 --> 19:05.360]  So I think that's one more reason to make sure that you're up to date.
[19:11.360 --> 19:12.360]  So that was it.
[19:12.360 --> 19:14.360]  I think I have five minutes left.
[19:14.360 --> 19:16.360]  So if someone has a question...
[19:20.360 --> 19:24.360]  Coming back to this problem with the class version,
[19:24.360 --> 19:31.360]  is it because we are trying to run classes
[19:31.360 --> 19:36.360]  which were compiled against JDK 19, for instance,
[19:36.360 --> 19:40.360]  at least under JDK 17, or stuff like that?
[19:40.360 --> 19:43.360]  This is because the bytecode is too new
[19:43.360 --> 19:45.360]  and contains features in Java.
[19:45.360 --> 19:47.360]  Yeah, I think that's the problem.
[19:47.360 --> 19:49.360]  It doesn't support the newer bytecode.
[19:50.360 --> 19:53.360]  So basically, you need to upgrade your JDK.
[19:54.360 --> 19:56.360]  Now you need to update the dependency
[19:56.360 --> 19:59.360]  so that it is compatible with the bytecode
[19:59.360 --> 20:01.360]  of that new version of Java.
[20:01.360 --> 20:04.360]  So this happens when you run an older dependency
[20:04.360 --> 20:06.360]  on a newer version of Java, basically.
[20:11.360 --> 20:14.360]  Would you recommend Github Dependabot?
[20:15.360 --> 20:18.360]  So the question is, would you recommend Github Dependabot?
[20:19.360 --> 20:22.360]  I think it's quite similar to Renovate,
[20:22.360 --> 20:24.360]  which I used.
[20:24.360 --> 20:28.360]  I quite like it, but it depends a bit
[20:28.360 --> 20:30.360]  on what kind of dependencies you use.
[20:30.360 --> 20:32.360]  Because some dependencies release really often,
[20:32.360 --> 20:35.360]  then you get a lot of those updates.
[20:35.360 --> 20:37.360]  But I think it's a lot better,
[20:37.360 --> 20:39.360]  because if you look at traditionally,
[20:39.360 --> 20:41.360]  a lot of projects are done by hand.
[20:41.360 --> 20:43.360]  It's not like a funny task to do
[20:43.360 --> 20:45.360]  to find out the latest versions
[20:45.360 --> 20:47.360]  by going to the maybe repository or something like that,
[20:47.360 --> 20:49.360]  so it's often neglected.
[20:49.360 --> 20:51.360]  And if you use tools like Dependabot or Renovate,
[20:51.360 --> 20:54.360]  you basically get the issue smashed into your face,
[20:54.360 --> 20:56.360]  like you have to merge it,
[20:56.360 --> 20:58.360]  and it's more or less automated,
[20:58.360 --> 21:00.360]  unless, of course, after you merge it,
[21:00.360 --> 21:02.360]  the build fails, then you have to fix it.
[21:02.360 --> 21:04.360]  But at least I think it helps
[21:04.360 --> 21:06.360]  to stay more up-to-date with your dependencies,
[21:06.360 --> 21:08.360]  because else, I've seen it in so many projects,
[21:08.360 --> 21:11.360]  most developers don't care about it,
[21:11.360 --> 21:13.360]  and they only upgrade once a security issue
[21:13.360 --> 21:15.360]  is being found or something like that,
[21:15.360 --> 21:17.360]  then they upgrade it,
[21:17.360 --> 21:19.360]  and else it stays the same old version.
[21:19.360 --> 21:21.360]  Although if you keep it up-to-date continuously,
[21:21.360 --> 21:23.360]  sometimes you have to do some minor fixes,
[21:23.360 --> 21:26.360]  but then you don't have to do those big fixes
[21:26.360 --> 21:28.360]  when your friends want to migrate
[21:28.360 --> 21:30.360]  to a newer version of Java.
[21:30.360 --> 21:32.360]  And also there's a topic,
[21:32.360 --> 21:34.360]  a session on this topic,
[21:34.360 --> 21:36.360]  the one after the next one
[21:36.360 --> 21:38.360]  about dependencies specifically.
[21:38.360 --> 21:40.360]  Yeah.
[21:40.360 --> 21:42.360]  Regarding the open-spot,
[21:42.360 --> 21:45.360]  is there a way for Java 11 compile time
[21:45.360 --> 21:48.360]  to report issues that will throw in Java 17 runtime?
[21:48.360 --> 21:51.360]  It's unnamed class opens, you know?
[21:51.360 --> 21:53.360]  Because we are compiling in Java 11,
[21:53.360 --> 21:55.360]  but when we run in Java 17,
[21:55.360 --> 21:57.360]  then we see that we need the keys at open,
[21:57.360 --> 21:59.360]  but it's like two, three...
[21:59.360 --> 22:02.360]  There was a flag here that could warn you,
[22:02.360 --> 22:04.360]  but I'm not sure...
[22:04.360 --> 22:06.360]  Oh, sorry, yes.
[22:06.360 --> 22:08.360]  So the question was,
[22:08.360 --> 22:10.360]  the gentleman compiled in Java 11
[22:10.360 --> 22:12.360]  then run it on Java 17, the code,
[22:12.360 --> 22:15.360]  and then it breaks because some add-opens were missing.
[22:15.360 --> 22:17.360]  Basically, they're using some internals of Java,
[22:17.360 --> 22:19.360]  and he asked, is there some way to find out
[22:19.360 --> 22:22.360]  on Java 11 if I'm missing those things?
[22:22.360 --> 22:25.360]  Because then I can fix it there already, right?
[22:25.360 --> 22:27.360]  So I know there was some flag,
[22:27.360 --> 22:30.360]  something like give a warning or something,
[22:30.360 --> 22:32.360]  but I don't know in which version of Java
[22:32.360 --> 22:34.360]  that was introduced.
[22:37.360 --> 22:40.360]  What would be the solution to compile with Java 17?
[22:40.360 --> 22:42.360]  Yeah.
[22:42.360 --> 22:44.360]  Yeah.
[22:51.360 --> 22:53.360]  Yeah, then you can run it on 17.
[22:53.360 --> 22:55.360]  That's of course the easiest way.
[22:55.360 --> 22:57.360]  Yeah, sorry.
[23:03.360 --> 23:05.360]  Yeah, then you get the warning immediately.
[23:05.360 --> 23:08.360]  Or you can see that flag already exists in Java 11.
[23:08.360 --> 23:10.360]  I'm not sure.
[23:10.360 --> 23:13.360]  It was introduced sometime, but I don't know which for it.
[23:15.360 --> 23:17.360]  And thank you all.