I completely hated these technologies initially.
Java seems large, low 30. The way cloud native development
was going, it was clear that the direction Java was taking was
just not compatible with this new feature.
There was a strong concern that the Java would still be alive in
10 years about. Java back then people associated
as a heavyweight. Has Java become a valid choice
for like cloud native application?
We do have a quarkless version for serverless.
It starts in milliseconds. How do you compare Java now with
my modern programming languages Rasco?
What are still some of the strengths that Java has that
people should consider? They honestly think Java is in a
very very good position. People maybe don't realize it,
right? At the moment, if you're still
active in the hibernate, how many contributors are there?
We just changed the license of Hibernatorium.
We had to contact every single contributor ever that made some
meaningful contribution for projects.
It's like more than 2000 contributors.
There's such thing as politics in open source project.
I think there is, but there certainly are strong opinions.
Many programming languages now support some kind of ORM
library. Some people like it, some people
really hate it. What is your opinion?
There are lots of hybrid haters, right?
There is a large group of people that sadly have been both hybrid
at the wrong way. And then of course, there is a
category of people that's. ORM widely adopted.
When do you think it's not the right time to use like ORM or
Hymony? I might be biased.
I would always start from. Hello guys.
I think this is our first time having technical journal
recording, in person podcast recording.
So as the first honorary guest, we have Sunny in this studio
today. Sunny is a long time open source
contributor with Hibernate, Quakers and an infinite Span, so
many projects. He has been a long timer in Red
Hat as well, probably about 16 years.
And he is travelling to Singapore.
So we had a good chance to actually speak to him and ask
him about his journey. So welcome to this first in
person podcast recording, right Sunny in the beginning.
I always love to invite my guests to maybe share a little
bit about your career, especially turning points that
you think we can learn from you. Yeah, yeah, fantastic.
So when I was at university, I was in, in Italy finishing my
studies and I once, you know, professors had, they would
assign students to some practical jobs as well at the
end of that. And so I got involved into a
big, very large Java project, which was using a Java
enterprise at the time deploying on Jboss.
I completely hated these technologies initially.
Like it was like, oh, Java seems large, bloated.
It takes ages to deploy something and get feedback like
I'm on the right path. Of course, everything was new to
me. And so the fact that to to know
that some code that was actually going to work as expected needed
to go through this entire cycle of deployment, that was painful.
So very quickly I put down scripts to deploy this faster on
the application server and you know, to, to do all these kind
of things and you realise it's open source and you can read it.
So you Start learning a lot about the platform and how to
work better with it. And well, that project, it went
from being extremely large and slow and complicated to
something that I really like doing.
And so very quickly I was, I became from being like the
junior guy that Barry knew some Java to actually lead the
project. And then well, there was a bit
of a competition, like a Red Hat was looking for interesting use
cases to share to their customers.
And so I wrote down what we had done with the project and we won
an innovation award. So they sent me to Orlando to
get this award. It was a bit weird because I was
like very young and suddenly and they are between all the, you
know, these guys that are my heroes.
Like these are like the Java developers that actually created
these technologies. But they were all like very like
level where they they would, they were interested to hear my
about my experience and then also about the problems that I
had. And then, you know, they
immediately started brainstorming with me, Oh, how
can we fix these things? Right?
Yeah, that that was like an amazing impression for me.
So then I immediately knew like, oh, OK, these projects are
really amazing. Like they're being used so many
places. They're solving so many problems
and they have ideas that are evaluated there.
Like they want to to hear about those and they also want me to
fix them. Say innovation award, what kind
of project that you actually built back then?
Yeah, That was a library management system for the
Italian government. It was a very complicated, big
project. So it starts from like the basic
things like people need to loan a book and so, you know, you
need to just record who was the person that took a certain book
and it brings it home. But it was also like the central
catalog for the national system. So if somebody wrote a new book,
it needs to be assigned an ESBN code.
And there is a whole official process behind.
And so, yeah, the complexity of the thing was, you know, much
higher than what you would expect if somebody is not
working that domain. So we had something like 1200
different database tables. And I remember, you know,
statistics that I had to write for this paper for the award,
like we had more than 2000 different web pages.
You know, this was all running at the time on Jboss application
server, Hibernate, Hibernate Search, that was a key project
from my career because Hibernate Search had just been pretty much
created as a prototype by Emmanuel Bernard, who's a big
friend of mine and became my mentor later.
So it was like a prototype. He was doing some of the
essential things which were like absolutely key for my project.
Like we would not have succeeded in doing anything if Hybrid
Search had not existed there. But at the same time it was
missing some things which are absolutely critical for us.
So really for my project to succeed, it was essential for us
when we were working on this library system that we
implemented these missing features.
And then of course at some point I promised them I know I would
open source that components and push them to Hypernet Search.
So you mentioned you met some of your Java heroes, right?
So can you? Yes.
Who are some of your heroes? Oh, back then, yeah.
I mean, I have lots of heroes today.
So, yeah, when when I when I arrived at Orlando, I was very
keen to meet some of them. I I remember.
Yeah, Emmanuel, of course, was there.
Bellaban, he was, he still is today, the leader of the Jacobs
project. I think I met him there.
I might confuse some events now. There was Andy Miller.
He was director for the performance team at JBOS.
And one of the big problems we had with our system was of
course, making sure that the system would perform at the
level that the customer was expecting.
It initially did not at all. We had made lots of mistakes and
I had to learn really quickly again as a, you know, complete a
junior person facing Java for the first time about profiling
tools and hold what's behind that.
So when I get there and I see presentations from this person,
which is giving me a lot of clarifications, a lot of really
good hints, pretty much for free.
Like these conferences are amazing.
They're just, they're to just honest sharing of knowledge for
just very, very good. So yeah, after that, I, I go
back to Italy with a lot of new knowledge, a lot of new friends,
a lot of network promises of contributions back.
But I wasn't working for Red Hat, right?
I was working for these other companies and well, I realized
that I actually know a lot of things about Hibernate itself.
And you know, all these things I'm doing with Hibernate Search,
they needed to dive really deep and understand things more as a
framework implemented and as a as a user.
So I quickly started with a career in consulting.
That was a good career acceleration.
I've been working in banks. I was like a lead architect for
like a technology choices in one of the major Italian banks I
worked at for, for Sourcesense, which was very cool, very small,
very selective company in Italy about they wanted to have like
the brightest minds in the open source ecosystem and you know,
sell premium expertise as consultants.
I did that just a year. Like I, I started like very,
very loving this group, but then I had to work often in a bank
which they really valued us. But at the same time, this bank
had the firewall and from within we could not use Internet,
completely not allowed. And you know, they're big, very
legacy, big systems complicated. They would come to me like I was
a guru of these things and ask me questions that I needed to do
more research. And so, you know, you would need
to do that at home and then research and then go back.
So I also like disappeared from this network from the open
source world because I was always firewalled out of the
rest of the world. And the Hibernate team was
missing me. Like they were like, oh son,
where, where are you? And so I explained the situation
and then they said, well, why don't you come work for us full
time? And so, you know, that was very
interesting for for me, like, oh, I could join these people
and work with them. And so I accepted that
immediately. Yeah, since we're talking about
careers here, I did a big mistake there as well.
I I was so keen to join them that they actually took a
massive packet. And I thought, well, you know,
it doesn't matter. I really want to, you know, I
would work for three years. We'll, you know, we'll address
that later. And it wasn't dressed later.
Like I clearly, I mean, that put me very low in the ladder there.
And then I realized I was a bit more senior than that.
So it was fixed. But it has been fixed very
slowly over the years. Because of course, once you are
inside a big company, there are all kinds of rules like I can't
hear, just hear double your salary overnight today.
Oh, we need to do this 5% here and 5% over there.
So it took some time and yeah, thinking in retrospect, I
probably, you know, they didn't have the budget at that moment.
I probably could have said, well, let's talk in two months,
you know, and that would have been better for everybody.
But yeah, I was so keen to join them and learn more and just
work full time on those projects.
But I I said, well, let's do that.
And maybe that was a good thing. So I think one unique thing that
you just shared with us, right, you contributed to open source
since very early in your career, right?
Since you know, maybe you won the award and you got into
Hibernate, Hibernate Search, maybe you kind of Ditto a bit to
like banks and all that. But you have always been
contributing in the open source, which I find maybe for some
people it's rare because they think you might need experience,
understand a little bit of fundamentals and technical
details before you can contribute to open source.
So maybe can you share a little bit back then?
Do you find it challenging as a youngster, you know,
contributing to a big open source, you know, like Hibernate
and all that? Or do you actually find it's
actually useful for your career? Oh, it definitely was useful for
my career and it was challenging, but it wasn't that
early in my career to premise like I had been studying a
university degree, which is in Italy.
It's like it's called like the old system.
So university degrees were far longer, so they would go much
deeper and I was busy with that. So it was a kind of advanced
course, right? So many of the fundamentals were
kind of note to me. Java, I was not a professional
in the Java space, of course, because universities, they don't
really teach you the practical ways of things like, so for
example, making a library, that's something that I would
have never seen. And I think it was a library
like something that on the side. So that was new to me or like a
build systems, right? You would not really use those
in like university systems. But I, since I was working also
the in source science and in this other contractor positions,
I had been exposed also to agile practitioners, extreme
programming practitioners and participated in these
communities. And I had some really good
mentors as well helped me. So I was becoming really quickly
familiar with these projects and then and only then this open
source things happened. Right.
If I look back at my career back then, actually Hibernate was
kind of like released early in my career.
To me back then, it was like a revelation.
You know, usually we wrote like, I don't know, like JDBC driver,
plain sequel, then come ibatis, Mybatis, right?
And then Hibernate came, became like the de facto ORM.
So to me, that was like magical, right?
Oh, what do you mean? You can write just plain simple
Java object and you can translate to SQL queries just by
itself. I mean, back then it was like
magical, right? So having been in that project
for that long, right, What is the state of this Hibernate
project now? Is ORM widely adopted?
Is it like the standard practice for Java developers these days?
So tell us maybe a little bit more insight.
So it's a great question. We do have download statistics
and it's doing incredibly well. Like we are in the dozens of
millions of downloads per month. Problem is we don't know what
people do with it. So for all I know, it might be 1
script somewhere that's Downing it a million times per day.
Good here in practice we do know of course via read that we have
customers that we know they're using it because they open
support tickets, they ask questions, they ask
clarifications, they ask for like road map plans, they
suggest features. So we know there is a, a lot of
activity there. We are not the first line of
support, but there are like 3 lines.
So there is lots of people answering, you know the the most
common questions they they don't want to bother us.
And there is a second line of people more expert for the more
difficult questions. And only the maximum escalation
level comes to our team direct, right?
So even there, we struggle getting a bit of feedback from
the front, let's say, but just looking at the sizes and it
starts there. We do know it's heavily used,
right? And then there are community
report researchers that try to get a bit of a breakdown of what
community happening from those. It seems that the S Hibernate is
very widely used and it has an extremely large market share
noise. They're always a bit biased.
You know, each of these vendors, they ask their community, their
section. So it's a bit difficult to have
the full picture or even like what's the error range in this
measurements. But we're very confident that's
pretty much every Java developer has heard of it, you know, or
used it at least once in some projects.
I guess that also depends because back then, right, I must
admit I have left Java world for, I don't know, maybe 10
years or maybe around that time by now, right?
So back then, like Spring Boot was the kind of like the main
framework for us to build any kind of application.
It could be recipe and micro service, whatever that is,
right? And Spring Boot by default
package Hibernate as their GPA of choice or something like
that, right? Maybe that could also be the
driver for, you know, the number of downloads because every time
you build Spring Boot apps it downloads those kind of stuff.
Yeah, we like Spring. The the Spring group is a bit of
a competition to Jboss and Red dot, but they're also like big
friends in the way that you know the they understand that Spring
wouldn't be as useful without Hibernate and we totally
understand that Hibernate wouldn't be as popular without
Spring, right. So there is very respectful back
channel communications between them.
I am a little bit sad that sometimes by how they advertise
some things. And one problem that we have in
the relation is that like we are allowed, it's even in our
employment contract, we are allowed to contribute to any
open source project ever when we want to.
We don't have to ask for permission.
It's clarified like this in the contract.
It doesn't matter which project it is.
It can even be a competitors project.
Other engineers are not that fortunate.
We we understand that. So there there is a bit of this
sad thing that I know the Spring team sometimes would like us to
make some changes. And it's always a bit of a
difficult conversation because they can send patches.
It's not allowed for them. And then, you know, for us, it's
a bit tricky to understand what exactly you mean.
And some members of the Hibernate team, they really
struggle with that kind of relation.
And therefore, you know, sometimes there is a bit of
tension there. But yeah, overall, I think there
is a strong sense of mutual respect.
And of course there is Quarkus, which is a challenger to string
boot. That makes things even more
interesting. I was in the initial group
that's created Quarkus. And so actually one of the
things we were using as a like a key thing like can this whole
technology work was like the proof was like, can you get
Hibernate to work in this very special way that's Quarkus does?
The idea was like we wanted to have Grau VM to support Grau VM
properly. Gravel VM at the time had a lot
of limitations. Many of those have been, you
know softened or resolved nowadays.
But at the time the list of limitations was really daunting.
And among them pretty much in this list of limitations
Hibernate would do all of them. So I was tasked we can you try
to make Hibernate work on Gravel VM.
And my mentors, Jason Green and Emmanuel, they were very keen
about you need to make it happen.
It's really important for the entire Java world, the entire
Java ecosystem, and I'll get back to that, why we thought
that was the case. So they were saying to me, OK,
maybe some of the features of Hibernate cannot work in native,
remove them like they were thinking or suggesting to me
create something new which would like have the role of Hibernate
in this new world but may be different.
And we were like what about like JPA the spec right and things.
Now. The situation was a bit dire
like so we do have, we give a lot of importance to the spec,
but at the same time the way cloud native development was
going, it was clear that the way the direction Java was taking
was just not compatible with this new feature.
And so there was a bit of a strong concern that the Java
would still be alive in 10 years.
And then we were really thinking that, OK, if the current Java
enterprise specs are not fit for the purpose, maybe we should
propose a new set of specifications.
So my task initially was actually like write down what
you would think should be something that we were calling
like JPL Light. That was the idea.
And you have to identify which things that Hibernate is doing
today we can do in this JPA light and which things you need
to leave behind in interest of making things happen in the, in
the Gallian world. So I start working on that.
And this list is very long and the amount of complexities we
have, it is very daunting. You know, I'm thinking I'm
showering a lot and going back and, and at some point I have
this, you reckon moment, which was really like a brilliant,
like I, I just twist around the thing a little bit.
And then I, I wrote this e-mail to my colleagues saying, look,
if we boot the entire framework in this particular way, I have
no limitation whatsoever. Like we, we solve all the
problems that Grav VM is offering.
And so there is no need for any specification, right?
So that was a very nice breakthrough.
Of course, this was all theory. And then, you know, we start
prototyping those things and well, these prototypes are all
in GitHub. And so people can have a look
now. It's pretty much if you check
out the work with source codes. And you sort them by date and
you go in the very early things, you'll see some scripts and
scribbles and really terrible code that I wrote at a time,
which have nothing to do with what resist today.
Well, there were other colleagues working on other
aspects to make a new generation framework, but I was focusing on
this thing of like, do we need a new spec?
Is GPA fit for the future in the the gravel VM space?
Right. And that was resolved this way,
but it the way I was resolving this was extremely specific for
Hibernate. I mean, this was a good
breakthrough because if we had solved these workarounds for
Hibernate which had all of these limitations, then it was
probably going to be easy to apply the same ideas to all the
other frameworks which have simpler use of the JVM strategy.
Maybe for the benefit of some of us which don't know the details
in like what are some of the biggest limitations that you see
Gravel VM is not able to run Hibernate or maybe most of the
Java frameworks back then. What are some of the biggest
hurdles for you and how did you actually solve that by inventing
walkers? OK, well, I wasn't alone in
inventing Quackos, right? I was focusing from this aspect.
Yeah, for example, Gravel VM, the entire code base needs to be
known at build time. That means also like that the
bytecode is not changing. So no bytecode manipulation, no
generation of bytecode at runtime.
And also like no reflective invocations either.
It needs to do reflective calls now since many years already we
tried to not use reflection on runtime because it used to be
quite inefficient in the JVM. It's better optimized nowadays
in the JVM, but still we try to avoid it.
I mean we already implemented the all the schemes to avoid it,
so it's better that way. But at least during the
bootstrap, we need to know your entity, which properties they
have, what's their name, what's their type, and which classes
actually have under certain annotations, right?
So all of that goes pretty much via the JDK standard reflection
API, at least it used to. And the reflection doesn't work
at all in ATV unless you specifically tell the compiler,
hey sorry, there is like an additional resource file that
you can type in in if it's Jason.
Now I forgot I I haven't written one of these resource files in
years. But you can give a lot of input
to the diagram compiler to tell it oh at runtime.
This method might need to have like a reflective access.
This type needs to have a reflective construction.
This other type might need to be serializable.
You need to be thorough in listing all the cases otherwise
it's going to fail. Resource loading wouldn't work
unless you register IT. Service loading doesn't work
unless you register the type that's going to be loaded.
And well, we do all of these things in Hibernate and in many
other frameworks, right? Yeah.
Now the key was really like the Gaussian compiler is a Java
process and it is triggering initialization of the constants
in your code. So what I did was really like,
oh, it means that if I with my main class and I do like public
static final session factory and I initialize Hibernate in a
constant, the LVM compiler is going to initialize the entire
Hibernate in this constant. And it did.
So it's booted entire Hibernate in there.
And now there are some problems with that.
First off, you don't want it to actually connect to the database
because you're building the application.
Your database is maybe not even reachable from this environment.
Or well, you certainly don't want it to connect even if it's
reachable, right? Because you're building.
So yeah, I started patching Hibernate in a bit of a private
branch, you know, we want to do real quick, like what happens if
I delete this stuff and nobody cares?
So lots of patches in there. So I just make sure that the
life cycle of the booting phase is pretty much split between two
phases, building the entire model, discovering, doing the
reflection work and all that. And then actually, you know,
connecting to the database and doing the fix.
This was complicated because the boot strap is very cyclic, very
unstructured. It's, well, it is structured,
but it's designed in an era in which this separation was not an
objective at all. Now the trick here is that all
of these reflection and all of these work in annotation,
scanning and configuration parsing and all of it.
It's happening when the compiler is running.
Now the compiler happens to be a valid JVM.
Grove VM is written in Java. So this processing which is
running and defining the constants, all these operations
that are not valid after being compiled are valid during the
compilation. So all of these limitations,
suddenly we're not applying. I just needed to make sure that
we would not use any of those things at runtime.
Of course we would still use some of those things at runtime,
but it's really reduced the set to something that was manageable
short time. For example, Hibernate, if you
use bytecode enhancement on entities, it will not need a
reflective call on objects except the constructor, I
believe. But still, I guess.
But if you do the bytecode, you know, if you don't do bytecode
enhancement, then a lot of reflection is happening.
So, you know, very quickly we decided, well, bytecode
enhancement is mandatory. We don't even ask people to use
it. It's just something the
framework does for you during the build.
So it's it's simpler and it's also simpler for us because one
problem Hibernate had over the years is lots of configuration
properties, lots of even in the engine possibilities like do we
need to handle the entity as a manager?
Do we need to handle, Has it been enhanced with which
capabilities? And so for us, even like
reducing the things that we actually need to support also
helps us to increase the quality of the.
Current, right, I think 1 aspect about Java back then, right?
It used to be very people associated as a heavyweight, you
know, whenever you run Java applications.
Plus, yeah, when you boot it takes a while, maybe seconds and
it depends on your project. If it gets bigger then it might
take even up to a minute I would say.
Now with all these inventions like Quarkus and maybe Grau VM
itself and maybe other projects that I'm not aware of, has Java
become a valid choice for like cloud native application?
Think of it like a function as a service, you know where you need
to boot up really fast and react to certain events.
Has it reached that stage yet? I think it did, yes.
It's absolutely in that category.
Like we do have a Quark Goes version for serverless.
It starts in milliseconds, so people can really decide if they
want to go into that direction. Actually, the beauty of it is
that you don't have to decide in which direction you're going
upfront. You're not going to choose a
framework because you're going serverless.
You're building your code and then you can deploy the same
application easily. You can change it to in ordering
the in the build property saying, well, I want to build
this as a serverless function, right?
And then maybe you realize, you know with the the load on this
serverless thing is getting higher and higher.
You're better off if this was like a regular Java application.
It's just a matter of changing the configuration property of
the system. Or maybe you want, you know, you
are getting like very low load occasionally, but it's more
convenient for you to run it as a native image and you just
can't compile the same application to native.
What I really like is this flexibility that you don't have
to decide upfront, like you're not going to use Quarkus because
you need native. You're going to use Quarkus
because you want to write in Java.
And what's coming after that, well, depends on the needs of
the day. And you know, requirements
change often and agility is quite important nowadays.
Helps to keep the cost low to adapt really quickly.
Right. I mean, Quacus itself solves
almost kind of like similar problem to Spring Boot, right?
Like it helps people to bootstrap like create new
applications faster. And there are a lot of, you
know, niceties, you know, other generation and things like that,
I guess. So tell us why we should use
probably Quacus versus Spring Boot.
And I know that for some people this is probably common
question. So I think we are at the stage
in which the majority of German workers have experience with
Spring Boot. So one thing that we really took
a lot of care of is to make it really easy for somebody that's
has experience with Spring Boot to move to Quarcos.
There is a book by Eric Tandrea about it's called I believe
Quarcos for Spring developers. And the book is free.
You can just Google it. You can download the PDF for
free like or you can also buy a paper copy if you want it sent.
But essentially you can get the PDF for free.
It is really easy because you know, they're built on very
similar technologies like if you have say a very large complex
hybrid model, I mean, they're running the same hybrid and
they're probably running the same version of hybrid, right?
So, right, that's a piece of cake right Now there are some AP
is in Spring. Say you're using a Spring Data
JPI, right? I don't like it, but that's
personal, right? It's my totally be fitting for
your project. Now we do have a Spring Data JPI
in corpus. It's probably not perfect
because when you're replacing implementation from A to B,
there might be some imperfection, but it will
definitely help people to migrate from one to the other.
And basically they're built on the same, similar standards
like. So if you're using like the JPA
spec or even if you're just using JDBC Servlets, JAXA, RES,
you're using JAXA, you want to, you know, use Kafka Connect,
Elastic Search, it will be all be pretty very, very, very
similar, much pretty much the same in many cases, same code.
So that's very easy. Now, why would you use Quarkus?
So there are lots of very good reasons.
First off is, well, the developer Joy is fantastic.
Developer Joy is for our framework of reference, but it
means several things like that. Pretty much.
We make your productivity very high.
The feedback loop is really short and that makes people
happy. Essentially the main feature is
the life reloading capability. We do aim at any change making
the code when you are in dev mode is reflected in your
running system 100 and 100 milliseconds.
That means that you're, you change a method, you refresh
your browser and you immediately see if you're on the right path.
You made a mistake like I did a demo this morning and I forgot
to change some path if in the rest endpoint and you know, then
I had a duplicated path because I made my change by copying a
block and then making a change. And then, you know, I refresh
the browser, I get an error in the browser saying me what I had
done wrong. OK, so I flip back to focus,
change the thing, refresh and now I'm fine.
These kind of errors since I get immediate feedback and I'm still
focused on. I just created the method.
It's creates a much lower cognitive load, right?
So I'm not frustrated because an error happened because I'm still
in the flow. I have not been distracted.
And then I know I just keep going with my things.
So I'm happy because I'm very productive and I'm learning and
I'm constantly getting feedback that I'm on the right path.
Speaking of feedback on the right path, we have something
called continuous testing. So while you're working, you can
have continuous testing running, which is pretty much like it's
running the unit tests loop really quickly.
And while you're coding, you might see, but now this test is
red. This is immediate, right?
And there are some interesting techniques in there so that it
actually knows how to prioritize which test to run, which are
related to the code you modified, right?
The other thing is dev services. So if you want to start
developing say a new application, which is like
Hibernate connected to Postgres and maybe elastic searches in
Hibernate Search and maybe finished band as an external
cache. Now you start having many
external components. Now as a developer, it quickly,
you know, becomes, oh, OK, I'll spend my morning installing all
these systems in quad Cos you don't have to install anything
about your starting. It knows, OK, you have the
Postgres extension, you have Hibernate.
This implies you're going to need Postgres.
So it will behind the scenes, it will use those containers, fetch
Postgres instance, start a Postgres instance behind the
scenes for you. And you don't even have to
provide the connection properties because those are
being provided and injected into the running dev mode.
So you can quickly start working on your model and immediately
get refresh. You know, you just refresh the
application and see the schema evolving as you're evolving the
model. Or you know, in the other
direction with depending what's your cup of tea.
But the flow goes really fast and you you're not wasting time.
Boring things, weren't it? I, I really believe that the
feedback loop, right, the shorter you can make it right?
And the developer joy, right? I still remember back then when
I did Java, right, whenever there's a class signature that I
need to change, it was like, oh man, I have to restart my
applications, wait for the booster.
And back then, when there was AJ Rebel, maybe you have heard
about it, that was also quite revolutionary, although it was
quite pricey back then for some of us, right?
But yeah, this thing that you mentioned, even though I haven't
used Quarkus, I really believe that it can make life really
simpler and more productive for developers.
Yeah, yeah, we, I remember at the time, yeah, Jerebel was very
interesting, but I think they had a big maintenance problem
because they had to know how each framework is going to
react. I needed to know how to, I
remember the conversation with them.
I was already known in the Hibernate community.
They wanted us to have some kind of stable API that we would
promise to never change over time so that they would know
where to hook. It was very useful, but it was
also extremely costly. You know, you know, Quark was
really takes a very innovative idea there, which is like since
it's so fast to boot, just reboot entire application over
time and it's very reassuring. It means you really have a clean
slate and this is really the output.
It's not, you know, it's something fancy because maybe
some of your tools is something strange.
But the state might be gone right if.
You the state is gone, but that encourages you to also work on
your import scripts and your setup scripts in the in the
right way, right? So you're constantly also
checking that those things are In Sync.
It actually leads you into the right touch.
So all along in your so-called career, right, maybe you dealt
mainly with Java technologies. I know like for some, I don't
know, youngsters, right, People who just came into software
engineering, maybe in the last 10 years or so, Java is
associated with like, oh, legacy heavyweight and now also like
the version changes so fast. So how do you compare, maybe
from your point of view, maybe a little bit biased, but how do
you compare Java now with like modern technology, like
programming languages, like maybe Rascal and even
TypeScript, right, Python. What are still some of the
strengths that Java has that people should consider?
Even though they're like youngsters, They want modern
technologies, Yeah. I honestly think Java is in a
very very good position. People maybe don't realize it
right? Because you know, depends who
you listen and what you get excited about.
But if you look at, you know, each of the languages you
mentioned, they all have like 1 strong suit and very weak in
other areas. While Java is maybe not top
leader in all of those areas, but it's very close to be
leading in all of those areas. It has been innovating quite
aggressively recently. Like I think the Oracle Stewarts
and including like the Reddit engineers also contributed some
the improvements there are are studying up the pace accelerated
and it's very interesting where it's headed.
Like now we're working on a project Leiden.
There are lots of interesting things happening in the open
GDK, but personally very interested in Project Leiden
because of the things that we do with Quark Quiz and how we also
integrate with it, right. So project Leiden is going to,
you know, they kind of realize from pressure and low VM
interesting people that it boots faster that the open JDK had the
problem in booting too slowly and they're addressing that.
It's improving very significantly with Leiden.
And so that's very interesting. Project Lily put is making it
consume less memory because it had this fame of being bloated
and all that. Honestly, the fame of being
bloated is very often coming from the frameworks that were
pretty much not designed to do things to boot fast because
nobody cared. The application was going to be
up for many, many months, and if it was taking some seconds more
when it would booting that was like a drop in the bucket and
completely meaningless. So these things are being
addressed now because people start to pay attention to them.
Now, of course, these these libraries, they're so widely
used and they're so large and feature full that it takes some
time to get there right. But we are getting there really
quickly. If you look into the Quark
space, like a very big complex Quarkus application with
thousand hybrid of entities can boot it under one second.
Wow, that's that's yeah, that's I'm very, very happy with that.
But we keep working on it. I have more ambitious targets
like we want to go in there like 203 hundred milliseconds of
space. And yeah, about other the other
languages. Well, Rust is really very
interesting, but more for the properties that it has, right?
We do believe that in terms of like achieving maximum
performance or maximum efficiency of the system, like
if you really want to handle a very, very high load, Java is
the way to go. It's came really.
There are so many clever things happening in the JVM in Grove
VM. The combination of these things,
the combination with quarkless things that we're exploring are
really pushing the throughputs to very, very high levels.
And we do compete and we do benchmark ourselves also with
benchmarks in other languages, because work is significantly
faster than any other Java framework around there.
So it's not fun. The challenge really is like, is
this design perfect? Like can this go any faster
today? To verify that I need to compare
myself with other languages including like Rust, assembly, C
We're getting really close to that level.
How about Kotlin? I mean is it like the default
language use or people still write in Java?
I see a lot of interest in Kotlin, but again, it depends on
which area you're looking. I have not intentionally avoid
Kotlin. I tried to learn it but I never
had any actual need. I I'm not a Kotlin professional
at all. Everything I do is in Java and I
don't feel the need for Kotlin. I don't know, time might tell,
but the impression really is that Kotlin and Ceylon, they
have been pushing the JVM to innovate, but many of the most
important things, they are now available in the JVM or they are
coming very soon in the JVM, right.
So this is kind of removing the need for people to go and earn
Scala cutling things, yeah. So let's maybe go back to the
Hibernate side, right? So ORM technologies, I mean,
many programming languages now support some kind of ORM
libraries. Some people like it because
maybe they can write some, you know, database related
applications fast. Some people really hate it.
So from someone who is like a common dinner of Hibernate, what
is your opinion? Yeah, we we had to have a thick
skin because yeah, there, there are lots of Hibernate haters,
right. And there are two categories I
think of Hibernate haters. Generally there is a large group
of people that sadly have been both Hibernate the wrong way and
I am trying to address that. It's difficult because knowledge
propagates online without getting, you know, I'd have no
control of those things, right? We, we might have some authority
say, hey, I work on Hibernate, but still, if somebody publishes
a book and it's completely wrong, I, I can't go to the
editor and say, you have to withdraw this from the market,
right? And somebody purchased a blog, I
can't go to Google and say, you need to delist this because I
don't agree with its content, right?
That's not how it works. And then of course, there is a
category of people that they have been imposed that you use,
you have to use Hibernate for these projects when it made no
sense, right? This is something that we also
fight for. Hibernate is not something that
should be used in every situation.
There are some situations in which is really under the right
tool, but still it gets imposed as a standard by in some places,
right? And of course, if you are a
smart developer and you understand that this is being
imposed to you and it is the wrong tool, you know you're not
going to have a good relation with the tool.
When do you think it's not the right time to use like ORM or
Hibernate? Well, I might be biased.
I would always start from an ORAM, or at least in most cases.
Of course, if you need to do a lot of operations inside a
database, maybe store procedures frowned upon, but in some cases
they are the right. I would always try to minimize
the the span of transactions. So if that implies that the
transaction gets extremely chatty over a wire that's a
problem, then it's not a good solution.
But in most cases, I would have in my system, I would have
Hibernate available. And then, you know, there are
many operations, many business operations, and some of them
would use Hibernate, some of them would not use Hibernate.
But it's important that people remember that Hibernate is an
ORAM, but it's also facilitating access to native SQL queries in
many ways and mapping results of native SQL queries.
One thing that was done recently, Hibernate had since a
very long time that had the stateless session, which is
important for some of these access patterns.
And well, recently the state of the session got to learn some
more love like some some more improvements in that area and
the documentation was improved a lot as well.
So a good user should understand when to use hybrid with the
stateful session, hybrid with the stateless session, or when
to just send these settings to the database.
I guess this also comes back to the design, right?
The design of your application, because it can be misused in a
way such that your entity class is used all over the places,
right? Maybe from the entry points of
the APIs you deal with the entity class straight away,
right? You propagate all this, you
know, so-called object chain all over the places and somehow
magically the transaction works. I guess that's when people
actually kind of like hate this ORM and especially if you have
like the n + 1 problem, those kind of stuff, right?
It tends to be very slow. I guess the design is important,
right? So you encapsulate the entity
for the right reason and don't propagate it all over the
places, don't expose attributes that you're not supposed to to
other parts of the, you know, other modules, I guess.
So maybe in your point of view, what kind of design pattern
maybe that people should think about?
Is it like the main driven design or is it like something
like the hexagonal pattern? Is there anything that you think
from your experience as well? Those patterns, they're all
fine, right? It's more like how people think
that the operation will work in a database that is important.
And then then there are lots of like Lord people give each other
which are actually unfounded, just a very simple one.
A lot of people still believe that an Hibernate entity needs
to implement Serializable. It's just not true.
It might need Serializable because you're using that same
object with other frameworks which require it, but Hibernate
doesn't care at all if it's serializable.
We never need that. And then, you know, they are
serializable and then they add the serial, your ID and you
know, they're adding lots of things in there, which I'm
thinking, well, fine, you can add it, but you're just, you
know, making your code less readable.
And then, you know, there are discussions, getters and sectors
rather than a field. Make it public.
You can do whatever is good for design your application.
I mean, it doesn't care. It can be a public field for all
we want. It can be a private field.
It doesn't matter. We'll we'll get access to it in
some way, right? And it doesn't really make any
change in the semantics of of what we do.
It's all the same. The equals and hashcode is a
very tricky one because people seem to think they have to
implement equals and hashcode on the entities.
In practice they don't. But if you implement it, there
is a very good chance you're getting it wrong.
So I would typically suggest that implement it please.
And why do I say you're getting it wrong?
Because it's an entity. Purpose of the entity is that
you change its state to represent changes that you want
to happen in the database. It means that you're changing
the state like you're going to change the hash code.
Now, the only reason for you to implement equals in hash code is
because you want to store this, say, in a hash set somewhere.
Again, Hibernate doesn't care about this, won't it?
If you implement it or not, it's totally fine.
But you might want to implement something in your entity because
you need it for some other reason.
Like you want to store this in a hash set.
But if you store things with multiple attributes in a hash
set, you're calling for trouble because that's how Java
collections work. So it's a bad idea for Java
collections. The only thing that's typically
stable in an entity is the primary key.
And I'm saying typically because if you just created the object
and you didn't store it yet, the primary key is not assigned
unless you assign them yourself. So one correct way in my
opinion, because of course might vary, but in my opinion, 1
correct way of implementing equals and hash code is to only
include ID, the primary key in your implementation.
But also to make sure that before you ever invoke those,
the ID gets assigned right, either by you or by the
framework. And then you start having these
kind of responsibilities and you know, if you just leave the
default, it's going to work. Now that you mentioned it, I
could still remember back then, right?
Equals hash code, we use ID auto generation, most of that.
I haven't choose the important properties or attributes.
Everything would be, you know, important for the entity class.
So going back to the open source world, right, You mentioned you
work in open source, but also get contracts like employed as
in like you contribute to open source for some people, like for
me, I haven't done it before. How does it like to work in an
open source? But it's kind of like paid.
To do that. So at the time, you mean?
Yeah, before I was employed by Red.
Yeah, yeah, Yeah, that was, that was very interesting.
Of course, good money, but also you spend some time in the
commercial aspect, things which I hated, but I would forget to
send invoices and then just thought I'd care about it and
then I would have no money. But you know, if you do it
properly and you are disciplined with the commercial part, I
think that would be a very good career, right.
But you need a network, right. You need to be somebody that's
actually an expert, right? So to be an actual expert, you
need to spend time contributing those things.
So I think a model that would work really well for an open
source contractor is somebody that charges a premium because
so to some important customer, because he's actually an expert,
but also because he makes changes happen in open source
project, right? So the company might have a
particular issue, you are able to fix it and therefore you can
charge a premium, but then you also actually do fix it and make
sure that it gets merged. Now that is a bit tricky because
you know, you might think, well this is a solution going to push
it to the project and I'm done that you charge, right.
But there are the other members of the team might not agree with
that change. So there is that risk.
It means you nearly need to work or being pretty good, right?
Because you need to be persuasive to the other people
and you need to really make sure that it's a high standard good
quality work, right? So yeah, you might charge a
premium, but maybe you have been at a company just two days, but
you're going to spend 20 days making sure that that budget
gets. So please stop balance.
So at the moment, I mean if you're still active in the
Hibernate, because you are a technical lead, right, I assume,
how many contributors are there in this project?
I actually do know now because we just changed the license of
hibernator M, It has been since forever LGPL 2.1 with what we
call crosspot clarification. Now in Java, LGPL spare you the
details, but we decided at some point that it was, you know,
rather than having to have clarifications about what was
interpretation of the license to reassure people that it's fine,
it's open source, but it does not affect your code.
That was the concern for some companies.
Of course, not many companies because a lot of people use it,
but we did have some cases in which people have this rule.
You can't use Hibernate or you need to use.
You can use it, but the code needs to be compiled purely
against the JPIAPI is that you can't invoke Hibernate code to
clarify that it's easier to be Apache licensed by Apache
licensed version too. So we wanted to change to Apache
license version 2. This is actually one of the
first things I asked my colleagues when I joined many,
many years ago is wouldn't it be easier if we switched the
license? I remember they laughed at me
like, Oh yeah, maybe, but it's impossible.
We can't do it and why, why can't you do it?
Well, you need permission for contributors.
So now I really want to change the license because of all the
reasons we can get them later. But we had to contact every
single contributor ever that made some meaningful
contribution to the project. Key is meaningful, right?
Because otherwise we would never have finished.
But yeah, we had to go through it's like more than 2000
contributors. So we start sending requests to
the ones that contributed the most so that we didn't have to
review as much code. And then there is this long tail
of people that contributed maybe just one or two patches and
those who have been looking at 1 by 1 to see is this meaningful
from a legal link, copyright, intellectual property law point
of view. So you discard some of them and
then you start sending more emails and more emails and more
emails. And you know, eventually we got
permission from everybody. So now it's partially licensed
too. But that was that was big.
It's a very large community. That's pretty a lot, right?
2000 plus contributors And when you say meaningful, what do you
mean? Like how do you define
meaningful right? Yeah, the the tricky part was to
understand that it's meaningful in the context of intellectual
property and not from the point of view of software engineering.
So if you had for example, in the grammar, there is a piece
called this is like a string. It looks like a bit like a
regular expression. So imagine you have a regular
expression that's like page long.
Somebody added question mark. It's a very specific point to
fix an issue. You as a software engineer, you
look at that and well, you know, it's A1 character change.
At the same time, you know, it has probably hasn't been easy,
you know, to figure out that from the problem you had
distillate to a test and then eventually figure out that that
one character was missing precisely that point.
So a lot of work behind that patch, but from an intellectual
property point of view, it's just one character, doesn't
matter. On the other hand, if somebody
would fix something trivial, just a one liner in
implementation. But now a rule we have is every
contribution needs to be covered by a test of Congress for that
for future regressions so that you can say if it's fixed then
it will never happen again. So even if somebody would
contribute a fix, which is one line would ask, well, you had a
test for it and now the test would have an entity.
The entity needs to have a name. So somebody would just have a
person. Somebody would say animal,
somebody would come up with something new.
There's creativity in that that is meaningful.
Wow. Even if it's a very trivial
test, which is probably copied like the the same template and
the same pattern for many, many other things.
So you need to understand this difference.
When you mention about that, I mean, it reminded me with all
this AI now, right? Because somebody could generate
tests very easily with AI and now this becomes blurry, right?
Is it meaningful because, you know, a machine actually
generated that? Like in your maybe open source
experience, have you seen a lot of increased contributors that
actually leverage AI? And what are the reactions of
the core open source community towards, you know, AI?
Because on one hand, sometimes it works, right?
But most of the time also the design might not be optimal and
maybe italicinates a little bit. Or is it fringe some copyright
from some other libraries that it copies, like you don't know
from where? So how do you?
What's your take about all these?
It's very difficult to say if somebody use the eye, yeah.
So we do see an increase in contributions, but I mean,
Quarkus didn't exist six years ago and we have 1000
contributors in Quarkus nowadays.
So it's really skyrocketing the interest, but also the amount of
contributions in there, it's growing significantly.
I wouldn't know if it's AI, right?
I would guess there is very, very little AI there.
There might be some, but I, I suspect actually normally that's
my suspicion, right. But if I need to create a bash
script, which is say copying some things from one to the
other, I've seen that AI is very helpful with that because I'm a
little bit out of my territory. I know how to write mesh
scripts, but I don't remember some of the details.
So I need to like how is the equality sign again for
variables, integers, I don't remember those things.
So I use an AI for that. It helps me.
I can check, Oh yeah, that's what I needed to services some
memories and you try it out, works.
But when it comes to Java code, it never did the right thing.
Never. And I think it's because the
kind of work we do is always kind of novel in a particular
strange space, right? I'm not using Hibernate or
creating a new entity, which would potentially be a very
repetitive thing that requires maybe domain knowledge, right?
Maybe you are in a medical field, you know exactly what
kind of proteins you need to do here and therefore you you map
that and putting the annotation on there and the properties is a
boring thing that I can help you with.
The kind of puzzles we solve are a bit of a different league.
So you have worked with so many contributors, maybe tell us what
are your biggest challenges working in such a big, you know,
open source project? There was a time in which I
tried to follow all the discussions.
I no longer do that. It's, it's important to have
subgroups and a lot of trust in the other people.
So I know there are areas that are being watched by the
colleagues, friends, external contributors that I trust and I
really, really trust them. I also know that if they needed
me, they would come to me. And so I don't have to go and
read. That has been overwhelming.
That does work. I'm quite curious, is there such
thing as politics in open source project?
Because as you have numbers of people right, maybe some people
have a strong opinions, they gather influence.
Is there such a thing? Because I've never been involved
in such a big open source project.
I'm just wondering because this has to happen in any kind of big
organizations. I think there is.
I wouldn't say if it's politics, but there certainly are strong
opinions. Very often they come from
misunderstandings. But also, you know, some
discussions are happening in a chat maybe, and you are typing a
response before having read the other one.
People start interleaving things.
They go on a tangent, right? And then there is a significant
misunderstanding sometimes. And now if I, if you didn't
understand the problem and then I'm really sure that this is the
solution and the other person is like, you're an idiot, then that
that doesn't solve my problem at all, right?
So, yeah, these things, these things happen.
I've never seen people being intentionally going in the
wrong, you know, or trying to mislead others.
Like everybody's coming in very good faith, right?
And so when there is something, some tension growing, it's
always a misunderstanding. But also, you know, emotions,
though, they don't come across really well in written form.
Also, it's also for engineers, they might have a bit of empathy
problems. And it's extremely
international. So culturally, the expressions
might not translate really well or translate in a wrong way.
And then you know that amplifies some problems.
Right. So, yeah, I think I'm always
amazed, you know, like in open source project, especially with
this many contributors, people may not meet each other, right?
They may not know each other, but they can build like such a
good software, you know, like that works and serves more
people than just the contributors themselves, right?
It's always amazing for me and kind of like the pickup rate of
open source maybe in the past 20 years has been a lot, right?
Like so many companies these days will just adopt open
source. Before when I started my career,
it's always a problem, OK, you cannot use this open source.
You have to go through, I don't know, an enterprise architect
board to approve a certain version of open source.
But these days, I'm sure like almost all software engineers,
we'll just use open source because it's so big with this
and so made life so much easier, right?
So one aspect of open source that is becoming a challenge
these days about security. We have seen many threat actor
trying to be a contributor, make some changes that actually is,
you know, security threat. How do you actually identify
this detect and maybe protect your open source from such, you
know, threat actor? Yeah, that was certainly a wake
up call. We used to give say commit
access quite easily. Yeah, I wouldn't say too easily,
but if you had been around for let's say six months and done
some good work, I would give you commit access nowadays.
I am, I'm not saying I'm going to do a background check, but
kind of like I want to know what kind of person dealing with and
the whole, the whole life cycle and management of projects
changed a bit. Like in some projects, we really
just really restrict the permissions to the bare minimum.
This might seem a bit unfair and we're trying to compensate the
fairness now with, you know, a bit of an open governance that
is great writing down rules of like, how do you join the
project and what are the expectations?
It's not clearly written down, right?
So that there is a level of fairness.
It's difficult to write down those rules because you we need
to think about them. How, how does this work, right?
And it's kind of a novel territory there.
But yeah, there there was a time in which it would have been
fairly easy to get commit access.
But even then we always review each other's codes.
So the way you know, GitHub rules are set up, CIA set up,
and we really do expect that even if I may want to make a
change, like I said, the request tell somebody else is going to
review it and then it gets merged.
And there is a lot of automation there.
Some of my colleagues so they created a very nice framework to
create a GitHub bots so. Any time there is a need of
making changes there, there is new strip thingy starting and
helping. So it's kind of easy to also
enforce roles like this. Also with git, when I start my
work I fetch changes with look at them.
I might miss something for it. Yeah, that's the risk.
So, yeah, again, like these security issues really is very
hard and especially we have heard so many, especially maybe
in the JavaScript world, because when you pull package, you pull
maybe 10 or more dependencies. Sometimes it's just a small
library that you think it's insignificant, but it could be,
you know, changed by some hackers or whatever that is such
that you're using vulnerable libraries, right?
So I think, again, open source can be a threat sometimes,
especially these days. And I was having chat in some of
the episodes as well. Like when you create an
application, 90% of what you're running.
It's. Actually open source software.
So yeah, like you really don't know how come the code gets
generated that way, right? What kind of things that it does
on the background. So I think, yeah, maybe one
challenge there for people to actually also identify
vulnerabilities as you pull new versions or new changes in the.
In the yeah, well we're certainly looking at it much
more carefully. Like one thing we're working on
now is like a reproducible bills.
We want to make sure that the bills are reproducible.
That helps, you know certify origin of things.
It's going to be mandatory for red dot products and projects.
I believe it is already maybe sorry not very involved in those
areas, but there are certainly a lot of attention, right.
For example, anything like you know, Red dot supports product
versions of our projects and that's why they employ us.
They sponsor the project pretty much, right.
But what they do is like they do rebuild the entire thing in a
closed adapt environment before it's being sent to customers and
they have a lot of additional checks and controls at that
level. Of course, that happens after
our upstream work. So some things that we would
like to do really is to improve the upstream project as well.
It's not just responsibility of red dot, it's a responsibility
of how the open source project is set up.
And well, one of the things we're doing now is we're
actually donating the entire Hibernate code base and
intellectual property to an open source format.
This is literally to signal that this is not just red dots
responsibility, right? We do have many contributors
from other companies, especially like database vendors.
They really like that Hibernate supports all their exotic
features, including features of database versions that have not
been released yet. Initially those conversations
were a bit funny and like they wanted to pay us to implement
things that we weren't allowed to know about unless we signed
an NDA. And but we're not going to sign
an NDA with like Oracle or things like that when we're
employed forever. And it gets all very tricky.
So they all these other companies, they do stuff people
that work with us on fiber code base.
And we really want to make sure that that happens more
frequently. It's really nice for us and for
projects to have more companies involved in projects.
So for that, these projects are being donated to a common house
foundation, which is a very young new foundation.
We did explore like the Eclipse Foundation, the Abashi
Foundation. They're all fine and great for
some projects, particular projects.
But for a mature framework or mature library like Hibernate,
in which we already have our way of working our CIS, our system
being by getting in the Apache would have been problematic.
You need to migrate our ticket system, our mailing list, and
it's a lot of work. They also have a lot of other
rules that we don't necessarily like.
We have an established process which we think works fairly
well, like we have experience as well.
So common house gives us a bit more flexibility in that sense.
So yes, going to common house and yeah, we really hope that
that's triggers them more companies to not only contribute
but also steal it and lead it. This is all entirely in hands of
Red Hat engineers nowadays. Just totally fine.
But, you know, more diversity there would be really nice.
So if you are allowed right to talk about, so you've been in
Red Hat for like 16 years and throughout this time there's so
many changes, series of acquisition, series of license,
probably changes for some of those.
So tell us how Red Hat you know is going to advance in the next
few years, right? Where do you see the next big
thing that would come from? Red Hat?
We just had very big news. It's very big for us, probably
hope meaningless for everybody else, but our entire group is
being moved to IBM. So we will no longer be under
red ads, but under IBM. The things they promised was the
reasons they gave us seem very positive, like it seems like a
really good idea. IBM has always had a very large
team working on a lot of Java things, including a lot of open
source Java projects. And so we're even not even
joining the team. We're going to be side to side
with them, but I expect a lot more collaboration with those
guys. So that's great.
We do have concerns about the open source commitment because
like in Red dot it's very easy. Like we, as I said before in our
employment contracts, we have this thing that you're allowed
to contribute to anything. IBM has been very reassuring
about us, like they clearly don't want to lose us and they
want us to keep working the way we are.
We are used to work, so probably nothing is going to change, but
for us this is a bit surprising. Yeah.
I can't answer your question about where Red Hat is going
because we won't even. Be there for such a big name,
you know, Red Hat has been in the open source from the Linux
and maybe maybe many other projects like Hibernate.
I think that's really a big contribution and hopefully you
guys can continue all this great work and, you know, support the
community. So Sunny, as we reach the end of
our conversation, I have one last question before I let you
go. I call this the tree technical
leadership wisdom, but you can think of it simply just like
advice that you want to give to the listeners.
Maybe you can share some of your advice for us.
Yeah, this is the tricky question.
I thought about like the most important one.
I realized this was actually advice given to me some years
ago. It took me a while to implement
or realize how important it is. But I think it's very important
to make yourself replaceable aggressively.
So I think many of us see it working in this space the way
you might suffer from, you know, imposter syndrome, right?
Oh, I got here out of luck, but I don't really know as much as
all these other smart people. I'm working, right.
So you kind of tend to make yourself valuable so that you
are kind of reassured that you're not going to be removed
next week. Right now, I have been working
on Hibernate for a very long time.
And then, you know, we created Quarkus and then I was involved
in Quarkus and in Hibernate and I was the architect for
Hibernate team, which means also like interfacing with all the
other products that have to do something with Hibernate or
integrate with it or and know about, you know, life cycle
versions. How long are you working
supporting this other branch? Lots of discussions and it was
just way too much. I love these projects, so I
could not just quit any of them because I felt that some things
were unfinished and were not clear or like some other people
were not in a, the right position to replace me.
And that was actually a problem. So I've been mentoring Joran
Rodier now. It's extremely brilliant
engineer in France and he's, he took over already.
I have since last October, I believe the role of Hibernate
architect. So I'm no longer official in
that's who I'm mentoring him. So I'm still kind of in the
picture and I'm still working on Hibernate, right.
But I really realize that it's important to make sure that I'm
not indispensable. I had to go on paternal leave.
And so I was literally, you know, not having sleep for four
months. You, it's not good for the
project if something like that happens.
And you are not irreplaceable, right?
So it also prevented me from expanding and, like, diving deep
into other important opportunities within these
projects, right? Yeah, this is done now.
I think we're all in a better position because also out of
respect for the project, the other people, they were not
getting the attention they needed or the direction they
needed. Now that I have him and it's us.
So yeah, making yourself indispensable a big mistake.
But that's what's big time. And in the same space, I'm
thinking of interviews like. So I've been a trader for a very
long time. And another funny thing is most
of my colleagues, I've been the same for all those years.
And I even had like the same manager for I think like 14
years and he didn't even quit. He retired at some point.
Because, you know, all this long, I realized in the
industry, this is really, really unusual.
And for many, many years, I also did not interview anywhere else
because, you know, you love the project.
You, we have a fantastic team. And so, you know, going and
answer to a recruiter or somebody feels a bit like a
betrayal of your best friends or your life, baby, right.
I think that was a mistake as well.
I, I did some more interviews in recent years and doing them, it
helps or better understand my own value.
And then therefore, you know, you get those very interesting
offers. It builds up my confidence.
And that helps, again, to fight imposter syndrome.
And that helps to realize that, you know, that the way you're
working is valuable. It's valued by the others, and
it just helps make you a better reader.
I never learned because, you know, yeah, you'll get maybe the
offer. It's assuring to know that if
you left here, there are other opportunities, but then you
still reflect like, well, I, I like this one should, but but
it's still something that I even suggest my colleagues, you know,
do some interviews. Sometimes it's good and then,
you know, we talked about it and the worst case, you, you're
going to need a raise to stay. It's also not bad to truly
listen to the others. Like one thing as a leader,
especially in these groups know if that always resonates to me.
The six in the aerospace industry, they noted that most
accidents have when you know, you have two pilots in an
airplane, it's much more likely that an accident happens when
the senior pilot is piloting because the other guy that's you
know, they monitor each other. The junior one is less likely to
speak up or if he does, he might not be respected in his opinion.
That really struck with me and I think it applies also a lot in
other areas, right? Especially the technical things
we work on. I've seen, you know, indeed all
these chats and all these misunderstandings that we have.
It happens quite often that somebody that's very junior or
maybe has a very basic understanding of our frameworks,
you know, when external user comes to us in the chat and asks
something, he clearly has many misunderstandings or not read
something, et cetera. And then, you know, his opinions
get really discarded really quickly.
And sometimes, you know, many times it doesn't have value,
right? But sometimes there are really
important feedbacks in there. Also between colleagues, you
know, there is a bit of a hierarchy.
So if you are on top, it's very important to listen what the
other guys say. And well, the opposite of
listening truthfully is also like, I expect the others to
also be truthful in what what they say.
And this is especially important now that we all work remotely
and that we are far away and we don't know each other.
The trust that there is between the people is so important.
I had been blindsided once. Like there was one person that
lies to me. And I realized later that I was
like, I was very naive. I realized it had been many,
many, many years that I've been working with lots of smart
people and it had never happened to me, right?
So I completely am in working in a world in which the technical
excellence is really reached by the fact that these people are
very honest about what they see, what they are proceeding and all
that. So I feel like it's when
something doesn't, you know, you didn't do something that you had
to do. I really value that people are
very honest about what it is like.
It's much better to hear that you didn't do it because
yesterday you had other things on your mind and you didn't feel
like working. And that builds a much stronger
relation. Then, you know, you you might
need some slack or you might have a motivation issue.
And then it's better if you tell me we can work on that together
and that really helps creating a bonding in long term.
But then we see in these teams that, you know, they we stayed
together for a long time and we may create a good things
together. Yeah.
Well, I really love that you know, listening and be open, say
truthful thing, right, the psychological safety and you
know, some people say. That's so that's.
Pretty super important. So Sunny, thank you so much for
coming here. Thank you.
Again. This is our first time doing the
in person podcast. I hope you enjoyed the
experience. Yeah, good luck with all the
open source projects out there. So again, thank you for your
time. Thank you.