Porting .NET framework to .NET core / standard / 6+ really isn't as smooth as MS would like you to believe.
And the support lifecycle for .NET4.8 is ironically better than they are for .NET 6 (already dead) and .NET 8, because of the shipping-with-windows thing.
The odd-numbered .NET releases aren't even worth looking at from an enterprise perspective.
So yeah, there'll be a bunch of .net framework code around for a while.
That said, it's frustrating, because in some places the performance just isn't there, and there are so many nuanced differences between them there's a weird effect trying to switch between them.
You not only have to recall which APIs are available in each, but the performance differences between otherwise identical (or near identical) APIs.
> Porting .NET framework to .NET core / standard / 6+ really isn't as smooth as MS would like you to believe.
Having just spend the better part of 3 months porting a lot of legacy projects, you're absolutely right, but I am not sure where MS said this would be smooth. There are some processes that are standard enough but certainly there is a lot of hands on work involved, and actually for good reason, there are performance and security issues that need to be addressed (In my brief, and hopefully final experience).
That said, porting from event .net versions (stable LTS versions) such as 6 -> 8 has so far been flawless, I think over the last year, we ran into maybe some minor semantic issues.
It's not perfect, but I have to defend MS unfortunately, they are taking things in the right direction while being tied to a LOT of legacy enterprise clients and systems.
I'd add that WPF was "don't bother" up until recently when WPF support was added. (Though I don't know if that means stock WPF or that it supports the breadth of WPF controls out there, and whether it requires WPF component vendors to make changes)
We just migrated our massive WPF application to .NET 8 and there are a handful of libraries that are not supported or had to be replaced but overall it was surprisingly smooth. The biggest issue we have is that garbage collection seems to have taken a huge hit and there are bugs in the Microsoft WPF components (any sort of list view in particular) but it's all relatively easy to work around.
Yes, it's partial parity, and is server only. It's also not easy to migrate; the upgrade-assistant tool typically just gives up.
The client libraries only came separately, and much later[1] , and in typical "Fuck your migration path" fashion, doesn't have any .NET standard support.
Support for .NET Frameworks 4.8 is essentially forever and .NET Core requires you to jump one version up almost every year, which has a much higher maintenance cost.
This is completely false and goes against the experience of the vast majority of the teams.
Using .NET Framework carries significant risk and opportunity cost. Updating LTS every 2 years usually comes with simply bumping up versions and rebuilding.
It’s not “completely “ false. Otherwise this sentiment wouldn’t exist and .NET 4 would be a nice memory like Windows 2000.
Opportunity cost? Sure, but you can’t deny that small teams that just wanted some stuff to please a business itch were able put the shitty code in whatever Win server they had at the time and forget about it. They didn’t have to ask IT to evaluate any installs, it was right there. And today in win 10 servers, that code still runs, returning ugly aspx.
We have some equivalent 2.1 stuff laying around and no one wants to go through the trouble of updating that.
You’re probably going to say something like “well that’s what you get when you just let your code rot and no one cared to document it and maintain it”. Yes, true, but that’s not the on topic point, one of those constantly comes up in vulnerability reports and one doesn’t.
Yep, this is correct. Not to mention the maintenance cost of .NET Framework going up every year because the library ecosystem moves onwards, eventually, from legacy behaviors.
And also, bumping the .NET version from 8 to 9 or 9 to 10 is typically a very small effort for most. I think what the OP is describing is working for a software cost center where they don't value the software system itself.
But you will only be able to hire the employees willing to tolerate working with it. Especially the condition of not planning any form of modernization.
And as phillipcarter noted, increasingly more libraries drop 'netstandard2.0' target, depending on the workload the performance difference is going to be anything between 50% and multiple orders of magnitude (e.g. Regex engine has gotten tens of thousands of percents faster for some patterns).
Working with .NET Framework from non-Windows environment requires using Parallels / UTM on macOS or QEMU or any other VM env. on Linux - there's Mono but it's not a replacement, and I don't think Visual Studio will work under Wine.
There are all sorts of hidden costs that you don't plan for, that come with using .NET Framework.
One of the bigger problems with staying on .NET Framework is that it limits you to C# 7.3, which lacks a lot of new language features (e.g., most pattern matching, records, nullable reference types, etc.). It can be both frustrating and even potentially career limiting to be stuck on that for too long.
You can use newer LangVersions with older targets, including .NET Framework. A good deal of features can be made work by just setting LangVersion: 13 and doing dotnet add package PolySharp. But of course this won't bring missing span-based APIs, new ASP.NET Core and EF Core, etc.
However, the workplaces that adamantly refuse to upgrade also select for developers who may not be familiar with pattern matching or other features at all, and never read release notes.
Honestly, if a project in 2025 is on .NET Framework, I am simply not going to believe any statements about pending modernisation. Simply because if it was going to happen, it would have happened already.
Not sure why this is so aggressively downvoted. I work in legacy software and it's true. A firm that's still on .NET Framework, PHP 5.6, or Java 8 is likely to stay on those versions for the near future.
We just moved from 4.6.1 to 4.8 this year. We maintain a frontend(++) for a major enterprise software package, and follow them. They just moved to 4.8 so we did as well. Not even the point release. The contractor I work for is pretty conservative, he likes his 1+ million dollar home and worldwide vacations. He won't be changing anything without being forced by Microsoft.
Even if Microsoft puts in a huge effort to updating a migration tool to be seamless, we wouldn't use it. It'll only happen when either the larger enterprise corporation migrates, or when Microsoft forces people off 4.8.
.NET as well. If you do a framework-dependent deployment, then in many cases you only need to run Windows Update, just like with .NET framework.
Yes... if you do self-contained deployments or build containers, then of course you're tied to the version you've built with - but that is your choice and therefore your responsibility.
You are now blaming having that some deployment choices cannot be updated manually. It is the wrong mindset.
> .NET Core requires you to jump one version up almost every year,
Close.
* The requirement is to jump every second year when a LTS version comes out. Last one was .NET 6 to .NET 8. And next, .NET 10 will come in November 2025. You can jump 1 version every year, but it's not a "requirement".
* It's just called ".NET" now, not ".NET Core". There is no ambiguity in e.g. ".NET 8" - it's the modern version formerly known as ".NET Core".
* Release is every year in November, and every second one is LTS. there's no "almost", it's every time. IDK if this will still be so in 10 years time, but it's been consistent.
* maintenance cost? Yes, you have to review project files and build pipelines in order to to update, so there's some detailed work, but the actual breaking changes and puzzling issues are few to non-existent. It typically goes very smoothly after you change some numbers.
For what it's worth, migrating from Java 8 to 11 is much smoother than .Net 4.x to .NET Core / Standard / 6+. In all honesty, in all the project we've migrated it was only ever so slightly more painful than migrating 11->17 or 17->21. You typically have to upgrade some libraries and your version of Gradle (assuming you're using it).
There is a much stronger case for enterprise apps being stuck on .NET 4.x.
In my experience porting from .NET Framework to .NET Core isn't that difficult per se -- it is the frameworks that we are stuck on that cause the difficulty, namely if you have a large project using ASP.NET pages and EntityFramework classic, which do not have compatible .net core versions really. The .net core replacements are objectively better, but have significant conceptual and API differences that prevent a simple move.
There are some community projects that try to fill this void by porting entityframework classic to .net core for example though.
> The odd-numbered .NET releases aren't even worth looking at from an enterprise perspective.
Not hard to argue the opposite either; as you have to upgrade every 2ish years anyway is the LTS track really that valuable compared to updating every march-ish when the latest has been proven? 6 -> 7 -> 8 -> 9 was trivial too.
Meanwhile a friend of mine still has 4.6 going strong and I’d struggle to argue a reason to migrate.
I've been given an old .NET Framework project, at least with .NET you can target .NET Standard 2.0, and that way additions can be done on top of the modern(ish) ecosystem, for progressive rewriting
At least MS won't kill .NET Framework until they've fully transitioned Desktop Office, Visual Studio and Sharepoint, so we at least have a couple decades ahead (Much to my chagrin)
Sidenote: Whoever is in charge of Microsoft naming schemes deserves to be taken behind the barn and shot, they can't keep getting away with this
The horrible naming thing is epitomised by the frankenstein that is, "ASP.NET Core 2.3", which is a re-release of "ASP.NET Core 2.1", which is actually a .NET Framework thing.
Re-released because ASP.NET Core 2.1 had a better support lifecycle than ASP.NET Core 2.2, and people "upgraded" to 2.2 not realising this.
So people got stuck on unsupported 2.2, rather than the supported 2.1.
So they re-released 2.1 as 2.3, to give people an "upgrade" path from 2.2 to 2.1.
All named after "ASP.NET Core" which, confusingly, is detached from ASP.NET on .NET Core.
( .NET Core which is now just ".NET" , of course. )
I swear .NET has had the best technology focus for the past 5 or so years, but has had absoultely the worse brand and a complete lack of developer relations / brand ambassador type work.
They need someone who can turn around and tell them to stop this madness, and focus on getting out that .NET is a fantastic ecosystem that performs damn well, and modern C# a pleasure to write in.
But instead we get stuff like "EF Core 9" that targets .NET 8, and all the 9.0.x system libraries, where isn't not clear whether you should be using them if you want to stick to the LTS and target .net 8.
Do you think with different naming or branding it would've been any better? I'm not sure it would - I think the big thing is that they've tried to move from a (legacy) Windows-heavy language/runtime to one that is more cross-platform, and that is inevitably going to be tricky no matter what you call it.
I think the naming does make sense, it's just been maybe been poorly communicated, because I've seen a few people getting tripped up by it.
The projects would be roughly the same, but information about them would be significantly cleaner
If I see an article about .NET, depending on the year it might be about 2 different product lines, because the shorthand was made to be the same
If I need to google how to X in Visual Studio, more than half of the results will be irrelevant, because they will be about a different product, so on and so on
If the naming was good, it wouldn't trip up people (So regularly at least), that's my point
Other ones that trip up people, Teams for personal use?, that one regularly bugs out when interacting with business users?
Skype vs Skype for Business?
That does introduce some ambiguity, I just don't know how often people google things like that. And if searching "how to authorize HTTP request .NET" (or similar) is a common occurrence, I reckon there's a bigger problem lurking beneath the surface there...
It's worse on less formal communication, but shorthand "We're targeting .NET" might mean
"We're targeting .NET (Standard)" (Which works on both Framework and used to be Core / current .NET)
"We're targeting .NET (Framework)" (Used to be shortened to .NET)
"We're targeting .NET" (Formerly .NET Core) / (6/7/8/9), current recomendation being to call this one just .NET (But not always respected, and not retroactively applied
If legacy wasn't a thing, there wouldn't be much trouble, but since many libraries and some functionality does get backported, you might be stuck with documentation doing any of them, maybe even inconsistently
We have a(n enterprise) product that uses .NET 4.x for the UI, and I've explored moving to current .NET, however:
* Supporting some older OSes and requiring less system base updates is key
* There's a priority to keep installation size (relatively) small
* There's a (higher-up) notion of "if it works, why change it"
On top of that, some technical issues I've encountered (since resolved) and gave up on upgrading were:
* Up until relatively recently there was no "single executable" deployment
* For some part of Core's lifetime you had this weird deployment of DLL-run-by-EXE that's a dealbreaker for the software's security boundaries & requirements
* Huge executable size, until recently where trimming unused framework code was added
There was also some period of time where the .NET party line was "WPF is legacy, we don't support it on modern .NET" and our UI is already built in WPF. We couldn't move to something like WinUI due to supporting Windows <10 and even then, WinUI 3 increases your deployment executable's size by a lot. Thankfully they added WPF support in .NET 8/9.
The .NET 4.X runtimes baked into Win10/11 are OS components just like Win32 is an OS Component.
That's first of all brilliant if you want to ship apps that run on those systems, because you don't need to ship the runtime.
But it's painful when you want to write server software. Because you don't want your deployment story to be dependent on the server having some particular system level software (or it being windows).
So it's completely inevitable that 4.X will never die. Win32 won't die either.
And making the ship to a completely separate runtime that runs on Linux, and isn't an OS component (but in return requires deployment) was just natural. It's not completely unthinkable that the .NET Runtime will be shipped as part of Windows, but even that woulnd't mean that they can stop shipping the .NET Framework 4.X runtmes.
I just ported a 20 year old 200+ man year desktop app from 4.8 to 8.0 and it was pretty smooth. Even things like old binary-only proprietary winforms controls actually work, which was a huge surprise.
If you are making a web app or any kind of server side app, then the migration is usually straightforward. For client side software it's not as easy, and in some cases it's also not clear whether it's a win. If you are shipping some small Windows-only utility it's probably better to ship on the "old" runtime because your deployment will be smaller when you can use the OS runtime.
I started working for a team that built an ETL system for a large, globally operating client—handling everything from data processing to data storage. The entire infrastructure was, and still is, based on .NET 4.6.x, MSSQL Server, and SSIS.
The problem: everything is tightly bound to the Microsoft ecosystem—Windows Server 2019, SSIS development in Visual Studio (which only runs on Windows), and even a proprietary VPN tunnel to access the servers. Everything. And it’s been like this for years. Needless to say, there’s no proper documentation.
I raised concerns that this probably isn’t the most sustainable way to run such a critical system. But no one ever cared. Not only is it technically outdated, but the codebase has also grown organically into a somewhat chaotic structure, with countless things hardcoded in ways that make maintenance a nightmare.
The client isn’t tech-savvy, so they never questioned any of it. And the team has always worked in isolation, with no one ever challenging their approach. Thing is: they are total experts. They know the system inside out. “Never change a running system” is the motto of the day.
Now they’re sitting on this massive, outdated, self-built system. It’s probably difficult to find developers willing or able to work within these constraints. I’m standing on the sidelines, having lost the motivation to help, wondering whether they’ll ever get out of this—or if things will just quietly fall apart in the coming years.
In all my years as a developer/engineer across several companies, this is the first time I’ve encountered such stubbornness and turf protection.
(If I ever end up this stubborn, please slap me!)
I can't imagine not wanting to at least get on 4.8, we just did this year. Not that it was up to me to wait this long. But I definitely would advocate a project to get anything that may need updated quickly into configuration files. That's something we do well. The rest of the stack doesn't really matter, just a means to an end. Your group's bigger problem really is just general sloppiness.
MS dropped compatibility, so there really is no migration path off of .net framework, short of a full port. The resources -- time and money -- for this simply don't exist in the great majority of cases.
> might be decades away rather than years
It's never.
(Short of the decay of civilization, that is, to the point people can no longer run software generally).
People will run their .net framework software until they literally can't anymore. If MS won't/can't support it, another way will be found -- probably legacy software will run in virtual legacy environments, with security patches applied around it somehow (this approach is already in full swing, of course).
I'm not sure where the idea that everything that exists so far will conveniently disappear to make our lives simpler when something new comes out. It just doesn't work that way.
With the new .net, MS hasn't gotten away from anything. They just have yet another thing to support.
> People will run their .net framework software until they literally can't anymore. If MS won't/can't support it, another way will be found
Yep, I'm sure there's at least some out there who switched to running off something like Mono on Windows to work around some unpatched .NET Framework issues.
Migrated a small-ish project from ASP.NET Framework (.NET 4.8) to ASP.NET Core (i.e. .NET 8) including EF6 to EF Core last year. Even though it was pretty smooth sailing (the application was already using MVC), it was still a few weeks work.
Rewrite queries that are not yet supported on EF Core, create some new DTOs, create drop-in replacements for stuff that isn't there anymore, create plumbing to connect some old stuff to some new stuff. Figure out what's the new replacement for XYZ and use it correctly to not break anything. Replace nuget packages that are not maintained anymore or have so few downloads that they are a supply chain risk.
You need to test every endpoint, every query in your application.
And in the Microsoft World you're still pretty ok, overall, it's quite stable.
God forbid you put your money on the wrong web framework (not even talking frontend) in the Java space. There's still Tapestry/Struts/Grails/JSF/GWT/Play etc. applications serving your request out there. Saw some banking website with ".do" urls recently (indicative of Struts).
Unless we get superhuman AI that can do such migrations all on their own, those zombies might have a longer working life left than lots of developers. Many companies just can't afford to upgrade - there's so many systems built over decades that just do what they should do. Why shell out tons of money to just get the same functionality?
> Copilot agent mode can create apps from scratch, perform refactorings across multiple files, write and run tests, and migrate legacy code to modern frameworks.
I wonder if the relative lack of training data makes this harder for AI. Most of these legacy apps are in private repositories, so there’s nothing for GitHub to scrape to identify the before/after.
And if Microsoft is creating synthetic data, that won’t account for the truly awful ways in which enterprise software evolves (or devolves).
Java 8 to Java 9 is a huge change. Internal parts/utils where dropped. Modules where introduces that makes building your software slightly more complex. If your team is using an external product build on top of this JDK a migration to a newer is often delayed because of the external dependency (IBM WebShere took ages to migrate) plus it might require a new license and extra costs.
I've seen a number of startups who are stuck on .NET Framework, simply because some affordable agency built them an MVP with ASP.NET a while ago and it worked (TM) to get the business going.
Then someone like me gets called into a situation where they have ridiculous hosting costs (Windows-only, typically also MS SQL), nasty performance issues, and struggle to stay productive and find developers. The most reasonable path forward I see in those situations is a gradual migration to .NET Core and something like PostgreSQL.
And that's a major investment. Microsoft couldn't have made .NET Framework code harder to port to .NET Core if that had been their explicit goal. I find database migrations with Entity Framework similarly difficult compared to other ORMs. Startups can sometimes afford such investments, but often not.
And that's how you ironically get 2-3 year old startups stuck on a death march old school enterprise code stack. It appears to be more common than I'd like it to be.
Really if someone can make something that allows legacy ASP.NET code to run on .net core, that would be huge for getting older projects migrated. For example, https://github.com/zzzprojects/EntityFramework-Classic EntityFrameworkClassic is a fork of Entity Framework 6 which runs on .net core but still lets you use your existing EF6 code.
ASP.NET is a much different beast though, but I don't see any technical reason that it would not be possible. I keep expecting one to show up. I think the ISAPI integration is the biggest hurdle there; lots of weird behaviors that would have to be addressed.
Java has an almost unbroken history of hassle-free version updates, all the way back to Java 1.0. (Okay, okay, I know you have a specific anecdote of a broken version update. I said “almost”.)
The one major exception was from Java 8 to Java 9. There’s some good reasons why Java 8 to Java 9 wasn’t a smooth upgrade for all. But that’s a story for another day.
For slow-moving enterprise IT departments, that would involve a major “update Java” project. Which involves budgets and people and not doing other things in the meantime.
Hence why Java 8 is still so prevalent in enterprise world.
In a galaxy far far away so called "J2EE application servers" used to be the reason JDK upgrades were not allowed. And that would probably be a real major update Java project.
When I joined my current team (in a big honkin' corporation with a history of layoffs and outsourcing) I inherited a dozen microservices, all on JDK8 and a couple written in Scala. So among the first things I did was an upgrade to JDK17 of every single repository. And it was mostly uneventful. More or less use a different Docker base image and bump up the Spring Boot version from 1.x to 3.4. Not running the latest LTS release is professional negligence in my book.
I don't even remember Java 8 to 9 (our platform vendor updates his product and after that we have to update ours in a fairly short timeframe, so it must not have been too painful), but I think there is a breaking change in every recent release, most recently we had to rename javax.mail to jakarta.mail and some other stuff like that when upgrading to Java 21. I don't mind but would not describe that as hassle free.
At my workplace, we treat .NET 4.x as an enterprise runtime considering its widespread availability and good maintenance. While we design and compile all the modules with first-class support of new .NET versions, all of them are able to run on .NET 4.x as well. To make that possible, we use a handful amount of polyfills. Fortunately, it all works transparently without causing any troubles.
>It's kind of ironic that even today, the default .NET version baked into fresh Windows installs is 4.6 (or nearby), not the shiny new .NET 8/9.
This is because the distribution model changed ? You would probably publish self-contained .NET app these days ? Not sure - have not built a desktop app in .NET in a decade :)
I think there is an increasing number of Enterprise planning to move direct from JDK 8 to the latest LTS JDK 21. You get insane amount of improvement just from the JVM alone.
It is sad you dont often hear about any of these on HN. C#/ .Net, Java / JDK, PHP, MySQL, MSSQL, Oracle, or anything older, boring technology that is getting steady improvement, production usage, boring and never getting the upvote to get on main page for discussions. Everyone is chasing new hype and new JS front end.
Do not get fooled, HN tends to artificially distort our perception of reality by manually ranking and de-ranking topics according to political and monetary agendas of the day.
A very good example of that malignant practice is this very topic which was manually de-ranked.
Those narratives are pushed by the resource owners whose wellbeing depends on disruption and hype. But stability is an enemy of disruption, and delivered functionality is the enemy of hype. So they have no choice but to de-rank the topics like that, otherwise they lose power because everybody starts to see what is hidden behind the mask.
This is also why reports from StackOverflow on language usage should not be considered to represent the entire software development market, more so whats popular, new and open source.
Not long after JDK 8 Oracle made some changes to reflection that broke a lot of code, although often you can unbreak it with the right command line arguments.
Staffing and maintenance are the business concerns for staying on old tech stacks. .NET developers should absolutely be taking them to the bank if forced to work on .NET Framework without being able to migrate it.
I've worked for multiple shops that basically just moved to Java 8 and then bolted an anchor to the nearest pylon. A few made one move to JDK 11 for the "LTS" experience. I can understand their reluctance to move on as the move from <8 to 8 brought a lot of pain. Those old apps had a lot of cruft. Your modern Spring Boot app shouldn't be as tough though. (ByteBuddy maybe an issue). Even the folks that have moved on, aren't really using any of the new functionality. I realize every shop is different, this is just my experience.
I work for a 40 year old private enterprise with a large Java 8 micro-service architecture. My current project is to facilitate the migration to Java 21.
As you point out, there needs to be a compelling business reason. In our case, we are migrating to K8s as well, which is easier to make the business case for.
Security helps make the case as well. Any enterprise using Java 8 and Spring Boot is riddled with CVEs.
Spring Boot 3 requiring Java 17 is what allowed the migration in two companies I’ve been, it’s much easier to sell it as security issue than tech debt.
I guess those are runtimes just predating a fairly large breaking change (actually I know they are for C#, and I have a vague idea of what broke from Java 8 too).
I think that updating from old version is prime AI work. It's not hard, usually. It's just a lot of boring, soul-sapping work, enough that if you set the famous 10x engineer to do it, they wouldn't be a 10x engineer by the end.
Then again, maybe a super-engineer would do something wild like the Minecraft 1.8 modding community did... despite being a pile of code injection hacks into a famously messy codebase, chock full of reflection and classloader shenanigans, they actually found a way to run it on a newer version of Java than the official, latest version of Minecraft can run on.
I know the .NET story much better than Java. .NET Framework support is tied to the OS support for one thing, so as long as Windows is supported, so is the corollary.NET version.
One of the values of .NET Core is that it doesn't need to be installed at all in the OS.
We are migrating away from. NET as a SaaS company. Our Monolith is in Framework and being deconstructed into .NET (current) services. It's a journey, hoping to be done in 2 years. We did successfully migrate the frontend from webforms to React, page by page. I'm sure there are other teams as well. I just interviewed a lead that was on a team doing the same thing on a Java 8 platform with a monolith.
Having just done that on a massive monolith (10y+ codebase continuously developed) I would recommend biting the bullet and doing upgrading all of your projects at once to either .NET Standard or .NET 9 where applicable. Pause development of new features or just do minimal changes on the main branch. We had a ton of footguns (EF6 -> EF Core, WPF, WCF, file serialization, multiple web services) and we were able to complete the migration in 6 months.
> so as long as Windows is supported, so is the corollary.NET version.
With Windows 11, Microsoft stepped away from their normal long-term support lifecycle. Now, you get two years or so of guaranteed support per Windows 11 release, instead of the 5+5 years even Windows 10 received.
Unless you're targeting Windows server or LTSC, depending on the Windows library may not be such a great long-term solution anymore.
The OS support isn't quite as ironclad as that. Windows Server 2019 was the last version where .NET Framework 3.5 will be supported for the lifetime of the OS; while later versions still include 3.5 as an optional feature, it's only going to be supported until January 2029 (when 2019 goes out of support), even if the OS is still in support.
We know .NET Framework 4.x will still have to be supported through October 2034 to meet similar support obligations for Windows Server 2025; but Microsoft could easily let that be the end date for 4.x if they wanted, even if Windows as a whole is still supported.
In the case of .net , I think its due to support of windows OS like 7 , In my part of the world users refuse to update their OS. Software providers need to keep on supporting Obsolete OS's. Thus Runtime support exists till date.
Upgrading JDK 8 is a pain. Many JDK libraries have been moved to external dependencies (which is fine) with new class paths (which breaks existing code). Source code can be fixed with find/replace, but reflection stuff needs to be updated manually.
JDK9 also introduced a good modularization system, which broke many Java reflection hacks. JDK17 introduced even more boundaries which JDK21 enforced.
Companies with the foresight to upgrade before the end is near have been working on fixing these issues for a while now, but with Red Hat still supporting JDK8 for another decade or so, I don't think we'll be rid of these old runtimes any day soon. Furthermore, Oracle only distributes JVM8 to consumers. If you're building desktop applications, targeting JDK8 is a lot easier than targeting anything newer, unless you precompile your application or ship your own JDK.
Java devs can use any number of OpenJDK forks with support. Companies stuck in their ways will not update their toolchains until they break, and even then they will try to find workarounds before they implement fixes.
I don't know about .NET 5+, but without WinForms, new .NET just isn't a replacement. MAUI is nice and all, but it's not as simple and easy to use as WinForms, and there's no direct translation between the two.
Futhermore, the difference between .NET 4 and .NET 5/Core is that .NET 4 ships with Windows and is guaranteed to be available. .NET 5/Core will need to have its runtime be installed.
I think both Oracle and Microsoft are considering anything newer than Java 8/.NET 4 to be "stuff for large, packaged applications, web servers, and enterprise" and the old software part of their legacy API for consumers. I don't know of any Java application that requires a newer version of Java than Java 8 (that isn't itself an SDK for developing Java applications).
All of that said: upgrading Java is worth it, just for performance reasons alone. Java may not have the latest tech and it still lacks basic modern language features such as nullable types, but JVM is still an outstanding piece of tech.
Yes. We have several solutions that include WinForms projects. Migrating those from Framework 4.8 to .Net 8 was as simple as changing "net48" to "net8.0-windows" in the csproj file.
> It's kind of ironic that even today, the default .NET version baked into fresh Windows installs is 4.6 (or nearby), not the shiny new .NET 8/9. Meanwhile, Oracle still offers JDK 8 — albeit behind a paid support wall — much like Microsoft continues to patch .NET 4.x via Windows Update.
You answered your own question. .NET can never ship with Windows, because it then _needs_ to be supported forever. Imagine Microsoft needing to not only support .NET Framework 4.x, but also support .NET Core 3, .NET 6, .NET 8 etc.
.NET Core's migration story was a disaster; Microsoft's official guide basically recommended that you create a new project and copy files over one by one and hoped for the best. Many people didn't bother.
Java 9 was also a mess; inching slightly closer to Scala and Kotlin (but not enough to make it worth going back to Java-the-language if you had already switched to one of those), while breaking a lot of existing code (a cardinal sin for a platform whose stability was its primary claim to fame). Many people didn't bother.
>And are there any good examples where teams actually migrated away from 4.x or 8.x successfully
Sure, at my former workplace they migrated one of the products (a document processing platform) from .NET 4.5 to .NET 8.
It's quite a lot of work to do something like that and most companies who have old products on .NET 4 don't care to update them because they still work. Many are still adding new features to old .NET 4 codebases.
Many will only upgrade if Microsoft deprecates .NET 4 and stops providing updates.
Migration from Java 8 is very easy, I don't really know why they keep using old versions. Probably lack of qualification. Or project is just dead with pinned ancient dependencies of terrible libraries which rely on JVM internals. I'm using Java 8 with one project, because that project must run on Windows Vista and later javas don't run on it. As soon as Windows Vista would become irrelevant, I'll drop the support in one day.
The problem with Java migrations is sometimes people (ab)use the behavior of a specific library in that specific version, and when you change the runtime, everything comes crashing down (visibly or invisibly).
I have seen quite a few Java applications which fails at unrelated points, and every time I have been told that the thing only runs with "jre-old.very.specific.version-and.point.release". Otherwise you're out of luck.
Java 8 is...the 8th version of the Java Framework. It's supported until 2030. But frankly you can just move to more recent versions. The main reason not to is that once you do you're stuck moving more often, because the later versions are only supported until 2031. So you're not gaining much.
.Net Framework is the version of .Net that ships with Windows, and it's supported as long as Windows is. For Windows 11, presumably until at least 2035. It's entirely possible that Windows 12 will also ship with .Net Framework, as otherwise they'll have to convert a ton of MS apps to .Net, at which point you're safe until 2045.
.Net (previously .Net Core) is the open-source cross-platform framework forked from .Net Framework. And once you move to that you're going to have to move to the latest version every 3 years, because that's how long they're going to support an LTS version for.
So if you have a bunch of apps and don't care about the new functionality, and just want to make sure you have security patches then you'll stick to the version that you've got, and you'll only move once they tell you you have to.
Windows 11 still includes the Visual Basic 6 runtime, which predates .NET by quite a bit (from 1998!). There are many working systems that still rely on this.
In the case of Java 8, at least, I know that later versions significantly changed the kind of metaprogramming, standard library, and even project structure you could use. So I think there's more friction to move off of it than you might first imagine.
I suspect a non-small part of the story is accounting rules. If you're in a place where such an upgrade would be paid for out of operational expenditure, there's always going to be a reason not to do it.
Enterprises are stuck on Java 8, so that's what everyone is familiar with. This is why I use Kotlin; if you don't know the new stuff anyway, you may as well just use a better language.
Porting .NET framework to .NET core / standard / 6+ really isn't as smooth as MS would like you to believe.
And the support lifecycle for .NET4.8 is ironically better than they are for .NET 6 (already dead) and .NET 8, because of the shipping-with-windows thing.
The odd-numbered .NET releases aren't even worth looking at from an enterprise perspective.
So yeah, there'll be a bunch of .net framework code around for a while.
That said, it's frustrating, because in some places the performance just isn't there, and there are so many nuanced differences between them there's a weird effect trying to switch between them.
You not only have to recall which APIs are available in each, but the performance differences between otherwise identical (or near identical) APIs.
> Porting .NET framework to .NET core / standard / 6+ really isn't as smooth as MS would like you to believe.
Having just spend the better part of 3 months porting a lot of legacy projects, you're absolutely right, but I am not sure where MS said this would be smooth. There are some processes that are standard enough but certainly there is a lot of hands on work involved, and actually for good reason, there are performance and security issues that need to be addressed (In my brief, and hopefully final experience).
That said, porting from event .net versions (stable LTS versions) such as 6 -> 8 has so far been flawless, I think over the last year, we ran into maybe some minor semantic issues.
It's not perfect, but I have to defend MS unfortunately, they are taking things in the right direction while being tied to a LOT of legacy enterprise clients and systems.
I have pretty much the same experience, but it is highly dependent on what you were using.
- WCF ? (very enterprisy i know) : you are still mostly screwed
- aspx ? compulsory rewrite
- MVC ? mostly smooth (but most of the pain is in initialization so comes early and can discourage newbies)
- Console ? mostly smooth
- before .Net 6 ? it was a death march, not only many API were lacking, but third party libraries were also missing.
- .Net 6 -> .Net 8 ? very smooth
I'd add that WPF was "don't bother" up until recently when WPF support was added. (Though I don't know if that means stock WPF or that it supports the breadth of WPF controls out there, and whether it requires WPF component vendors to make changes)
We just migrated our massive WPF application to .NET 8 and there are a handful of libraries that are not supported or had to be replaced but overall it was surprisingly smooth. The biggest issue we have is that garbage collection seems to have taken a huge hit and there are bugs in the Microsoft WPF components (any sort of list view in particular) but it's all relatively easy to work around.
There is WCF Core but it is not even close to feature parity with the 4.8 WCF.
Yes, it's partial parity, and is server only. It's also not easy to migrate; the upgrade-assistant tool typically just gives up.
The client libraries only came separately, and much later[1] , and in typical "Fuck your migration path" fashion, doesn't have any .NET standard support.
[1]: ( https://devblogs.microsoft.com/dotnet/wcf-client-60-has-been... )
After.NET 6 upgrading is mostly just changing the number in the project file.
Support for .NET Frameworks 4.8 is essentially forever and .NET Core requires you to jump one version up almost every year, which has a much higher maintenance cost.
This is completely false and goes against the experience of the vast majority of the teams.
Using .NET Framework carries significant risk and opportunity cost. Updating LTS every 2 years usually comes with simply bumping up versions and rebuilding.
It’s not “completely “ false. Otherwise this sentiment wouldn’t exist and .NET 4 would be a nice memory like Windows 2000.
Opportunity cost? Sure, but you can’t deny that small teams that just wanted some stuff to please a business itch were able put the shitty code in whatever Win server they had at the time and forget about it. They didn’t have to ask IT to evaluate any installs, it was right there. And today in win 10 servers, that code still runs, returning ugly aspx.
We have some equivalent 2.1 stuff laying around and no one wants to go through the trouble of updating that.
You’re probably going to say something like “well that’s what you get when you just let your code rot and no one cared to document it and maintain it”. Yes, true, but that’s not the on topic point, one of those constantly comes up in vulnerability reports and one doesn’t.
Yep, this is correct. Not to mention the maintenance cost of .NET Framework going up every year because the library ecosystem moves onwards, eventually, from legacy behaviors.
And also, bumping the .NET version from 8 to 9 or 9 to 10 is typically a very small effort for most. I think what the OP is describing is working for a software cost center where they don't value the software system itself.
Avoid odd numbers for production. Update/upgrade every two years.
.NET Framework just get security updates means no rebuild, no unnecessary updates for your users
But you will only be able to hire the employees willing to tolerate working with it. Especially the condition of not planning any form of modernization.
And as phillipcarter noted, increasingly more libraries drop 'netstandard2.0' target, depending on the workload the performance difference is going to be anything between 50% and multiple orders of magnitude (e.g. Regex engine has gotten tens of thousands of percents faster for some patterns).
Working with .NET Framework from non-Windows environment requires using Parallels / UTM on macOS or QEMU or any other VM env. on Linux - there's Mono but it's not a replacement, and I don't think Visual Studio will work under Wine.
There are all sorts of hidden costs that you don't plan for, that come with using .NET Framework.
One of the bigger problems with staying on .NET Framework is that it limits you to C# 7.3, which lacks a lot of new language features (e.g., most pattern matching, records, nullable reference types, etc.). It can be both frustrating and even potentially career limiting to be stuck on that for too long.
You can use newer LangVersions with older targets, including .NET Framework. A good deal of features can be made work by just setting LangVersion: 13 and doing dotnet add package PolySharp. But of course this won't bring missing span-based APIs, new ASP.NET Core and EF Core, etc.
However, the workplaces that adamantly refuse to upgrade also select for developers who may not be familiar with pattern matching or other features at all, and never read release notes.
Honestly, if a project in 2025 is on .NET Framework, I am simply not going to believe any statements about pending modernisation. Simply because if it was going to happen, it would have happened already.
Not sure why this is so aggressively downvoted. I work in legacy software and it's true. A firm that's still on .NET Framework, PHP 5.6, or Java 8 is likely to stay on those versions for the near future.
We just moved from 4.6.1 to 4.8 this year. We maintain a frontend(++) for a major enterprise software package, and follow them. They just moved to 4.8 so we did as well. Not even the point release. The contractor I work for is pretty conservative, he likes his 1+ million dollar home and worldwide vacations. He won't be changing anything without being forced by Microsoft.
Even if Microsoft puts in a huge effort to updating a migration tool to be seamless, we wouldn't use it. It'll only happen when either the larger enterprise corporation migrates, or when Microsoft forces people off 4.8.
Writing C# code in modern .net is so much better.
It's close to the change when get/settwrs were made mostly redunant (but not quite).
Just so much less boiler plate that you didn't even really realize you were writing.
Nothing bad on staying a still supported framework.
Most of the time boring old technology beats shiny new one.
.NET as well. If you do a framework-dependent deployment, then in many cases you only need to run Windows Update, just like with .NET framework.
Yes... if you do self-contained deployments or build containers, then of course you're tied to the version you've built with - but that is your choice and therefore your responsibility.
You are now blaming having that some deployment choices cannot be updated manually. It is the wrong mindset.
> .NET Core requires you to jump one version up almost every year,
Close.
* The requirement is to jump every second year when a LTS version comes out. Last one was .NET 6 to .NET 8. And next, .NET 10 will come in November 2025. You can jump 1 version every year, but it's not a "requirement".
* It's just called ".NET" now, not ".NET Core". There is no ambiguity in e.g. ".NET 8" - it's the modern version formerly known as ".NET Core".
* Release is every year in November, and every second one is LTS. there's no "almost", it's every time. IDK if this will still be so in 10 years time, but it's been consistent.
* maintenance cost? Yes, you have to review project files and build pipelines in order to to update, so there's some detailed work, but the actual breaking changes and puzzling issues are few to non-existent. It typically goes very smoothly after you change some numbers.
We've only done it once so far, who knows if it'll stay that smooth. Before that it was chaotic, to say the least.
> .NET Core requires you to jump one version up almost every year, which has a much higher maintenance cost.
This is basically seamless now, the framework isn't changing in backwards-incompatible ways anymore.
For what it's worth, migrating from Java 8 to 11 is much smoother than .Net 4.x to .NET Core / Standard / 6+. In all honesty, in all the project we've migrated it was only ever so slightly more painful than migrating 11->17 or 17->21. You typically have to upgrade some libraries and your version of Gradle (assuming you're using it).
There is a much stronger case for enterprise apps being stuck on .NET 4.x.
In my experience porting from .NET Framework to .NET Core isn't that difficult per se -- it is the frameworks that we are stuck on that cause the difficulty, namely if you have a large project using ASP.NET pages and EntityFramework classic, which do not have compatible .net core versions really. The .net core replacements are objectively better, but have significant conceptual and API differences that prevent a simple move.
There are some community projects that try to fill this void by porting entityframework classic to .net core for example though.
EF6 works fine on .NET Core. EF Core does not work on .NET Framework.
> The odd-numbered .NET releases aren't even worth looking at from an enterprise perspective.
Not hard to argue the opposite either; as you have to upgrade every 2ish years anyway is the LTS track really that valuable compared to updating every march-ish when the latest has been proven? 6 -> 7 -> 8 -> 9 was trivial too.
Meanwhile a friend of mine still has 4.6 going strong and I’d struggle to argue a reason to migrate.
I've been given an old .NET Framework project, at least with .NET you can target .NET Standard 2.0, and that way additions can be done on top of the modern(ish) ecosystem, for progressive rewriting
At least MS won't kill .NET Framework until they've fully transitioned Desktop Office, Visual Studio and Sharepoint, so we at least have a couple decades ahead (Much to my chagrin)
Sidenote: Whoever is in charge of Microsoft naming schemes deserves to be taken behind the barn and shot, they can't keep getting away with this
The horrible naming thing is epitomised by the frankenstein that is, "ASP.NET Core 2.3", which is a re-release of "ASP.NET Core 2.1", which is actually a .NET Framework thing.
Re-released because ASP.NET Core 2.1 had a better support lifecycle than ASP.NET Core 2.2, and people "upgraded" to 2.2 not realising this.
So people got stuck on unsupported 2.2, rather than the supported 2.1.
So they re-released 2.1 as 2.3, to give people an "upgrade" path from 2.2 to 2.1.
All named after "ASP.NET Core" which, confusingly, is detached from ASP.NET on .NET Core.
( .NET Core which is now just ".NET" , of course. )
Read the whole horror-show here: https://devblogs.microsoft.com/dotnet/servicing-release-advi...
I swear .NET has had the best technology focus for the past 5 or so years, but has had absoultely the worse brand and a complete lack of developer relations / brand ambassador type work.
They need someone who can turn around and tell them to stop this madness, and focus on getting out that .NET is a fantastic ecosystem that performs damn well, and modern C# a pleasure to write in.
But instead we get stuff like "EF Core 9" that targets .NET 8, and all the 9.0.x system libraries, where isn't not clear whether you should be using them if you want to stick to the LTS and target .net 8.
Do you think with different naming or branding it would've been any better? I'm not sure it would - I think the big thing is that they've tried to move from a (legacy) Windows-heavy language/runtime to one that is more cross-platform, and that is inevitably going to be tricky no matter what you call it.
I think the naming does make sense, it's just been maybe been poorly communicated, because I've seen a few people getting tripped up by it.
The projects would be roughly the same, but information about them would be significantly cleaner
If I see an article about .NET, depending on the year it might be about 2 different product lines, because the shorthand was made to be the same
If I need to google how to X in Visual Studio, more than half of the results will be irrelevant, because they will be about a different product, so on and so on
If the naming was good, it wouldn't trip up people (So regularly at least), that's my point
Other ones that trip up people, Teams for personal use?, that one regularly bugs out when interacting with business users? Skype vs Skype for Business?
That does introduce some ambiguity, I just don't know how often people google things like that. And if searching "how to authorize HTTP request .NET" (or similar) is a common occurrence, I reckon there's a bigger problem lurking beneath the surface there...
It's worse on less formal communication, but shorthand "We're targeting .NET" might mean
"We're targeting .NET (Standard)" (Which works on both Framework and used to be Core / current .NET)
"We're targeting .NET (Framework)" (Used to be shortened to .NET)
"We're targeting .NET" (Formerly .NET Core) / (6/7/8/9), current recomendation being to call this one just .NET (But not always respected, and not retroactively applied
If legacy wasn't a thing, there wouldn't be much trouble, but since many libraries and some functionality does get backported, you might be stuck with documentation doing any of them, maybe even inconsistently
We have a(n enterprise) product that uses .NET 4.x for the UI, and I've explored moving to current .NET, however:
* Supporting some older OSes and requiring less system base updates is key
* There's a priority to keep installation size (relatively) small
* There's a (higher-up) notion of "if it works, why change it"
On top of that, some technical issues I've encountered (since resolved) and gave up on upgrading were:
* Up until relatively recently there was no "single executable" deployment
* For some part of Core's lifetime you had this weird deployment of DLL-run-by-EXE that's a dealbreaker for the software's security boundaries & requirements
* Huge executable size, until recently where trimming unused framework code was added
There was also some period of time where the .NET party line was "WPF is legacy, we don't support it on modern .NET" and our UI is already built in WPF. We couldn't move to something like WinUI due to supporting Windows <10 and even then, WinUI 3 increases your deployment executable's size by a lot. Thankfully they added WPF support in .NET 8/9.
The .NET 4.X runtimes baked into Win10/11 are OS components just like Win32 is an OS Component.
That's first of all brilliant if you want to ship apps that run on those systems, because you don't need to ship the runtime. But it's painful when you want to write server software. Because you don't want your deployment story to be dependent on the server having some particular system level software (or it being windows). So it's completely inevitable that 4.X will never die. Win32 won't die either.
And making the ship to a completely separate runtime that runs on Linux, and isn't an OS component (but in return requires deployment) was just natural. It's not completely unthinkable that the .NET Runtime will be shipped as part of Windows, but even that woulnd't mean that they can stop shipping the .NET Framework 4.X runtmes.
I just ported a 20 year old 200+ man year desktop app from 4.8 to 8.0 and it was pretty smooth. Even things like old binary-only proprietary winforms controls actually work, which was a huge surprise.
If you are making a web app or any kind of server side app, then the migration is usually straightforward. For client side software it's not as easy, and in some cases it's also not clear whether it's a win. If you are shipping some small Windows-only utility it's probably better to ship on the "old" runtime because your deployment will be smaller when you can use the OS runtime.
I started working for a team that built an ETL system for a large, globally operating client—handling everything from data processing to data storage. The entire infrastructure was, and still is, based on .NET 4.6.x, MSSQL Server, and SSIS.
The problem: everything is tightly bound to the Microsoft ecosystem—Windows Server 2019, SSIS development in Visual Studio (which only runs on Windows), and even a proprietary VPN tunnel to access the servers. Everything. And it’s been like this for years. Needless to say, there’s no proper documentation.
I raised concerns that this probably isn’t the most sustainable way to run such a critical system. But no one ever cared. Not only is it technically outdated, but the codebase has also grown organically into a somewhat chaotic structure, with countless things hardcoded in ways that make maintenance a nightmare.
The client isn’t tech-savvy, so they never questioned any of it. And the team has always worked in isolation, with no one ever challenging their approach. Thing is: they are total experts. They know the system inside out. “Never change a running system” is the motto of the day.
Now they’re sitting on this massive, outdated, self-built system. It’s probably difficult to find developers willing or able to work within these constraints. I’m standing on the sidelines, having lost the motivation to help, wondering whether they’ll ever get out of this—or if things will just quietly fall apart in the coming years.
In all my years as a developer/engineer across several companies, this is the first time I’ve encountered such stubbornness and turf protection. (If I ever end up this stubborn, please slap me!)
I can't imagine not wanting to at least get on 4.8, we just did this year. Not that it was up to me to wait this long. But I definitely would advocate a project to get anything that may need updated quickly into configuration files. That's something we do well. The rest of the stack doesn't really matter, just a means to an end. Your group's bigger problem really is just general sloppiness.
(I'll speak about .net since that's what I know.)
MS dropped compatibility, so there really is no migration path off of .net framework, short of a full port. The resources -- time and money -- for this simply don't exist in the great majority of cases.
> might be decades away rather than years
It's never.
(Short of the decay of civilization, that is, to the point people can no longer run software generally).
People will run their .net framework software until they literally can't anymore. If MS won't/can't support it, another way will be found -- probably legacy software will run in virtual legacy environments, with security patches applied around it somehow (this approach is already in full swing, of course).
I'm not sure where the idea that everything that exists so far will conveniently disappear to make our lives simpler when something new comes out. It just doesn't work that way.
With the new .net, MS hasn't gotten away from anything. They just have yet another thing to support.
> People will run their .net framework software until they literally can't anymore. If MS won't/can't support it, another way will be found
Yep, I'm sure there's at least some out there who switched to running off something like Mono on Windows to work around some unpatched .NET Framework issues.
Migrated a small-ish project from ASP.NET Framework (.NET 4.8) to ASP.NET Core (i.e. .NET 8) including EF6 to EF Core last year. Even though it was pretty smooth sailing (the application was already using MVC), it was still a few weeks work.
Rewrite queries that are not yet supported on EF Core, create some new DTOs, create drop-in replacements for stuff that isn't there anymore, create plumbing to connect some old stuff to some new stuff. Figure out what's the new replacement for XYZ and use it correctly to not break anything. Replace nuget packages that are not maintained anymore or have so few downloads that they are a supply chain risk.
You need to test every endpoint, every query in your application.
And in the Microsoft World you're still pretty ok, overall, it's quite stable.
God forbid you put your money on the wrong web framework (not even talking frontend) in the Java space. There's still Tapestry/Struts/Grails/JSF/GWT/Play etc. applications serving your request out there. Saw some banking website with ".do" urls recently (indicative of Struts).
Unless we get superhuman AI that can do such migrations all on their own, those zombies might have a longer working life left than lots of developers. Many companies just can't afford to upgrade - there's so many systems built over decades that just do what they should do. Why shell out tons of money to just get the same functionality?
Actually that superhuman AI is already here.
> Copilot agent mode can create apps from scratch, perform refactorings across multiple files, write and run tests, and migrate legacy code to modern frameworks.
https://code.visualstudio.com/blogs/2025/02/24/introducing-c...
I wonder if the relative lack of training data makes this harder for AI. Most of these legacy apps are in private repositories, so there’s nothing for GitHub to scrape to identify the before/after.
And if Microsoft is creating synthetic data, that won’t account for the truly awful ways in which enterprise software evolves (or devolves).
Java 8 to Java 9 is a huge change. Internal parts/utils where dropped. Modules where introduces that makes building your software slightly more complex. If your team is using an external product build on top of this JDK a migration to a newer is often delayed because of the external dependency (IBM WebShere took ages to migrate) plus it might require a new license and extra costs.
I've seen a number of startups who are stuck on .NET Framework, simply because some affordable agency built them an MVP with ASP.NET a while ago and it worked (TM) to get the business going.
Then someone like me gets called into a situation where they have ridiculous hosting costs (Windows-only, typically also MS SQL), nasty performance issues, and struggle to stay productive and find developers. The most reasonable path forward I see in those situations is a gradual migration to .NET Core and something like PostgreSQL.
And that's a major investment. Microsoft couldn't have made .NET Framework code harder to port to .NET Core if that had been their explicit goal. I find database migrations with Entity Framework similarly difficult compared to other ORMs. Startups can sometimes afford such investments, but often not.
And that's how you ironically get 2-3 year old startups stuck on a death march old school enterprise code stack. It appears to be more common than I'd like it to be.
Really if someone can make something that allows legacy ASP.NET code to run on .net core, that would be huge for getting older projects migrated. For example, https://github.com/zzzprojects/EntityFramework-Classic EntityFrameworkClassic is a fork of Entity Framework 6 which runs on .net core but still lets you use your existing EF6 code.
ASP.NET is a much different beast though, but I don't see any technical reason that it would not be possible. I keep expecting one to show up. I think the ISAPI integration is the biggest hurdle there; lots of weird behaviors that would have to be addressed.
This is completely self-inflicted. No one should be using obsolete stack, that's it.
.NET (back then Core) has been going on for 9 years. Surely there was time to finally let .NET Framework choices die.
(also a common theme on HN, to complain about problems that took place ages ago and imply they are still relevant)
Java has an almost unbroken history of hassle-free version updates, all the way back to Java 1.0. (Okay, okay, I know you have a specific anecdote of a broken version update. I said “almost”.)
The one major exception was from Java 8 to Java 9. There’s some good reasons why Java 8 to Java 9 wasn’t a smooth upgrade for all. But that’s a story for another day.
For slow-moving enterprise IT departments, that would involve a major “update Java” project. Which involves budgets and people and not doing other things in the meantime.
Hence why Java 8 is still so prevalent in enterprise world.
In a galaxy far far away so called "J2EE application servers" used to be the reason JDK upgrades were not allowed. And that would probably be a real major update Java project.
When I joined my current team (in a big honkin' corporation with a history of layoffs and outsourcing) I inherited a dozen microservices, all on JDK8 and a couple written in Scala. So among the first things I did was an upgrade to JDK17 of every single repository. And it was mostly uneventful. More or less use a different Docker base image and bump up the Spring Boot version from 1.x to 3.4. Not running the latest LTS release is professional negligence in my book.
I don't even remember Java 8 to 9 (our platform vendor updates his product and after that we have to update ours in a fairly short timeframe, so it must not have been too painful), but I think there is a breaking change in every recent release, most recently we had to rename javax.mail to jakarta.mail and some other stuff like that when upgrading to Java 21. I don't mind but would not describe that as hassle free.
At my workplace, we treat .NET 4.x as an enterprise runtime considering its widespread availability and good maintenance. While we design and compile all the modules with first-class support of new .NET versions, all of them are able to run on .NET 4.x as well. To make that possible, we use a handful amount of polyfills. Fortunately, it all works transparently without causing any troubles.
>It's kind of ironic that even today, the default .NET version baked into fresh Windows installs is 4.6 (or nearby), not the shiny new .NET 8/9.
This is because the distribution model changed ? You would probably publish self-contained .NET app these days ? Not sure - have not built a desktop app in .NET in a decade :)
Yes, presumably because otherwise multiplatform becomes a lot more complex
I think there is an increasing number of Enterprise planning to move direct from JDK 8 to the latest LTS JDK 21. You get insane amount of improvement just from the JVM alone.
It is sad you dont often hear about any of these on HN. C#/ .Net, Java / JDK, PHP, MySQL, MSSQL, Oracle, or anything older, boring technology that is getting steady improvement, production usage, boring and never getting the upvote to get on main page for discussions. Everyone is chasing new hype and new JS front end.
Do not get fooled, HN tends to artificially distort our perception of reality by manually ranking and de-ranking topics according to political and monetary agendas of the day.
A very good example of that malignant practice is this very topic which was manually de-ranked.
Those narratives are pushed by the resource owners whose wellbeing depends on disruption and hype. But stability is an enemy of disruption, and delivered functionality is the enemy of hype. So they have no choice but to de-rank the topics like that, otherwise they lose power because everybody starts to see what is hidden behind the mask.
This is also why reports from StackOverflow on language usage should not be considered to represent the entire software development market, more so whats popular, new and open source.
Not long after JDK 8 Oracle made some changes to reflection that broke a lot of code, although often you can unbreak it with the right command line arguments.
> - Industry inertia — teams hesitate to rewrite working systems without a compelling business reason.
Isn't this how it should be?
Staffing and maintenance are the business concerns for staying on old tech stacks. .NET developers should absolutely be taking them to the bank if forced to work on .NET Framework without being able to migrate it.
I've worked for multiple shops that basically just moved to Java 8 and then bolted an anchor to the nearest pylon. A few made one move to JDK 11 for the "LTS" experience. I can understand their reluctance to move on as the move from <8 to 8 brought a lot of pain. Those old apps had a lot of cruft. Your modern Spring Boot app shouldn't be as tough though. (ByteBuddy maybe an issue). Even the folks that have moved on, aren't really using any of the new functionality. I realize every shop is different, this is just my experience.
I work for a 40 year old private enterprise with a large Java 8 micro-service architecture. My current project is to facilitate the migration to Java 21.
As you point out, there needs to be a compelling business reason. In our case, we are migrating to K8s as well, which is easier to make the business case for.
Security helps make the case as well. Any enterprise using Java 8 and Spring Boot is riddled with CVEs.
Spring Boot 3 requiring Java 17 is what allowed the migration in two companies I’ve been, it’s much easier to sell it as security issue than tech debt.
I guess those are runtimes just predating a fairly large breaking change (actually I know they are for C#, and I have a vague idea of what broke from Java 8 too).
I think that updating from old version is prime AI work. It's not hard, usually. It's just a lot of boring, soul-sapping work, enough that if you set the famous 10x engineer to do it, they wouldn't be a 10x engineer by the end.
Then again, maybe a super-engineer would do something wild like the Minecraft 1.8 modding community did... despite being a pile of code injection hacks into a famously messy codebase, chock full of reflection and classloader shenanigans, they actually found a way to run it on a newer version of Java than the official, latest version of Minecraft can run on.
I know the .NET story much better than Java. .NET Framework support is tied to the OS support for one thing, so as long as Windows is supported, so is the corollary.NET version.
One of the values of .NET Core is that it doesn't need to be installed at all in the OS.
We are migrating away from. NET as a SaaS company. Our Monolith is in Framework and being deconstructed into .NET (current) services. It's a journey, hoping to be done in 2 years. We did successfully migrate the frontend from webforms to React, page by page. I'm sure there are other teams as well. I just interviewed a lead that was on a team doing the same thing on a Java 8 platform with a monolith.
Having just done that on a massive monolith (10y+ codebase continuously developed) I would recommend biting the bullet and doing upgrading all of your projects at once to either .NET Standard or .NET 9 where applicable. Pause development of new features or just do minimal changes on the main branch. We had a ton of footguns (EF6 -> EF Core, WPF, WCF, file serialization, multiple web services) and we were able to complete the migration in 6 months.
> so as long as Windows is supported, so is the corollary.NET version.
With Windows 11, Microsoft stepped away from their normal long-term support lifecycle. Now, you get two years or so of guaranteed support per Windows 11 release, instead of the 5+5 years even Windows 10 received.
Unless you're targeting Windows server or LTSC, depending on the Windows library may not be such a great long-term solution anymore.
The OS support isn't quite as ironclad as that. Windows Server 2019 was the last version where .NET Framework 3.5 will be supported for the lifetime of the OS; while later versions still include 3.5 as an optional feature, it's only going to be supported until January 2029 (when 2019 goes out of support), even if the OS is still in support.
We know .NET Framework 4.x will still have to be supported through October 2034 to meet similar support obligations for Windows Server 2025; but Microsoft could easily let that be the end date for 4.x if they wanted, even if Windows as a whole is still supported.
In the case of .net , I think its due to support of windows OS like 7 , In my part of the world users refuse to update their OS. Software providers need to keep on supporting Obsolete OS's. Thus Runtime support exists till date.
Upgrading JDK 8 is a pain. Many JDK libraries have been moved to external dependencies (which is fine) with new class paths (which breaks existing code). Source code can be fixed with find/replace, but reflection stuff needs to be updated manually.
JDK9 also introduced a good modularization system, which broke many Java reflection hacks. JDK17 introduced even more boundaries which JDK21 enforced.
Companies with the foresight to upgrade before the end is near have been working on fixing these issues for a while now, but with Red Hat still supporting JDK8 for another decade or so, I don't think we'll be rid of these old runtimes any day soon. Furthermore, Oracle only distributes JVM8 to consumers. If you're building desktop applications, targeting JDK8 is a lot easier than targeting anything newer, unless you precompile your application or ship your own JDK.
Java devs can use any number of OpenJDK forks with support. Companies stuck in their ways will not update their toolchains until they break, and even then they will try to find workarounds before they implement fixes.
I don't know about .NET 5+, but without WinForms, new .NET just isn't a replacement. MAUI is nice and all, but it's not as simple and easy to use as WinForms, and there's no direct translation between the two.
Futhermore, the difference between .NET 4 and .NET 5/Core is that .NET 4 ships with Windows and is guaranteed to be available. .NET 5/Core will need to have its runtime be installed.
I think both Oracle and Microsoft are considering anything newer than Java 8/.NET 4 to be "stuff for large, packaged applications, web servers, and enterprise" and the old software part of their legacy API for consumers. I don't know of any Java application that requires a newer version of Java than Java 8 (that isn't itself an SDK for developing Java applications).
All of that said: upgrading Java is worth it, just for performance reasons alone. Java may not have the latest tech and it still lacks basic modern language features such as nullable types, but JVM is still an outstanding piece of tech.
Re: .NET WinForms -- they open sourced it a few years back.
https://github.com/dotnet/winforms
They even went so far as to bring back the forms designer to Visual Studio.
https://devblogs.microsoft.com/dotnet/windows-forms-designer...
Obviously it's still a pretty sizable migration to go from .NET Framework to .NET, but at least the UI framework is available again.
Yes. We have several solutions that include WinForms projects. Migrating those from Framework 4.8 to .Net 8 was as simple as changing "net48" to "net8.0-windows" in the csproj file.
> It's kind of ironic that even today, the default .NET version baked into fresh Windows installs is 4.6 (or nearby), not the shiny new .NET 8/9. Meanwhile, Oracle still offers JDK 8 — albeit behind a paid support wall — much like Microsoft continues to patch .NET 4.x via Windows Update.
You answered your own question. .NET can never ship with Windows, because it then _needs_ to be supported forever. Imagine Microsoft needing to not only support .NET Framework 4.x, but also support .NET Core 3, .NET 6, .NET 8 etc.
.NET Core's migration story was a disaster; Microsoft's official guide basically recommended that you create a new project and copy files over one by one and hoped for the best. Many people didn't bother.
Java 9 was also a mess; inching slightly closer to Scala and Kotlin (but not enough to make it worth going back to Java-the-language if you had already switched to one of those), while breaking a lot of existing code (a cardinal sin for a platform whose stability was its primary claim to fame). Many people didn't bother.
>And are there any good examples where teams actually migrated away from 4.x or 8.x successfully
Sure, at my former workplace they migrated one of the products (a document processing platform) from .NET 4.5 to .NET 8.
It's quite a lot of work to do something like that and most companies who have old products on .NET 4 don't care to update them because they still work. Many are still adding new features to old .NET 4 codebases.
Many will only upgrade if Microsoft deprecates .NET 4 and stops providing updates.
Migration from Java 8 is very easy, I don't really know why they keep using old versions. Probably lack of qualification. Or project is just dead with pinned ancient dependencies of terrible libraries which rely on JVM internals. I'm using Java 8 with one project, because that project must run on Windows Vista and later javas don't run on it. As soon as Windows Vista would become irrelevant, I'll drop the support in one day.
The problem with Java migrations is sometimes people (ab)use the behavior of a specific library in that specific version, and when you change the runtime, everything comes crashing down (visibly or invisibly).
I have seen quite a few Java applications which fails at unrelated points, and every time I have been told that the thing only runs with "jre-old.very.specific.version-and.point.release". Otherwise you're out of luck.
> As soon as Windows Vista would become irrelevant
Wasn't that like 10 years ago?
I wish.
Java 8 is...the 8th version of the Java Framework. It's supported until 2030. But frankly you can just move to more recent versions. The main reason not to is that once you do you're stuck moving more often, because the later versions are only supported until 2031. So you're not gaining much.
.Net Framework is the version of .Net that ships with Windows, and it's supported as long as Windows is. For Windows 11, presumably until at least 2035. It's entirely possible that Windows 12 will also ship with .Net Framework, as otherwise they'll have to convert a ton of MS apps to .Net, at which point you're safe until 2045. .Net (previously .Net Core) is the open-source cross-platform framework forked from .Net Framework. And once you move to that you're going to have to move to the latest version every 3 years, because that's how long they're going to support an LTS version for.
So if you have a bunch of apps and don't care about the new functionality, and just want to make sure you have security patches then you'll stick to the version that you've got, and you'll only move once they tell you you have to.
Windows 11 still includes the Visual Basic 6 runtime, which predates .NET by quite a bit (from 1998!). There are many working systems that still rely on this.
More about this here: https://learn.microsoft.com/en-us/previous-versions/visualst...
Can we all accept the notion of feature-complete software?
It is easy if we take away employment incentives, promotion oriented work.
In the case of Java 8, at least, I know that later versions significantly changed the kind of metaprogramming, standard library, and even project structure you could use. So I think there's more friction to move off of it than you might first imagine.
I suspect a non-small part of the story is accounting rules. If you're in a place where such an upgrade would be paid for out of operational expenditure, there's always going to be a reason not to do it.
Enterprises are stuck on Java 8, so that's what everyone is familiar with. This is why I use Kotlin; if you don't know the new stuff anyway, you may as well just use a better language.
I don't see MS dropping support for .NET Framework 4.X. If they do they will probably announce it 10 years upfront, like they did with Silverlight.
SharePoint is built upon the .NET Framework, as is at least part of Exchange. .NET Framework has a very long life ahead of it.
For a very long time, Scala was stuck at JDK 8 which hindered anyone that had a mix of Java and Scala code from upgrading.
For once, the answer to the question in the title is "Yes".
Note how HN admins artificially de-ranked this topic. Come on guys, stop being puppets driven by venture capital, that's dishonest and boring.