Thanks to be here. Thanks for missing your lunch.
And let me rant about Kotlin. I am Nicolas Frankel.
I've been a developer for, like, now more than 20 years.
Perhaps I'm not a developer anymore.
I'm a developer advocate, but I still see myself as a
developer. I love developing.
Right now I work on the Apache API 6 gateway.
It has nothing to do with Java.
It's just an infrastructure component.
But since they allow me to be here, here is the slide.
Anyway, why am I talking about Kotlin in a Java room?
Well, they didn't want me to talk about Kotlin in the Kotlin
room, so that might be one of the reasons.
And also I've mentioned I have, like, two decades of coding
experience, and those two decades were spent in Java.
So I started with Java 1.3, 1.4, 1.3 perhaps.
And, well, there were, like, big wins and small losses.
And I tried Scala, and I didn't like it at all.
I still have the certificate saying, hey, you are like Scala
certified. I didn't like it for multiple
reasons. Then I went to a couple of
conferences. I had a friend,
and she made all sorts of talks about Kotlin.
And I said, we don't need Kotlin.
We have Java. It's enough.
Then I wanted to teach myself Android development,
and Android development at the time was only in Java,
and the API was super low level.
And I said, no, I cannot write such like codes that it brings
me back 15 years ago when I was writing Java on the service
site. And I looked for solutions,
and I found Kotlin. And I thought, wow,
that's cool. And I stopped learning
Android, and now I write Kotlin on the back end.
So just a disclaimer. If Java is the best language in
the world for you, just leave the room.
I'm not trying to bash Java, but depending on your
culture, I'm pretty straightforward.
You might feel offended. So better leave now.
It's up to you. OK, let's start slow.
Immutable references. I'm telling you,
hey, it's better in Kotlin. And you can't tell me,
hey, Java has it, right? Immutable references.
OK, let's try to check how it works.
Immutable references in Java. Oh, fun stuff.
Immutable references in Java. So here,
this is my immutable reference class.
So I have to put final here. I have to put final here.
And I have to put final here. Now I have immutable
references. Who puts final everywhere?
A couple of people. No, really.
We had this idea 15 years ago, and then we decided,
no, it just makes the reading so much harder.
So perhaps not. Even worse,
if you don't put final on the parameter,
you can actually relocate stuff, which I believe is one of
the worst things you can do. Like really, really,
really bad. So I'm not saying that Java
doesn't have it, but I'm saying that in Kotlin,
it's, from the beginning, you need to decide whether it's a
vowel, which means it cannot be reassigned,
or it's a vowel, which means it can be reassigned.
If you are using IntelliJ, I don't know about Eclipse or
NetBeans. The good thing is that if I
say it's a vowel, so it can be reassigned,
it tells me, hey, like, there is something fishy.
It's not an error per se, but at least it's visually like
pleasing. And, of course, by default,
yeah, for those who don't know, any is the equivalent of
object, so it's not very important.
I could write object. By default, you cannot reassign
parameters. Any language that allows you
to reassign parameters should be taken with,
like, utmost caution. It's actually not a great
design idea. So, of course,
Java was designed a long time ago, doesn't have it,
but Kotlin takes the lesson. And, if you think that vowel
and vowel are coming from Scala, because you are a Scala
fanboy, that's completely true. Kotlin has stolen every good
idea. So, don't pretend otherwise.
That's fine. OK.
Second, immutable classes. Well, that's fine.
Now we have Java records. We've got them.
That's fine. Let's continue.
Null safety. Null safety in Java is not that
fun, right? How many ways do you have to
implement null safeties in Java?
That's a good thing. Yeah, that's a good thing.
Diversity is a good thing, because we work in IT.
And, if you want to really, like, have fun, you might check,
like, null-able, null-able, null-able, null-able,
null-able, null-able, null-able, null-able.
Oh, not null. Well, I'm sorry.
Sorry? Yeah, exactly.
I'm not sure it's an error. I think I just copy-pasted.
So, I'm not sure. Yeah, that's really fun stuff.
And, of course, they won't work with one another.
So, you need to have the preprocessor.
Sorry, you need to have the compile-time processor.
And, you need to choose which library you will be using.
And, then, you hope that somehow it will work.
Good. In Kotlin, what do we have?
Well, it's backed into language.
So, basically, here I was too lazy to write it in Java.
But, basically, if you write something in Kotlin,
you have additional types. So, basically, for every,
like, normal type, this is a non-null-able type.
And, this says it's a null-able type.
It means that if you are calling something on a non-null-able
type, you can call whatever you want, plus whatever.
And, if you call something on a null-able type,
Kotlin will say, oh, it was saying something,
and now it doesn't say it. Yes, because plus is smart.
Plus knows how to operate on, like, null-able types.
But, let's do something that is not safe.
Which is, it's also very smart. The library is too smart for
me. Empty.
Reversed? Yeah, finally, thanks.
And, it tells you, hey, you know, this might be null-able,
so please don't call it like this, because there is a chance
you might encounter a null pointer at runtime.
And, yeah, you should take care. And, well, afterwards,
it's quite easy. You can do,
OK, this stuff. I mean, if you have been doing
groovy or, I think, Scala does it too.
But, the compiler tells you, you should be careful about this.
So, and it's, again, it's backed into the language.
So, like, for every type, there are like two real types,
one that might be null-able, the other might not be null-able.
The good thing with, I will show you afterwards,
one you can write extension function that work on null-able
type, which is really, really crazy.
Good. So, second stuff,
better.
The utils classes.
Who has not written a single unit utils classes in their
life? Nobody.
So, even people younger than 30 have written them.
In general, there might be a divide because, like,
yeah, all their developers have written them,
the younger ones, they are smart enough to use the library.
But, the thing is, well, at our age there was no library.
So, basically, we say that Java is in the object-oriented
language, and then we put everything in a class,
we put static methods in a class, and we pretend that it's
object-oriented. Right?
Yes. Well, let's not pretend it's
object-oriented. If it's no object,
a class with static methods is not object-oriented.
So, here I have created my amazing string-utils class.
And, of course, I need to remember because the users of
my class, well, they might instantiate it.
So, I will just remove the constructor, make it private,
again, very object-oriented, and then I create these
capitalized stuff, and I do whatever I want,
and then I can call the capitalized method.
Good. Scala and Kotlin have,
I think, like, similar stuff.
Let's not pretend we are an object-oriented language.
We can just add methods in states, but mostly methods,
on existing classes. That's crazy.
Yeah. Of course, at the bytecode level,
it boils down to a static method.
That's not the problem. The problem is the user
experience, the developer experience.
We can see now that we are really doing here,
we actually are doing object-oriented development.
So, through these functional stuff,
because here we create a function that is at the root
level, we are able to write better object-oriented
code, which is mind-blowing.
Even better, as I mentioned, we can say,
hey, this only applies so here we can have for f of type string
might be null, so this is a nullable type,
and here we cannot say f.capitalize because it's
null, right? It's a nullable type.
Here it only applies to real strings,
but we can do something like this.
We can say, hey, it might be a nullable type,
and we can check if this equals null,
then we return the default, which might be an empty string.
Yeah, I see like, what the hell?
And in the end, that's a static method,
but how you call it is like object-oriented,
which, in my opinion, makes Kotlin much more object-oriented
than Java will ever be. Well, will ever be,
no, I'm not sure. Let's see what we have in the
future. So, that's already good stuff.
And then, oof, Rayfied generics, right?
Who has been bitten by the lack of Rayfied generics already?
Yeah, so I have a collection of thingy and a collection of
foo, and well, at one time you have nothing.
So, the trick when you do Java is to pass the class.
So, here is taken from Spring, when you get a bean,
you say, hey, I want a bean of class whatever,
and then you will get the whatever.
Okay? How can we do it in Kotlin?
Kotlin has this Rayfied T.
When you call a get bean, you can pass the type that you
want, and it will get you, but it's a string.
If we are a bit, like, tricky, we can do this,
and it's a list of strings.
And if you tell it, because it's all about compiling,
because in the end, of course, the byte code is still the
same. The byte code must be compatible
with Java byte code. There is no Rayfied generic in
the byte code. So, it's just about compiling.
And here we can say either we set it here in the signature
when we call it, or we tell that type of,
that S is of type string, and we will get a string.
And I think that's pretty amazing.
The only thing that we need to do is do this.
We need to tell it's Rayfied. Sorry.
Again, we need to tell it's Rayfied, and for Rayfied,
you need to have inline. Why?
Because as I mentioned, there is no trick.
At compile time, it will actually replace the code.
It won't be a call. It will be just copy-pasted.
And so it knows which type you are.
And in the end, so I still have a bit of time,
we can do, like, really, really fun stuff.
I will, yes, fun stuff.
OK. I will create a function beans,
and for the moment, I will return any.
OK? So, some syntactic sugar,
I don't think it's really important.
I don't think it makes me want to use Kotlin.
I don't think you need to use it,
like, either you return the type like this,
or here any idiot can understand it returns any.
So the Kotlin compiler is not an idiot,
but the Java compiler is.
It doesn't make any sense to specify the type explicitly
every time, but still the Java compiler
requires you to do it. It makes no sense.
OK.
Sure, sure. If for whatever reason,
if for whatever reason you want to specify what it is,
because it might be complex, but then if it's complex,
perhaps it doesn't belong to a liner,
then you can still have loads, too.
Especially if you are using, if you return a concrete
implementation and you want your signature to be an interface.
That's perfect. OK.
And now I will have a class which I will call,
let's say, beans DSL.
OK. Here I want this to return beans DSL.
OK. So now I can write something like this.
I can have a main function, main, main, OK.
Private static void main, OK.
And I can call the beans function, beans function.
Great. Nothing mind-blowing.
Now what I can do is I want to write something like this.
OK. So I want to write something like this.
I will just use the compiler, OK.
So I create, here I accept a parameter that takes nothing
and returns units.
Here what I can do is normally I would write something like this.
But in Kotlin, if the loss argument is a lambda,
you can move it outside the parenthesis.
So that's what I did before.
And then here if there is no arguments and there is a lambda,
I can remove the parenthesis.
Good. Now I can add the bean method inside.
And I can say that I can actually call the bean method on the
bean DSL.
So here I can do something like this.
And what is it telling me?
And resolve method beans.
So I still have an issue.
Yes.
Little trick.
Yeah.
Sorry, that's live coding completely.
I thought I would be less fast.
OK.
And now we can say that the bean method is generic, right?
So we can say it accepts a type T.
And I don't remember how it's written.
So I will be doing my stupid stuff.
So this is the inline function.
So here inline fun.
Refi T.
Here and it returns a T.
And if you continue like this, you can have this kind of stuff.
So here this is the spring boot Kotlin DSL.
So you say this will create beans.
And then you can define either through lambda or directly.
And through the refit stuff, here you see the product handler
actually requires two dependencies.
And at compile time, it knows that it requires,
I don't know, a foo and a bor.
So because those ref methods are refit for generics,
it knows it needs to call the ref method calling,
getting a foo and a bor.
And it will inject them.
So here you have the magic at compile time.
And at runtime, it's the usual spring boot stuff.
And I believe it makes my code much easier to read.
Of course, you need to understand the trick.
It's like every time you need to be very explicit in the beginning
because you like a lot of context.
When you have the context, then it makes your stuff
much, much easier.
And that's all.
I don't want to bore you with more details.
You can follow me on Twitter.
You can follow me on masterdom because, well,
you don't know what will happen to Twitter.
And though the talk was not about Apache API 6,
you can check Apache API 6, which makes my job so much
easier.
And I can come back here to talk about unrelated stuff.
Is there any time for questions?
There is.
Thanks.