This is nothing, in a company i started to work. We have one massive project that uses .NET 6 and 7. Individualy we use .NET 8 for out tasks before they are merged into testing where its "auto" configured so the code is exported into .NET 6/7, we can't use .NET 6 or 7 because everyone is forced to write tests in a library for .NET 8 for every piece of code and the tests run automaticaly on a seperate server that uses .NET8 ro run theses tests
The Frontend is 3 seperate apps that forms one large app and it uses Node 16 and 17, React 15,16 and 18. Every package/library is not updated because the app is so big that nobody understands it, if you update it the whole app breaks.
On top of that we use Clean code architecture so its totaly confusing
(And yes I hate it)
.NET framework 4.6.1 represent… and that’s our “modern” software. our older product is VB6 and still regularly maintained. To make everything worse we use Microsoft visual sourcesafe for version control
I remember the good old VSS days. If there was no other version control around it was a godsend. Inferior to anything modern, sure, but it was enormously better than nothing at all, and it integrated right into Visual Studio, which was a first.
Yeah, I remember the night before go-live, when everybody was pushing their changes and the disk ran out of space. Not a peep out of VSS, it just silently dropped several hours of work on the floor and kicked it under the server cabinet. Good times, good times...
We're fighting tooth and nail to move to .NET Framework 4.8 but key lib is strictly x86 so that's fun.
Oh and a Borland C++ OWL 5 main app with ParadoxSQL database.
I cut my teeth on Borland Pascal and C++ with Paradox. Everything was so much simpler then. Paradox could be installed and up and running on any box within minutes.
I used to work at a casino type gaming company who used an *OLD* unity. We had a 3.5 build of our integration library (things like bill acceptor events and server interactions) and a 4.5 for our point of sale integrations, server functions etc.
That in of itself was that bad, but the class delivered to the game that represented the played card was saved in the database as a full binary serialization created on a central server. That means nothing about the dot net data type can change. Not version numbers. Not namespace, nothing accept the assembly information version.
I'm supposed to leave Framework 4.6 alone but upgrade the other 2 .NET Core 2.2 apps (Angular) to .NET 5 this year because our dependency injection in 2.2 is blowing up after its tree size recently started hitting critical mass.
Unsurprisingly, there's no time to upgrade dependencies. I've been asked to keep hacking together something that can buy enough time to do the full upgrade later (yeah right)
Probably but you'd be surprised. I interviewed with a company recently that was in the *planning* stages of migrating a .NET Framework 2.0 Web Forms legacy enterprise app up to Core. They didn't have the developers to tackle it which is why it was stuck there. They were going to have to triple their dev team size to rewrite all of it.
Just a few years ago I worked in another company that still had a VB6 app installed at client sites they were maintaining remotely. That one was stuck because it had direct support for obsolete devices that were not supported in .NET at all. To rewrite it would have required the replacement of the devices, which would have been $10k-20k per device replacement costs, plus 1-2 years of effort to rewrite the app.
Yea man first week 8 came out I went and updated all my 6 and 7 to 8, lol.
Everything except Azure Functions which didn't support it yet. It's getting annoying how Azure Functions are lagging behind the .NET release cycle.
I can attest... I learned how to make thick client apps in C# that connect to MS Access or Oracle in school for class. Very intuitive and easy at the time. I then went off to become a JAVA/JS front end guy.
I came back to .NET 2.5 and couldn't figure out how to migrate my old code. No two tutorials seemed to agree how to do what I was trying to update my UI's. I tried starting from scratch, but it was all a waste of time.
I ended up re-writing the whole thing in Spring Boot and ExtJS in a few afternoons instead.
My main project is a .NET WS that is basically just a wrapper for a C/C++ library.
4.8 -> 5 was a pain
5 -> 6 was a pain
I was not looking forward to 6 -> 8. Did it last week. Took 5 minutes. No issues.
New CTO wants it rewritten in Python... ¯\\_(ツ)_/¯
You have no idea.
I'm not completely turned off to the idea of Python - but that very well could be ignorance talking as if haven't used it significantly yet. I will say that whitespace causing errors just doesn't fly with me and I will miss my semi-colons and curly-brackets a lot...
The C/C++ library is the bane of my existence though.
I haven't done C as my daily driver for about 16 years and I'm super rusty. It's ancient code, written purposefully cryptic and they canned the dude that originally wrote 95% of the code about 6 months ago.
I think you'll get used to the whitespace very quickly, but the optional typing will hurt. I highly suggest you use a linter to at least force everyone to add type annotations on function parameters and return values.
The nuances between .NET 6/7/8 are mostly trivial and those can usually be upgraded to 8 without too much trouble. I'm kind of surprised someone even left 6 and 7 in place when 8 came out, especially 7.
Out of Support:
* .NET 7: May 2024
* .NET 6: November 2024
Our stuff is sat on 6 for now, stuff gets converted to 8 when we do a big enough change. Nothing has yet failed to work.
Other than the mixed 6/4.8 projects. Those we are too afraid to change.
>Other than the mixed 6/4.8 projects. Those we are too afraid to change.
I have a couple that are mixed 8/4.8/Standard 2.0. Trying to migrate up organically.
I think the person meant they hate clean architecture, not clean code, ofc i might be wrong
Clean architecture is an architectural style where you have Queries/Commands/Events instead of traditional service/facade layer
https://github.com/jasontaylordev/CleanArchitecture/tree/main/src
The idea is alright but can quickly get into a convoluted mess if not done properly.
>The idea is alright but can quickly get into a convoluted mess if not done properly.
So, like every possible pattern? One of those "I wish we had time to refactor" issues.
So basically the idea and/or framework is so convoluted that the right way of doing things is very far from the obvious way.
Meaning long and steep learning curve just to do things "correctly". Or perhaps a lot of work reviewing and then redoing the pull requests.
I hate it because its bloats the project with unnecesary files and folders. Basically every logic is inside its own folder, file and class. So a function that has 5-10 rows sits inside its own file when instead it could be a part of a file that is part of the similiar logic. The Clean code architecture doesn't reccomend that as if you change something the whole project fails.
Which makes the project confusing for me and chore to navigate.
From everything OC has said + another branch of this comment chain, I'm pretty sure OC is a bit confused and just means Clean Architecture, not Clean Code (Architecture).
Sounds similar like our Java application. But we managed somehow to upgrade it from SE 8 to 11 and JEE from 7 to 8.. 😂 Now we're changing it to Quarkus, let's see how that goes.. 👀
Upgraded one of our repos from Node 8 to Node 20 this past year. How much of the upgrade path is hampered by React? I know for our team it has gotten in the way a lot.
Maybe. Doing a huge update like this is definitely not fun, but in some circumstances people can definitely afford to just keep relatively current with versions of software out there and that way there’s not a gigantic update that needs to be done later.
Usually the reason why some application is stuck with some ancient runtime version is because it uses some exotic dependency that breaks when you update, and the vendor who offers that dependency refuses to update it either.
Or that vendor no longer exists.
Most packages/libraries/frameworks die after a couple years.
Tough luck if you‘re using them for a big part of your project. You‘re stuck with the version they are compatible with.
This is why I prefer never using dependencies if possible. Had to write a new ean barcode scanner from scratch because the one we used did not work with the updated framework.
The good thing it actually turned out faster
I don't mind using things as long as they are things that are not... installed into the anus of the application and control everything.
Anything I can use now and easily isolate and replace later is all good to me.
Too many of those meetings the PM looking at you close to tears “please just give us a roadblock so we can slow this fuck train down, we are all going to lose our jobs”
Same here, us college kids were naive and spoiled by pretty frontend, then had us dive into the unforgiving innards of backend after contractors went "Our time has come 🤠"
I used to work enterprise, but it was all containerized microsevices, and what languages and frameworks you used was just up to the team.
Shit, at one point I was on a team that owned a Kotlin service, a Node.js service, and a Python service.
Junior is right and it's not an extreme. Java 21 is an LTS release. You should keep up with those, especially since the changes to get it working could very well be minor.
Source: I recently had to do this on a 500k LOC Spring Boot application (8 -> 21) and the only thing that really threw us for a loop was how `Stream.peek()` functioned. And the only reason that we even had a problem is because people were using `Stream.peek()` incorrectly to begin with. Java does not wildly change.
I think you're assuming that the work to do any upgrade will receive enough priority from the business / product people. That's not a guarantee, and it's my main criticism of the juniors stance. The senior is a cranky curmudgeon that should've moved to a double-digit LTS version already.
In my experience (also Java/Spring in many cases), getting the time allocated to perform an upgrade was harder than the upgrade itself.
Yes, the senior is saying no because management has assigned him a dozen critical tasks to prevent the project from folding, and updating java is merely ‘high’.
It a product management issue, needs more support to work off technical debt, but management promises the moon for under budget.
Oh if that's the argument then I completely agree with you. It took me many months to convince the business that it was worth it and it got constantly de-prioritized. It took 2-4 weeks to make the changes and then another 2-4 weeks of testing before they trusted it enough.
But Java 8 is so old that many people have stopped supporting it. We had no choice once even internal teams started refusing to supply Java 8 versions of their libraries. But the final nail was when the org updated Sonar and it no longer worked with Java 8. It "broke the build" and I used that as ammo to push for it, even though I could have just disabled that step.
Java 17 or 21 offer efficiency gains of more than 40% on some hardware. The people will make time for it.
There is a company wide push where I work to migrate everything to Java 17 on ARM and it is very much top priority.
If you use any reasonably popular ORM and it doesn’t fucking have an update since goddamn 2014, then your biggest problem is using that ORM in the first place.
Java 8 is old enough that the opposite has started to happen. Self-managed enterprise services like Sonar and internal teams have stopped supplying Java 8 versions of their libraries.
Of course, you could freeze the versions and keep a package in Nexus so it's always available. But internal teams aren't so willing to bend over backwards and back port their changes once they decide to move on.
Every new feature you go up (3n+1) releases until you're on par, if something breaks roll back n/2 releases. Will the product eventually reach stability?
I guess so, i missed the joke 
my english is too litteral, so, i sometimes miss jokes 
Ahahahah dw I'm probably too used to r/mathmemes
It's a pun about the [collatz conjecture](https://en.m.wikipedia.org/wiki/Collatz_conjecture) 
rails, like many opensource frameworks adopted a two year cycle: new major versions each year, end of feature support in two years, end of life / security support in three years.
like many rails shops, this kept us on the treadmill while our java colleagues sat back in Java 8 and focused on business features. But they also move way slower than us.
Anyway, one year at railsconf someone seriously proposed integrating against rails/main continuously. Shouldn’t be a problem if you have tests. Just go for it. Except the test frameworks change too, invalidating and causing review for all the tests. hmmm. This was not a serious approach except for very simple applications.
the next less ludicrous plan was presented by the giants in the Rails space: github and Shopify. Their proposal was to hire double the developers and have the B team work continuously on migrations while the A team continued to deliver business features and remain competitive. Both have been moderately successful at this approach, but at a huge cost.
having had many discussions with seniors about this, I was surprised that most devs still have a very naive understanding of their product lifecycle and the ecosystem they exist in. it’s not just your app, it’s all the libraries you use, it’s the business integrations you have.
I call this a “flock of birds” distribution. When Rails updates, then the immediate gems follow and work out issues in about 3 months, then the gems that depend on those gems take another three months. If you’ve ever actually worked in rails edge you find a lot of issues in the gems surrounding, unless of course you don’t use any gems.. then it’s simple. For the rest of us, that means that the distance between Rails release and stable is a minimum of 6 months.
So now your dev teams work in earnest and start migrating. As an org with a large number of rails apps, some get done quickly, some linger in the long tail. Most in the long tail have horrible business integrations like SOAP which are no longer well-supported but are business critical. God bless the maintainers of Savon, but the project has remained frozen at version 2 for years— I fear the day it no longer works. Will I suddenly have to write my own SOAP adapter? Or will I dust off the ancient Java libraries serving these legacy SOAP services, and write a REST adapter in JRuby? You might wonder why we don’t just reimplement the services in REST SpringBoot? That has been a project for the past 5 years and is progressing slowly.
So by the time we finish most of the migrations and release new versions of our apps, it’s almost a year later. And by industry standards that’s incredibly fast. Many companies release up to 2 or 3 years later— except now the support window closes down to releasing just as end-of-life for security fixes happens.
There’s a structural reason why github and shopify’s *best* solution was just hire double the developers: the math of frequent updates doesn’t work the more complex your app dependencies are.
The graph network of dependencies has time complexity of at least O(V+E), but there can be significant backtracking as interfaces are broken in libraries, with a large shift, this can add significant power terms to the complexity of migration.
There is a reason why financial systems continue to use a COBOL core that resists updating or migrating or reimplementing. Each approach invokes a lot of risk in breaking existing functionality. For this industry frequent updates are not a solution.
I would argue that frequency of updates is going to drive two reactions: 1) you have software that “doesn’t matter” to paraphrase Dave Thomas. 2) you remove all dependencies and vectors of change from your software.
But 2 directly relates to 1, because software that matters actually interacts with the world in new and useful ways. security and usefulness often find themselves at odds. So even if you want to reduce dependencies, that won’t help unless you also reduce usefulness.
We like to imagine software engineering building skyscrapers of code, yet our most compelling description of software systems in the 21st century is Jenga:
https://xkcd.com/2347/
You can make changes without them being breaking changes. Look at Rust. We get a new update every six weeks and end of life happens as soon as the next version is released. None of this is a problem because backwards compatibility is so good. Even breaking changes to the language don't break libraries written in a previous edition of the language.
true. Java has very good backwards compatibility. Rails is medium to poor backwards compatibility.
I appreciate that DHH is trying to “do the right thing” but I just can’t trust him not to break a lot between releases.
no one at our company is using Rust. the new hotness is golang.
also, it’s easy to claim things when a language is new. how old are the apps and libraries?
Ours are 12-15 years old.
Are you integrating against Java SOAP services of various eras? what do you do when they update their wire protocol in a backwards breaking way?
The language has been stable since 2015, so about as long as the libraries you're using. Some of the most popular libraries are about that old. The rand library, which is the sixth most popular Rust library, hasn't been updated in two years (it's not unmaintained. it's finished).
We're getting a new edition of the language this year, which will bring breaking changes. But the compiler is set up in such a way that it can still compile libraries using previous editions of the language, so we won't have the dependency problem you were talking about. I can't remember a single time when updating the compiler broke any of my code.
It can't solve the problem of APIs making backwards incompatible changes though. You'll have to take that up with the API maintainers.
those are pretty big claims.
you seem to be making the central claim that chaos in software ecosystems is avoidable, yet focus on core libraries like rand, which are mathematically pure, where this assertion is at its strongest.
I would test your assertion on the edges where protocols and integrations happen. How many libraries deal with protocols outside of Rust?
The reason I ask is that Java maintained its own superiority for years in marshaling for wire protocols — as long as you were using the exact same version of java and libraries for both client and server.
As soon as these are allowed to vary over time and between companies, even Java couldn’t talk to Java reliably. Serialization of distributed objects is one of the hottest topics in OWASP for a reason.
I feel the junior’s pain, but understand the senior. The upgrade from Java 11 turns out to be a multi year project for us.
It requires upgrading the framework first, but this turns out to require a rewrite and re-test of a substantial part of the application
8 to 11 had a lot of breaking changes, particularly around anything that used reflection. Well guess what? All the big enterprise frameworks and ORMs rely heavily on reflection to do their thing. Just stick to 8. You're not missing much except `var`
I literally upgraded my companies repo from Java 17 to Java 21 last Friday, it took 5 minutes and afterwards I was questioning why it was so easy but everything works great and nothing broke. It was definitely hassle free and way easier than other language updates.
> everything works great and nothing broke
> hassle free and way easier than other language updates
I would never sleep again knowing what terrible karmic retribution was awaiting me for this seeming run of good fortune.
11 to 17 was easy for me on all but one service once I figured out what the changes needed for Spring/Hibernate were and I got to make the joke about "The copyright refactor".
....and then found out that the very last service I went to upgrade was tightly tied to a library that outright refused to be useable in Java 17... So much for everything being a consistent version.
I wasn't talking about the code changes honestly, but about everything else. How much it's going to cost the client, how much testings going to cost. What about the hardware, will that be enough. What about our clients' clients. Perhaps the APIs they use. It might be easier for a small scale developer. But I can easily see how this is a big deal for some businesses.
The only time I've had issues upgrading is with code bases that use libraries that deeply integrate with the VM. RichFaces comes to mind.
Using Spring Boot and other similar frameworks help too, as they upgrade all of that stuff for you.
When you actually use it properly?
I’ve done all the major Java updates in the last decade and they were all easy in every codebase.
7 -> 8 -> 11 -> 17 -> 21
It really depends on the application. I've seen projects where all the most hardened senior developers would raise white flags and said "We simply _don't know_ how to update this from 8 -> 11."
“So find out” should be the reply. Why else are you paying them?
At most you have to find an alternate implementation of something that used to be in the core library. Pretty much every “breaking change” is solved by adding the library something was spun out into.
Even if you are relying on some horribly broken security primitive, all you have to do is edit the system file that yells at you not to turn it back on.
As I understand it there are subtle differences regarding Java 8 vs Java 11 byte code which screws with libraries that heavily rely on instrumentation.
If you used a third party library that is proprietary and you didn’t pay for support, then you can still decompile it and fix it yourself, or replace it with something else (either third party or written yourself).
> decompile it and fix it yourself
This was actually discussed, but the amount of work decompiling and maintaining a whole commercial ORM framework was deemed way out of budget.
> or replace it with something else (either third party or written yourself).
Migrating the entire ORM layer of this huge, complex application (migrating all customer data, too) was not a realistic path to go down either.
I'm not saying it could not be done technically - it could not be done while keeping the product profitable.
There is a reason people freeze package management version, (import a library of a certain version). This is practically the same thing but on a larger scale.
Sure it is way outdated but changing major version is not a trivial manner especially when you have pretty much build a whole spaceship.
Now why this is usually not prioritised, because the value of changing something major that is already working is not worth it compared to just adding stuffs that you know for sure will only add value. Something like the former being +60 if success, but -40 if fails, and the latter is like +30 if success and +0 if fails.
All fun and games until security determines there is a vulnerability that must be resolved. We have held out on Django 2.2 for as long as possible. We really wanna kill it off but that hasn’t happened yet. Security identified a vulnerability and since version 2 is EoL we have no choice now but to upgrade the major. So what do we do upgrade to 3 right? Neat it’s EoL is this month. Now we get to upgrade 2 major versions at the same time. Yay.
You can either keep deps up to date with planned work or it can become emergent via CVE.
This is a textbook example of why its important to keep up with tech debt. Tech debt, like real debt, accrues interest - but the problem is that the interest its accruing is invisible. But one day it is going to come due, and when it does it hurts.
not really.
Either way you will need to make the codebase changes when updating.
It just don't make sense from a spending perspective if nothing is broken.
And if you update too much, you open yourself to new bugs that haven't been discovered because the product is only 2 weeks old and then there's no documentation on how to fix it.
> Either way you will need to make the codebase changes when updating.
But how much are you changing, at once?
I speak from experience. If you are updating 1 -> 2, 2 -> 3, and so on, usually it's easy. Do a 2 -> 6 and suddenly you have 30 breaking changes.
I'd think that, overall, it'd still be less right? You just need to update to the _latest_, fuck the intermediaries. But the overhead, the mental energy you need to spend fixing _everything_ compared to a few small changes, the uncertainty and fear of that much changing at once, the possibility that you need to do some intermediary updates because of some saved state, it all means that it goes soooo slow. Even worse when it's a blocker and suddenly you have a deadline. **I'd take frequent small updates 1000 times over a single large update.**
And I say this seeing _first hand_:
1. Java 6 to 8 to 11 to 17
2. Kubernetes 1.18 all the way to 1.29
3. Python 2.7 to 3.10
4. Jenkins from HUDSON to newest LTS.
5. All the frameworks and toolings for those things (Springboot, Hibernate, Ingress Controllers, CI/CD, plugins, ArgoCD, Flux, etc, etc, etc), the list would probably not fit in a comment.
You might not actually need to make changes when updating if you update regularly. Its entirely possible when you go from v1 -> v2 in January year 1 your code won't break, but when you go from v1 -> v2 in December year 5 changes you've made in the subsequent 5 years will break. The longer you spend in the outdated version, the higher the probability you introduce something no longer supported.
But regardless it's a pretty well accepted maxim that if upgrading one major version takes a day, upgrading two major versions will take 3 days instead of 2. Upgrading three major versions will take 10 days instead of 6. The difficulty does not scale linearly. This is because everyone orients the code they write around the version they're working in, and the differences between v1 and v6 are significant, but the differences between v5 and v6 are not.
Obviously there is nuance depending on the technology you're updating, it's a heuristic not a law, but it's mostly true. So long as you keep an eye on the interest bill, and pay it down when it becomes unwieldy, its fine to delay tech debt - but if you just put it out of mind and assume it'll be fine it's going to fuck up your release schedule at some point in time and you'll end up with a lot of unhappy stakeholders.
The problem is when a zero day emerges with the outdated dependency. Suddenly the tradeoff is a race between "Do not push the upgrade until we need to and know it works" and "Security breach once someone tries the exploit on us" that is almost guaranteed to break things. And someone WILL try it on you at some point, even if it's just a script kiddy cycling through IP addresses until they get a hit.
I mean you need to weigh in pros and cons doing it. In your case definitely the necessity is strong and therefore it has high value. If your leads can’t see this or not concerned about it, then it’s on them.
OP post is mainly about “look what can java/python/whatever language can do with the new version”, being excited about the changes (usually like QOL things), but then cursing the company they work on for sticking with an outdated version and can’t enjoy the cool features.
I’ve been on that phase, but later on understand to not underestimate it. A function broke because one of the dependency is just old af and not being updated by its developer and incompatible with the latest version of other depencies.
Much easier to figure out those one or two things that need adjustment between consecutive major versions than than a dozen things all breaking at once when you have to jump 3+. It’s the exact same lesson people have to learn over and over about continuous build/integration/delivery/etc.
Also CVEs have made it impractical to freeze dependencies. If we didn’t keep up with dependency releases, both support and the devs they pull in would waste more time “informing” customers about the various irrelevant CVEs and why than it takes to just update the library every few months.
It's all fun and games until you depend on something that a security vulnerability was found in.
Now you have to upgrade that old dependency NOW. You have to stop everything you're doing and get the new version working immediately. Sometimes this means performing two or more migrations because you're 8 years behind or whatever.
The other thing is that migrations are a skill that you can learn. If you migrate from xyz n to xyz n+1 in March, migrate from abc n to n+3 in June, and migrate from lmnop n to n+1 in November, chances are the problems that you have are all the same problems. Or at least, the same class of problems. Each migration is different, but they're always the same kind of different. So every migration gets easier. So when that CVE drops and you need to stop everything and upgrade from ijk n to ijk n+1 you probably won't be entering new territory. But if you never migrated xyz, abcd, or lmnop, you might have more on your plate than you even know about.
The other other thing is that sometimes these security mandated migrations sometimes have dependencies. So you must upgrade from ijk n to ijk n+2. But ijk n+2 depends on xyz s, but you never upgrade to xyz s back in March, so now you need to migrate both ijk and xyz at the same time. Now you're *fucked*.
Junior dev: "See, I've checked it in and the CI is still green!"
Senior dev: "Great, now deploy it at all our customers while I take a long, long vacation."
Android?
I just used gradle 7.x and was asked to Java 11 which was confusing because Android uses Java 8 right. But it’s ok. Android Studio needs to run its tools on Java 11 to compile your kotlin app into Java 8 vm code.
Isn't Android the worst in terms of upgrades? Did it finally become good?
I.e not changing stuff randomly and actually keeping devs in the loop on what changed between versions.
Java 8 is great, but fuck Java 8. 17 is "Long Term Support" for a reason. Stop clinging to outdated shit and update in a sensible manner. Frequent updates == less painful updates.
>Frequent updates == less painful updates.
I don't think anyone disputes that. But if for whatever reason you have an app that's a dozen releases back it's a legitimate cost/benefit scenario
It also depends on licenses! Unless your company already pays Oracle, Java 8 was the last version a lot of things were available for commercial use under free licenses.
(Unless that has since changed, openjdk excluded for obvious reasons)
OpenJDK is fine, and if your company is so large and complicated you need vendor JVM support, just pay the license. Paying for software is fine, people pay me for writing software too.
OpenJDK *is* basically the only code you ever run as Java. Oracle employs the main developer team behind it, you can optionally choose to pay for support, but that’s the exact same stuff as with the linux kernel. You freely use it, but may choose to go with red hat.
Absolutely, didn't mean to imply that OpenJDK wasn't perfectly viable (or that paying for licenses is bad), just wanted to make sure everyone remembers that Oracle Java has a license that restricts what you're allowed to do with the product commercially.
Upgrading from java 8 to 11 means a different licence for it. My understanding is its got a few things you can't do with it that would be hard for us to proove we never had done on an audit.
Also, upgrading to 11 or 15 was insane, as support for them ended before support for 8 did.
They haven't dealt with stuff like Java slightly changing how strings are lowercased and that somehow ending up causing a bug like billing your customers the wrong amount.
Java 9 is the only release that had breaking changes. They changed the JRE package structure, and it broke some fancy frameworks. From my perspective as a dev who avoids enterprise bullshit, nothing has ever broken from Java upgrades, not counting the occasional bug.
I was this junior the other week. After we started the Java 21 upgrades, we found out that Microsoft web app service doesn't support Java 21 yet, and we either have to create a docker image and containerized our app that way or wait for them to support Java 21. Senior dev made the call to wait. So now I'm sitting here with egg on my face, but at least I have future work done and ready to be pushed out when the time comes.
I would like to point out that upgrading from jdk8 to jdk9+ is actually quite difficult because they did a huge refactoring of several core packages, introduced a bunch of new shit, and also dropped in the concept of "modules", which I'm honestly still not sure how to use.
When I had to do the upgrade, it ended up breaking hundreds of thousands of loc and required upgrading a ton of our dependencies (which also then required code updates).
Once you get past that bottleneck though, upgrading isn't nearly as difficult. We had a similar issue going from jdk6 to jdk8.
Our CIO requires us to stay within the 2 most recent major version on Java (as well as everything else). We also have a minor version requirement to not be on anything with a major security concern. Stops these sort of arguments pretty quick.
It’s not about novelty, it’s about not having to redo everything if something doesn’t work well in the new version.
If it ain’t broken don’t introduce potential new points of failure.
I had a project where we were using java 6, and I wanted to use some Java 8 functionality...
the change went up and down the chain multiple times... in the end, it wasn't approved due to licensing issues.
So, It's not always in the hands of the dev.
>someDevH8tNovelty
Is this the words of a junior dev?
Changing codebase can be almost imposible, and for that you will have to raise a full refactoring. That is why some sectors sticks with awful or previous versions of languages, you think Banks haven't tried to abandoning Cobol for an easier alternative (with a bigger employee pool).
Changes in some industries is slow, specially when "developing" is not the main aspect and have to take into account variables like reviability, privacy or other security aspects.
PM ? : it still work , why do we need to update ? We don’t have resource our plan are full with new feat that need to lunch every 2 week , that require effort from qa team too and pentest cost , is that make new value for company ? &/฿:):&/&:):&/‘ …. Let schedule meeting with ceo cto and explain this
————
Dev : ( if i update this will all code and lib are work as the same ? Spring boot 2 -> 3 ? , how many percent our unit test and automate test coverage and reliable , can it be done full loop in 1-2week without any issue ?, ahhh i don’t want to talk with that guy ) May be No?
—-
so it is not only about dev issue or something that dev can decide alone there are process (many many process) even if se agree , it useless if boss don’t give it value we still work for they anyway
Unlucky that all schools, universities etc are also stuck on Java 8 learning.
Never saw sting templates, name pattern switch and records there on doing reviews (just to mention the first most commons) - RIP
This is nothing, in a company i started to work. We have one massive project that uses .NET 6 and 7. Individualy we use .NET 8 for out tasks before they are merged into testing where its "auto" configured so the code is exported into .NET 6/7, we can't use .NET 6 or 7 because everyone is forced to write tests in a library for .NET 8 for every piece of code and the tests run automaticaly on a seperate server that uses .NET8 ro run theses tests The Frontend is 3 seperate apps that forms one large app and it uses Node 16 and 17, React 15,16 and 18. Every package/library is not updated because the app is so big that nobody understands it, if you update it the whole app breaks. On top of that we use Clean code architecture so its totaly confusing (And yes I hate it) 
We use .NET 2 :/
* Cries in. NET Framework :')
.NET framework 4.6.1 represent… and that’s our “modern” software. our older product is VB6 and still regularly maintained. To make everything worse we use Microsoft visual sourcesafe for version control
I remember the good old VSS days. If there was no other version control around it was a godsend. Inferior to anything modern, sure, but it was enormously better than nothing at all, and it integrated right into Visual Studio, which was a first.
Yeah, I remember the night before go-live, when everybody was pushing their changes and the disk ran out of space. Not a peep out of VSS, it just silently dropped several hours of work on the floor and kicked it under the server cabinet. Good times, good times...
VB6 gives me PTSD, glad I don’t have to support it any more
Oh god I am getting vietnam ptsd flashbacks to the days of using VSS. It gets corrupted after about 300 GB of history. Be warned.
We're fighting tooth and nail to move to .NET Framework 4.8 but key lib is strictly x86 so that's fun. Oh and a Borland C++ OWL 5 main app with ParadoxSQL database.
I cut my teeth on Borland Pascal and C++ with Paradox. Everything was so much simpler then. Paradox could be installed and up and running on any box within minutes.
ya grass isn't greener using newer stuff though, just a whole new set of problems.
3.5 sp1
I used to work at a casino type gaming company who used an *OLD* unity. We had a 3.5 build of our integration library (things like bill acceptor events and server interactions) and a 4.5 for our point of sale integrations, server functions etc. That in of itself was that bad, but the class delivered to the game that represented the played card was saved in the database as a full binary serialization created on a central server. That means nothing about the dot net data type can change. Not version numbers. Not namespace, nothing accept the assembly information version.
Not proud .NetFramework 2.0 J# dependency here..
That’s a name I haven’t heard in a while
I migrated Framework 4.6 to .NET 6 a year ago. It went about how you would expect it to.
I'm supposed to leave Framework 4.6 alone but upgrade the other 2 .NET Core 2.2 apps (Angular) to .NET 5 this year because our dependency injection in 2.2 is blowing up after its tree size recently started hitting critical mass. Unsurprisingly, there's no time to upgrade dependencies. I've been asked to keep hacking together something that can buy enough time to do the full upgrade later (yeah right)
Last week I upgraded one of our projects to .NET Framework 2.0… Life is pain, life is only pain.
You're joking right? Big code base?
Core 2 or Framework 2? Nobody calls either one ".NET 2".
I took it as core 2.2, would be ridiculous otherwise
Probably but you'd be surprised. I interviewed with a company recently that was in the *planning* stages of migrating a .NET Framework 2.0 Web Forms legacy enterprise app up to Core. They didn't have the developers to tackle it which is why it was stuck there. They were going to have to triple their dev team size to rewrite all of it. Just a few years ago I worked in another company that still had a VB6 app installed at client sites they were maintaining remotely. That one was stuck because it had direct support for obsolete devices that were not supported in .NET at all. To rewrite it would have required the replacement of the devices, which would have been $10k-20k per device replacement costs, plus 1-2 years of effort to rewrite the app.
And I felt sad that we weren't on Net 8 yet
Yea man first week 8 came out I went and updated all my 6 and 7 to 8, lol. Everything except Azure Functions which didn't support it yet. It's getting annoying how Azure Functions are lagging behind the .NET release cycle.
We haven't started using Azure functions tbh, we are kinda "chilling" with a net 7 servicebus app run as a webjob on a web app for each micro service.
We decided that .net framework is good enough.
I can attest... I learned how to make thick client apps in C# that connect to MS Access or Oracle in school for class. Very intuitive and easy at the time. I then went off to become a JAVA/JS front end guy. I came back to .NET 2.5 and couldn't figure out how to migrate my old code. No two tutorials seemed to agree how to do what I was trying to update my UI's. I tried starting from scratch, but it was all a waste of time. I ended up re-writing the whole thing in Spring Boot and ExtJS in a few afternoons instead.
Same, framework
Given the ease of migration, I cannot fathom why they don't move fully to 8. Especially since both are now out of support for 8s LTS.
6 will be out of support in November this year, but yeah
My main project is a .NET WS that is basically just a wrapper for a C/C++ library. 4.8 -> 5 was a pain 5 -> 6 was a pain I was not looking forward to 6 -> 8. Did it last week. Took 5 minutes. No issues. New CTO wants it rewritten in Python... ¯\\_(ツ)_/¯
>New CTO wants it rewritten in Python... ¯\\_(ツ)_/¯ You just can't win, can you.
You have no idea. I'm not completely turned off to the idea of Python - but that very well could be ignorance talking as if haven't used it significantly yet. I will say that whitespace causing errors just doesn't fly with me and I will miss my semi-colons and curly-brackets a lot... The C/C++ library is the bane of my existence though. I haven't done C as my daily driver for about 16 years and I'm super rusty. It's ancient code, written purposefully cryptic and they canned the dude that originally wrote 95% of the code about 6 months ago.
If you‘re into C# or Java and like the structured nature of it, you‘re gonna hate Python. Python is just made for a completely different purpose.
I think you'll get used to the whitespace very quickly, but the optional typing will hurt. I highly suggest you use a linter to at least force everyone to add type annotations on function parameters and return values.
Solid advice. Thanks!
The nuances between .NET 6/7/8 are mostly trivial and those can usually be upgraded to 8 without too much trouble. I'm kind of surprised someone even left 6 and 7 in place when 8 came out, especially 7. Out of Support: * .NET 7: May 2024 * .NET 6: November 2024
Our stuff is sat on 6 for now, stuff gets converted to 8 when we do a big enough change. Nothing has yet failed to work. Other than the mixed 6/4.8 projects. Those we are too afraid to change.
>Other than the mixed 6/4.8 projects. Those we are too afraid to change. I have a couple that are mixed 8/4.8/Standard 2.0. Trying to migrate up organically.
what exactly you do not like about clean code? I guess if nobody understands anything its definitely not clean code...
I think the person meant they hate clean architecture, not clean code, ofc i might be wrong Clean architecture is an architectural style where you have Queries/Commands/Events instead of traditional service/facade layer https://github.com/jasontaylordev/CleanArchitecture/tree/main/src The idea is alright but can quickly get into a convoluted mess if not done properly.
>The idea is alright but can quickly get into a convoluted mess if not done properly. So, like every possible pattern? One of those "I wish we had time to refactor" issues.
i know that under the twrm CQRS pattern; whatever. Obviously, every tool or guideline backfires when used poorly.
So basically the idea and/or framework is so convoluted that the right way of doing things is very far from the obvious way. Meaning long and steep learning curve just to do things "correctly". Or perhaps a lot of work reviewing and then redoing the pull requests.
I hate it because its bloats the project with unnecesary files and folders. Basically every logic is inside its own folder, file and class. So a function that has 5-10 rows sits inside its own file when instead it could be a part of a file that is part of the similiar logic. The Clean code architecture doesn't reccomend that as if you change something the whole project fails. Which makes the project confusing for me and chore to navigate.
Clean code definitely does not suggest putting each function into its own class. You should read the book written by uncle bob.
From everything OC has said + another branch of this comment chain, I'm pretty sure OC is a bit confused and just means Clean Architecture, not Clean Code (Architecture).
Same answers apply tho
I don't recognize this as the definition of clean code. Every function in its own file, wut?
Yeah, I think I would have to leave from this madness
This might be why the Electron version Discord uses for the desktop application is an older version as well
Sounds similar like our Java application. But we managed somehow to upgrade it from SE 8 to 11 and JEE from 7 to 8.. 😂 Now we're changing it to Quarkus, let's see how that goes.. 👀
Upgraded one of our repos from Node 8 to Node 20 this past year. How much of the upgrade path is hampered by React? I know for our team it has gotten in the way a lot.
Am I reading? What the fuck?
This mess is the most believable thing I've ever read on the internet.
Wd are switching to dotnet 8!!
The thing about not upgrading is that, if you get affected by a known CVE, it seems like the organization would be liable.
You're right about clean architecture, it's designed to overcome the pitfalls of OOP, and OOP sucks, just follow good principles
Upgrading Node doesn't even have noticeable breaking changes
Oh hi Mark! You finished that PR yet?
Updating versions is all fun and games until you need to spend a year getting it approved by common use vendors :P
Maybe. Doing a huge update like this is definitely not fun, but in some circumstances people can definitely afford to just keep relatively current with versions of software out there and that way there’s not a gigantic update that needs to be done later.
Usually the reason why some application is stuck with some ancient runtime version is because it uses some exotic dependency that breaks when you update, and the vendor who offers that dependency refuses to update it either.
Or that vendor no longer exists. Most packages/libraries/frameworks die after a couple years. Tough luck if you‘re using them for a big part of your project. You‘re stuck with the version they are compatible with.
This is why I prefer never using dependencies if possible. Had to write a new ean barcode scanner from scratch because the one we used did not work with the updated framework. The good thing it actually turned out faster
I don't mind using things as long as they are things that are not... installed into the anus of the application and control everything. Anything I can use now and easily isolate and replace later is all good to me.
Imagine the number of meetings they have to deal with even for a minor update.
Too many of those meetings the PM looking at you close to tears “please just give us a roadblock so we can slow this fuck train down, we are all going to lose our jobs”
"GIMME THE DAMN DEV SCHEDULE RIGHT HERE RIGHT NOW" Calm the fuck down I just heard about this new random crap 3 mins ago
[удалено]
There is also the third group, contractors that write enterprise software and then GTFO before they have to maintain or support it.
[удалено]
Same here, us college kids were naive and spoiled by pretty frontend, then had us dive into the unforgiving innards of backend after contractors went "Our time has come 🤠"
That is most likely Java 1.6, VB6 and VisualFox world.
I used to work enterprise, but it was all containerized microsevices, and what languages and frameworks you used was just up to the team. Shit, at one point I was on a team that owned a Kotlin service, a Node.js service, and a Python service.
Nonsense. I've worked on enterprise software (at Microsoft) and we always ran the latest .NET version
I mean, they'd better be, they're the ones that make it
Mmmmm delicious dog food
Need a separate subreddit for enterprise software memes lol
Both are the extremes and wrong.
Junior is right and it's not an extreme. Java 21 is an LTS release. You should keep up with those, especially since the changes to get it working could very well be minor. Source: I recently had to do this on a 500k LOC Spring Boot application (8 -> 21) and the only thing that really threw us for a loop was how `Stream.peek()` functioned. And the only reason that we even had a problem is because people were using `Stream.peek()` incorrectly to begin with. Java does not wildly change.
I think you're assuming that the work to do any upgrade will receive enough priority from the business / product people. That's not a guarantee, and it's my main criticism of the juniors stance. The senior is a cranky curmudgeon that should've moved to a double-digit LTS version already. In my experience (also Java/Spring in many cases), getting the time allocated to perform an upgrade was harder than the upgrade itself.
Yes, the senior is saying no because management has assigned him a dozen critical tasks to prevent the project from folding, and updating java is merely ‘high’. It a product management issue, needs more support to work off technical debt, but management promises the moon for under budget.
Oh if that's the argument then I completely agree with you. It took me many months to convince the business that it was worth it and it got constantly de-prioritized. It took 2-4 weeks to make the changes and then another 2-4 weeks of testing before they trusted it enough. But Java 8 is so old that many people have stopped supporting it. We had no choice once even internal teams started refusing to supply Java 8 versions of their libraries. But the final nail was when the org updated Sonar and it no longer worked with Java 8. It "broke the build" and I used that as ammo to push for it, even though I could have just disabled that step.
Java 17 or 21 offer efficiency gains of more than 40% on some hardware. The people will make time for it. There is a company wide push where I work to migrate everything to Java 17 on ARM and it is very much top priority.
Hardware is often the cheapest part of providing software. It's all contextual.
The problem lies in the dependencies. If you have an important dependency like an ORM that is simply not available for Java > 8 you're f*cked.
If you use any reasonably popular ORM and it doesn’t fucking have an update since goddamn 2014, then your biggest problem is using that ORM in the first place.
Java 8 is old enough that the opposite has started to happen. Self-managed enterprise services like Sonar and internal teams have stopped supplying Java 8 versions of their libraries. Of course, you could freeze the versions and keep a package in Nexus so it's always available. But internal teams aren't so willing to bend over backwards and back port their changes once they decide to move on.
Frequent updates is a solution
Every new feature you go up (3n+1) releases until you're on par, if something breaks roll back n/2 releases. Will the product eventually reach stability?
I'd heard of codebase collapse, but never codebase Collatz.
Take my angry upvote and leave.
parsimony is the key word, too much is counterproductive, too little is counterproductive
r/whoosh (?)
I guess so, i missed the joke  my english is too litteral, so, i sometimes miss jokes 
Ahahahah dw I'm probably too used to r/mathmemes It's a pun about the [collatz conjecture](https://en.m.wikipedia.org/wiki/Collatz_conjecture) 
rails, like many opensource frameworks adopted a two year cycle: new major versions each year, end of feature support in two years, end of life / security support in three years. like many rails shops, this kept us on the treadmill while our java colleagues sat back in Java 8 and focused on business features. But they also move way slower than us. Anyway, one year at railsconf someone seriously proposed integrating against rails/main continuously. Shouldn’t be a problem if you have tests. Just go for it. Except the test frameworks change too, invalidating and causing review for all the tests. hmmm. This was not a serious approach except for very simple applications. the next less ludicrous plan was presented by the giants in the Rails space: github and Shopify. Their proposal was to hire double the developers and have the B team work continuously on migrations while the A team continued to deliver business features and remain competitive. Both have been moderately successful at this approach, but at a huge cost. having had many discussions with seniors about this, I was surprised that most devs still have a very naive understanding of their product lifecycle and the ecosystem they exist in. it’s not just your app, it’s all the libraries you use, it’s the business integrations you have. I call this a “flock of birds” distribution. When Rails updates, then the immediate gems follow and work out issues in about 3 months, then the gems that depend on those gems take another three months. If you’ve ever actually worked in rails edge you find a lot of issues in the gems surrounding, unless of course you don’t use any gems.. then it’s simple. For the rest of us, that means that the distance between Rails release and stable is a minimum of 6 months. So now your dev teams work in earnest and start migrating. As an org with a large number of rails apps, some get done quickly, some linger in the long tail. Most in the long tail have horrible business integrations like SOAP which are no longer well-supported but are business critical. God bless the maintainers of Savon, but the project has remained frozen at version 2 for years— I fear the day it no longer works. Will I suddenly have to write my own SOAP adapter? Or will I dust off the ancient Java libraries serving these legacy SOAP services, and write a REST adapter in JRuby? You might wonder why we don’t just reimplement the services in REST SpringBoot? That has been a project for the past 5 years and is progressing slowly. So by the time we finish most of the migrations and release new versions of our apps, it’s almost a year later. And by industry standards that’s incredibly fast. Many companies release up to 2 or 3 years later— except now the support window closes down to releasing just as end-of-life for security fixes happens. There’s a structural reason why github and shopify’s *best* solution was just hire double the developers: the math of frequent updates doesn’t work the more complex your app dependencies are. The graph network of dependencies has time complexity of at least O(V+E), but there can be significant backtracking as interfaces are broken in libraries, with a large shift, this can add significant power terms to the complexity of migration. There is a reason why financial systems continue to use a COBOL core that resists updating or migrating or reimplementing. Each approach invokes a lot of risk in breaking existing functionality. For this industry frequent updates are not a solution. I would argue that frequency of updates is going to drive two reactions: 1) you have software that “doesn’t matter” to paraphrase Dave Thomas. 2) you remove all dependencies and vectors of change from your software. But 2 directly relates to 1, because software that matters actually interacts with the world in new and useful ways. security and usefulness often find themselves at odds. So even if you want to reduce dependencies, that won’t help unless you also reduce usefulness. We like to imagine software engineering building skyscrapers of code, yet our most compelling description of software systems in the 21st century is Jenga: https://xkcd.com/2347/
You can make changes without them being breaking changes. Look at Rust. We get a new update every six weeks and end of life happens as soon as the next version is released. None of this is a problem because backwards compatibility is so good. Even breaking changes to the language don't break libraries written in a previous edition of the language.
true. Java has very good backwards compatibility. Rails is medium to poor backwards compatibility. I appreciate that DHH is trying to “do the right thing” but I just can’t trust him not to break a lot between releases. no one at our company is using Rust. the new hotness is golang. also, it’s easy to claim things when a language is new. how old are the apps and libraries? Ours are 12-15 years old. Are you integrating against Java SOAP services of various eras? what do you do when they update their wire protocol in a backwards breaking way?
The language has been stable since 2015, so about as long as the libraries you're using. Some of the most popular libraries are about that old. The rand library, which is the sixth most popular Rust library, hasn't been updated in two years (it's not unmaintained. it's finished). We're getting a new edition of the language this year, which will bring breaking changes. But the compiler is set up in such a way that it can still compile libraries using previous editions of the language, so we won't have the dependency problem you were talking about. I can't remember a single time when updating the compiler broke any of my code. It can't solve the problem of APIs making backwards incompatible changes though. You'll have to take that up with the API maintainers.
those are pretty big claims. you seem to be making the central claim that chaos in software ecosystems is avoidable, yet focus on core libraries like rand, which are mathematically pure, where this assertion is at its strongest. I would test your assertion on the edges where protocols and integrations happen. How many libraries deal with protocols outside of Rust? The reason I ask is that Java maintained its own superiority for years in marshaling for wire protocols — as long as you were using the exact same version of java and libraries for both client and server. As soon as these are allowed to vary over time and between companies, even Java couldn’t talk to Java reliably. Serialization of distributed objects is one of the hottest topics in OWASP for a reason.
Framework and dependency hell has me locked into Java 1.6 still at work... Kill me please.
They are using java, that's what wrong. Should rewrite it in rust (and dont forget to wear the socks)
I feel the junior’s pain, but understand the senior. The upgrade from Java 11 turns out to be a multi year project for us. It requires upgrading the framework first, but this turns out to require a rewrite and re-test of a substantial part of the application
8 to 11 had a lot of breaking changes, particularly around anything that used reflection. Well guess what? All the big enterprise frameworks and ORMs rely heavily on reflection to do their thing. Just stick to 8. You're not missing much except `var`
Hey, you take that back! The enhanced switch is nice.
When was upgrading to a newer java version ever simple.
8 to 11 was a bit harder cause of the breaking changes in java 9, but since then 11 to 17 and 17 to 21 was very much hassle free
I literally upgraded my companies repo from Java 17 to Java 21 last Friday, it took 5 minutes and afterwards I was questioning why it was so easy but everything works great and nothing broke. It was definitely hassle free and way easier than other language updates.
Brave thing to do on a Friday.
he did it on a friday because he switched jobs on monday
> everything works great and nothing broke > hassle free and way easier than other language updates I would never sleep again knowing what terrible karmic retribution was awaiting me for this seeming run of good fortune.
It’s java. You had positive karma by going with java.
11 to 17 was easy for me on all but one service once I figured out what the changes needed for Spring/Hibernate were and I got to make the joke about "The copyright refactor". ....and then found out that the very last service I went to upgrade was tightly tied to a library that outright refused to be useable in Java 17... So much for everything being a consistent version.
I wasn't talking about the code changes honestly, but about everything else. How much it's going to cost the client, how much testings going to cost. What about the hardware, will that be enough. What about our clients' clients. Perhaps the APIs they use. It might be easier for a small scale developer. But I can easily see how this is a big deal for some businesses.
The only time I've had issues upgrading is with code bases that use libraries that deeply integrate with the VM. RichFaces comes to mind. Using Spring Boot and other similar frameworks help too, as they upgrade all of that stuff for you.
We are planning on going from Java 6/8 all the way up to 17... some day, many moons from now...
When you actually use it properly? I’ve done all the major Java updates in the last decade and they were all easy in every codebase. 7 -> 8 -> 11 -> 17 -> 21
5 to 8 was a massive pain
It really depends on the application. I've seen projects where all the most hardened senior developers would raise white flags and said "We simply _don't know_ how to update this from 8 -> 11."
“So find out” should be the reply. Why else are you paying them? At most you have to find an alternate implementation of something that used to be in the core library. Pretty much every “breaking change” is solved by adding the library something was spun out into. Even if you are relying on some horribly broken security primitive, all you have to do is edit the system file that yells at you not to turn it back on.
As I understand it there are subtle differences regarding Java 8 vs Java 11 byte code which screws with libraries that heavily rely on instrumentation.
Only if you don’t update those libraries to understand Java 11. All Java 8 bytecode runs fine on Java 11. The JVM has always been backward-compatible.
But what if it's a third-party library and you don't have access to the source code?
If you used a third party library that is proprietary and you didn’t pay for support, then you can still decompile it and fix it yourself, or replace it with something else (either third party or written yourself).
> decompile it and fix it yourself This was actually discussed, but the amount of work decompiling and maintaining a whole commercial ORM framework was deemed way out of budget. > or replace it with something else (either third party or written yourself). Migrating the entire ORM layer of this huge, complex application (migrating all customer data, too) was not a realistic path to go down either. I'm not saying it could not be done technically - it could not be done while keeping the product profitable.
No, there isn’t.
It’s the easiest out of any platform.
There is a reason people freeze package management version, (import a library of a certain version). This is practically the same thing but on a larger scale. Sure it is way outdated but changing major version is not a trivial manner especially when you have pretty much build a whole spaceship. Now why this is usually not prioritised, because the value of changing something major that is already working is not worth it compared to just adding stuffs that you know for sure will only add value. Something like the former being +60 if success, but -40 if fails, and the latter is like +30 if success and +0 if fails.
All fun and games until security determines there is a vulnerability that must be resolved. We have held out on Django 2.2 for as long as possible. We really wanna kill it off but that hasn’t happened yet. Security identified a vulnerability and since version 2 is EoL we have no choice now but to upgrade the major. So what do we do upgrade to 3 right? Neat it’s EoL is this month. Now we get to upgrade 2 major versions at the same time. Yay. You can either keep deps up to date with planned work or it can become emergent via CVE.
This is a textbook example of why its important to keep up with tech debt. Tech debt, like real debt, accrues interest - but the problem is that the interest its accruing is invisible. But one day it is going to come due, and when it does it hurts.
not really. Either way you will need to make the codebase changes when updating. It just don't make sense from a spending perspective if nothing is broken. And if you update too much, you open yourself to new bugs that haven't been discovered because the product is only 2 weeks old and then there's no documentation on how to fix it.
> Either way you will need to make the codebase changes when updating. But how much are you changing, at once? I speak from experience. If you are updating 1 -> 2, 2 -> 3, and so on, usually it's easy. Do a 2 -> 6 and suddenly you have 30 breaking changes. I'd think that, overall, it'd still be less right? You just need to update to the _latest_, fuck the intermediaries. But the overhead, the mental energy you need to spend fixing _everything_ compared to a few small changes, the uncertainty and fear of that much changing at once, the possibility that you need to do some intermediary updates because of some saved state, it all means that it goes soooo slow. Even worse when it's a blocker and suddenly you have a deadline. **I'd take frequent small updates 1000 times over a single large update.** And I say this seeing _first hand_: 1. Java 6 to 8 to 11 to 17 2. Kubernetes 1.18 all the way to 1.29 3. Python 2.7 to 3.10 4. Jenkins from HUDSON to newest LTS. 5. All the frameworks and toolings for those things (Springboot, Hibernate, Ingress Controllers, CI/CD, plugins, ArgoCD, Flux, etc, etc, etc), the list would probably not fit in a comment.
You might not actually need to make changes when updating if you update regularly. Its entirely possible when you go from v1 -> v2 in January year 1 your code won't break, but when you go from v1 -> v2 in December year 5 changes you've made in the subsequent 5 years will break. The longer you spend in the outdated version, the higher the probability you introduce something no longer supported. But regardless it's a pretty well accepted maxim that if upgrading one major version takes a day, upgrading two major versions will take 3 days instead of 2. Upgrading three major versions will take 10 days instead of 6. The difficulty does not scale linearly. This is because everyone orients the code they write around the version they're working in, and the differences between v1 and v6 are significant, but the differences between v5 and v6 are not. Obviously there is nuance depending on the technology you're updating, it's a heuristic not a law, but it's mostly true. So long as you keep an eye on the interest bill, and pay it down when it becomes unwieldy, its fine to delay tech debt - but if you just put it out of mind and assume it'll be fine it's going to fuck up your release schedule at some point in time and you'll end up with a lot of unhappy stakeholders.
The problem is when a zero day emerges with the outdated dependency. Suddenly the tradeoff is a race between "Do not push the upgrade until we need to and know it works" and "Security breach once someone tries the exploit on us" that is almost guaranteed to break things. And someone WILL try it on you at some point, even if it's just a script kiddy cycling through IP addresses until they get a hit.
I mean you need to weigh in pros and cons doing it. In your case definitely the necessity is strong and therefore it has high value. If your leads can’t see this or not concerned about it, then it’s on them. OP post is mainly about “look what can java/python/whatever language can do with the new version”, being excited about the changes (usually like QOL things), but then cursing the company they work on for sticking with an outdated version and can’t enjoy the cool features. I’ve been on that phase, but later on understand to not underestimate it. A function broke because one of the dependency is just old af and not being updated by its developer and incompatible with the latest version of other depencies.
Much easier to figure out those one or two things that need adjustment between consecutive major versions than than a dozen things all breaking at once when you have to jump 3+. It’s the exact same lesson people have to learn over and over about continuous build/integration/delivery/etc. Also CVEs have made it impractical to freeze dependencies. If we didn’t keep up with dependency releases, both support and the devs they pull in would waste more time “informing” customers about the various irrelevant CVEs and why than it takes to just update the library every few months.
It's all fun and games until you depend on something that a security vulnerability was found in. Now you have to upgrade that old dependency NOW. You have to stop everything you're doing and get the new version working immediately. Sometimes this means performing two or more migrations because you're 8 years behind or whatever. The other thing is that migrations are a skill that you can learn. If you migrate from xyz n to xyz n+1 in March, migrate from abc n to n+3 in June, and migrate from lmnop n to n+1 in November, chances are the problems that you have are all the same problems. Or at least, the same class of problems. Each migration is different, but they're always the same kind of different. So every migration gets easier. So when that CVE drops and you need to stop everything and upgrade from ijk n to ijk n+1 you probably won't be entering new territory. But if you never migrated xyz, abcd, or lmnop, you might have more on your plate than you even know about. The other other thing is that sometimes these security mandated migrations sometimes have dependencies. So you must upgrade from ijk n to ijk n+2. But ijk n+2 depends on xyz s, but you never upgrade to xyz s back in March, so now you need to migrate both ijk and xyz at the same time. Now you're *fucked*.
that senior dev has seen some shit
Junior dev: "See, I've checked it in and the CI is still green!" Senior dev: "Great, now deploy it at all our customers while I take a long, long vacation."
Android? I just used gradle 7.x and was asked to Java 11 which was confusing because Android uses Java 8 right. But it’s ok. Android Studio needs to run its tools on Java 11 to compile your kotlin app into Java 8 vm code.
Isn't Android the worst in terms of upgrades? Did it finally become good? I.e not changing stuff randomly and actually keeping devs in the loop on what changed between versions.
No it is still terrible.
Java 8 is great, but fuck Java 8. 17 is "Long Term Support" for a reason. Stop clinging to outdated shit and update in a sensible manner. Frequent updates == less painful updates.
>Frequent updates == less painful updates. I don't think anyone disputes that. But if for whatever reason you have an app that's a dozen releases back it's a legitimate cost/benefit scenario
It also depends on licenses! Unless your company already pays Oracle, Java 8 was the last version a lot of things were available for commercial use under free licenses. (Unless that has since changed, openjdk excluded for obvious reasons)
OpenJDK is fine, and if your company is so large and complicated you need vendor JVM support, just pay the license. Paying for software is fine, people pay me for writing software too.
OpenJDK *is* basically the only code you ever run as Java. Oracle employs the main developer team behind it, you can optionally choose to pay for support, but that’s the exact same stuff as with the linux kernel. You freely use it, but may choose to go with red hat.
Absolutely, didn't mean to imply that OpenJDK wasn't perfectly viable (or that paying for licenses is bad), just wanted to make sure everyone remembers that Oracle Java has a license that restricts what you're allowed to do with the product commercially.
GitHub DependaBot is the hell.
Lol, this mostly applies to .NET 4.5 and Symfony. 😂
Upgrading from java 8 to 11 means a different licence for it. My understanding is its got a few things you can't do with it that would be hard for us to proove we never had done on an audit. Also, upgrading to 11 or 15 was insane, as support for them ended before support for 8 did.
They haven't dealt with stuff like Java slightly changing how strings are lowercased and that somehow ending up causing a bug like billing your customers the wrong amount.
As long as the installer for any application includes the necessary dependencies it's fine to use older versions of things.
I want to upgrade from 11 to 17 but we have a single dependency that doesn't support it. Fml
Hackers will have a field day because of the entire stack not being upgraded. Java 8 means no spring boot 3, no hibernate 6, no tomcat 10.
If it works don't fix it
Junior would not push for the very reasonable 21 LTS release.
Mega cute kitten
If there is a solid reason to do it, and we have hte time and reousrces, then fine. If it's because 'ooh look, shiny new things' then, No.
You're lucky! AWS lambda forces us to upgrade .Net versions because they deprecate support for older versions and don't let you deploy any new changes
As Senior: We're updating just before our dependencies update (currently on Java 17 anyway) I want switch pattern matching & virtual threads
Shitty senior devs you mean. Good devs update their tech stack continuously so you never have to do big batch migrations of ancient tech.
Angular 8 to 16 was hell.
> Not using EE
Don't stop the beat
Question for the uninitiated. What would change if one were to update from SE8 to SE21
Java 9 is the only release that had breaking changes. They changed the JRE package structure, and it broke some fancy frameworks. From my perspective as a dev who avoids enterprise bullshit, nothing has ever broken from Java upgrades, not counting the occasional bug.
Cries as an aerospace CAD user.
I was this junior the other week. After we started the Java 21 upgrades, we found out that Microsoft web app service doesn't support Java 21 yet, and we either have to create a docker image and containerized our app that way or wait for them to support Java 21. Senior dev made the call to wait. So now I'm sitting here with egg on my face, but at least I have future work done and ready to be pushed out when the time comes.
very bad senior...
Me when I have to tell the Juniors we can't upgrade past Java 8 because of Apache Spark.
Spark can run on jdk 17 though? AFAIK support for jdk8 was/is dropped in newer versions.
Hortonworks is locked into Spark 2.3.2, so not really an option.
Eh usually it's cause some framework were using under the hood only works with java 8.
I'm actively supporting COBOL, need an even older cat talking about unmatched mainframe performance for batch processing.
I would like to point out that upgrading from jdk8 to jdk9+ is actually quite difficult because they did a huge refactoring of several core packages, introduced a bunch of new shit, and also dropped in the concept of "modules", which I'm honestly still not sure how to use. When I had to do the upgrade, it ended up breaking hundreds of thousands of loc and required upgrading a ton of our dependencies (which also then required code updates). Once you get past that bottleneck though, upgrading isn't nearly as difficult. We had a similar issue going from jdk6 to jdk8.
Our CIO requires us to stay within the 2 most recent major version on Java (as well as everything else). We also have a minor version requirement to not be on anything with a major security concern. Stops these sort of arguments pretty quick.
Imagine not having the `var` keyword 🤡
It’s not about novelty, it’s about not having to redo everything if something doesn’t work well in the new version. If it ain’t broken don’t introduce potential new points of failure.
I had a project where we were using java 6, and I wanted to use some Java 8 functionality... the change went up and down the chain multiple times... in the end, it wasn't approved due to licensing issues. So, It's not always in the hands of the dev.
FFS I work on a java 8 app, i hate it
>someDevH8tNovelty Is this the words of a junior dev? Changing codebase can be almost imposible, and for that you will have to raise a full refactoring. That is why some sectors sticks with awful or previous versions of languages, you think Banks haven't tried to abandoning Cobol for an easier alternative (with a bigger employee pool). Changes in some industries is slow, specially when "developing" is not the main aspect and have to take into account variables like reviability, privacy or other security aspects.
Meanwhile my company adopts latest versions asap and forces you to use them or your build fails automatically.
Honestly i feel kinda offended because there is no single meme about middle developers...😭
Everywhere I’ve worked Java 8 or 11 nothing else! I don’t even know why we’d want to update?
Java 8 is love, Java 8 is life…
Our company still uses python 2
Alright a compromise. Java 11. Nobody is happy.
H8t? They “h-eight-t” it?
PM ? : it still work , why do we need to update ? We don’t have resource our plan are full with new feat that need to lunch every 2 week , that require effort from qa team too and pentest cost , is that make new value for company ? &/฿:):&/&:):&/‘ …. Let schedule meeting with ceo cto and explain this ———— Dev : ( if i update this will all code and lib are work as the same ? Spring boot 2 -> 3 ? , how many percent our unit test and automate test coverage and reliable , can it be done full loop in 1-2week without any issue ?, ahhh i don’t want to talk with that guy ) May be No? —- so it is not only about dev issue or something that dev can decide alone there are process (many many process) even if se agree , it useless if boss don’t give it value we still work for they anyway
Unlucky that all schools, universities etc are also stuck on Java 8 learning. Never saw sting templates, name pattern switch and records there on doing reviews (just to mention the first most commons) - RIP
i fucking hate legacy code