This video is so much better than it needs to be. I appreciate the work done to bring fun and levity into the Java ecosystem which has historically been rather dry.

@michaeleaster1815

2 жыл бұрын

100% agreement

@nipafx

2 жыл бұрын

Thank you very much, Zac, that is great to hear! ❤

I have been waited for long time for project loom. Now it is available in JDK 19 💪

@arunrajput1007

2 жыл бұрын

me too bro :)

The day Valhalla lands on Java mainline as preview or incubating feature. That would be great release. Hopefully something in Java 20.

Very informative update. Thanks for publishing! Java is awesome!

@java

2 жыл бұрын

Glad you like it!

This is extra ordinary release. Thanks for sharing.

I think that Vector API should wait even after project Valhalla, if operator overloading will be considered in the future. With operator overloading the Vector API will have a much cleaner syntax. Even value types will have a cleaner syntax if operator overloading is introduced.

@feryadialoi2244

2 жыл бұрын

can't agree more

@nipafx

2 жыл бұрын

I have only very vague memories of this but I seem to recall a design document or mail on a mailing list where the only kind of operator overloading Java would ever get was described as one where specific methods like `add` or `multiply` could be replaced with infix operator notation, e.g. `+` and `*`. That would allow such methods on vectors to be used with operators instead. And it makes sense to design that feature to be compatible with existing methods because otherwise `BigInteger` couldn't benefit from it. To make a long story short, I don't think the vector API has to wait for that and can instead rely on operator overloading, if it ever comes, to be compatible with it.

@SourabhBhat

2 жыл бұрын

@@nipafx Thank you very much for an detailed reply. I agree that it won't matter for the Vector API. The API can always be remapped to use operators internally (depending on the syntax decided if operator overloading is part of Java later) and all the code will automatically be backward compatible. However, imagine what will happen to the code written in applications by Java developers before and after introducing operator overloading. Especially if operator overloading decides to have plus() instead of add() or times() instead of multiply() and so on... Since Vector API is targeting speeding up of mathematical operations, is it not worthwhile to wait for operators to express it succinctly? This is my opinion only if operator overloading will be considered soon.

@nipafx

2 жыл бұрын

@@SourabhBhat If the main goal is to speed up mathematical operations (and it is), that can be achieved without operator overloading. Of course operator overloading would make it much more elegant and concise to do fast math but that's surely a secondary concern. Good point about "soon" - I don't actually know about where that idea stands at the moment. Will ask. :)

Java and mojitos in Crete. Where do I apply?

@billykorando6820

2 жыл бұрын

inside.java/jobs/

@nipafx

2 жыл бұрын

