The irony here is that on the job interviews they keep asking questions about the the latest versions of java and the difference between each version and the other but when you get the job you find that they are stuck in the old versions like a Java 8 or even Java 6
So many many enterprises are stuck under Java 11, because of the conversion issues. Having recently done some enterprise conversions from Java 8 to Java 21, Spring Boot 2 to Spring Boot 3. OMG, it was incredibly challenging. It was not just the libraries(Jakarta concersions) . It was XML to JSON issues(Both in request and response) becasue users expect the old application to respond exactly like the old one A single conversion should not take 6 months
Most places that use Java have no incentive to upgrade. Developers don't care, for infra it is too much work, and for business it is an investment with uncertain return. With extended support for Java 8 available through 2030, I think almost nobody will bother until there is a hard end date for support. For greenfield people will probably choose something relatively modern like 17, but I doubt many mature enterprise products will go through upgrade.
For Spring Boot users, it makes sense to upgrade, and we do so regularly. The security fixes alone that come with newer versions, which, on the other hand, require a newer Java version, make it necessary.
@@nico.strecker True, and great that your team is on top of this, but your situation is not the most common according to the results of the author's survey. I'm just offering a hypothesis as to why almost half of the survey respondents consider Java 11 "new". In large organizations there is often a significant legacy footprint where newer Java versions are either completely unavailable or expensive and difficult to implement due to skill, organizational and technical reasons.
Most developers work in outdated knowledge economies. And have never looked to the new stuff. They pretent to be agile, but if you cannot absorb new versions, you are agile in name only.
Last year my team did the full switch from 8 to 17. For security/reliability reasons, I know we can't adopt the latest and greatest right away, but hopefully we can continue staying up to date on my team by moving to 21 at some point. For my personal projects, I stick to using the latest LTEs since they are in production.
@@Java.Brains One thing I do find amusing is how a lot of members of my team tend to neglect changing their code habits in light of newer versions' features, but I also believe in ever evolving my code habits as the technology evolves.
Large organizations are NOT slow- they are smart and spend money wisely. Haven't you heard : "Why Fix Something That Ain't Broken ?" So long as the version of Java is running the apps on Prod satisfactorily in all aspects - performance, security, scalability, why worry. Spend your dime on business features, rather play a catch up with version upgrade. Large organizations do a "wait and watch" policy for how latest versions of technology fare in the market and wait until all the rough edges are smoothened out and it is stable. Only then will they decide to move the applications to the newer versions strategically Just coz, you are on Java 23 doesn't mean your application is the holy grail.
As a java engineer with 10+ years of experience, I've laughed in my whole voice. That's soooo true. We're using java 11 and java 9. Only for very few projects it is java 17.
2:40 I saw the poll but didn't answer it because it was ambiguous: the two questions seem to contradict each other and the second one is not intelligibile "are you would consider you are unfamiliar with". After watching the video is clear what was the question and my answer is "the latest LTS: 21".
My company was about 3 years ago still on 8, which was short after i started there. We switch to 11 and a year later to 17. As a medium sized company there was just a lack of manpower to handle all the changes that came with updating the Java version. There were multiple critical libraries that didn't had a newer version and we had to find new ones. The switch from 8 to 11 was the biggest problem, 11 to 17 went pretty easy in comparison and i hope we can be swifter in future to adopt new LTS versions.
@@nitinmuley7030 kind of monolith kind of not. The system has 3 applications each runs in own docker container. Spring boot + angular applications. It was quite easy to do the migration. Did not use any migration tools. Had some issues with some maven dependencies but nothing major.
it's not that we are slow to move, it's just that it's expensive to move. In my company we have around 80 micro services running on spring boot 2, java 11. I've been wanting to migrate since the beginning of the year but we got so many projects and crazy deadlines that it's troublesome to find time to migrate, test and deploy 80-ish services.
I am working in a small company. We migrated from Java 8 to Java 17 8th months after it was released. There were quite a few headaches along the way. We migrated to Java 21 2 months after it was released. The update was very smooth, mainly testing the effect of ZGC. I can imagine that upgrading from Java 8 can be a much larger problem for a bigger shop and they will postpone for as long as they can.
There are really a lot of newer, and nicer features in recent editions of the language, that our developers are still learning and incorporating into the codebase. We upgraded mostly for security reasons, but everyone is happy we did.
The advantage Java had pre-Java 9 was backwards compatibility with newer versions. If I had an app written in Java 6, I could very easily move to Java 7 without worrying about anything breaking. Then along came the geniuses who brought modules to Java 9 and insisted that we all needed modules. Many years later, I've never had a reason to write a single module. Most devs in the Java community don't use modules. Java 9 effectively ruined backwards compatibility for Java devs. Companies don't like upgrading language versions for their production apps, because it's just too risky. Oracle understood this. Or at least, I thought they did. Maybe Java Brains and the rest of well respected folks in the community should have worked harder to convince the powers that be not to ruin the ecosystem in this way. Java 9 introduced a chaos that Java as a language will never recover from.
Most Java version upgrades happen simply for security compliance. Existing systems don't necessarily start using the new features offered in newer versions. So you still have the same old code base running on a newer version. That brings up the question of real adoption vs version upgrades. Is it considered a new version adoption if I don't use any of the new features?
The two parts of the question were pretty contradictory though. The "oldest version I would consider myself unfamiliar with, or have little experience working on" is Java 1.0. I've never worked with it, and I'm pretty sure I would be unfamiliar with the best practices without the newer features.
A few months ago I saw a guy struggling to run Java 6 in Docker (he was trying to create an image with jdk 6). Some people don't want to leave the legacy code.
we moved to JDK 17 only like a year or two ago , still most of the other apps on JDK 7 and JDK 8 in other teams , obv the new green field projects start with jdk17 or the latest LTS but the older projects as you said take their sweet time to migrate
Exactly what I excepted. My work is stuck in Java 11 :( I remember my first project. Started working in Java 17 where spring had all the Jakarta stuff. When I deployed...everything broke because it was stuck at Java 11 and javax. Definitely made that project take longer than it had too lol. Though when I'm doing non-work coding, I typically go with 17
Upgrades are not always straight forward - you upgrade Java, so now you have to upgrade Spring and Spring Boot. Spring Security is not compatible, libraries have deleted deprecated stuff that you call. So yeah, Java is religious about backwards compatibility, but it can still be a challenge
2:52 What the result of the poll shows is that half of the people "consider Java 11 as new version", that does not necessarily mean they are using a lower version.
People are not use properly java 8 . Mostly can't write code using lamba and stream . One other reason might be people mostly walk on the defect fixing L1 L2 support, mostly people don't get a chance to work in development . even people not able to properly use Java 5 generics and concurrency packages. Because of mostly into the defect fixing it is very difficult to debug the Lambda so people have very loose grip
As Tomcat and Weblogic and other platforms age into CVE etc, they end up forcing people to become minimally compliant. I've been fortunate enough to be on at least one project where I was able to ensure that the way we built it would make it easy to upgrade :D Some people just build things poorly and document it even worse-- and then they retire. Some people do it on purpose for job security. ... starting to sound like a people problem now that I think about it.
Oh this is VERY much a people problem. There is this implicit need for justifying ROI for any such a move and most people don't care unless there's some issue.
I green light Java version upgrade 6 months before the LTS version’s end of life. We are Java 8 and I have 2 more years. I see no reason to upgrade to 11 yet. My team wants to abandon Java in favor of Rust or Go anyway and we are exploring other options.
I'm working on Java 21 for past 1 year and switching to Java 23 next year. I conduct interviews on a weekly basis and it is such a sad state that people are not working on even Java 17/18. They have 0 self-motivation to explore anything beyond Java 7 or 8.
This is totally to be expected people do not develop new applications/systems in Java anymore (unless they are forced to), Java is seen as a purely legacy language now by the majority of developers these days. Most younger developers would do anything they can to avoid using Java, it is seen as a backwards step for them to have to use Java 💯
The irony here is that on the job interviews they keep asking questions about the the latest versions of java and the difference between each version and the other but when you get the job you find that they are stuck in the old versions like a Java 8 or even Java 6
So many many enterprises are stuck under Java 11, because of the conversion issues. Having recently done some enterprise conversions from Java 8 to Java 21, Spring Boot 2 to Spring Boot 3. OMG, it was incredibly challenging. It was not just the libraries(Jakarta concersions) . It was XML to JSON issues(Both in request and response) becasue users expect the old application to respond exactly like the old one
A single conversion should not take 6 months
Most places that use Java have no incentive to upgrade. Developers don't care, for infra it is too much work, and for business it is an investment with uncertain return. With extended support for Java 8 available through 2030, I think almost nobody will bother until there is a hard end date for support. For greenfield people will probably choose something relatively modern like 17, but I doubt many mature enterprise products will go through upgrade.
For Spring Boot users, it makes sense to upgrade, and we do so regularly. The security fixes alone that come with newer versions, which, on the other hand, require a newer Java version, make it necessary.
@@nico.strecker True, and great that your team is on top of this, but your situation is not the most common according to the results of the author's survey. I'm just offering a hypothesis as to why almost half of the survey respondents consider Java 11 "new". In large organizations there is often a significant legacy footprint where newer Java versions are either completely unavailable or expensive and difficult to implement due to skill, organizational and technical reasons.
Most developers work in outdated knowledge economies. And have never looked to the new stuff. They pretent to be agile, but if you cannot absorb new versions, you are agile in name only.
Last year my team did the full switch from 8 to 17. For security/reliability reasons, I know we can't adopt the latest and greatest right away, but hopefully we can continue staying up to date on my team by moving to 21 at some point. For my personal projects, I stick to using the latest LTEs since they are in production.
That makes sense. You can switch to a newer version without having to use newer features
@@Java.Brains One thing I do find amusing is how a lot of members of my team tend to neglect changing their code habits in light of newer versions' features, but I also believe in ever evolving my code habits as the technology evolves.
Large organizations are NOT slow- they are smart and spend money wisely. Haven't you heard : "Why Fix Something That Ain't Broken ?" So long as the version of Java is running the apps on Prod satisfactorily in all aspects - performance, security, scalability, why worry. Spend your dime on business features, rather play a catch up with version upgrade. Large organizations do a "wait and watch" policy for how latest versions of technology fare in the market and wait until all the rough edges are smoothened out and it is stable. Only then will they decide to move the applications to the newer versions strategically
Just coz, you are on Java 23 doesn't mean your application is the holy grail.
As a java engineer with 10+ years of experience, I've laughed in my whole voice. That's soooo true. We're using java 11 and java 9. Only for very few projects it is java 17.
2:40 I saw the poll but didn't answer it because it was ambiguous: the two questions seem to contradict each other and the second one is not intelligibile "are you would consider you are unfamiliar with". After watching the video is clear what was the question and my answer is "the latest LTS: 21".
My company was about 3 years ago still on 8, which was short after i started there. We switch to 11 and a year later to 17. As a medium sized company there was just a lack of manpower to handle all the changes that came with updating the Java version. There were multiple critical libraries that didn't had a newer version and we had to find new ones.
The switch from 8 to 11 was the biggest problem, 11 to 17 went pretty easy in comparison and i hope we can be swifter in future to adopt new LTS versions.
Hello Koushik,
First of all, thank you for sharing all the useful content.
Is it possible for you to prepare and roll out the playlist for Java 23?
Just migrated one of my customer project from Java8 to Java17.
Is that monolith? And any migration tool/library you used ? Currently am working on one migration from 8 to 17 version
@@nitinmuley7030 kind of monolith kind of not. The system has 3 applications each runs in own docker container. Spring boot + angular applications. It was quite easy to do the migration. Did not use any migration tools. Had some issues with some maven dependencies but nothing major.
@@muurimc Cool .. thanks
it's not that we are slow to move, it's just that it's expensive to move. In my company we have around 80 micro services running on spring boot 2, java 11. I've been wanting to migrate since the beginning of the year but we got so many projects and crazy deadlines that it's troublesome to find time to migrate, test and deploy 80-ish services.
I am working in a small company. We migrated from Java 8 to Java 17 8th months after it was released. There were quite a few headaches along the way. We migrated to Java 21 2 months after it was released. The update was very smooth, mainly testing the effect of ZGC.
I can imagine that upgrading from Java 8 can be a much larger problem for a bigger shop and they will postpone for as long as they can.
Well said! Yes That's the reason I use 23 in my home projects
The people who have even upgraded, have done so for sake of NFP or to be just compliant, not as actual upgrade for functionality.
At this state? Whatever the reason, we should happily take it! :)
There are really a lot of newer, and nicer features in recent editions of the language, that our developers are still learning and incorporating into the codebase. We upgraded mostly for security reasons, but everyone is happy we did.
The advantage Java had pre-Java 9 was backwards compatibility with newer versions. If I had an app written in Java 6, I could very easily move to Java 7 without worrying about anything breaking.
Then along came the geniuses who brought modules to Java 9 and insisted that we all needed modules. Many years later, I've never had a reason to write a single module. Most devs in the Java community don't use modules.
Java 9 effectively ruined backwards compatibility for Java devs. Companies don't like upgrading language versions for their production apps, because it's just too risky. Oracle understood this. Or at least, I thought they did.
Maybe Java Brains and the rest of well respected folks in the community should have worked harder to convince the powers that be not to ruin the ecosystem in this way.
Java 9 introduced a chaos that Java as a language will never recover from.
Java 9*, but spot on
the simple reason is fear.
and because, lot of code does not have proper and thorough unit/integration tests..
This has to be related to "If it works, don't break it" 🤔
Most Java version upgrades happen simply for security compliance.
Existing systems don't necessarily start using the new features offered in newer versions.
So you still have the same old code base running on a newer version.
That brings up the question of real adoption vs version upgrades.
Is it considered a new version adoption if I don't use any of the new features?
The two parts of the question were pretty contradictory though. The "oldest version I would consider myself unfamiliar with, or have little experience working on" is Java 1.0. I've never worked with it, and I'm pretty sure I would be unfamiliar with the best practices without the newer features.
My ex company was on Java 8 , the amount of issues we had with upgrading to different libraries.
A few months ago I saw a guy struggling to run Java 6 in Docker (he was trying to create an image with jdk 6). Some people don't want to leave the legacy code.
we moved to JDK 17 only like a year or two ago , still most of the other apps on JDK 7 and JDK 8 in other teams , obv the new green field projects start with jdk17 or the latest LTS but the older projects as you said take their sweet time to migrate
Exactly what I excepted. My work is stuck in Java 11 :(
I remember my first project. Started working in Java 17 where spring had all the Jakarta stuff. When I deployed...everything broke because it was stuck at Java 11 and javax. Definitely made that project take longer than it had too lol.
Though when I'm doing non-work coding, I typically go with 17
Upgrades are not always straight forward - you upgrade Java, so now you have to upgrade Spring and Spring Boot. Spring Security is not compatible, libraries have deleted deprecated stuff that you call. So yeah, Java is religious about backwards compatibility, but it can still be a challenge
2:52 What the result of the poll shows is that half of the people "consider Java 11 as new version", that does not necessarily mean they are using a lower version.
I saw the poll and I didn't vote because I didn't understand the question, I still don't
I use 17 at work now and I've worked with 8-11 for 2 years
People are not use properly java 8 . Mostly can't write code using lamba and stream . One other reason might be people mostly walk on the defect fixing L1 L2 support, mostly people don't get a chance to work in development . even people not able to properly use Java 5 generics and concurrency packages. Because of mostly into the defect fixing it is very difficult to debug the Lambda so people have very loose grip
There is 23 now ? Last I remember was 17th used to be pretty stable version.
As Tomcat and Weblogic and other platforms age into CVE etc, they end up forcing people to become minimally compliant. I've been fortunate enough to be on at least one project where I was able to ensure that the way we built it would make it easy to upgrade :D Some people just build things poorly and document it even worse-- and then they retire. Some people do it on purpose for job security.
... starting to sound like a people problem now that I think about it.
Oh this is VERY much a people problem. There is this implicit need for justifying ROI for any such a move and most people don't care unless there's some issue.
Java 17 and 21 here!
I am in Java 7 😂
😂😂😂😂😂
Amen
Such a shame
I want to know the diiference in terms of migrationbetween java8 and java 21 . Could any suggest some resoures.
Finally in my project we move from 11 to java 17; and spring boot to version 3•x
Catching up with 17 here
We are forced to upgrade from java 8 to java 17 to fix security issues like white source, fortify
11 to 17 was a nightmare with spring, tomcat and javax issues
Waiting for a new course on JB website.
Coming up VERY soon. It's about Networking fundamentals for System design interviews
java 8 is used most widely
I green light Java version upgrade 6 months before the LTS version’s end of life. We are Java 8 and I have 2 more years. I see no reason to upgrade to 11 yet. My team wants to abandon Java in favor of Rust or Go anyway and we are exploring other options.
In reality I am part of 49% poll. Sad to say ... :(
in last 4 yrs..i am first time getting job calls where they asking java 17 now.
Using 8 in company and 21 for myself.
I'm working on Java 21 for past 1 year and switching to Java 23 next year. I conduct interviews on a weekly basis and it is such a sad state that people are not working on even Java 17/18. They have 0 self-motivation to explore anything beyond Java 7 or 8.
Poll question starts at 1:26
Unpopular question amongst java developers, why aren't we moving to Kotlin already?
i can still write java 7 code in jdk 23
Staying with Java 8. There is nothing in new versions that warrants moving to newer versions.
It's not about fast all the time. JVM overhead is too much.
Next video series: Java7 till Java23 changes.
Teach us Java 23. In fact help us/me in transition from 8->11->17->23
funny but sad, still writing for(int i=0;i
Same here .. using 17 now. Struggled Migrating from 8 to 11 to exclude duplicate guava dependencies from two different dependencies 5 years ago. 😵💫
Using java 11 in prod
I am in java 1.5
Java dependency hell
... because upgrading Java is and has always been a royal pain in the buttocks ... just the worst language in all creation for dependency problems
Enough with the clickbait
This is totally to be expected people do not develop new applications/systems in Java anymore (unless they are forced to), Java is seen as a purely legacy language now by the majority of developers these days. Most younger developers would do anything they can to avoid using Java, it is seen as a backwards step for them to have to use Java 💯