It is funny how history repeats 😂 Green threads refers to the name of the original thread library for the programming language Java (that was released in version 1.1 and then Green threads were abandoned in version 1.3 to native threads). It was designed by The Green Team at Sun Microsystems.
I love Java 21. Next, I would like to see a project that allows null safety similar to Kotlin without typing everywhere NonNull annotations. Migration is often impossible, and I prefer overall Java syntax except for the lack of null-safety.
Null safety has never been an issue in any of the projects I’ve worked on for the last 20 years. It’s been oversold a lot by the Kotlin community, and seems to appeal mostly to students or junior programmers.
@@pompiuses You can say the same about unnamed classes. And yet, this change was introduced in Java 21. No matter if it's a small or big change, Java seems evolving. Null safety seems to be a much bigger issue than the additional two lines with class declaration. We can say it's just a "student or junior" problem, but in the end, the code goes to production and companies are losing money on faulty software and further fixes. I have half of your experience, so maybe my view will change over time but for now, I think this type of error could be solved by specifying at the type check level if you allow nulls or not. Like you can do in Rust, Dart, C# or others.
I am using it and the performance is superior to previous versions. I have some GUI Swing and FX hobby programs. I am not a professional Java programmer, I am doing it for my own personal needs on the computer at home. For my Swing programs I use Jyloo's look and feel. I started with Java 5 many years ago
Thanks for the video. Amazing features are comming with every release, thanks! I'm, however, not fan of some of Amber Project features. From my point of view, some of these new features (such as unnamed classes, var, etc) are complicating the language, making developers have to learn how to read and mantain multiple ways of doing the same thing... and the only advantage is typing a few less characters. I don't think is worthy: - The more ways to declare the same thing, the more a developer has to learn (and the more code need to be written and mantained for IDEs and compilers). - Explicit declarations may be more verbose but are easier to read than an implicit way of coding (Scala code can be very powerful and concise but often developers have a very hard time wondering were's all the magic and what side effects their changes can have). - IDEs help with a lot of features (autocompletion, etc) to ease the "typing burden". - Developers spend a lot more time thinking and designing (at least in their minds) than writing classes of variable declarations.
@@alessioantinoro5713Yeah, I don't know, it sounds like the 251st recap I've watched recently. Like if they repeat the same thing over and over, people will suddenly forget about java 6. they seem to react to features in other programming languages to stay relevant instead of leading tech innovations. Anyway, good luck to Oracle as they attempt to regain some market share from Python, Golang, NodeJs and cie after decades of stagnation and disregard for their ~community~ customers.
Everything Oracle is doing now should have been done 10 years ago. New projects are now being developed in Kotlin and Go; nobody uses Java anymore. The only ones left are the enterprise who are still on Java 8 and can’t even afford to upgrade to 11, let alone 21. It would be just as time-consuming to migrate to Kotlin, but the results with Kotlin would be much greater. Due to their greed, Oracle lost Android, and now due to their sluggishness, they are losing server-side. Nobody needs their innovations. It's just laughable. I believe that Oracle should admit defeat, officially stop supporting new versions of Java, and recommend transitioning to more modern languages, such as Kotlin. Lastly, Google has moved away from Java on the Android side, and now they’ve done the same on the server side. Draw your own conclusions.
@@RakeshPatel-zh7ds No matter if you use Java 17, it doesn’t change the facts in my previous post. Unfortunately, that’s the current reality. Name one reason why those enterprises that have moved to Kotlin, and those that are transitioning now, should return to Java? Java’s only strength is its large legacy, the only thing keeping it afloat.
That's a pleasure to have Brian passionately talk about Java
I still love and use Java❤
It is funny how history repeats 😂
Green threads refers to the name of the original thread library for the programming language Java (that was released in version 1.1 and then Green threads were abandoned in version 1.3 to native threads). It was designed by The Green Team at Sun Microsystems.
wonderful talk, thank you 😌
I love Java 21. Next, I would like to see a project that allows null safety similar to Kotlin without typing everywhere NonNull annotations. Migration is often impossible, and I prefer overall Java syntax except for the lack of null-safety.
You should check out JEP draft: Null-Restricted Value Class Types (Preview)
They are going over this with Valhalla
Null safety has never been an issue in any of the projects I’ve worked on for the last 20 years. It’s been oversold a lot by the Kotlin community, and seems to appeal mostly to students or junior programmers.
@@pompiuses You can say the same about unnamed classes. And yet, this change was introduced in Java 21. No matter if it's a small or big change, Java seems evolving. Null safety seems to be a much bigger issue than the additional two lines with class declaration. We can say it's just a "student or junior" problem, but in the end, the code goes to production and companies are losing money on faulty software and further fixes. I have half of your experience, so maybe my view will change over time but for now, I think this type of error could be solved by specifying at the type check level if you allow nulls or not. Like you can do in Rust, Dart, C# or others.
A project that allows us to not have to add final everywhere would be equally as desirable to me. Such a pain final is not the default
I am using it and the performance is superior to previous versions. I have some GUI Swing and FX hobby programs. I am not a professional Java programmer, I am doing it for my own personal needs on the computer at home. For my Swing programs I use Jyloo's look and feel. I started with Java 5 many years ago
Good to see Haskell as a measure of conciseness. Good to see it as a measure at all, for a mainstream giant like Java.
You are now happy by introducing scala features
Awesome speaker and content!
great that made it more modern now
Java21+ the new Javaly
I still love java 21
13:42 Why do I feel like I've already heard this somewhere, ah right the dude who was upset under a Java bug fix video lol
no way this is duke's nose, not an eye
Thanks for the video.
Amazing features are comming with every release, thanks!
I'm, however, not fan of some of Amber Project features. From my point of view, some of these new features (such as unnamed classes, var, etc) are complicating the language, making developers have to learn how to read and mantain multiple ways of doing the same thing... and the only advantage is typing a few less characters.
I don't think is worthy:
- The more ways to declare the same thing, the more a developer has to learn (and the more code need to be written and mantained for IDEs and compilers).
- Explicit declarations may be more verbose but are easier to read than an implicit way of coding (Scala code can be very powerful and concise but often developers have a very hard time wondering were's all the magic and what side effects their changes can have).
- IDEs help with a lot of features (autocompletion, etc) to ease the "typing burden".
- Developers spend a lot more time thinking and designing (at least in their minds) than writing classes of variable declarations.
Can 1000 threads implicate 1000 JIT compilations from many parts of JVM code with their new problems as the CPU cache misses and higher latencies?
oop < fp < pp
What about valhalla?
So where's the VSCode extension?
See inside.java/2023/10/18/announcing-vscode-extension/
@@delabassee Oh wow released just today, ty
Nothing about Lilliput and value types. The community, sorry the customers, didn't learn anything new in this presentation . Back to rust/golang
I guess it was just a big recap of what's going on
@@alessioantinoro5713Yeah, I don't know, it sounds like the 251st recap I've watched recently. Like if they repeat the same thing over and over, people will suddenly forget about java 6. they seem to react to features in other programming languages to stay relevant instead of leading tech innovations. Anyway, good luck to Oracle as they attempt to regain some market share from Python, Golang, NodeJs and cie after decades of stagnation and disregard for their ~community~ customers.
The good old days, now it is crap
Everything Oracle is doing now should have been done 10 years ago. New projects are now being developed in Kotlin and Go; nobody uses Java anymore. The only ones left are the enterprise who are still on Java 8 and can’t even afford to upgrade to 11, let alone 21. It would be just as time-consuming to migrate to Kotlin, but the results with Kotlin would be much greater.
Due to their greed, Oracle lost Android, and now due to their sluggishness, they are losing server-side. Nobody needs their innovations. It's just laughable.
I believe that Oracle should admit defeat, officially stop supporting new versions of Java, and recommend transitioning to more modern languages, such as Kotlin.
Lastly, Google has moved away from Java on the Android side, and now they’ve done the same on the server side. Draw your own conclusions.
rubbish, lots of java devs around including me. I am also using java 17 for the past year.
Your degree of self-confidence is envious.
lol.. people say "java is dead" for 20 years.
Even if Oracle gives up, Java community just simply won’t.
@@RakeshPatel-zh7ds No matter if you use Java 17, it doesn’t change the facts in my previous post. Unfortunately, that’s the current reality.
Name one reason why those enterprises that have moved to Kotlin, and those that are transitioning now, should return to Java? Java’s only strength is its large legacy, the only thing keeping it afloat.