Great summary. I decided to jump from 8 to 17 and this is a great highlight reel of features I am happy to see (except maybe "var"). Another feature I love now is how easy it is to read and write text files using Files.readString() and Files.writeString().
You ignore the most important feature, of the switch... it can be an expression and you can return a value. Why repeat the System.out.println() 4 times, when you can simply return the club and print it using one println call? Everyone seems to be obsessed about doing their side effects everywhere... Method is easier to test when you return a value.
Thank you! I'm planning to make a video about Java 21 soon, there are some really interesting changes coming up! Yesterday I published a new video about Stream API: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-u9GPhRjBVzU.html And I'm planning to publish new videos more often now:)
Thanks! I've been running a programming channel in Polish for more than three years and people like it, so I hope to give similar value to an English-speaking audience now. I'm glad that you subscribed, new videos are coming soon!
As a concrete example where var is very handy: Spring! ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml"); Saves copy-pasting (or worse, retyping) the class name!
And it makes the code much easier to read! Variable names are much more important than the class names and such long names like ClassPathXmlApplicationContext are nothing but noise.
This is such a great video. Haven't touched Java in years, and wanted to see what the differences were... Perfect ! Loving that NullPointerException message now. You know what it's like. As hard as you try, something somewhere doesn't get set. Then you're spending ages figuring out the specifics. This just gives you that little bit more detail to get you started. Really don't get the point of sealed classes/interfaces though. One useful thing I guess is it tells you which classes implement/extend it. But still, could come back to bite you in the ass I reckon! Thank you anyway. Really useful.
I don't like the concept of sealed classes either. Venkat Subramaniam made an interesting video about it ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Xkh5sa3vjTE.html, but still I just don't see myself using this feature in any future projects.
I love them, but I actually can't believe it took so long (C# too) to get them. It's such an obvious improvement and, from an outsiders perspective, low hanging fruit for improved efficiency when developing.
@@kamilbrzezinski8218 I don't like it as a concept either, but I read it improves performance because the compiler knows when and where to look for inheriting classes.
Great video! I recently saw a meme praising Java 19 (I think), and was surprised to see what the fuss was all about. Not surprised to know that most of these features are already built in Kotlin.
Great video. I guess you forgot to mention that when creating collections using of method the collections created are immutable. Also for set there must be no duplicates.
Thanks and good comments too. Been using Java for years and haven't had the courage to jump from 8 yet. Still have nightmares jumping from 3 to 4 or 5.
I appreciate the summary. While nothing quite as ground breaking as generics or function programming introduced in 7 and 8 (I think generics were 7?), really nice features if I can remember to use them!!
Great video! We need more Java videos like this, very easy to digest and helps with interviews for example (Just had a couple of interviews with new feature questions). Subbed and hoping to see more. Keep it up!
Good explanation! Thank you much! Even though I don't see "var" as a top feature, but merely as something I have to criticize in future code reviews. ;-)
One of the viewers came up with a concrete example where var can be used - long class names like ClassPathXmlApplicationContext. And I agree with this because usually a variable name is more important than a class name. So var is kind of a syntactic sugar making code a little bit cleaner and easier to read :) But I also agree that's not much and probably it'll be used extremely rarely ; )
It's almost like a new language! :) And in September there will be Java 21 which also brings a lot of new features. I'm going to make a video about them soon! Now I only covered a new approach to the main method: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-pTLfwhCOkQs.html
(Great video, though... as someone who largely migrated from Java 1.8 to Kotlin, it's good to see this information presented concisely instead of having to dig it up all over the place.)
Great summary, i was kinda wonder about this because i started to learn java in JDK 17, but a few years ago i bought a book about java but it was 1.8 so i kinda wonder what feature i missed 😄
You forgot to mention if Record covers hashCode, equals and toString or not? If not, there is little difference between using a class with all public fields.
It covers all of them. And Record is immutable, so instead of writing/generating this (or using Lombok): public class Person { private final String name; private final String address; public Person(String name, String address) { this.name = name; this.address = address; } @Override public int hashCode() { return Objects.hash(name, address); } @Override public boolean equals(Object obj) { if (this == obj) { return true; } else if (!(obj instanceof Person)) { return false; } else { Person other = (Person) obj; return Objects.equals(name, other.name) && Objects.equals(address, other.address); } } @Override public String toString() { return "Person [name=" + name + ", address=" + address + "]"; } public String getName() { return name; } public String getAddress() { return address; } } you only need to write this: public record Person (String name, String address) {}
You're right, thanks for catching this! It wouldn't have changed the behaviour though - if we use 'var' we need to initialize a variable in the same line.
And yet java refuses to introduce tuples ... as are present in python.. its such a handy construct.. i guess record would be a way to achieve it..bt still u wud require a verbose atleast 1 liner to achieve it But awesome video... loved the depth yet simplicity
When you want to have an immutable class that just holds data. It was present in Kotlin many years ago: kotlinlang.org/docs/data-classes.html And now Java introduced the same feature :)
For an old language like Java, trying to implement modern features without breaking the old code's compilability (it's a word, right?) does not seem to result in a good syntax. Why not just add some sort of compiler directive at the beginning of a file? So, if there is nothing, then compile it like Java 6 or something. If the file has something like /***Java 17*/ at the beginning, then compile it with a new syntax. This way, the Java language designers would have much more freedom to revive this relic language of the 1990's.
People sometimes copy and paste code snippets, making it easy to create incompatible code in the process if there was such a compiler directive and backwards incompatible syntactic changes.
But how to fall throw? You give also lot of examples using audio files. Maybe you know that Java can directly to stream music to DAC now? Just kidding, I know it can't.
@@kamilbrzezinski8218 Some time both cases are the same except a line of the code. So I do something like : case1, cases2: if case1 then doSomeSpecific(); doCommon(); How should it look when a good design?
@@kamertonaudiophileplayer847 Just move doCommon(); to after the switch. If you need the common to run for multiple cases but not all then you probably need to refactor something since at that point you're trying to be too clever for your own good and it'll just lead to confusing code.
@@LittleLily_ If a language gives some feature, you always try to use it. Otherwise, it sounds fishy, the language contains some features in state - do not use them. Maybe it is time to select a different language?
Hey, how do I get IntellJ IDEA to now hang and stutter when using it? Do I need a bigger CPU or something? I'm using a SSD and 32GB of RAM and my cpu is just a two core AMD, but it has a 3.4Ghz rating. And the thing just won't run smoothly! Are their configuration settings that I'm not using or something?
@5:45 you like to show, that `var name3;` can't be used, because it needs initialization on declaration, but you're trying to show it by assigning to `name` instead of `name3`. ;)
Problem is: most of these new features won't be adopted by "big tech" companies anytime soon, because... I think those corporations are the biggest obstacles to the development of java, as they almost have the final say over the technologies they will use, and how they plan to "upgrade" the infrastructure to accomodate modern Java. No matter how Java improves, they can just choose other modern languages for their projects.
At 8:00, why are you inserting getters if the fields are declared final? What's the point? Just make the variables public. (Not to say that records aren't a huge improvement, like Kotlin data classes, but still... I'm not even sure why records can't make their variables public and need to add accessors.)
@@egozMaster Yes, I do, and I can see why you might want to make them methods if you decide to change their underlying representation at some point, but for something this simple, you will almost certainly not. Look at Java Swing (and other Java APIs, but Swing is where it is most prevalent from what I've seen), for example: it defines a huge number of final constants with int values (not enums) to be passed to things like borders, alignments, etc. Following strict OOP rules is so late 1990s / early 2000s. Most of the organizations I know and have worked with now use a combination of immutable objects (which are basically equivalent to records) and functional programming instead of long-winded pointless strict OOP principles. I mean, if you want to aim for verbosity and redundancy, knock yourself out, but a final field that stores a primitive type or an abstract interface is just as good as a getter. Do a basic google search and you'll see that pointless getters have fallen out of fashion. There's no need to aim for strict purity unless you're a pedant.
“permits” keyword is weird. A generic class knowing about a more specialized class in its context. Just sounds off… Maybe keeping everything package-private and isolating from outside world is a cleaner approach.
Venkat Subramaniam gave an interesting talk about sealed classes: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Xkh5sa3vjTE.html But I still don't quite feel it yet. Package-private is an interesting approach, have you ever worked on a project having this in mind and sticking to it?
