Foojay Podcast #63: How do we keep your Java applications up to date and secure?

Transcript

Automatically generated from the audio, so it can contain errors in names and technical terms. Suggest a correction.

[0:00] How do we keep our Java applications up to-date and secure let’s find out in this podcast wel to the FJ podcast all your news about OpenJDK last month I published a Foojay blog post about the risks in systems that are stuck on Old or outdated Java versions and got a lot of feedback from developers most of them want to move on but get stuck on management decisions outdated production environments or one of the many other reasons that keep systems stuck on all Java versions and dependencies do you want to bring your system from java 8 to 23 did you know that Java 17 already got 13 security releases and that you can use tools like open rewrite to help you to update your code I talked about all these topics with several visitors of the jall conference in the Netherlands gar Grunwald about keeping your systems up to date Martin dasor about the challenges of upgrading projects Carl wanting and Charles fashing also share their experiences with migrating projects and Johan yansen helps you to convince your managers of the importance of upgrading I also interviewed Jonathan Schneider the co-founder of modna and

[1:18] The creator of open rewrite let’s start with my colleague Garrett Grunwald he’s a deil at Azul who loves Java and talking about it I asked him about the security risks in outdated Java run times and how we can keep our systems up to date the problem is that most of you probably know when you download an update right you see this security advisories that means that you always get a list of cves that have been fixed in with this update but people don’t really read it so I took the time and then created a chart and this was for JDK 17 right just to say if you start with JDK 17 General availability the first version up to 17011 then you pile up 70 around 70 cves that and that means issues security vulnerability issues that are open if you don’t update your JDK and if you just use jdk8 and you stick to the last free available version I’m not sure about the number 252 or something I think it’s more than 180 or even more cves that are open that means you provide your application with a JDK or JRE which has so many open cves you open all the doors right it’s really dangerous from a security

[2:41] Point of view so a CV what is it is a known issue which has a specific problem yeah so CV is a common vulnerability and enumeration that’s what it’s what it called and the idea behind it is that someone figures out a vulnerability right in the JDK for example or whatever software you like you can read that up everything is documented in the so-called nvd which is the national vulnerability data database which if you just search for nvd you can find all the cves there with a description what is the harm they doing and all these kind of things and like I mentioned with every update of a JDK of each of the jdks you get a list of fixed cves in with this update so that means you can really look it up I think in the advisor you can even just click on the cve it will lead you directly to the nvd page and then we’ll show you everything about this cve so you mentioned every update if I’m on version 17 am I safe depends it depends on the update right so we have four updates a year and I think it’s January April July and October or September no October is the update and so that means means every

[4:02] 3 months there is a new updated version of the JDK and JRE which contains security fixes right so and this is announced publicly and you should just go there download the latest version update your environment everywhere right and to make sure everything is secure interestingly most of the developers don’t really update to the latest JDK they have oh yeah have 170 oh what is it three yeah it’s fine it works yeah it works but still it’s a good idea to keep it up to date and there are different tools that help you with that right you can use sdkman for example we have this disco API that Foojay created where you can get the latest version of all the different distributions so that means there’s not really a big hurdle to just update the JDK it’s for free it doesn’t take long but people are lazy that’s the biggest problem I think and that’s also the distin between a long-term support version and a short-term so 1721 they keep being updated and all these ones in between that stopped somehow yeah so the idea is you have there not it’s it’s not really official right so but somehow it is

[5:17] Because there are specific versions of OpenJDK builds that get longer support than others in the past there was this name like long-term support version LTS releases which Oracle said it’s there is no LTS release but somewh it is and it started with eight then we had 11 17 and then 21 and that means if you for example look from 17 to 21 all the versions in between that means 18 19 20 these versions only get support for 6 month so you get two updates and that’s it and after that you have to switch to the next JDK version to be safe again because if you for example stick to 18 then 1801 1802 and that’s it there won’t be any security fixes for this 182 version anymore so that means if there is any vulner if there are any vulnerabilities in this version 18 you have to live with it right or you have to update to the next version which is 19 and then again 1901 1902 and then it’s 20 or 102 and then it’s 21 and 21 get updates I think up to 2035 or whatever so that means if you go to production always make sure you use the long-term supported version this is the Golden Rule right so and

