SharePoint is built upon the .NET Framework, as is at least part of Exchange. .NET Framework has a very long life ahead of it.

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.

>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 :)

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 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

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.

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.

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.

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.

For once, the answer to the question in the title is "Yes".

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.

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.

.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.

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.

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.

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.

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.

Can we all accept the notion of feature-complete software?

It is easy if we take away employment incentives, promotion oriented work.

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.

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?

> - Industry inertia — teams hesitate to rewrite working systems without a compelling business reason.

Isn't this how it should be?

(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.

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 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.

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.

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.

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.

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.

Note how HN admins artificially de-ranked this topic. Come on guys, stop being puppets driven by venture capital, that's dishonest and boring.

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.

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...

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.

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.

> 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.

>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.