We got 2:34 wrong. Named groups in regular expressions are supported since Java 7. What's new (in 20) is that the methods related to named groups moved up the dependency tree from `Matcher` to the interface `MatchResult`.
You're absolutely right. What has been done in 20 is that the methods are now available on MatchResult (interface implemented by the Matcher class), along with some others. I should have mentionned namedGroup() also.
@@muzzletov If the JDK calls it Charset, it is Charset and not CharSet. And honestly, I would consider charset to be its own (atomic) word and (at least in the context of Java,) it isn't really a set of characters.
Really appreciate this format of doing updates. Also a cool idea: the amount of coffee left in the cup should match the progress of the video ;) Also thankful that new APIs and methods aren't using checked exceptions! 🎉
So, named groups, which arrived in Java SE 7, is now suddenly something new? If you could write the name of the group in some meaningfull way without of a lot a string gymnastics, then there would be some thing new.
Nope, not in that case. If what you need is to kill your JVM as fast as possible, taking the time to execute all your close(), finalize(), etc... would probably be a mistake,
IMO the state enum is missing something. "CREATED" or "UNSTARTED", because there is no way to track if a task was already started or not. Which is useful if you have a queue of tasks that are expensive and you want to cut basically anything that isn't started yet, and you didn't expose the Queue itself. Unless state returns null if it isn't started yet, then i take that back.
I fully agree, currently it seems they put the state as RUNNING as soon as the task is submitted. probably it is being thought that since we can have virtual threads, the number of threads in the pool will be more and no task will be waiting to get started. but for tasks which are computative (no blocking activity), one may not like to use virtual threads. In any case you are right, that state has been missed.
@@JorgetePanetein a method's scope that's probably easy enough (GoLang has the defer keyword for this use case pretty much), but how would you do it in the case of a field? It would have the same problems as the finalize method I'm pretty sure.
@@JorgetePanete the reason rust can automatically close is it's strict borrowing and moving rules. In java you can move objects freely and rely on the GC to clean them up
Yes, there could be a separate class for all the Unicode properties. There are still a lot of unicode properties not available in Java API (Character class).
It's not because it's old that it's not useful. With the deprecation of finalize(), AutoCloseable becomes more important. Thus the new classes that implement it. Keeping repeating old stuff is not a problem for me.
var often shows that the variables names used are not good enough to transport the information. That lets me reconsider my names and make it better (hopefully ;-))
We got 2:34 wrong. Named groups in regular expressions are supported since Java 7. What's new (in 20) is that the methods related to named groups moved up the dependency tree from `Matcher` to the interface `MatchResult`.
no worries, everyone here knows the vids are just about coffee sipping with some words inbetween 😁
i was going to complain the same, named groups are allowed since I learnt regex like 3 years ago and more I suppose
Yeah I was really confused about this. Was going to comment the same thing. Brain fart !
Apologies, isn't the feature mentioned at 2:34 already available since Java 7?
Yes, it is.
What is new in Java 20 though, is that MatchResult now supports named groups. Perhaps there was a mixup here.
You're absolutely right. What has been done in 20 is that the methods are now available on MatchResult (interface implemented by the Matcher class), along with some others. I should have mentionned namedGroup() also.
Thanks! I cant wait for the named String groupings to help parse flat files.
Thanks for the overview ! A few nice things that may be shadowed by virtual threads
Thank you!
Great topics I had to comment and thumbs up.
Thanks a lot José.
Thank you Khaled!
Thank you for making this video! Very useful
Thank you!
Good explanation Sr! Thank very much!
Thank you!
3:59 With large patterns in a multiline string, instead of using backslashes you can also use the COMMENT flag. This will be more readable.
Awesome video, thank you ☺️
thank you for valuable information sir...
btw I like ur coffee cup
Came here for Java, stayed for their use of my favourite local cafe in the background! 😂
Shouldn't it be "Charset" instead of "CharSet" in 7:09?
CharSet is just short for Character Set. So, no, it shouldnt.But yes, the class is called Charset, which feels wrong :D
@@muzzletov If the JDK calls it Charset, it is Charset and not CharSet. And honestly, I would consider charset to be its own (atomic) word and (at least in the context of Java,) it isn't really a set of characters.
It should. Thank you for pointing it out!
Really appreciate this format of doing updates. Also a cool idea: the amount of coffee left in the cup should match the progress of the video ;)
Also thankful that new APIs and methods aren't using checked exceptions! 🎉
Well it does ;) This is real coffee that I drink during the recording.
@@JosePaumard Cool! I bet it's actual Java coffee too ;)
@@nO_d3N1AL Oh yes it is! 😊
Pleasant coffee lounge atmosphere, perfect for learning.
So, named groups, which arrived in Java SE 7, is now suddenly something new?
If you could write the name of the group in some meaningfull way without of a lot a string gymnastics, then there would be some thing new.
What is new is that the methods are now also on the interface.
08:44 close() method will be called no matter what? what if there is System.exit(0); in the try block?
Nope, not in that case. If what you need is to kill your JVM as fast as possible, taking the time to execute all your close(), finalize(), etc... would probably be a mistake,
In your example at 7:15, your types should be "byte[]" instead if "int[]"
ahh... certainly too much coffee 🙃
Hi Jose, Big Fan!! Your Coffee looks yum
after what JDK will be the whole lambda as was introduced in JDK8 deprecated and ousted ? Can't wait the moment
IMO the state enum is missing something.
"CREATED" or "UNSTARTED", because there is no way to track if a task was already started or not.
Which is useful if you have a queue of tasks that are expensive and you want to cut basically anything that isn't started yet, and you didn't expose the Queue itself.
Unless state returns null if it isn't started yet, then i take that back.
I fully agree, currently it seems they put the state as RUNNING as soon as the task is submitted.
probably it is being thought that since we can have virtual threads, the number of threads in the pool will be more and no task will be waiting to get started. but for tasks which are computative (no blocking activity), one may not like to use virtual threads.
In any case you are right, that state has been missed.
legend has it this guy is still sipping his coffee and hasn't finished it
He did finish his coffee at the end of the episode 😅
Another legend says that the cafeteria behind is a green screen and he is actually in a pub, and that's not coffee in the glass but Guinness
What's new about pattern matching? Named groups have existed for years.
So Autoclosable is a functional interface?
It is. I'm not sure that it will be very useful to implement it with a lambda though...
Ok.
class Closer {
static void closing(Closeable closeable) throws Exception {
System.out.println("Now closing: " + closeable.toString());
closeable.close();
}
}
class AClosable implements AutoCloseable {
@Override
public void close() throws Exception {
System.out.println("I am closing");
}
}
public class CloseableDemo {
public static void main(String[] args) throws Exception {
var aclosable = new AClosable();
Closer.closing(() -> {
try {
aclosable.close();
} catch (Exception ex) { }
});
}
}
@@JosePaumard Thanks, I tried anyhow. 😉
@@edmaphis9805I'm not sure I would use this pattern in a real application 😉
رائع
Emoji methods !!
Holy smokes !!
Thank you
Thanks
thank you
I think close() should be called automatically when the object is no longer needed
Wouldn't that cause the same problems as finalize?
@@SourabhBhat At least if it's called at the end of the scope of the object I think there wouldn't be problems
@@JorgetePanetein a method's scope that's probably easy enough (GoLang has the defer keyword for this use case pretty much), but how would you do it in the case of a field? It would have the same problems as the finalize method I'm pretty sure.
@@alessandroautiero5414 I don't know, I just wish it was like Rust does
@@JorgetePanete the reason rust can automatically close is it's strict borrowing and moving rules. In java you can move objects freely and rely on the GC to clean them up
🎉
How's the coffee?
wow, all these have been in Erlang/OTP, Python, Elixir right at those languages' first version.
Naming capture groups is a super old feature of Python.
Why do they pollute Character class with emoji methods 🤮? They could have made it as a separate util class .
Yes, there could be a separate class for all the Unicode properties. There are still a lot of unicode properties not available in Java API (Character class).
piano in background still drives me crazy.
AutoCloseable?
Why are you presenting these OLD features as if they were new? Are you crazy?
Watch it one more time. AutoCloseable is OLD. But now ExecutorService, HttpClient..etc also implement the interface. Thats what he says!
It's not because it's old that it's not useful. With the deprecation of finalize(), AutoCloseable becomes more important. Thus the new classes that implement it.
Keeping repeating old stuff is not a problem for me.
You used var. Shame on you.
Oh no, I love var.
@@JosePaumard var var var var. Just for you. Quess what objects I'm using.
@@nicholas1460 You don't need to use it everywhere. But there are still many places where it will make your code more readable.
var is a great addition to java. I have been using for couple years now,
var often shows that the variables names used are not good enough to transport the information. That lets me reconsider my names and make it better (hopefully ;-))
What an old ugly mess language. I feel bad for android devs when they gota look at swift and swiftui