[6:37] You have to really do that because otherwise bad things can happen right or if you use a shortterm version because you really need that new feature you also have to keep moving to the next short term until you back at the long term which is really I mean for small companies or for developers it’s it’s not a big deal right you just up download the latest version install it okay oh it’s there’s a new JDK yeah okay you go from 1802 to 19 no problem for company totally different story right some companies it takes really long because the process internally is not so easy to update all the stuff to the next JDK again in case you need a specific feature from an SDS a short-term support version then you have to update to all the jdks up to the next LTS right so that’s really important but it’s a lot of work right so this is and there’s even other policies I heard of which some companies have the policy they are not allowed to go to the latest long-term support version but only to the one before which comes with totally different problems right because for example if you for example go with an

[7:52] Oracle JDK which is free yeah in production nice for 3 years that means you go to 1 because you are not allowed to go to 21 so then 21 comes out but this company needs to stay on 17 but as soon as 21 comes out the license change right so suddenly you have to pay for Oracle which is really a bad thing so this is stuff you really I have a session about that because it’s really complicated and U most people don’t know right since say yeah it’s free I can use it for free yeah for some time right so where for example for the zul J case we don’t have that right so you can use Zulu for free 17 21 whatever even in production but if you would like to have support you can pay for it where with Oracle they force you to after three years if you don’t go to the latest LTS you have to buy right so which is it’s a different thing so and this is all these things and other companies do other things right I think I’m not sure if boft does something similar or other OpenJDK distributions but as soon as you start paying for support you have to make sure that your read the license correctly yeah so one message people

[9:03] Should remember is check the version but check the last number of the version of your Java right exactly so check it’s not only the feature version like 1721 but check the last one right 170 11 12 whatever right this is an important number and then keep it up to date that’s the biggest thing and remember to check it every three months yes you should oh there are tools I I’ve wrote tools yeah right if you’re on Mac you can use JDK update no I wrote to because it’s I forget about it right so because you have to check oh there’s a new version available so I’ve wrote some tools that just remind me that there is a new version I can just click a button and download it keeping your yaava runtime up to date is one important topic but keeping your code and dependencies on the latest versions is equally important open rewrite is a tool to help you achieve that it was created by Jonathan Schneider at Netflix almost 10 years ago let’s start with the goal of open rewrite at this point there’s this General concept we have called text act liquidity which is the idea of being able to move from one state to another

[10:14] And that could be a framework version update like a spring boot two to three or it could be a Java upgrade like Java 8 to 21 or 23 whatever the latest version will be but it could also sometimes be like I’m trying to get off of one vendored API and move to another or one database to another and so anything that requires Mass code change like that and it’s based on Reyes right yeah there’s a there’s kind of two parts to it there’s the data which is we call the lossless semantic tree which is not the text of the code but and not the abstract syntax tree but the abstract syntax tree with everything the compiler also solve about it so when it looks at a particular method it tries to figure out where the declaring type is where it came from all the dependencies all that’s captured in the LST or the loss of semantic tree and then recipes are programs that iterate over those trees and make modifications to them those modifications can then be materialized back to source code to present a death essentially I saw some demonstrations of this so if I move from a really old spring to the latest spring it’s

[11:31] Actually going version by version I can upgrade my code that’s right that’s right so these recipes themselves are compositional so you can have an individual step like change a method name or upgrade a dependency but then recipes can have lists of other recipes so then of course it’s recipes of recipes and recipes and so the way we’ll TR tend to organize this will be like you know to migrate to spring boo 34 now you have to migrate to spring boo 3 3 32 3 130 which involves a Java 17 upgrade which involves a Java 11 and 8 so like it will Cascade like that and each one of those steps individually is a recipe that can be ran or you can run the whole bundle all at once so theoretically if I am on Java 8 an Old Spring I could move to Java 23 new spring all automated that’s right yeah that’s the goal and would that be a good idea to have it truly up I think that’s that’s something that we see you know just thousands of occurrences of now what what’s gets interesting I think is the social engineering or the social dynamics around accepting large change like that and so some people will just be

