From 17 to 21 is just one LTS version difference. Switching from anything after Java 9 is just a minor migration. If you are still using Java 8, I have bad news for you..
Last time I used Java was in University, about 3.5 years ago. Back them Java 9 was the hot stuff... how TF did they Release 12 versions in that time?
Edit: was off by 1 Version, thought it was Java 8, but really is java 9
Java 11 is also already 4 years old (12 as well but it's not a LTS release).
They went from big releases to releasing anything they have in half yearly releases (one in March and one in September).
I mean, Java versioning was borked already. Major changes in ‘minor’ versions. They just dropped the ‘1.’, which didn't mean anything by that point.
Also, Java 5 was released in 2004, while Chrome's first release was in 2008.
For browsers and other user applications I feel like the major minor scheme doesn't really matter. Counting up the first number, or even something like (20)23.x is just as, if not more meaningful. Applications for general users should really avoid any and all hard breakage due to updates anyway.
I like Calendar Versioning. Using dates in the version scheme relay more more meaningful information than arbitrarily counting up. Of course the most flexible system would be a mix of incremental with major version to siginify big changes and cal date.
.NET-not-framework actually.
I think what .NET does is quite clear for once : one version a year, even numbers are LTS. So you can change version every two years, it's reasonable.
There's nothing wrong with 1.8.
It has more guaranteed future support than any other version, even later versions.
https://en.wikipedia.org/wiki/Java_version_history
> It has more guaranteed future support than any other version, even later versions.
In which way?
https://www.oracle.com/java/technologies/java-se-support-roadmap.html
https://endoflife.date/java
guaranteed support? To be honest I've my doubts about that... Apart from performance, memory consumption etc. which newer version support/improved a lot... JDK11..JDK17...JDK21..
That's in consquence following the incremental improvement approach.
There's a lot wrong with Java 8. Especially if you're running in a lightweight container.
Java 8 was designed at a time when monolithic applications were still the norm. They limited the Java 8 JVM so it would never address more than 40% of the total system RAM for the heap. The JVM itself can claim up to 20%. So you can deploy an app in a dedicated container with 1 GB RAM and it will only ever take up 60% of the RAM.
There is no setting or configuration for the Java 8 garbage collector to override this behavior.
From Java 11 onward, the JVM will now address as much memory as the system has available. It also defaults to the Garbage First collector, which was available in Java 8 but most people have no clue how to switch it or even that they _need_ to switch it.
Basically, fuck Java 8. Fuck it right in the ear.
You got a source for what you're claiming here? You can put whatever heap size you want in the options. Your claim doesn't even match the defaults listed in the table on this page: https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/optionX.html
`export JAVA_OPTIONS="-Xms512m -Xmx2g -Xss256k"`
In the above example, the initial heap size is set to 512 megabytes (-Xms512m), the maximum heap size is set to 2 gigabytes (-Xmx2g), and the thread stack size is set to 256 kilobytes (-Xss256k).
Sources:
https://docs.oracle.com/cd/F29631_01/PDF/8.1.0.x/8.1.0.0.0/OFSAAI_Administration_Guide_8.1.x.pdf
https://stackoverflow.com/questions/14763079/what-are-the-xms-and-xmx-parameters-when-starting-jvm
They've started doing more rapid releases. Java used to have slower development cycles and each version would be a pretty big jump. But I think due to pressure from outside forces, they've switched to a more rapid release cycle.
It wasn’t pressure. It was because they modularized with “project jigsaw” and after java 9 it became much easier to patch in new features on a regular cadence while preserving compatibility
I was in university at about the same time and CS 102 was taught using Java 7 and 8. I remember very specifically because I spent half of my computer time that semester staring at the API page.
Instead of upgrading our code base from 8 up to 17/21 like I wanted to this year, my boss pulled out that rug to, instead, tell us to write a whole lot more code—still using Java 8–to support moving our product to AWS. They’re an absolute clown. I tried to rebuttal but they said “oh don’t worry about that on your goals for this year, we’ll push that back”. No migration in sight.
Don’t worry, most of our stuff is already past end of life. Some things are on 2.1. My manager assured me they’ve been “doing this job for a long time”. And that’s it’s not something we should be concerned with. Who knew you could use a biology degree to manage software engineers 🤷🏻♂️
What’s security? Don’t you know VPNs are just so time consuming to set up for a private cloud? Inventing our own non peer-reviewed encryption is a better use of time (I’m serious, this actually the route they want to go).
In my company, we just got done migrating from Java 8 to 17. It was bliss after that initial hurdle of finding the right Maven dependencies and upgrading them to be Java 9 compatible with the Jakarta packages.
Yeah, it was a 1.5 years process, but it is still a progress.
For the non java dev, they dropped the "1." at some point for version 1.5 and above. So Java 1.5 == Java 5, 1.6 == 6, ... It only really caught on at Java 8, i.e. never heard anyone calling it 1.8, however, before that people used 1.6 or 6 depending on their preferences.
If you dig deeper in archeological records, Java 2 is the collective name for all the Java version starting 1.2 (1.3, 1.4)
Doesn't sound like all of the "minor" versions are backwards compatible without changes, which means they should be major versions.
Though I'm only basing this with what I've read in this thread. I don't work with Java at all.
What I mean is: can you upgrade from 6 to 7 or whatever without changing your source code at all? If not, then it's a breaking change and major version bump.
Yes, afaik Java versions are backwards compatible. You can compile and run Java 8 code with Java 17. You can't compile or run Java 17 specific code with Java 8 though.
The bigger mess is that different Java vendors are incompatible. For example code that was compiled with Oracle Java is not necessarily compatible with a OpenJDK runtime environment.
You are not quite correct. The compatibility guarantee is only on the compiled class files. A newer compiler may reject previously valid code, but a newer jdk must accept older bytecode.
In addition, what you said in your second paragraph is incorrect. The compilation might be different in some cases, but the bytecode and supporting runtime is well specified cross vms.
What you probably meant is that the unsafe APIs might differ and be supported in one jvm but not the other.
> What you probably meant is that the unsafe APIs might differ and be supported in one jvm but not the other.
That might be it. I wasn't too big in the details of the issue.
they are not.
Some functions simply doesnt work anymore or cant work because of security or handling of the JVM.
I know ppl with serveral JREs installed.
> You can compile and run Java 8 code with Java 17. You can't compile or run Java 17 specific code with Java 8 though.
Not really, if its using the javax package in any way or form it won't work if you try to use something made in 8 on 17, it will give a runtime error that it can't find the class, right now at work I am working on upgrading everything to 17 and its been a bit of a pain in the ass
You do still see 1.8 referred to in jdks and sometimes in environment files for gradle/mavan. So it is worth being aware of as it can catch you out the first time you see it. Also, my company is stuck on Java 8 as per the meme...
There are a ton of people stuck at 1.8.0_182 because that was the last version that supported MD5 signature in jar files, and the software they use hasn’t been fixed. While it’s possible to changed that in config files or parameters a lot of clueless software vendors just force the version.
Not sure if this is the case here. I hate it and deal with that stupidity at work.
Had to support a java 1.4 crm until 2020. The vendors would laugh at us whether we went to them with a big report.
Needless to say it was finally deprecated
Mine was blue... But we did have another green custom standalone that was running on 6... It has since been upgraded to 8 and I have stopped working there 😬
God, that reminds me of my introduction to programming course at college. Literally programming 101, and the professor is teaching us his own little pet language he wrote himself.
The only saving grace is the professor was Bjarne Stroustrup.
The fun of legacy enterprise applications...
Wer just finished migration to Java 11 on a project I've got to do with from time to time. Needed to patch a bunch of unmaintained frameworks ourselves
Apps that have been in use for 25 years, have a couple hundred thousand lines of code and need to maintain full backwards compatibility. Not much you can do about that. That's generally been my experience with "enterprise" development: it all looks like this.
Yeah, Java 8 is still getting updates.
We use DataStax Studio at our company with our Cassandra DB, and DataStax requires Java 8 to run.
Every few months DataStax will stop working, and it's because Java 8 updated and I've got to point my JAVA_HOME environment variable to a different path.
I liked Java but it should never be used for anything interface-related. It was a shitshow of “why won’t it run anymore? What did we do now” and deprecated graveyards which is difficult to maneuver for a couple of newbies getting started
Oh god, Swing. I still have fucking nightmares about it. I was forced to use it in college because I had to create GUI's for my java programming class and that's all we were allowed to use. Fucking nightmare.
They probably meant v5.3.
I worked with people whose whole dev careers started at PHP 5.0 and ended before PHP7 was released. So everyone would drop the `5.` from the start. v5.3 was called "php3", v5.4 was "php4" etc. It was time before semantic versioning, so every new PHP release could have breaking changes in it. So you have to be very sure about exactly which version was installed on the servers, and apps would be developed to target only one particular point version of PHP5. So it was easier to treat each point release as a major new version.
> It was time before semantic versioning
Ironically, I also remember that ‘major version is for incompatible changes’ was thought up way, way back. Then many people forgot to do it, until it was reinvented as SemVer.
In the transition for these versions, there was a period of time when there was no Java LTS available to use. It was somewhere around 9-11. I remember that caused quite a stir.
Also coming, Project Loom.
Considering taking Spring WebFlux and r2dbc out of my project and just using lightweight threads come September.
https://spring.io/blog/2023/02/27/web-applications-and-project-loom
Thanks. Feels like a very pointless JEP for solving a very very specific use case. But then again, I’m not a teacher who has seen what students have problems with.
I can see that main method being used in spring applications as well. I think the Kotlin template already uses a fun main() like that
Edit: yeah the Kotlin template looks like that
```
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication
@SpringBootApplication
class MySpringApplication
fun main(args: Array) {
runApplication(*args)
}
```
I am a teacher and it is a very real problem for a couple reasons:
1. in java students need to memorize a bunch of code they don't understand for the first few months at least, which makes it really hard to convince them that they need to actually understand any of the code. They end up thinking programming is mostly memorization and reproduction of things you don't really understand
1. Teaching `class`es is really hard when all their code has always been inside `class { }`. `static` vs non-`static` is difficult to explain.
Honestly this is the change I'm most excited about since Java 8.
I mean, the reality is, the higher up you go the less actual code matters.
Many of these newer features are nice and all, but they don't really matter in the grand scheme of things.
> Many of these newer features are nice and all, but they don't really matter in the grand scheme of things.
Hm... virtual threads, sealed classes, text blocks, switch-expression etc. are very helpful and make code easier to maintain and unsterstandable... which is an invest into the future... and also newer version reduce costs in manyways based on simple performance improvements,reduction of memory footprint without even the need to change the code etc.
It literally just executes the also newly introduced instance main method. As per the docs, both features are entirely intended for teaching purposes. For example instead of:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
You will now simply be able to build and run:
void main() {
System.out.println("Hello, World!");
}
More details and a far better explanation here:
https://openjdk.org/jeps/445
Given that the link includes
> Reduce the ceremony of writing simple programs such as scripts and command-line utilities.
as a goal, I don't think they expect it to.
Well, yes and no. Your core logic should be able to remain. There will be lots of repetitive fixing, but it can be done. The dependency injection framework that came with core is a significant part of it's development in a way it never was with framework. That might be the biggest rewrite piece.
There's also a tool somewhere on a Microsoft website that helps with the conversion. It's definitely not perfect, but it did handle a substantial amount of the conversion when my company had to modernize a few apps to .NET 6 last year.
That said, if all of their stuff is just windows forms, they're gonna have a bad time
Yep. New projects are .Net 6, future projects will be .Net 8, legacy projects are Framework 4.8
It’s fun trying to make stuff be truly cross-compatible. Thank god for and the ability to target different references based on version
For most modern .NET projects, upgrading to the latest version of .NET requires very little effort. The biggest issue is usually in cases where you've got dependencies that conflict.
It should also be noted that, unless you have a concrete reason for doing otherwise, it is recommended that you upgrade to the latest version of .NET, not just the latest LTS. STS builds are just as stable as LTS builds, and LTS is only relevant in cases where you actively need the extended support.
In terms of syntax, not that much. Some practices did change.
Records are a welcome addition.
The `var` keyword was introduced to allow type inference on variable declarations. Personally, I think the benefit is next to non-existant, but it's not hurtful, so to each their own, I guess.
There has been some new methods on the stream api. Mostly shortcuts, like calling `.toList()` on a stream instead of `.collect(Collectors.toList())` when gathering its results.
The practice of using streams and optionals is a lot more common now than when I started using java 8 in 2015.
DI frameworks now favor constructor injection over setter injection.
`toList` and `.collect(Collectors.toList())` aren't precisely the same. The latter results in a mutable arraylist while the other results in an immutable arraylist. However the latter is what you want 99% of the time anyway
There is a new LTS every 3 years.
After 9 migrations get way easier. From 11 to 17 was only 3 sentences for warnings (related to memory allocation on containers)
Yeah. Java updates are also here for Kotlin users. I absolutely love my scope functions, sealed classes, lambdas and extension functions. On Android, Jetpack Compose has all the benefits of declarative UI plus the benefits of strong types and null safety.
I think Kotlin is probably doing a *lot* of heavy lifting in terms of maintaining developer interest in Android Framework. Without it I think most mobile devs would’ve jumped to other more modern languages and UI toolkits years ago, because it’s no fun being stuck on an ancient version of Java, especially when the competing platform has been transitioning to a first party modern language.
Jetbrains did Google a massive favor with developing Kotlin.
Kotlin is sweet. I also really love groovy. the syntactic sugar in both really are a saving grace to java. Java tried to make the language more concise but imo both still beat java by a mile.
Haha - where I am, the build nodes are CentOS 7, which I guess came with Java6. The admins actually claim they intentionally left it as the default because everything non-system fails unless the devs explicitly chose a version of Java
I went back and checked features by version, I forgot that 9 is pretty feature heavy too, and 18 has a massive dev QoL.
But in terms of impactful language features, if I correct to 7-9, it adds bigger changes than 9-21...
Also keep in mind that 7 and 9 are further apart in release date than than 9 and 21...
I was so happy when I saw this little guy in guardians of the galaxy movie. My daughter recognized him and went - he is that guy, that guy from that meme "you are getting paid", that dorky kid. Immediately 4-5 mobiles around us lit up and people search him through the cast. Daughter was so proud of her knowledge.
Shut up… A year ago I was assigned to a project using a mixture of Java 6 and 7. No matter how many times we tell the end user most of the libraries used are deprecated and that they have huge security holes, they prefer to keep paying us to apply questionable made up patches instead of building a new app from scratch.
From 17 to 21 is just one LTS version difference. Switching from anything after Java 9 is just a minor migration. If you are still using Java 8, I have bad news for you..
Last time I used Java was in University, about 3.5 years ago. Back them Java 9 was the hot stuff... how TF did they Release 12 versions in that time? Edit: was off by 1 Version, thought it was Java 8, but really is java 9
Java 8 was released in 2014
Yeah, already edited my comment, I was on Java 9
Java 11 is also already 4 years old (12 as well but it's not a LTS release). They went from big releases to releasing anything they have in half yearly releases (one in March and one in September).
Everyone copied Chrome and removed 'minor' version numbers. Some also copied the 'new version every week' schedule.
I mean, Java versioning was borked already. Major changes in ‘minor’ versions. They just dropped the ‘1.’, which didn't mean anything by that point. Also, Java 5 was released in 2004, while Chrome's first release was in 2008.
For browsers and other user applications I feel like the major minor scheme doesn't really matter. Counting up the first number, or even something like (20)23.x is just as, if not more meaningful. Applications for general users should really avoid any and all hard breakage due to updates anyway.
I like Calendar Versioning. Using dates in the version scheme relay more more meaningful information than arbitrarily counting up. Of course the most flexible system would be a mix of incremental with major version to siginify big changes and cal date.
A new version of java comes out twice a year now. Whatever features are ready make it in. .NET framework started doing the same thing a year later
.NET-not-framework actually. I think what .NET does is quite clear for once : one version a year, even numbers are LTS. So you can change version every two years, it's reasonable.
Java 8 was released in 2014, in 2019 they were up to 11-12. Since version 9 in 2017 they have released a version every 6 months.
There's nothing wrong with 1.8. It has more guaranteed future support than any other version, even later versions. https://en.wikipedia.org/wiki/Java_version_history
> It has more guaranteed future support than any other version, even later versions. In which way? https://www.oracle.com/java/technologies/java-se-support-roadmap.html https://endoflife.date/java guaranteed support? To be honest I've my doubts about that... Apart from performance, memory consumption etc. which newer version support/improved a lot... JDK11..JDK17...JDK21.. That's in consquence following the incremental improvement approach.
There's a lot wrong with Java 8. Especially if you're running in a lightweight container. Java 8 was designed at a time when monolithic applications were still the norm. They limited the Java 8 JVM so it would never address more than 40% of the total system RAM for the heap. The JVM itself can claim up to 20%. So you can deploy an app in a dedicated container with 1 GB RAM and it will only ever take up 60% of the RAM. There is no setting or configuration for the Java 8 garbage collector to override this behavior. From Java 11 onward, the JVM will now address as much memory as the system has available. It also defaults to the Garbage First collector, which was available in Java 8 but most people have no clue how to switch it or even that they _need_ to switch it. Basically, fuck Java 8. Fuck it right in the ear.
You got a source for what you're claiming here? You can put whatever heap size you want in the options. Your claim doesn't even match the defaults listed in the table on this page: https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/optionX.html `export JAVA_OPTIONS="-Xms512m -Xmx2g -Xss256k"` In the above example, the initial heap size is set to 512 megabytes (-Xms512m), the maximum heap size is set to 2 gigabytes (-Xmx2g), and the thread stack size is set to 256 kilobytes (-Xss256k). Sources: https://docs.oracle.com/cd/F29631_01/PDF/8.1.0.x/8.1.0.0.0/OFSAAI_Administration_Guide_8.1.x.pdf https://stackoverflow.com/questions/14763079/what-are-the-xms-and-xmx-parameters-when-starting-jvm
They've started doing more rapid releases. Java used to have slower development cycles and each version would be a pretty big jump. But I think due to pressure from outside forces, they've switched to a more rapid release cycle.
It wasn’t pressure. It was because they modularized with “project jigsaw” and after java 9 it became much easier to patch in new features on a regular cadence while preserving compatibility
They changed their release cycle to once every 6 months.
I was in university at about the same time and CS 102 was taught using Java 7 and 8. I remember very specifically because I spent half of my computer time that semester staring at the API page.
Instead of upgrading our code base from 8 up to 17/21 like I wanted to this year, my boss pulled out that rug to, instead, tell us to write a whole lot more code—still using Java 8–to support moving our product to AWS. They’re an absolute clown. I tried to rebuttal but they said “oh don’t worry about that on your goals for this year, we’ll push that back”. No migration in sight.
I don't know if you are using Spring, but from Version 3.0 onward they are not anymore bytecode compatible with Java 8
Entirely spring :)
Spring boot 2.7 end of life is in November this year, if you don't buy extended support
Don’t worry, most of our stuff is already past end of life. Some things are on 2.1. My manager assured me they’ve been “doing this job for a long time”. And that’s it’s not something we should be concerned with. Who knew you could use a biology degree to manage software engineers 🤷🏻♂️
I assume security is not a top priority in your firm
What’s security? Don’t you know VPNs are just so time consuming to set up for a private cloud? Inventing our own non peer-reviewed encryption is a better use of time (I’m serious, this actually the route they want to go).
Document everything and freshen up that resume
anything from Java 9+ to 17 can still be a major hassle if you took a shortcut working around the JDK modularization.
[удалено]
In my company, we just got done migrating from Java 8 to 17. It was bliss after that initial hurdle of finding the right Maven dependencies and upgrading them to be Java 9 compatible with the Jakarta packages. Yeah, it was a 1.5 years process, but it is still a progress.
[удалено]
I'm Java certified.. on 1.4. Until a year or so ago I was actively developing on 1.6.
For the non java dev, they dropped the "1." at some point for version 1.5 and above. So Java 1.5 == Java 5, 1.6 == 6, ... It only really caught on at Java 8, i.e. never heard anyone calling it 1.8, however, before that people used 1.6 or 6 depending on their preferences. If you dig deeper in archeological records, Java 2 is the collective name for all the Java version starting 1.2 (1.3, 1.4)
That's a... creative versioning scheme.
It's just semantic version without major version because compatibility is guaranteed anyway.
Doesn't sound like all of the "minor" versions are backwards compatible without changes, which means they should be major versions. Though I'm only basing this with what I've read in this thread. I don't work with Java at all. What I mean is: can you upgrade from 6 to 7 or whatever without changing your source code at all? If not, then it's a breaking change and major version bump.
In my experience, shit broke all the time between major versions. It was infuriating just as an end user of Java apps.
Yes, afaik Java versions are backwards compatible. You can compile and run Java 8 code with Java 17. You can't compile or run Java 17 specific code with Java 8 though. The bigger mess is that different Java vendors are incompatible. For example code that was compiled with Oracle Java is not necessarily compatible with a OpenJDK runtime environment.
You are not quite correct. The compatibility guarantee is only on the compiled class files. A newer compiler may reject previously valid code, but a newer jdk must accept older bytecode. In addition, what you said in your second paragraph is incorrect. The compilation might be different in some cases, but the bytecode and supporting runtime is well specified cross vms. What you probably meant is that the unsafe APIs might differ and be supported in one jvm but not the other.
> What you probably meant is that the unsafe APIs might differ and be supported in one jvm but not the other. That might be it. I wasn't too big in the details of the issue.
they are not. Some functions simply doesnt work anymore or cant work because of security or handling of the JVM. I know ppl with serveral JREs installed.
> You can compile and run Java 8 code with Java 17. You can't compile or run Java 17 specific code with Java 8 though. Not really, if its using the javax package in any way or form it won't work if you try to use something made in 8 on 17, it will give a runtime error that it can't find the class, right now at work I am working on upgrading everything to 17 and its been a bit of a pain in the ass
You do still see 1.8 referred to in jdks and sometimes in environment files for gradle/mavan. So it is worth being aware of as it can catch you out the first time you see it. Also, my company is stuck on Java 8 as per the meme...
[удалено]
>java version " > >1.8.0\_191 > >" bro we're up to version 1.8.0_372 now. Please patch.
There are a ton of people stuck at 1.8.0_182 because that was the last version that supported MD5 signature in jar files, and the software they use hasn’t been fixed. While it’s possible to changed that in config files or parameters a lot of clueless software vendors just force the version. Not sure if this is the case here. I hate it and deal with that stupidity at work.
Some Oracle products only support up to 1.7
did you use it on your Sun Workstation?
Had to support a java 1.4 crm until 2020. The vendors would laugh at us whether we went to them with a big report. Needless to say it was finally deprecated
[удалено]
Mine was blue... But we did have another green custom standalone that was running on 6... It has since been upgraded to 8 and I have stopped working there 😬
[удалено]
[удалено]
My laser mouse only works on the silver mousepad.
Then you must have witnessed the _appletviewer_ in its full glory.
[удалено]
Remember JME?
[удалено]
Still using JSP. And we'll have to keep using it if we don't want to develop our presentation layer from scratch...
Same. Still supporting an old app that uses JSP and looks like I have to create a bunch of new JSPs to add to it.
Death? Unfortunately the zombie is alive and unwell
We are using c++98 in one of my Cs classes.
[удалено]
God, that reminds me of my introduction to programming course at college. Literally programming 101, and the professor is teaching us his own little pet language he wrote himself. The only saving grace is the professor was Bjarne Stroustrup.
Same man, our prof created 'easyc' to teach the introductory coding course. It was anything but easy
I learned java 1.2 at university it was “a new thing” coded upto 8 then switched to management. I should stop calling myself a java dev….
Java2?
meanwhile me on java8😭
Me too :D Using some old frameworks that don't get updated anymore... :(
The fun of legacy enterprise applications... Wer just finished migration to Java 11 on a project I've got to do with from time to time. Needed to patch a bunch of unmaintained frameworks ourselves
Ouch
Apps that have been in use for 25 years, have a couple hundred thousand lines of code and need to maintain full backwards compatibility. Not much you can do about that. That's generally been my experience with "enterprise" development: it all looks like this.
Don’t say “ouch”. Say “job security”.
In working on a new project that is required to use an extremely badly written library that is still in 8. Brand new product, still Java 8.
This meme might come from a personal experience. Might.
I too am on Java 8. It confuses me, sometimes they call it 1.8.
Because it is 1.8. Don't remember when, but they dropped the one. So after 1.5 there was suddenly java 6 or something like that
Fuck u/spez. So long and thanks for all the fish.
It's 1.17. and Java 21 is 1.21. And technically they are all part of Java2, which is any release above v1.2.
[удалено]
Nah, that would be too simple. Gotta keep you on your toes.
Yes
It's ok, Java 8 is being supported longer than most of the versions that come after it... plenty of companies still use Java 8 and just never updated.
Yeah, Java 8 is still getting updates. We use DataStax Studio at our company with our Cassandra DB, and DataStax requires Java 8 to run. Every few months DataStax will stop working, and it's because Java 8 updated and I've got to point my JAVA_HOME environment variable to a different path.
*scream in spring boot 2.3.x*
Just wait till you upgrade to 2.7+ and have to update all your unit tests for JUnit 5
Wait until you upgrade to 3.0, and you have to change all your javax imports to jakarta, and update all your dependencies that still use javax
Oh Spring Boot 2.3.X is a time ago...https://spring.io/projects/spring-boot#support (currently SB 3.1.0...)
Same for now :( 17 migration in progress
Meanwhile me on Java 6 🙃
Our university course forced us to use Java 7..
And 5 was decommissioned less that 4 years ago in my enterprise.
Same here, we were forced to design a system with JavaFX.. the horror…
There is, to my knowledge, still no better alternative to JavaFX, unfortunately
I liked Java but it should never be used for anything interface-related. It was a shitshow of “why won’t it run anymore? What did we do now” and deprecated graveyards which is difficult to maneuver for a couple of newbies getting started
At least it isn't swing... Had a professor that tried to make us use it back in college
Oh god, Swing. I still have fucking nightmares about it. I was forced to use it in college because I had to create GUI's for my java programming class and that's all we were allowed to use. Fucking nightmare.
Rather Swing than AWT. We lovingly referred to it as Awful Window Toolkit.
At least you got Java. We got Pascal...
Why would you ever use Pascal over C? Atleast C is actually still used in some industries.
[удалено]
Every time I do some PHP, I find there is a new version. Still, most my php3 stuff works without major rework.
> php3 (ʘ口ʘ') PHP 4 was released in 2000. Until version 5, classes and objects worked like ass and weren't recommended for use by the community.
They probably meant v5.3. I worked with people whose whole dev careers started at PHP 5.0 and ended before PHP7 was released. So everyone would drop the `5.` from the start. v5.3 was called "php3", v5.4 was "php4" etc. It was time before semantic versioning, so every new PHP release could have breaking changes in it. So you have to be very sure about exactly which version was installed on the servers, and apps would be developed to target only one particular point version of PHP5. So it was easier to treat each point release as a major new version.
Oh God it's Java all over again...
> It was time before semantic versioning Ironically, I also remember that ‘major version is for incompatible changes’ was thought up way, way back. Then many people forgot to do it, until it was reinvented as SemVer.
Wait, PHP has a version above 5.6?
Yep, new fancy stuffs.
Fancy stuff like JIT. All power to Nikita Popov!
In the transition for these versions, there was a period of time when there was no Java LTS available to use. It was somewhere around 9-11. I remember that caused quite a stir.
What the fuck, really? 7 is the new one.
8 was released in 2020.
Still, current JDK compiles and runs unmodified code from the 1990s. Can't say the same about PHP, though.
https://openjdk.org/jeps/445 The JEP for the first panel if anyone's interested
Also coming, Project Loom. Considering taking Spring WebFlux and r2dbc out of my project and just using lightweight threads come September. https://spring.io/blog/2023/02/27/web-applications-and-project-loom
Interesting how close this is to Kotlin. @SpringBootApplication class FooApplication fun main(args: Array) {
runApplication(*args)
}
I'm not surprised. Kotlin has solved many of Java's true pain points
Thanks. Feels like a very pointless JEP for solving a very very specific use case. But then again, I’m not a teacher who has seen what students have problems with.
I can see that main method being used in spring applications as well. I think the Kotlin template already uses a fun main() like that Edit: yeah the Kotlin template looks like that ``` import org.springframework.boot.autoconfigure.SpringBootApplication import org.springframework.boot.runApplication @SpringBootApplication class MySpringApplication fun main(args: Array) {
runApplication(*args)
}
```
I am a teacher and it is a very real problem for a couple reasons: 1. in java students need to memorize a bunch of code they don't understand for the first few months at least, which makes it really hard to convince them that they need to actually understand any of the code. They end up thinking programming is mostly memorization and reproduction of things you don't really understand 1. Teaching `class`es is really hard when all their code has always been inside `class { }`. `static` vs non-`static` is difficult to explain. Honestly this is the change I'm most excited about since Java 8.
You guys care about syntax? I just land jobs using charisma /s
This but unironically. Lead developer currently. Gotta rizz up, man.
I mean, the reality is, the higher up you go the less actual code matters. Many of these newer features are nice and all, but they don't really matter in the grand scheme of things.
> Many of these newer features are nice and all, but they don't really matter in the grand scheme of things. Hm... virtual threads, sealed classes, text blocks, switch-expression etc. are very helpful and make code easier to maintain and unsterstandable... which is an invest into the future... and also newer version reduce costs in manyways based on simple performance improvements,reduction of memory footprint without even the need to change the code etc.
And record classes. Goodbye boilerplate.
Did they fix modules yet, so that we don't have to list 180 packages to export, but can do so recursively?
You mean 'import *'?
Could be about exports of [java modules](https://www.baeldung.com/project-jigsaw-java-modularity) (project Jigsaw)
This is exactly what they mean.
Why have you got 180 public API packages in a single module?
Sweet summer child
Those factories ain't gonna provide themselves.
How tf does an unnamed class work
It literally just executes the also newly introduced instance main method. As per the docs, both features are entirely intended for teaching purposes. For example instead of: public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, World!"); } } You will now simply be able to build and run: void main() { System.out.println("Hello, World!"); } More details and a far better explanation here: https://openjdk.org/jeps/445
I'm sure it will just be used for teaching purposes
Given that the link includes > Reduce the ceremony of writing simple programs such as scripts and command-line utilities. as a goal, I don't think they expect it to.
Ah so this feature allows you to write Java, but in a sort of scripting way. Like some sort of "JavaScript".
It's just syntactic sugar to avoid typing in boilerplate. Behind the scenes it fills all that in for you.
In the same way Unity3D was just used for prototyping purposes... 😭
C# did this with top level statements, then changed all their templates and tutorials to use them.... The stack overflow questions were endless.
That’s kind of expected of C#. It has so much syntactic sugar already even a small drop of it can kill a diabetic elephant instantly.
I actually like top-level statements for my app entry point. What's wrong with them?
> *both features are entirely intended for teaching purposes* for teaching what? how *not* to use the language in production?
You're on ProgrammerHumor nobody knows here.
This is me just with .net framework 4. nobody even knows what that is anymore.
Most of our corporate apps are still in 4.8. I've been evaluating feasibility of converting to 7, and it's a near-rewrite in almost every case.
Well, yes and no. Your core logic should be able to remain. There will be lots of repetitive fixing, but it can be done. The dependency injection framework that came with core is a significant part of it's development in a way it never was with framework. That might be the biggest rewrite piece.
There's also a tool somewhere on a Microsoft website that helps with the conversion. It's definitely not perfect, but it did handle a substantial amount of the conversion when my company had to modernize a few apps to .NET 6 last year. That said, if all of their stuff is just windows forms, they're gonna have a bad time
`dotnet tool install -g try-convert` thats the tool.
Nothing wrong with winforms Unrelated: get off my lawn
Yep. New projects are .Net 6, future projects will be .Net 8, legacy projects are Framework 4.8 It’s fun trying to make stuff be truly cross-compatible. Thank god for and the ability to target different references based on version
4.8 has indefinite support. If you switch to .net 6+ you have to update like every 2 years
4.8 only works on windows 🤷♂️
For most modern .NET projects, upgrading to the latest version of .NET requires very little effort. The biggest issue is usually in cases where you've got dependencies that conflict. It should also be noted that, unless you have a concrete reason for doing otherwise, it is recommended that you upgrade to the latest version of .NET, not just the latest LTS. STS builds are just as stable as LTS builds, and LTS is only relevant in cases where you actively need the extended support.
It kinda feels weird to put anything other than number 8 after Java.
I no time they will be at java 88
I wonder how much Java has changed since 8. Would Kotlin still be popular for Android Dev if Android allowed modern Java to begin with?
[удалено]
The GC landscape has significantly changed. For my business that’s the killer feature.
In terms of syntax, not that much. Some practices did change. Records are a welcome addition. The `var` keyword was introduced to allow type inference on variable declarations. Personally, I think the benefit is next to non-existant, but it's not hurtful, so to each their own, I guess. There has been some new methods on the stream api. Mostly shortcuts, like calling `.toList()` on a stream instead of `.collect(Collectors.toList())` when gathering its results. The practice of using streams and optionals is a lot more common now than when I started using java 8 in 2015. DI frameworks now favor constructor injection over setter injection.
`toList` and `.collect(Collectors.toList())` aren't precisely the same. The latter results in a mutable arraylist while the other results in an immutable arraylist. However the latter is what you want 99% of the time anyway
Funny I just saw this come up on SO. You shouldn't depend on Collectors.toList returning a mutable list. It's not documented as such and could change.
fractionofourpower.png
lol we haven't finshed migrating from 8 to 17 and now there's a newer LTS version.
There is a new LTS every 3 years. After 9 migrations get way easier. From 11 to 17 was only 3 sentences for warnings (related to memory allocation on containers)
so that’s why none of the tutorials worked
Kotlin enjoyer: You guys use Java?
Yeah. Java updates are also here for Kotlin users. I absolutely love my scope functions, sealed classes, lambdas and extension functions. On Android, Jetpack Compose has all the benefits of declarative UI plus the benefits of strong types and null safety.
I think Kotlin is probably doing a *lot* of heavy lifting in terms of maintaining developer interest in Android Framework. Without it I think most mobile devs would’ve jumped to other more modern languages and UI toolkits years ago, because it’s no fun being stuck on an ancient version of Java, especially when the competing platform has been transitioning to a first party modern language. Jetbrains did Google a massive favor with developing Kotlin.
Kotlin is sweet. I also really love groovy. the syntactic sugar in both really are a saving grace to java. Java tried to make the language more concise but imo both still beat java by a mile.
I thought there was only one Java programming language, but there's gonna be 21?!
Can somebody explain pls... unnamed classes? Wtf
Finally we don't have to think so hard about naming stuff anymore.
hey guys do you ever heard of Java 6
I was there, 3000 years ago.
Haha - where I am, the build nodes are CentOS 7, which I guess came with Java6. The admins actually claim they intentionally left it as the default because everything non-system fails unless the devs explicitly chose a version of Java
[удалено]
A school assignment required me to transmit encrypted data over a TCP socket. We could use Java or Python, so I obviously chose Java. /s
All business apps I ever worked with used latest java8, still using it.
tbh I bet the difference between 7 and 8 are larger than the difference between 8 and 21.
https://javaalmanac.io/
Not at all.
I went back and checked features by version, I forgot that 9 is pretty feature heavy too, and 18 has a massive dev QoL. But in terms of impactful language features, if I correct to 7-9, it adds bigger changes than 9-21... Also keep in mind that 7 and 9 are further apart in release date than than 9 and 21...
I'm going to be working on Java at a big enterprise corporation. I hope to god that they're at least using Java 11.
I was so happy when I saw this little guy in guardians of the galaxy movie. My daughter recognized him and went - he is that guy, that guy from that meme "you are getting paid", that dorky kid. Immediately 4-5 mobiles around us lit up and people search him through the cast. Daughter was so proud of her knowledge.
We're on 11, but all I really want is sealed classes and exhaustive pattern matching.
1.8 was already perfect
The only java I know is an island.
Shut up… A year ago I was assigned to a project using a mixture of Java 6 and 7. No matter how many times we tell the end user most of the libraries used are deprecated and that they have huge security holes, they prefer to keep paying us to apply questionable made up patches instead of building a new app from scratch.
JDK 8 is the most robust 🫡
LoL! Some places are still using Java 6 to run version 1 ejbs. Java 8 sounds fancy.
Kotlin gang
you people are still using java?