It was Gin Tonics (they didn't have Mojitos!), but otherwise: inside.java/jobs/ 😉

Java 19 would always be remembered as a groundbreaking release, and this video will always be remembered for Billy's groundbreaking funny video editing skills. 😂

Finally Loom! Welcome!

Loom is finally here. I'm so glad

Agreed. Considering all the features expecting in JDK 19, will Java outperform Go Programing language in future?. Metrics like performance speed, pause time for garbage collection etc.

@StefanReich

2 жыл бұрын

They are just very different. Java is huge, starts slowly, but finally optimizes things to the moon. Go is just a tight classically compiled language plus a garbage collector .

Can't wait for loom to go ga.

Needs more Billy!

@billykorando6820

2 жыл бұрын

Agreed!

3:25 great video! though I think the heading slide for Foreign Function & Memory API JEP 424 is a minor error (re: Vector API)

@nipafx

2 жыл бұрын

I blame my editor. 😁

I hope we see project Valhalla preview in jdk20. Would be an amazing easter egg.

Can we do bitwise operations with Vector API?

But Java 19 will be released in September, right? I wonder why this video is released so early?

Great job on hyping JDK

Yo, you work even on your holiday ;o

@nipafx

2 жыл бұрын

My hobby is my job and vice versa, so that happens regularly. 😁

@oskarkamil8208

2 жыл бұрын

@@nipafx Also working remotely allows us being on holiday during work. One of many perks

yall need to slow down, I / we are still on 8 lol

@billykorando6820

2 жыл бұрын

The Java release train has no brakes

What about new feature in Java like ... nice girl on the beach 🙂

I was very exited when I heard of pattern matching being developed, but the more I see where it's going, the more disappointed I am. This is just exploiting the term, but rather doing something else.

@LannisterFromDaRock

2 жыл бұрын

I'm pretty sure that they will extend it's usage in the future. At the moment its just scratching the surface.

@nipafx

2 жыл бұрын

What do you think it should be to be pattern matching?

outdoor sound is horrible.

@nipafx

2 жыл бұрын

I wouldn't describe it as horrible, but it is considerably worse than usual, yes - it was pretty windy those days. But now holiday's over and so the next one will be indoors again, so the sound will be back to normal. 😃

@betancour

2 жыл бұрын

@@nipafx is just my opinion I am an ASD person, sometimes I just express what I feel, but the content of this video is excellent and thanks for it, please accept my apologies .

@nipafx

2 жыл бұрын

@@betancour No worries, all good!

the jdk should be smarter enough to add the case null automatically if not present in case you use pattern matching, or at the very least show a warning at compile time

@nipafx

2 жыл бұрын

But what should it do for 'case null'? A compile warning would be ok, I guess, but I write my code so that 'null' is no legal value and so it should rarely if ever make it to a switch in the first place. An NPE would be just fine then. So I'd turn that warning off. 😁

@user-zq8bt6hv9k

2 жыл бұрын

@@nipafx you get a runtime error instead of a compile one. Semantic of switch expression is you are supposed to cover all the cases. Null is also a case. I'm working with pattern matching in rust and that's how it works there, which makes totally sense. At compile time i know for sure there is zero null pointer in my program.

@billykorando6820

2 жыл бұрын

@@user-zq8bt6hv9k But isn't that potentially burdensome on the developer, forcing them to handle a null when a null might not be possible, or the only logical response would be to throw an NPE? A null isn't required to be handled, because the JVM already has a well-known way to handle that, throw an NPE.

@user-zq8bt6hv9k

2 жыл бұрын

@@billykorando6820 it's a semantic issue. If you assume that you must handle every cases or provide a default on a switch expression, then you'll definitely forget to put the null. I mean you've set a default, what could go wrong? I definitely lost hours of debugging when I was a junior because of that. The problem is that default should handle the null case, but for compatibility issue that's not possible apparently. If that was possible, then there wouldn't be any burden on the developer, as they already have to provide a default. could look like: default when null : throw NPE or simple warning default : do something useful

@nipafx

2 жыл бұрын

@@user-zq8bt6hv9k I agree in principle that more explicit null handling is better. Unfortunately, this ship has sailed for Java and it's questionable whether it helps to have some language feature be stricter than others for no other reason than that they were introduced later. > Semantic of switch expression is you are supposed to cover all the cases. Null is also a case. Semantic of *all* code is to cover all cases and yet no Java language feature requires explicit null handling. You can assign null to fields, use it in `instanceof` checks, pass it as method arguments, etc. etc. and nowhere does Java need you to handle it. I think we both agree that it'd be better if it did that, but the fact of the matter is it doesn't. Does it help if a specific feature does? That's probably where we disagree. > At compile time i know for sure there is zero null pointer in my program. You will never have that in Java. > The problem is that default should handle the null case, I disagree. null is no value like any other and (mis)handling it as one would make things much worse. When you spent hours of debugging as a junior to figure out why a switch lead to an NPE even though the runtime points at the exact line where the error pops up, imagine how much worse it would've been if it silently fell into the default branch and did whatever that one did. I think it's prudent to write code so that null is never a legal value and fail fast if it pops up. I like that switch has that behavior and doesn't require me to handle null in each switch even though it should never get there and all I'd want to do is `case null -> throw new NullPointeRException();`

More like chessed off or something. What are you on about?

Boss, if you are serious try explaining in a room man. not like this... :(

Probably jdk 8.. because everything past that seems to break stuff and add even more complicated syntax.