[12:47] Very what I call yippy Cay like wild west you know like yeah I’ll just take it all and you know merge it roll it out that’s my personality some people are much more reserved and will want to take one of those individual steps and run it first and get into production and then go back and run one of the larger pieces and so it very much depends on the risk tolerance and how much test Automation and everything there is in the project accepting the change yeah but because yeah it’s a list of Reyes that gets executed you could indeed do one push your changes wait for your test result and then go on to the next one and so a very common thing I’ve seen is like for organizations trying to get to Spring boot 3 for example we’re just focusing on the spring for a moment but there’s of course recipes for corus micro do and a bunch of other things as well people will sometimes say like well let’s just get Java 17 first even even maybe not 21 or 23 just let me get to Java 17 first you know you could stay on Spring boot to and get to Java 17 so it’s it’s at least a step in the right direction

[13:56] Get it to production operate it for a little bit then come back can run the larger recipe at later time I can imagine that writing these recipes is not that easy who does that is that your company who does that is that the community it’s mostly community at this point I think whether it’s easy or not very much depends on what’s you know what’s being done I think at the framework supports a very lowlevel visitor pattern traversal of the LST and all of its data and that’s the being exposed to that level of data requires some you know learning about the structure of code but recipes also encapsulate higher level types of Transformations like change a method name for example you could just use a recipe with an option which is change method name you just have to specify the target declaring type and the original method name and then what the new method is you don’t really need to know anything about the LST to use it so a lot of large complicated migrations are assembled from these building blocks that have been provided at higher and higher levels of encapsulation over time so it’s a tool which is free available

[15:11] It’s an open source project so what is modna doing as a company on top of this yes so open reate is a Pache license right now and we think that’s essential because the ecosystem so broad so recipes should be provided by framework authors as they’re making breaking changes in other words if you break it you fix it that’s the that’s my Mantra and of course there’s a lot of them so requires participation up and down the stack for mad we provide multi- poster experiences on these kinds of things which we’re going to take a recipe and run it on potentially billions of lines of code or tens or hundreds of millions of lines of code thousands of repositories what’s not so obvious I think with open source is that recipes in addition to making changes can also produce what we call data tables can emit structured data out of the LST in rows and columns so in a tabular form and so large scale impact analyses are done at Broad scale by writing recipes that extract pieces of information out of the LST and I’ll give you an example of that we had one customer trying to move from Oracle to postgress

[16:21] So you know we’ve all been in situations like this where somebody comes down and says okay let’s let’s move from orle postgrad like how long is how many hours is it going to take how many engineering resources do you need and it’s you know when you have four or five thousand repositories it’s an overwhelming question you don’t where is the workl specific syntax I don’t I don’t even know so these projects are hard to estimate what that kind of effort would start by writing a recipe that would just admit every SQL query rip it apart look for Oracle specific syntax and what you wind up with when you run it on all 4,000 repositories is an inventory of where exactly that problem is and what the problem is and then you can sort of plan that migration so it’s that multi- repository impact analysis and transformation that we really add on top of open right okay so I guess so open rewrite helps you to evolve your project while Monna helps you to keep track of a lot of projects a lot of different repositories and so companies and eventually move them forward yeah the tool itself open rewrite is

[17:32] Also I know it exists also in Visual Studio code as an extension I think created by Microsoft are there other ways other places where we can find op rewrite yeah so jet brain’s also natively integrated open Rite as a plugin not really as a plugin but I suppose it’s a it’s a native plugin that chips with the IDE now as of this year Amazon qod Transformers engine the thing that actually does the work of transformation is open rewrite underneath the covers now just a few weeks ago Microsoft announced Microsoft get a copot Upgrade Assistant is also based on open rewrite broadcom has a product called broadcom application advisor which is more narrowly focused at Spring upgrades that’s also built on open rear right so I think we’re seeing this kind of broad uptake of this is this framework as the way of specifying Transformations MH I think this is the great thing about as you mentioned it’s open source so everyone can build these recpes and everyone is responsible to maintain so is for instance the spring team creating the recpes for spring they do some I think the spring

[18:49] Team is a bit they’re also trying to productize a commercial offering around broadcom application advisor so they don’t share all the recipes they create back with open source that’s unfortunate I think you know the micro entertainment Oracle for example has created recipes for every breaking change they made for the last three or four years and open source them so I think their behavior is a little more commendable I think than what we see from the spring team right now but you know everybody has a different position on this we see the AWS team providing AWS SDK updates in open source Maven authors junit authors kind of up and down the language stack a lot of folks are really providing them back so the people that provided most of the open source recipes for spring boob migration it was partly Madan working on it was partly some of the large Banks we work with they can’t wait for the spring team to write recipes they have tens of thousands of apps written on this so it’s been a collaboration I think of a lot of different parties that are all

[19:59] Hurt in some way by these migrations that have provided them to that large set that exists today which is great the community just works together to fix these as an expert in upgrading and keeping things up to date how do you look at the problem of companies being stuck on an older Java why what are the advantages of upgrading for such projects there’s of course improvements in the JDK itself but I was just talking to one of our banking customers Executives a few weeks ago he has a regulator hounding him his business unit about one particular vulnerability in an appli in a library and I don’t won’t say what the library was but that library’s the minimum fix version that includes that the fix for that vulnerability has a Java 17 Baseline now now this whole business unit is right now running on Java 8 and so you know my initial thing is oh great we have a Java 8 to 17 recipe yeah but all these applications are running on web spere a web spere version that only supports up to Java 8 so you can see how this becomes this like sweater thread pole like I just wanted to fix this

[21:20] One vulnerability but to do that I have to move to Java 17 and to do that I have to rebase everything from web spere onto tomcat and so this is something we we’ll do with them you it be it is planable it’s just that to fix this one thing wasn’t just a dependency version bump it was the whole Java AG 17 thing was web tocat which means web seere mq to rabit mq which like so it becomes a more complex recipe that involves multiple pieces ultimately so it’s not only the Java language or a specific version for the runtime but it’s also the whole system the production system where it runs on absolutely so I mean go back to the spring example spring boot 3 I think also had a Java 17 Baseline that’s not going to run you know on this particular application server so you wind up having to upgrade the whole thing you know the whole infrastructure stack as well from what I learned myself and from experience from others the big change is from java 8 to let’s see 11 which is then the next LTS but is it correct that once you’ve passed that point of 11 things are a lot more smoother and easy it that was

[22:39] The most dramatic change that Java xarda migration was a big deal for a lot of customers of course not all of them use the Java X packages so it’s it’s easier or harder depending on how much that surface area exists in your applications there are little things though I think that there’s for example a Constructor for double just a regular capital d double box type the Constructor for double has been deprecated and it’s scheduled for removal and so you have to move to a static Builder now double out value of so these like little things like that and there can be it’s some cases tens of thousands of occurrences of that throughout the codebase so it’s you even small things can be pretty annoying when you’re trying to move from one version to another I love those things too because something like that you know double that value of I there was we were working with one customer and that change was proposed and they actually rejected the whole language version update because of it they said I don’t I don’t like that style I would prefer to continue to use

[23:55] The double Constructor and so that’s like again that’s social engineering problem where we had to educate a little bit and say I don’t like it either but this isn’t optional you know like it’s that the Constructor is going away so we don’t really have a choice here and just that little bit of human communication helped to you know break down the barrier that resistance barrier to getting it done and like for instance for that conversion from double to double value of is there a single recpe to do that through all through the whole code so that could be that would be contained within the larger language version update but it can be ran in isolation as well yeah so you can push that one single change across the whole of your code as one commit yeah and then yeah indeed have this fight of is this an ugly way of writing it or not that’s right and that brings up a good point some of these things are required like double that value of is not going to be optional sooner or later but some things are more just more idiomatic like there’s a new string. format instance method in Java

[25:02] 17 which looks better in many cases in the code than using the static string up format method that’s existed from almost the beginning of java itself but you know that can be that can dominate the changes if you do a Java 17 migration you can have a lot of string that format calls and so often times people will set that recipe aside basically remove it from the that migrate everything else and then come back and do that in a separate commit so that commit contains just m the you know idiomatic changes to the new string. formatted instance method okay but yeah it’s a nice message that even if you’re stuck now you should really think about how am I getting past this point of where I’m stuck and move on because one day it will be needed yeah yeah and the day is coming sooner and sooner I mean the our applications depend on more and more third party and open source stuff it’s really an industrialized software development ecosystem and your supply chain is moving out from under you so it’s keep up or you know application stop functioning sooner and maybe even there’s a bit of

[26:18] Of cost benefit because yeah better newer Java runs smoother requires more less resources maybe even I’m sure you’ve I’m imagine you’re talking about this in other blog post as well but garbage collection alone is a huge benefit of just moving from jav 8 to 17 if you change nothing else I think it was something like what 30% Improvement and just r or G1 collector U makes a huge difference so maybe a bit of the cost of changing the code is regained by having a more a better production system which actually leads to another interesting point that because recipes are programs they’re just regular it’s not like a query language like SQL it’s like it’s a it’s a program it’s a class we’ve seen some interesting situations where people have stitched together online systems or stateful systems with the data at rest or the code at rest which is really the loss of semantic tree so there was one you know one organization just a few weeks ago that wrote a recipe really clever wrote A recipe that looked at the kubernetes manifest in a repository looked up the application in the

[27:32] Monitoring system for the demonstrable usage of like CPU and memory and then adjusted the resource requests in the kubernetes Manifest to better match what was actually being used in production and so you know afterwards they could actually scale down their kubernetes nodes you know basically just like cut the Reon sources available to them and the like estimated annualized savings was like $5 million or something like that so you can imagine if you changed nothing else but mve Java to 17 and did something like that your memory requirements on a cluster like that go down substantially so that’s what you said in the beginning it’s not just a tool to rewrite your code that’s right can even help you with your devops right right people who are interested in open rewrite modna where should they start looking at are there easy examples with some migration stories where how they can test it yeah I think if you look at m.ai so it’s m mod NE that AI at the top of that page there’s six key use cases that are fairly common so security vulnerability repair framework migration Etc and those will sooner or later Point

[28:57] Down to the individ ual recipe examples that accomplish those things as well Martin dor is a Java developer working on systems used in education in the Netherlands he has a long history in Java and has a lot of experience with the challenges of upgrading projects well we constantly monitor of course the Java ecosystem and we upgrade our software so we you started I think in Java 5 migrated to Java 6 Java 7 Java 8 until recently we migrated to Java 11 and we’re currently on Java 17 what is the most difficult move from 78 811 1117 can you compare that the yeah we had some unfortunate incidents I worked also at the primary school system and we moved from java 6 to Java 7 and that worked pretty well but that caused a lot of synchronization issues in our multi surf application and so we were constantly waiting on deadlocks in our application and or we tried reproducing it or to try to do performance test in our own test environments but we couldn’t get the same amount of load our users triggered so it was constantly okay put the

[30:28] Version live oh now it’s it hangs on this point take a step stack dump find out what the lock was transform that into a non-blocking code and then set put the next version live and until we had all the bottlenecks ready that was the biggest problem we had with upgrading Java frame Java versions ever since we learned to first put the Java version update the Java version for the time without changing your code and then only after that RNs very well modify the source code as well that’s something people don’t realize so you can run an old version Java on a newer runtime in production yep so that’s the first step try your application on a newer runtime and then start moving into the code yep that’s that’s what we currently do so now we’re now container and such so you just ship your Java version in your inside your container so it’s just packaging the new version in your container and then shipping it and not change your source code because otherwise you’re married to that particular version you can’t go back one of the things we learned back then is you always need

[31:47] To be able to go back to the prior version otherwise you’re you’re you’re hurting your users too much why do you want to move is it to make your developers happy that they can use the latest Java is it performance is it security what are the main topics there all the things so it’s very difficult to get new employees if you’re not working with new technology and I think the Java ecosystem is moving very very quickly ahead and improving quite a lot but performance every new release or a long-term release gives you better garbage collection fewer bottleneck in locking experience easier to write code all the kinds of stuff that all the goodies that you enjoy it’s mandatory to incre to upgrade your Java versions also for security reasons as well and if you want to keep with the times with your with the ecosystem so if you want to enjoy for instance wildfly and new Jak Jakarta e versions then you have to move with wildfly and wildfly stopped supporting Java 8 quite a while ago with Carl wanting and Charles fashing both

[33:15] Doing Java development since the early days I also discussed the approach to keep Java applications up to date but first I asked them how the curing Java is different from the one they started with is it still the same language oh hell no I started with stuff going oh back to orik doing some remote remote client server type work and a lot of client side work so swing and the UI framework before that awt so yeah it’s it’s completely different there weren’t lambdas there was so many new things now it’s it’s different so I started with Java 1.3 and back then it was a lot more verose a lot more structur you had to really write things out and really know the syntax and the structures and what does what and I would say nowadays it’s a lot more intuitive it’s a lot quicker to think it’s a lot more Behavior driven thinking what do you want to do and then the code does a lot of the thinking for you or a lot of the plumbing for you and I would say one thing I respect and think takes a lot of effort is the backwards comparability of the Java nowadays especially with Java 23

[34:38] All the way and then some features and some pieces do get dropped but there’s a very long let’s say compatibility window yeah and I think that’s commendable but I think it takes a lot of thinking it’s compatible with older versions so you can run your old application I yes you also went through a lot of transformations of your applications how do you look at going from java 8 to 11 to 17 with an existing application is that a joy to do it’s not a joy it’s but it’s not a chore it’s fairly simple you run a couple of scripts you fix a few minor problems where things need to be changed that just that don’t get changed by the scripts that you can find and for the most part it’s actually fairly easy Java 8 to Java 11 was way more difficult than 11 to 17 but 11 to 17 was changing a version number recompiling and fixing one or two little things and I expect 17 to 21 and 21 to 22 and so on to be even easier so the newer versions are much more stable but bringing developer improvements and runtime improvements quite yeah yeah I would say pre Java 9 Java 8 was quite a step up into

[35:57] Functional programming as you said but we’ve at my client still have pre Java 8 infrastructure and Legacy systems so to upgrade them all the way to Java 2123 is going to be a challenge we’ve decided also to upgrade some but we said let’s upgrade the platform first and then keeping the Java Edition back because that with the Java ecosystem and the libraries and the maven and all of that already brings a challenge in itself and then upgrading to a newer Java version we could we don’t have to change a lot but I see a lot of people say it’s an opportunity to improve your code to remove some technical debt to improve your system and with that you really have to then think of how do we change it for a better so it’s it’s not a rewrite but it’s it’s a hybrid kind of upgrade with Rite so yeah support for Java 8 will end in a few years so they said a few years ago that’s right so it changed again but still it will end one day so people who have a running application which are stuck to Java 8 what should they do they need to move absolutely there there’s no doubt about it that they have to move

[37:24] Either move or completely rewrite and some companies I guess are taking the option of completely rewriting some will stick on Java 8 without support the amount of technical debt the amount of customization that they’ve done that kind of makes it prohibitively difficult to transform from 8 to 11 if you’ve stuck with a Vanilla Java and you haven’t gone and done funny things it’s really easy should they move absolutely the benefits in the garbage collector alone make it a worth while move and that the benefits that are continually being addressed actually make the proposition of going version by version as they released into a stable version make that a really compelling proposition yeah you agree yeah yes or no so I would say there are benefits as we said U it’s not only new features but the stability and the efficiency of the JVM has really improved but for people who are really hard and fast of saying we don’t have the Manpower we can’t move it’s too complicated you can stick with let’s say a free to use a JVM like aul it’s not it has commercial versions but it’s not

[38:50] A mandatory one and then if you run out of support yeah it’s a risk you got to take but also remember though is that by not upgrading at the same time the further and further away that you get from java 8 and I’m pretty sure Java fire for a lot of people the further away that you get from the current architecture on motherboards and chips it’s not Unthinkable that we could have a different chip architecture in the next 5 to 10 years that means that Java 8 could in fact be completely incompatible even down to an architecture on the motherboard and the chip level with the latest version of java which means that at some point it might actually become impossible to upgrade directly so companies may see a step where they have to go 8 11 17 and then jump to whatever the new version is so the longer they wait the more pain they’re buying themselves Johan Jansen a software architect shares some of his migration experiences and how you can convince your management that there are many benefits of upgrading your projects we actually did some migrations in several projects so that was sometimes a bit of a hassle but in the

[40:00] End yeah mostly it’s quite manageable I think the biggest discussion is always to convince management to spend some time on it but then mostly it’s quite easy to do and nowadays you have helped with tools like open reite and other tools that can assist you basically and I actually gave a session in the PST as well on how you could upgrade from one Java version to another so I always try to stay up to date with Java versions as as much as possible basically what do you tell to people people who say yeah we are stuck on Java 8 because of many reasons do they have can they stay there or do they really have to move I think it’s weird right if you have a car you also do maintenance and make sure that’s up to date because otherwise one point in time it will break down and that’s probably An Inconvenient time well now you can plan a convenient time to do the upgrades so normally I will also always suggest to upgrade unless you know that your application will be removed after like I don’t know a year or something that it might not be worth the investment but if you think you will continue running it

[41:00] You should upgrade it basically so you gave a talk about this subject what were your advice is there so basically my advice was that well often it’s a discussion with management to convince them it’s also in your personal benefit because if you upgrade Java you can use all those cool new features so you should also spend maybe some effort there so what I did in the past for instance was when I did my hours for the week I spent a few hours upgrading Java see what broke and then I could give a bit better guess at how much time I would need to fix it and then I could say ah if I have a week more I can fix it and then mostly you get the week what I saw with a lot of people is they say it takes a couple of months with a couple of persons to do the upgrade and then management of course says yeah we don’t have that time while in reality I seldomly see that it’s so much work so it’s more of just try it and see what happens and then investigate exactly and now especially with tools like open rear ride you can just run it and see if everything still compiles and the test still run so it’s even easier and in

[42:02] Most cases if you’re a bit up to date with your dependencies because that’s most of the work mostly then upgrading the Java version is quite okay in most projects so basically what open rear ride does is it’s sort of a recipe based tool and they have all kinds of recipes so for example they have recipes to go from java A to 11 or whatever version and then what it does is it upgrades the dependencies but it also changes the code so for example now we have that multi-line string if you had the old way of declaring strings it will automatically convert the code to the new style and it’s basically git based so you basically get some git changes and if you don’t like them you can ignore them if you like them yeah then it made your migration a lot easier well already using all the new features in Java that you also don’t need to do by hand so it brings quite some advantages again a shout out to open rewrite as a handy tool to bring Java code to the latest version in the next podcast you’ll get the remaining jall interviews about various topics see you then and thanks for listening give me a f give me a j give

[43:08] Me the friends of OpenJDK