Here we come to what I think may have been one of my worst
mistakes in my career. I shudder to think at how many
billions of dollars or something have lost productivity result
from that one error. Gavin King, the creator of
Hibernate and key contributor to enterprise Java specifications,
shares his hibernate creation story and how he's currently
modernizing Java persistence. What exactly the problems that
you saw back then that led you to creating Hibernate?
My career really started out of my frustrations with the Java EE
platform. Hibernate started as a result of
a kind of an argument with my boss at the time who wanted us
to use entity beans. I argued that beans just didn't
work very well. Many people carry around the
belief that specifications designed by committees are
doomed to fail or be bad in some way.
I actually hold absolutely the opposite view.
For my career, the things I'm proudest of is those
specifications work we've done within the JCP and now at
Jakarta. Explain a little bit why there
are such love and hate relationship with ORM.
In the past, Hibernate picked a way of doing things which
involved more magic than some people probably wanted.
People have been sold in this notion that persistence can be
transparent. My goal has always been to give
people powerful primitive so that they can implement whatever
sorts of architectural decisions that they wish to implement.
The whole discourse around design patterns and
architectural patterns lacks foundation in logic and math.
It lacks empirical foundation. Architecture is something that
has to emerge naturally from the code.
If they don't make the code better and more elegant and more
flexible, then you should not be doing them.
All right, so welcome to the Tech Lead Journal podcast,
Gavin. Uh, it's my pleasure actually to
have you here. So I had Sanne maybe a couple of
weeks back, right? Yeah, sure.
So I'm very happy to have another, you know, so-called
Hibernate creator to be in this show.
Uh, and I must say, um, when I started my career, Java
Persistence with Hibernate is like my, go-to book, especially
20 years ago. I just started my career, you
know, learning about Hibernate and all of that.
And thanks for writing the book and, uh, it's my pleasure to
have you in the show. Thanks for having me here and
you know, thanks for, thanks for liking my, liking the book, and,
you know, uh, that's great to hear.
So Gavin, maybe people know a lot, uh, you as a creator of
Hibernate. Uh, but maybe let's start by,
you know, maybe sharing some stories about yourself, any kind
of career turning points or highlights that you probably
think we can learn from you. I don't know, I don't know how
much there is to learn from me, but, um, I guess I can give you
a rundown of, you know, um... I started my career by dropping
out of a PhD and going to work for a bubble tech, you know, the
original tech bubble company, startup company.
And, um, because I was just very interested in this new world of
the internet, right? And the worldwide web, which
was, you know, I was reading Wired magazine and, you know, I
didn't have a background in computing.
I have a background in mathematics.
Um, and you know, I started working with Smalltalk a little
bit, and then very quickly Java came through like this wave,
which took over the, you know, the industry at the time.
And so I started working with Java.
I was working on, at a consulting firm in Australia who
were doing IBM WebSphere consulting, so building, um,
applications on top of using WebSphere.
And my, I guess my career really started out of my frustrations
with the JavaEE platform as it existed at that time.
And so Hibernate started, you know, for, in one sense, as a
result of a kind of an argument, you know, a debate let's say I
had with my boss at the time who wanted us to use entity beans
and the standards because, you know, he argued, you know, in a
sense, quite rightly that there is value in standards.
There's a value of having a standard way of doing things so
that everybody knows how to do things in the same way.
And I argued that entity beans just didn't work very well.
And that, you know, no matter what the value of a standard is,
if the thing doesn't actually work, then, um, you shouldn't
use it. And so I was very interested in
open source, which was kind of a, I don't wanna say it was a
new, new thing, but it was, at least, it was something that was
new to me. The idea of, you know, the whole
question of how open source related to the commercial world
of building software for money was a very interesting, you
know, to me, just a very intellectually interesting
question, right? How do you, you know, what is
the best way to produce software?
This thing which has a zero unit cost of production, but it is on
the other hand, very expensive to produce.
You know, how do you, what is the best business model for
accommodating those economic realities?
And so I was interested to start an open source project.
And so that's how Hibernate began.
We just, I just started writing some code for persistence and
put it out there. And in those days, that was a
way that it was quite easy to get attention, right?
Um, I think it's probably harder to get attention just from that
today. And I think that open source
projects today that become successful are a lot, more of
them have some sort of corporate backing.
But at that time it was, well, it was possible, as you know.
Um, and so there's a lot of that going on.
Pretty soon, like a, you know, a year, a year and a half, two
years later, I was absolutely overwhelmed by the amount of
work that was involved in supporting this open source
project. And so this is critical to
understand that, you know, an open source project does require
some sort of business model behind it or you're just gonna
be overwhelmed by the work it takes to support it.
So I was looking for a way, you know, I got fired from my job
for spending too much time on this, you know, um, I was outta
work for a while. That was quite precarious
actually. But I, you know, I had this
thing there that seemed to be going places, right?
And I was actually in Boston for a speaking event.
I forget what it was. But, um, and then these um,
couple guys from this tiny little company that was barely
even a company at that point called JBoss from Atlanta,
Georgia, you know, flew up. Well, I actually, uh, Bill lived
in the area, but, um, Ben flew up and, to talk to me and they
were like, you know, well, you know what, you know, would you
be interested in, you know, coming and joining JBoss?
And I was like, yeah, hell yeah, absolutely.
I'm interested. That was exactly what I was
hoping you were gonna ask me. And so, um, I moved to Atlanta
from Australia. And then began the two or three
most intense years of my life in some ways, um, of, uh, just
flying around and, you know, talking to people about
Hibernate and about. And it was crazy.
You know, it's, uh, it's amazing to think of all the stuff that
happened in what was really such a short period of time.
At one point, and I think a very important turning point was
that, you know, Hibernate was not the only game in town at the
time. There was JDO, for example,
which was a specification that these object database vendors
had. MyBatis, iBatis, MyBatis.
Yeah, ah, those kind of came later.
Yeah, I, no, at the time, the biggest kind of sort of
contrary, you know, other option that people were pushing was the
JDO specification, which was already an existing
specification. It had certain features that
meant that, you know, we, I really didn't like it.
But there was a perception that we needed to adopt some sort of
specification. You know, JBoss was implementing
Jakarta, uh, Java EE, and, and there was a perception that, you
know, we should be somehow involved in the specifications.
Um, what happened eventually was that, um, Marc Fleury and I one
day got on a phone call with the EJB3 group and, you know I,
proposed that, hey guys, why don't we just drop this whole
entity beans thing, do something else, which is more like the
direction that Hibernate. Um, after that, the TopLink guys
got involved and then JPA was born, Java Persistence API.
Now that was, I mean, an incredibly politically fraught
process. Um, it's, you know, huge, huge
credit to Linda DeMichiel for actually like living through and
having to, you know, fight through all the stuff that got
thrown at JPA. I learned so much from that.
And in particular I learned a lesson, which I think that many
people, a huge number of people back in those days and I think
still these days, carry around a belief that specifications and
especially specifications designed by committees are
doomed to fail or be bad in some way.
I actually hold absolutely the opposite view from my, you know,
experience with that, with, you know, working on some of these
specifications. Um, I think that specifications
force you to really think through the semantics of things
you're doing. Iron out the, um, you know,
little corner cases. And so I have a very different
attitude towards specifications than I think most of, even most
of my colleagues. And you know, I learned that
from Linda, you know, from watching Linda worked.
And, um, and so, you know, for me, you know, for my career, the
things I'm proudest of is the, you know, the specifications
work we've done within the, in the JCP and now at Jakarta.
After that I started, I was concerned about the question of
how these kind of more, what were considered sort of more
backend technologies, you know, EJB, JPA integrated with the
Java EE, web layer, the servlet, etc, JSF.
And so, you know, there was no good tie in there.
You kind of were forced to introduce a sort of a layering,
which was unnatural. And the, you know, EJB3 had a
kind of a dependency injection approach, which at the time was
a super popular thing. But it wasn't really, it wasn't
really well integrated with the web layer.
You know, you had JSF had its own sort of approach.
And so I proposed this JSR, the Java Specification Request
called, which was titled originally Web Beans to kind of
integrate the two sides of the, you know, Java EE programing
model at the time, after EJB3. And that eventually evolved into
what's now called CDI, which is kind of a central sort of glue
that, you know, now today holds the Jakarta EE platform together
in some sense. And that was, you know, that was
again, um, a very interesting political process, um, some
stage. Yeah, anyway.
Um, that was interesting. After that I had got a bit
frustrated with all the politics, which is something I
think a lot of people go through.
And I was also kind of frustrated with the Java
language as it was at the time. Not kind of, I was very
frustrated. I felt that the things we were
doing as builders of frameworks and libraries, we were very, we
were always stuck in this straitjacket of what was
possible in the language. Even today, there are just
things that are missing from Java that would make my life as
an API or library designer, you know, like the ability to be
able to refer in a type safe way to a method of function, right?
You know, the lack of method references is to my mind, just,
you know, 2025, the language has been around for decades, it is
crazy, right? Java has improved a lot.
At that time, you know, we didn't even have higher order
functions, etc. So I proposed to my boss that
we'd do a language that would act as, that would enable us to
do more in our platform and in the libraries and frameworks we
were building. And so that's where, that's how
Ceylon started. Ceylon was something, it's
something I, at one stage after it was all, after the dust all
settled, I sat down and realized I'd spent 10 years of my life on
that, right? Yeah.
Um, and I mean, in a sense, I mean we did a lot of, you know,
really great technical things. The type system of the language
is, you know, I mean, I will defend it that this, that is the
right type system for a language with subtype and parametric
polymorphism and normal typing. Like that is the correct type
system. And there are things which just
work out so much more elegantly with that type system.
Sadly, you know, the, in terms of our commercial perspective,
you know, we had a user community, but it just never...
Red Hat, in part because Red Hat didn't really know what to do
with it in terms of promoting it.
In part, I'm sure because of mistakes, you know, we made, it
wasn't so easy to just kind of start using it in a language, in
a, excuse me, in a project which was already in Java anyway.
It wasn't a success and eventually the project ended.
Um, and that was a, you know, really a thing which, you know,
sent me, you know, really into a period of, I don't know, I
wouldn't say depression because I had my family, I had my salsa,
I had, you know, lots of things going on.
But, um, but in terms of, uh, career wise, I was very, um,
unmotivated. And, you know, I would say that,
you know, so that's important to acknowledge that, you know, a
career goes through, you know, ups and downs with, you know,
these incredibly intense periods and then periods where, um,
just, you know, things you just feel like, you know, well, what
do I do next, you know? I don't have anything.
And, um, eventually when Quarkus came along and we were kind of
looking around and realized that persistence was still, and I sat
down one day and I was like, oh, they wanna use Hibernate.
And I'm like, it's like 15 years.
And they, I'm like, is this still something that's...
Yeah, I'm like, is this so still something that's relevant and
important today? And, you know, so I went and
like pulled some the data set they have for Stack Overflow and
did some analysis on that and, you know, looked at some other.
And it turns out, oh yeah, actually it turns out this is
still what everybody's still all using.
And we've kind of had it a bit in maintenance mode, right?
And so, you know, I'd say, I don't want to say that this all
happened all at once, but so I kind of came back and started
asking the question of, well, if we were just designing this
today, what would we do different?
How can we go beyond what were the limitations?
And so somehow I got dragged back into doing, to doing
Hibernate again. Something I'd promised that I
wasn't gonna let happen. I don't know, the last, it turns
out that there was so much still to do and the persistence, you
know, nobody talks about persistence, but it's like
something that is so central to really what most program,
enterprise programs do that it's something we should actually
probably talk about more. So, yeah.
So that brings me here and um, and that's what I've been
working on recently. Wow.
Thank you so much for sharing, you know, almost kind of like a
full picture of your career, I would say.
There are ups and downs. I think one thing that really
stood out for me is your persistence.
I mean, not talking about 'persistence', but persistence
in pursuing the idealism, right? So like when you fought with
your boss, you know, trying to pursue how to create standards,
specifications, making the open source successful.
And then creating a new language because you think there will be
a better way of creating new language.
And then yeah, coming back to, um, you know, working on the
Jakarta EE stuff, I think, definitely, we, as community,
can thank you for your contributions towards all these,
uh, great inventions, right? So maybe if I can just try to
pick some parts of what you just shared, right?
Let's start with Hibernate, right?
So you were saying back then EJBs, right?
My experience with EJB is when I studied in university.
Maybe it's EJB2 something. It was quite horrible, in fact.
Um, but what I wanted to ask you is like what exactly the
problems that you saw back then that led you to creating
Hibernate? Like because Hibernate is like a
new paradigm altogether. The way it works...
I wouldn't say that, but finish, finish the question.
Yeah, because to me back then it was like totally new paradigm.
It's a POJO thing, right? And then you have some, you
know, annotations and all that. It feels different for me.
But maybe tell us a little bit more the story.
What frustrated you the most and why?
What led you to creating Hibernate?
Yeah, that's a good question. So it was unclear I would say at
the time, whether, and I'm still unclear on this whether entity
beans had ever, you know... Okay, first of all, let, I'll
take, let me take a step back. I wasn't around, I was like, the
very beginning of my career, I was not involved in at all in
the creation of any of the Java platform up until Java, up until
EJB3. I don't really know what
happened, right? And I, and so it's hard for me
to come up with explanations for what went wrong.
But my speculation has always been that Java was new.
Nobody actually knew how to write Java effectively at the
time. And I speculate or infer that
the people who were writing the specifications for the early
versions of Java EE were in fact not Java developers because, you
know, that was the next generation of people who were
actually Java developers, right? And so they had inherited some
thinking about the ways to do things, which kind of came from,
you know, C++ and kind of came, you know, from CORBA, and the
work on that. And the web was new and the
whole question of how you architect, what the architecture
for program, which, you know, makes data available on the web.
I mean this was something which was new.
And there weren't, you know, answers.
And so it takes, so it is normal that you take some time to
evolve or a meaningful, you know, the right solution.
I think what went wrong was that somehow some people's
experiments kind of got pushed suddenly, all of a sudden on,
you know, I don't know, hundreds of thousands of developers
before going through a process of maturation and, you know,
okay, did that work? Or, you know, no, well, we
better change it like this. And so it was kind of a victim
of its own success and suddenly you had a bunch of angry people
because if you told that this was the way, this is what they
had to do, which is probably never the attention of the
people developing. You know, I'm quite certain that
the people who are developing this platform, you know, you
used to hear oh, vendors, they're terrible.
They do, you know, they're always in their own interest.
No, I'm quite certain. I know some of these.
You know, I've met some of these people.
I'm sure that their intentions would've produce something great
that made it easy as possible to build these systems.
But I think that just nobody knew the right way to do things
at that time. And so I think that's, I think
that's what went wrong. Specifically in the case of
entity beans, which was always the worst part of it.
I'm not even clear that they were originally intended for
object relational mapping, okay. I don't know the answer to that.
It's unclear. I've heard some people say no,
I've heard some people say yes. But certainly they were
interpreted as that. You know, with an identity or at
least people with looking, you know, people obviously were
looking for, okay, well okay, we've got this platform.
You know, how do you do, you know, how am I supposed to
interact with the database? And so, you know, that was an
obvious construct to map to the data.
Oh, we have these things with an identity that are sort of
persistent and so we'll try to map them to that.
The issue was that building an object relational mapping
solution is an enormous undertaking.
And that just wasn't, just wasn't there, you know?
Um, nobody had a good enough implementation.
A second problem with this issue of how I'm trying to avoid all
sorts of words I hate, like heavyweight, um, which I think
is a meaningless term, um. In EJB, there was an extremely
intrusive programming model and quite verbose.
And this was in a time when Java the language didn't have the
kind of tooling we have today. The language itself was more
verbose. We certainly didn't have coding
assistants. And so the amount of just typing
it took to create a simple piece of functionality was out of
control. Um, sometimes people forget,
fail to recognize how far we've come, right?
You know, from WebSphere in those days to, you know, Quarkus
today. I mean, just that, just the fact
of, you know, hey, you spent all day restarting the server and,
you know, to see your changes. I mean, it was awful.
You know, nowadays with Quarkus, you just make a change and there
it, refresh, there it is, right? Um, it's crazy.
So I would say, you know, yeah, it's a combination of you know,
people were trying to do things before really understanding the
problem well enough, and just because of the incredible amount
of energy and attention, and in Java at the time, stuff just got
adopted wholesale before it had been, you know, too fast, right,
is what I would say happened. But we've, but you know, and
this is what I think people should give more credit.
We fixed it, right? Like the Java Community Process
responded to that. They went, you know, guys like,
you know, JBoss, you know, annoying JBoss people who, you
know, people didn't necessarily like us very much, right?
You know, we came along and said, no, we should do this and
this, and who the hell are you? You know, you're like four guys
and a dog in Atlanta, right? But they responded to that,
right? You know, these enormous
companies, they went, yeah, all right.
Okay. Let's do what these guys are
telling us we should do. I mean, do you realize how, you
know, that is something they deserve massive credit for.
And so the truth is that the community process that Sun had
set up was successfully responded the objections.
It improved the platform. And the platform actually kept
improving. And what we have today is, you
know, is it perfect? No, it's not perfect.
But in fact, you know, I mean, I think is a sad thing is that the
platform went through several years of not evolving very fast.
Um, and I, I'm hopeful that there's a quite a fair amount of
energy coming back into it right now and coming back into,
certainly, on the persistent side, things are moving very
fast right now. And so, yeah, like, um, I know I
say too much about specifications and about, you
know. But you know, I think that's
some of the narrative I hear, I think is unfair.
Sorry. Yeah.
Thanks for sharing the perspective from you.
Like I'm, even though that's not true, right, a hundred percent,
but at least we got a glimpse how difficult it is to actually
evolve a language that is being used by a lot of people,
especially enterprise, right? And there are so many vendors,
you know, backing it as well, right?
So definitely to make a change is not an easy thing.
Personally myself, maybe I haven't used Java a lot in the
last, I don't know, maybe 10 years, let's put it that way.
And I saw your demo just recently as well.
I think the amount of changes, it seems pretty intensive.
Like a lot of new stuff being introduced to the language, you
know? I think it's pretty exciting if
let's say people are still working on the new Java, uh,
version, right? Yeah, yeah.
I think there are people, sometimes I see comments from
people talking about, you know, criticizing Java and I can just
see, I can just see that they are thinking of a version of
Java which existed 10 to, you know, 10 years ago.
And it is not the reality of the current technology, you know, of
what's there today. Right.
So Hibernate definitely is like one of your biggest achievement,
I would say, right, um, in your career.
So obviously, it's very hard to kind of like summarize the key
success factors to the project. But now we can see like millions
of downloads. Maybe people even like pulling
it out of a framework without actually knowing Hibernate is
there. And there are many contributors
as well. I think Sanne told me the other
day there are like thousands of contributors to the project.
Maybe as a creator yourself, first, like how do you feel
about it and what do you think, if you can pick maybe, I don't
know, top three, top five key things that make Hibernate
really successful? Hmm.
I mean, first of all, I mean it's wonderful.
I mean, I'm so happy to have, you know, got lucky enough to
have been able to do something that was so, you know, kind of
so significant in enough people's lives.
Um, you know, I think that's the most you can hope to get out of
a career is um, to make things better for a significant number
of people. Yeah, I actually, Sanne would
know how many contributors there are because we recently went
through the process of, he recently led the process of
relicensing Hibernate and getting everybody's, all the
contributors' sign off and permission to, uh, switch to the
Apache license. Um, so yeah, I mean there've
been a lot of people who have worked on it over the years.
So why was it successful? I mean, again, I think it was
successful because, you know, first of all, because it was
solving a problem that is absolutely ubiquitous.
Persistence, as I said, is something we barely talk about,
but it is there as an incredibly important problem in, you know,
essentially all the programs people write.
It is underserved. People don't pay enough
attention to it. And if you can find a niche like
that and make something which addresses, you know, this
extremely common unaddressed need, then it can become very
successful. Obviously, the fact that it was
open source, especially at that time, was enormously
significant. Obviously, TopLink could not.
TopLink, which is a relatively similar, took a relatively
similar approach didn't have the potential to blow up the way
Hibernate did because of its commercial, the commercial
nature of it at that time. So that was very important.
As I kind of alluded to earlier, I think that at that particular
point in time, it was very easy for a little open source project
run by a couple of guys to get attention.
And I am very sad that I think, at least in the Java world, that
we've lost some of that. And that now we expect for
everything to come, you know, all nicely packaged up from a
major vendor and... Guys, I mean, you don't need to
be spoonfed everything, right? You know, it can be good to
like, you know, try out something you find on the
internet, right? And see if it works.
I'm a little concerned that now we, you know, we have, so...
And I mean, it's great in some sense that we have this such a
high expectation of platform integration, that you just pull
Quarkus and then everything's there for you, right?
I mean, that's great. But I almost feel like we've
moved away from this, you know, thing we had where somebody
could put something out and people would try it out, and
then people would get in, you know, have their flame works on
the flame, flame wars on theserverside.com about it.
And it would be this thing that everyone was talking about.
Perhaps this, perhaps that just represents the fact that there's
less energy in Java these days. Perhaps, you know, the, it is
still the case in, you know, if we would, you know, for people
doing AI stuff that the world really still is like that.
I'm not clear on that. I don't think it is, but, uh,
not in quite the same way. Yeah, um I think that was an
important factor that the world at the time was a little more.
And here's what I wanna, I guess I wanna say where I'm going with
that. I think that the world of blogs
and news sites was a better world than the world of Twitter
and LinkedIn, right, for people trying to build interesting
things, right? Why do you think that's the
case? It was the fact that you could
publish news on theserverside.com, that would
go, ah, great, you know, they would publish anything, right?
And the whole, you know, kind of the whole, not the whole
community, but like a significant chunk of the
community would see that and respond to it.
Twitter is like this fragmented thing where people don't
interact because, I mean, what happens on social media?
Yeah, we used to have flame wars, but I mean, social media
flame wars in this tiny little, you know, messages are way more
toxic. And so people don't interact,
people don't get into any sort of debate of substance on social
media today. You know, um, you have people
post stuff on LinkedIn. It's crazy to say, but LinkedIn
is kind of better than, more interesting than Twitter these
days, it feels like. And yeah, it just, it's just the
nature of, you know, where publications have to fit on the
screen of that thing. Um, there's just less content,
there's less sophisticated ideas being communicated.
And somehow we have to get back to...
I mean, there's no going back to blogs, I guess, but we have to
open up a space where people can communicate ideas that don't fit
in on this, this, I dunno how, I don't know how that's gonna
work, right? But it'll have, it'll happen
eventually. Right.
I think some of the alternatives these days are like Reddit,
Hacker News, those kind of stuff.
But obviously sometimes it's like the social media effect as
well. If it doesn't get picked up by
somebody. And it doesn't get commented as
well, I guess it will be drowned against all the other posts.
So yeah, definitely thanks for sharing, um, you know, the key
success factors. And I think it works as well,
right? Hibernate works compared to, you
know, well, I guess that's the key success factor, uh, as well,
right? And it gets adopted by other
frameworks as well. So I think, and the vendors, the
enterprise, Java Enterprise server or something like that,
right? And once again, right?
It was important. People may not realize it and
some people thought it wasn't important.
Some people thought we shouldn't do it, right?
It was important that we wrote the JPA spec.
And that then the Hibernate was implementing a specification
that was, you know, the specification is this public
document that says, hey those of us who know something about this
topic, TopLink and you know, and JBoss and Sun and IBM, we've
come together and we've agreed, we've come to agreement that
this is the right way to do persistence in Java.
And here we have documented, laid out what it has to do,
right? There is huge value in that.
And it was important to Hibernate, to the existence of
Hibernate I believe, that we did that.
We took that step. Um Otherwise, I'm not quite sure
what would've happened. But you know, I mean, you can
say that, okay, you know, Spring have always been hostile to
going down that path and they've become successful anyway.
I dunno how much I want to go. Let's, let's not go, let's not
go there right now. Um, but, um, to me, I think
that, particularly given that Hibernate at the time was not
the only game in town, that it was very important to have,
being part of, to have had the specification where we would,
where we were not the only implementer, that there was
TopLink, but there was other things implementing it, right?
I think that was also important. Right.
I think this is also a good segue to go to your work at the
standards, specifications and all that, right?
I think for many people, right, we are not involved in this kind
of process, right? So maybe let's try to demystify
what actually happened behind the scenes when people are
putting JSR, putting something to the standards.
And you were mentioning political a few times.
I guess maybe if you can share a little bit, um, like what's the
process like? How difficult it is to introduce
a change to a language that is kind of like widely used, a lot
of enterprise usage, and it has to be backward compatible,
right? I think that those kind of main
things about Java. Sure.
So I can't talk about the language.
I've never been involved in the Java SE side of things, okay?
Um, I can say sort of a little bit how it used to work with the
EE specs was that, you know, you submitted a JSR and one of the,
one of the big things was to have a specification request and
they convince enough of the members of the executive
committee, hey, this is something that should, you know,
give us a chance to work on this, right?
Then you need to form a group of people who are actually gonna
support and actually, you know, give meaningful feedback.
You don't wanna just sit down by yourself and write a spec and
then say, hey, vote on this, right?
Um, you want to get, you know, you actually have to get
meaningful feedback and suggestions from, you know, the
other people working in that space.
Because the simple fact of the matter is, you know, often I
know what the right answer should be.
Not always. You know, very often someone
would come and I'd be like, oh, you know, oh yeah, shit, I
didn't think about it. Yeah, we should do that instead.
You know, great. Like, you know, having a way to
gather feedback from, you know, especially feedback from other
groups, which may be, you know, you may, they may, you know, it
may be vicious competitors in other scenarios.
But you want to get together, you know, ideas.
I think people imagine that the process of writing a spec is a
lot more, involves a lot more horse trading than it does, than
it actually does. Obviously there is a lot of
negotiation, but the kind of negotiation that at least
ideally is more, you know, involves a lot more, okay, let's
all sit down and think about what is the best solution that
addresses everyone's substantive concerns.
I have not, at least in my experience, I have not seen this
dynamic that people, I believe assume, and that I used to hear
people from outside saying, that's how it works.
Oh, such and such is trying to standardize their technology,
right? And they're just trying to put a
rubber stamp on. I have never particularly seen
that dynamic. Yes, people will come and they
will have a product now of an implementation and obviously,
you know, that does what they thought was the best, you know,
the right way to solve the problem.
And they'll say, yeah, we should do something like this.
Okay. But I, you know, at least the
people, you know, most of the people who are actually get
involved in this sort of work are people who are, you know,
extremely open-minded, are extremely committed to finding
the technically best, you know, option.
And so in the, you know, in the best case where people are,
uh... and also it takes a particular personality type,
right? It takes the sort of
personality, which isn't the sort of person who is not gonna,
sort of get defensive of the first solution they came up
with. You know, for me working on
these things, you know, I have to, you know, it's something I
like in there, always telling myself, always telling myself,
okay, don't, you know, give this, it's fair.
You know, give this, what this person's saying its fair
hearing. Switch into this mode where you
take this idea seriously and take it and see how far it gets,
right? And that's not to say I'll be
like, you know, oh yeah, that's a great idea to every proposal.
Absolutely not. In fact, I'm more likely to be
okay about this, right? And this and this, okay.
But, you know, it has to go through that process, right, as
well. But that doesn't mean that I'm
not there telling myself, okay, but what are the pluses of this?
You know, even if I don't like it, right?
Where, what does it have, what is there in there that even if
this is not what we go with, that we need to somehow recover
that good aspect of it, right? And so that takes a particular
sort of mental discipline. I think not everybody has or
wants to have or whatever. I don't know, it's a different,
it's a different thing to sitting down and writing code,
obviously. Yeah, I guess it involves a lot
of people, right? Maybe, uh, a lot of backers as
well. Typically, typically not.
So typically the specifications I've worked on had a relatively
small number of active contributors.
In fact, that's probably what works best.
It's, you know, when you have three or four people with, you
know, two or three suggestions for how to do something that's
probably works better than if you have 20 people with too many
good ideas, right? So I think definitely, right,
the, again, the persistence of you pushing into the
specifications. I think we all can thank you for
that. Because back then when I was
starting my career, right, there was already this war between
standard. Following standards or following
like Spring, Hibernate path, right?
Which is like open source, um. And back then to me like seems
following the open source way is much better because again, the
community thrive on it. There are many new inventions.
And definitely we don't want to get associated with heavyweight
kind of server and all that. Nobody likes that.
Um, so I think now that the specifications kind of like get
evolved and modernized as well, I think I can see a lot of, uh,
so many cool things happening in Java world.
So again, thank you for that. So one thing these days when
people hear about Java EE, right?
Like for me, right? Uh, It's kind of like renamed to
Jakarta EE, so it's a bit trivia.
What is the story behind it and why Jakarta?
Because I'm Indonesian. In one sense, I'm very proud
about it. Java and then now Jakarta.
So maybe a little bit trivia, why is this, uh, renaming?
Yeah. Okay.
So I, first of all, I hate it. Um, I actually was not involved
in, I was away doing other things, Ceylon and stuff, when
most of that was going on. Max Anderson is the person from
our side who has, I think has the most visibility to what went
on. So there was a lot of pressure
on Oracle after Oracle acquired Sun to make Java open source and
to make, um, and I believe... No, let me not say something on
video where I might have my facts wrong.
Anyway, there was pressure to, for various reasons which as I
said, I'm not an expert on for, to make the Java EE platform,
you know, open source and let it evolve out in the community.
Now so the Eclipse Foundation at the time was quite popular.
And so Eclipse was, they identified somehow that Eclipse
was the right place to carry it forward.
And look, I've heard some stories, but I wasn't there, so
I'm not gonna count them. That was so Spanish.
That was Spanish English. I'm not going to recount them.
But essentially, Oracle agreed to do that, but they insisted
that the name Java, which they, you know, acquired from Sun,
couldn't be put on this stuff anymore, which caused this, you
know, renaming of all the packages from Java X to Jakarta.
I actually have often asked myself, because Jakarta was a
name for the Apache Jakarta project.
Um, and so somehow that name was transferred to Eclipse, and I
have no idea how that happened. As I said, I wasn't, I wasn't
there. Yeah, so now it's no longer
called Java EE, which I, I'm really not happy about it, um.
It makes it seem, you know, somehow less, you know, than
what it was, um. But it is still what it was.
And you know, really, I still think it is the best place for
us to move the enterprise, you know, technologies forward.
And that's why, you know, investing time in it.
Right. At least it still retains the J,
right? So you can still call JPA and
all that. Otherwise...
I presume that's... I presume the word Jakarta.
Jakarta's a city in Java, so, and...
So you now are working with, you know, Jakarta Data, Jakarta QL,
and all that, right? So as part of, you know, solving
the persistence problem, right? So maybe let's elaborate a
little bit, right? So persistence, right?
What do you think is some of the common problems before this
Jakarta projects come in, right? So what are the common problems,
what are common complaints from people, and what are you trying
to solve now with this new standard?
Mm. Okay.
So with specifically with Jakarta data or with Jakarta?
Let's just talk about the whole thing, right?
Yeah. Because in a sense, you know, we
have a bunch of moving parts and it's, you know, sometimes
difficult even for my colleagues to see how all the bits relate,
you know, like, um. You know, Hibernate 6.0 was a
massive, a massive investment of work and a massive step forward
that for Hibernate on the implementation side, you know,
we've had Jakarta Persistence 3.2, which has a bunch of sort
of little improvements that you might almost think are not that
significant, but together, you know, I really do believe that
sometimes like if you pile up enough little improvements, it
amounts to a big improvement. After that, Jakarta Persistence
4.0 is a much bigger, is a much bigger thing that, you know,
we're still working on. We've introduced Jakarta Data,
and that's forcing us into the direction of, of this Jakarta
Query initiative. What is all this amounting to?
Okay, so first of all, you know, after so many years we realized,
okay, there was some things which weren't quite perfect,
right? Let's first of all say, you
know, what are the things that, you know, I mean, the first step
was, you know, well, what are all the things that both TopLink
and Hibernate have that were never in the spec?
And let's just, you know, that's low hanging fruit.
Let's just, you know, write them down.
Um, a second thing was, you know, especially since I had
been spending a decade or whatever thinking about type
systems, about type safety and, you know, I come back and look
at this stuff and it's, you know, kind of a little cringe
worthy to see strings in some places where there shouldn't be
strings. Um, so a big motivating factor
was to improve the type safety of things.
You know, and that was what really... that desire for type
safety and for compile time type, checking of queries and
stuff like that was what convinced us to get involved in
Jakarta Data. You know, I said last night, it
was something that we were originally kind of not that
excited about. But when we kind of realized
that okay, with adaptation processes and with the, I mean,
there was some non-trivial work to like which, you know, I kind
of get the Hibernate query compiler working inside an
annotation processor, right, within a, in a high performance
way, right, so that, you know, if you weren't gonna be sitting
there waiting for your, you know, um, for the compiler, was
non trivially hard, right, and involved significant package.
But it worked. It works very surprisingly well.
I'm actually amazed how, shocked how well it works, um, and
actually works. And so it was when, you know,
kind of Steve and I realized that, hey, we can do this with
an annotation processor and we can get something out of this,
which we didn't, which we really didn't have before, that we
realize, okay, so maybe this repositories thing has something
that's useful in that. And so we kind of, you know, try
to push this, the spec in a different direction with this as
the goal. And so finally Jakarta Data kind
of delivers on something which I think Jakarta Persistence
somehow failed in the end to deliver, which was, you know,
that compile time type safe querying.
And, um, and that's great, you know, that's wonderful.
You know, maybe, you know, Jakarta data might not be for
everybody and that's fine. That's completely fine.
Jakarta Persistence doesn't need to be for everybody.
And that's also completely fine. Yeah, so with Jakarta Query, an
aspect of Jakarta Data, which I'm not the person to talk
about, is that it does not only target relational databases, but
can also be used with other different kinds of data for
technology, graph database and document database.
And we subsetted the query language of Jakarta Persistence
in a way that allowed implementation of the subset of
Jakarta Data Query Language on these other data stores.
That process involved quite a lot of back and forth between
the two spec. Okay, back and forth between,
it's like, you know, me talking to Lucas, me talking to W and,
and Nathan. But you know that's still back
and forth and it's, and and you realize, okay, you know, no,
this isn't the way. What we really need is a common
specification document for Jakarta Persistence Query
Language, Jakarta Data Query Language, you know.
So let's have a Jakarta Query Language.
Um, this will be the object oriented dialect of SQL, right?
There used to be one. Um, the ODMG, um, used to have
this thing called object query language.
It never went really anywhere. I don't think it was ever fully
implemented. I think I, you know, I believe
maybe one or two object database vendors maybe partially
implemented, but it was never fully implemented.
And so, and, but I'm sure its capabilities are nothing like
the capability to say Hibernate Query Language, for example.
So, hey, you know, this is an actual thing, like a dialect of
SQL for querying, you know, objects, classes, is an actual
real thing. It would be good to have written
down what that thing is and what it should be, again, right, to
have a public document that says this is what this technology,
this is what this technology should look like, what it should
do. And yeah, it'll have a, you
know, a way of a complete implementation of it, which we
know to be implementable against relational data stores.
Without giving too much away, I wanna say that you guys should
be looking forward to a world where the full power of Jakarta
Query or Jakarta Persistence Query Language is available not
only on relational data stores, but also on at least one other
data database technology, which a lot of people are using.
But then there will be, but obviously, you know, you can't
implement all of HQL on a key value store or a, you know.
There are limitations. And so, and so there is a subset
which is meant to be implementable on less, let's
say, data store technologies with less powerful querying
capabilities, right? But I, you know, I don't know
how this far this is gonna go, but let's say that, you know,
document databases and graph databases these days have fairly
powerful querying capabilities. So, you know, perhaps we're
looking, you know, ideally, and I'm not making saying this as a
prediction, but as a, a hope, as a, that maybe we can have an
object oriented query language that works, that really does
work against these very different, these very distinct,
um, technologies. Right.
You mentioned something about type safety, right?
And I can imagine that, let's say when I write a SQL query,
like it's a string, right? And then I, if somehow I get a
typo or I misarrange the, you know, the columns and all that.
I could only get sense that I'm wrong when I test it.
Or when I write some tests in the background, right?
And so why do you think type safety is so, so much important
in this persistence framework? And maybe if you look back at
the language aspect as well, right?
There are some languages that are type safe and there are
languages that are not, maybe more dynamics.
And you can even change it during runtime and all that.
So maybe in your view, what's the importance of type safety?
Right. So I think, you know, one of the
fallacies that... I think a good number of people
understand, but there are still some people who don't
understand, is that a very tiny percentage of my time is spent
authoring code. Incredibly tiny percentage.
When I'm actually, you know, developing rather than just
thinking, um, or writing, the most frustrating and
demoralizing, and by far, the most time consuming part of
developing a, you know, mature system like, you know, Hibernate
or like Ceylon or like, you know, whatever you can think of,
is waiting for the test to run. That is the most time consuming
part of developing, okay. So you wanna run tests as little
as possible, okay. People who make the claim, and
you will hear this even today, but you certainly used to hear
it 10 years ago. People who make the claim that I
don't need types because I have tests, are not taking into
account that how often you run your tests is, essentially, that
is the bottleneck for being able to produce code quickly, right?
That is the primary bottleneck, is how long it takes to run the
test. Especially these days when, you
know, okay, the test, my test ran against, um, H2 locally.
Okay, great. Now I've gotta wait for them to
run against, you know, 10 different database, well, less
than 10, on the, you know, CI bill, right?
It slows you down incredibly, okay.
So any little thing which can be found at compile time without
having to write the test makes me, you know, means that I have
to run the test one time less. And that makes me much faster,
right? What happens with coding
assistants once we throw them into the mix?
Well, actually nothing changes, right?
Because coding assistant code like humans by nature, right?
And they make the same kind of mistakes.
And I don't think we can, at least not at current technology
levels, I don't think we can assume that coding assistants
are gonna make fewer of the sort of, of the sort of bugs which
can be detected by a static type system.
And in fact, you know, having used coding assistants a little
bit recently, I've noticed that I spend a lot of time waiting
for the, uh... so I mean, you know, the... you know, I wanna
shift things always to more code writing and thinking time and
less finger twiddling and scrolling Twitter time, right?
So, you know, so coding assistants aren't gonna help
with that part, but static types are gonna help with coding
assistants. And so, you know, when we're
talking about pushing development forward, I think
that nowhere near enough attention, I still believe this,
you know, even after, you know, the failure or whatever Ceylon,
I still believe that we are not paying enough attention to
static typing and its potential. Um, you know, Java has a kind of
medium level, good type system. It, you know, has obvious
problems, lack of type safety for null, generic type erasure,
which is terrible, results in all these unchecked type casts,
which can fail at runtime in your tests.
But it's, you know, it's still better than, it's still better
and more expressive than, you know, Python or Go or whatever,
you know, or whatever. You know, I use Python on a
pretty regular basis these days. You use Python for anything to
do with quantum, use Python for anything to do with AI.
And it's miserable, right? It is so much slower.
Oh my God, right? Like you know, things I can do
with this in IntelliJ, in Java. No, I mean, you're sitting there
typing, pressing keys. It's that, man.
It's terrible. Um, and, and it actually doesn't
have to be like that. Well, the reason, you know, the
biggest reason it's, you know, okay, let's not say it's the
biggest reason. Our reason I have to go to
Python to do quantum things, to do data science, is that
unfortunately we have no linear algebra library in Java.
That's something which I really think our community needs to,
you know, jump on and say, you know, Java could be a...
I don't know if Java can be a good language for data science.
It could certainly be a perfectly good language for, um,
uh, the kind of, you know, AI applications we're seeing
become, you know, huge today. No reason it can't be, you know.
There's no reason, you know, from the nature of the language
why you couldn't have a version of Qiskit in Java.
Um, well there is a reason which is there's no equivalent of
NumPy, right? Anyway, sorry.
Sorry. That was, that was a...
I think essentially the type safety brings a much faster
feedback loop, right? So even when you're typing the,
if you use good IDEs, it will tell you straight away, okay,
this is probably not right, right?
And you can even use their kind of like autosuggestion and
things like that to fix it straight away, right?
So I think the feedback loop... I mean, it, it is important to
always keep in mind, you know, it's a balance, right?
It's a, you know. Yes, it is true that a lot of
typing errors are false positives.
There's no doubt about that, okay.
That is absolutely true, and I think that's where your first
encounter with Java, not so much with Java but certainly with the
language of a very, with a very powerful static type system by
some people. Sometimes people's first
encounter with static typing if they're used to, or something
more like JavaScript or Python or whatever.
You know, is, ah, but that's, you know, but that's fine.
That code's fine. Why is it making me jump through
hoops? Okay.
And that's fair when you have, when your program is little,
right? But as your programming gets
bigger and bigger and bigger, yes, yes, you have to sometimes
jump through hoops to accommodate, you know, to get
past these false positives. But ultimately, you know, once
the program gets big enough that you can't fit it all in your
head, you know, the benefits far outweigh the, um, the downsides.
The other thing about false positives is that they often
point to a lack of expressivity in the type system.
And that often with a more powerful type system, you will
have maybe less false positive. Fair enough.
Well, type safety is one thing that you are working on to
improve, right? The other thing, I think I must
guess that it relates to some of the, maybe reasons why people
hate ORM. You know, like I mean there are
two sides in the programming world these days, right?
There are people who feel ORM is very useful and great.
There are some people who may have been bitten by some past
experience, say that ORM is the worst thing that, you know, they
have used in the past. So I guess maybe you can explain
a little bit why there are such love and hate relationship.
And what are you trying to fix, uh, in this new spec?
So, I mean, I'm not... I'm not sure if I can give you a
great explanation. It's something that I, you know,
spend time, you know, have spent time trying to think about and
trying to understand what it is that people are saying when they
say they hate ORM. And unfortunately, a very
unfortunate fact is that very often they don't actually give a
proper explanation of what it is.
And so I'm often left a little confused.
And sometimes when there is some sort of an explanation, it's,
you know, not a particularly good one.
But I have some speculation. First of all, I think there's
some aspect to it, which is just that any persistent solution and
certainly a powerful object relational mapper like Hibernate
is a very complex piece of technology.
Anytime you insert something complicated into your program,
there is some sort of a cost to that.
Okay. Without a doubt.
I think in addition to that, in the past, things like Hibernate
picked a way of doing things which involved more magic than
some people probably wanted, right?
And so this comes back to this thing I've talked about quite a
lot with the fact that, and this was, you know, let's be clear,
this is what most people ask for, right?
This notion of a stateful persistence context of managed
entities. So these objects that represent
the state in our database, you know, belong to a first level
cache. There are automatically dirty
checks. So if I change them, the change
to them is automatically propagated back to the database.
Everything happens sort of asynchronously.
So me calling the persist method doesn't actually do very much.
And that programming model is obviously more difficult to
reason about. I don't think there's any
denying that. And it's certainly more
difficult to debug. And so I speculate that this is
a major factor in people who dislike ORM.
I don't think that what they dislike is the object relational
mapping bit. I think the bit that they
dislike is the, is the, um, is the, is the, uh, you know, the,
the stateful persistence context bit, right?
And here we come to what I think, you know, may have been
one of my worst mistakes in my career, which was that in
Hibernate 3.0, we, you know, kind of recognized that there
were cases where, you know, um, stateful persistance concepts
simply weren't appropriate. And so I kind of threw the, I
quickly did this thing called stateless session that was sort
of, you know, obviously in an incomplete state, threw it out
there, and then I went to work on other things for 15 years.
And because it wasn't in JPA, because in our documentation we
kind of, you know, presented it as this thing for bulk
processing, which wasn't a sweet spot of ORM anyway, right?
People just didn't use it, right?
And it wasn't finished. And because nobody was using it,
nobody thought to finish it, and because it wasn't finished,
nobody felt like this was a viable alternative, right?
And when I kind of came back to persistence, I looked at all
this and I, you know, tried to, you know, trying to think about,
well, okay, even though this is clearly, you know, empirically,
this is clearly the thing that most people are using, right?
Why is it that we have this minority of people who dislike
it? And one of the things that
really hit me is, well, you know, they probably don't like
the stateful persistence context programming model.
And so that was a mistake. You know, we should have had the
stateless model in JPA from the start.
Anyway, so it's gonna be in Jakarta Persistence 4.0 like,
you know, two decades too late. And, you know, you have me to
blame for that. Um, you know, I shudder to think
at how many billions of dollars or something of lost
productivity result from that one error.
Forgive me, you know, um. Yeah, so that was a mistake, um,
that we're belatedly fixing. Stateless session is now fixed
and Jakarta Data by default, you know, in implementation go
through stateless session, you know?
Um, and so hopefully people now, you know, those people who you
know now have an alternative, which is less magic, which they
have more control over. Another thing is, you know, I
think that Hibernate, at least, you know, when, if you see
people complaining about Hibernate, at least in the case
of Hibernate, I think that it was originally developed with a,
you know, with a view of what was good error reporting that
was actually relatively okay back in 2003 or whatever, when
things typically didn't have great error reporting.
But, but that, you know, kind of got stuck a bit there.
And, um, one of the things we put a lot of work into recently
is improving all the error messages you get out so that
people aren't left... You know, and I would, I hate it
too, right, when I'm trying to use something and I do something
wrong, but it spits out some message that doesn't identify
what it is I did wrong. And I think that Hibernate used
to be quite bad at that. It wasn't the worst.
I've seen much worse things, but, um, but it used to be quite
bad at that. So that's another thing, I think
where we really went wrong, and that probably is a major, was a
major contributor to people who are hostile to objectional
relational mapper as I'm sure that we weren't the only object
relational mapper that have poor error reporting because good
error reporting is actually really, really hard, especially
with a, you know, when you have this.
Yeah, I mean one of the problems we do have to deal with is that
the databases themselves and the JDBC drivers tend to report
errors in a atrocious way. Um, and so then we have to
figure out how to make sense of it.
But, um, yeah, I mean, we traditionally did a bad job on
that. We do a much better job on that
now. Um, so there's, those are two
things. And I think, I like the way you
explain it, right? Because in the very beginning
when people pick up Hibernate or maybe learn a about it.
The magic thing really stood out like, whoa, what do you mean?
Like it can flush all this thing automatically.
You can just make changes to the object.
It knows how, you know, to update the database and all
that. But obviously when you start
building enterprise applications, when many
developers are working on it, it's really hard to debug,
especially when things happen asynchronously, right?
And maybe that's some of the reasons why people hate it.
The other one is probably about association, I suppose, like
eager fetching, lazy fetching, you know, when you have one to
many, many to many, those kind of stuff.
Yeah, but I insist that this problem is fundamental, okay?
That this problem you will have to deal with even if you're
writing your stuff by hand, okay?
Well, okay, look at the way I tried to present it last night,
okay? You have two options.
Not really, because I didn't actually choose.
There's a linear space of options in between.
There are two extreme options, right?
One of the extremes is I don't need entity classes, right?
I'm gonna have queries I write in SQL or whatever.
It doesn't have to be in SQL, in JPQL, no problem.
And I'm gonna have these little records, right, which model the
shape of the result set of the query, right?
This is actually reasonable, especially on a smaller program.
Excuse me. If you have a, you know, just a
few screens, this is entirely reasonable.
It works. You write a query, which fetches
exactly the data you need, and then you have something which
will slot it into a list of records, okay?
Thousands of things will do that for you.
I mean, you know, yes, you can use Hibernate to do it for you,
but you can also use much simpler things as well, right?
So that is an option. Now I am never gonna tell you
it's a terrible option. I'm never gonna tell you it's a
bad option in context. What I'm gonna say is that I
don't believe it's the best option in all contexts.
And I think that the fact that by far the overwhelming majority
of enterprise developers are not choosing that option is a very
strong hint that in fact, in most contexts, it's not the
better of the two options, okay. So the other extreme is that you
have Java classes, which represent the entities, the
basic things in your model of the problem domain.
And the things and the, the fundamental constructs you work
with in the business logic in your program are graphs, not
trees, excuse me, um, you know, graphs of not even DAGs, but,
you know, serious graphs of entity instances.
And it doesn't matter whether you use ORM or not, you are
gonna have to deal with the following simple fact.
In a relational database, this meant this is probably not the
case with a document database, that's murkier, right?
But in a relational database, you do not have trees.
Everything is interconnected. It's a, you know, it's a fully
connected graph or a graph with, you know, a small number of
connected subgraphs typically, okay.
You cannot just go, gimme the book and everything that's
related to it. No, 'cause everything is
related, includes all the authors and all the other books
they've written and all the authors of all those books.
And pretty soon it's the whole database, okay.
And the, and it's publisher and all the other books are
published by that publisher, and yeah, pretty soon, and it's the
whole database. So you have to determine where
to stop that graph, right? This didn't arrive in the
option, in the first extreme option because, you know, we
kind of had a different type safe model for each, for each
query, right? But over here where we're trying
to share the same model between all our bits of, you know,
business logic, this problem arises.
You know, because of how shared that entity model is, we can't
into the type system engineer the fact of where the graph
stops. And so there's this fundamental
hole in how this is typed. That hole is plugged by lazy
initialization exception. Okay.
And so what happens, right? If I'm, if I approach this
naively, you know, what happens? I run into one of two things.
I run into, you know, lazy fetching happening.
One I didn't want it to be happening, and N+1 selects.
I run into, oh, lazy initialization exception.
Why didn't they, bla bla bla. Okay.
There's a solution and a solution involves discipline,
alright? And I insist to you that this is
not anything to do with using an object relational mapper.
It is a fundamental aspect of using graphs of entities to
represent your data and having a database that's external to
that. You have to specify upfront what
data you're gonna use in this transaction, have that data
fetched in an efficient fashion, and that is certainly no easier
if you write that code yourself in SQL.
In fact, it is harder. Hibernate makes that much, much
easier. And this is where people like
get wrong. What they get wrong, right.
But you have to do it, you have to specify explicitly, right?
What happened? People have been sold, not by
us. Okay.
We have always said right from the start, there is no such
thing as transparent position, eh, persistence.
People have been sold in some books this notion that
persistence can be transparent. There's all this stuff that, oh,
oh yeah, what's it called? Ports and adapters or something
nonsense. Um, that, oh, we can have, you
know, persistence is adapter or something, right?
And we can just swap it in and out, right?
No, you, no, you cannot just swap persistence in and out,
right? It fundamentally impacts the
whole, um, the whole way you define the behavior of your
application. You have to specify, I'm gonna
be needing this data, right? Get me this data in an efficient
way. And then I can start navigating
my graph of objects and, you know, if I run into lazy
initialization exception, that's my indication that I needed to
get more data, um, before I start writing, um, N+1 selects.
Interestingly, the stateless model where lazy fetching is an
explicit operation rather than an implicit operation because
this thing is not a managed, never a managed entity, results
in more lazy initialization exceptions.
And that's an advantage, right? Because it's telling you, oh,
you didn't have the data you maybe thought you had, right?
And so you're far less likely to accidentally get N+1 selects,
um, happening. I hope I explained that well.
Yeah, definitely. I think it's, again, the
discipline that you mentioned, right, for developers, right?
Especially when accessing data. I mean, many developers just
think, okay, we, I can just query, do whatever I need and
just pass it back to whatever that needs it, right?
But I think thinking about transaction boundaries, that's
the first thing that is, can be difficult, right?
You want it to be short as much as possible.
And then second thing is fetch as sufficiently as possible.
And this could relate to the type of database that you use,
right? It could be relational, it could
be document database. Different databases, different
characteristics when you query them.
It relates to also how, um, you can, if you introduce a second
level cache into your system, that's also gonna impact how you
fetch it. Yeah.
And cache is always like the most difficult problem in
computer, I guess, yeah. So definitely, uh, thanks for
sharing that. And I believe these days, right,
there's also a way for you to mix and match, right?
So like what you mentioned the two extreme, right?
So for some problems, maybe you can use ORM which is much more
effective and efficient, especially when you have so many
columns. I don't think we want to write
it, although now maybe coding assistants can help in a sense.
Uh, but in some way when you actually need to kinda like in
detail specify the queries you can use, you know, the stateless
option or maybe the records result set kind of, uh, types to
actually represent that. Yeah, so I think, yeah, as I
said, so I think that is these two extreme options where, no,
I'm gonna use this everywhere, and oh no, I'm gonna use this
other thing everywhere. And no, I think the best option
is to, you know, use the thing that's most convenient in this
particular context and which gets you want, where you wanna
go fastest. And, you know, certainly, you
know, any decent ORM solution will make it very easy to use
either of those options. Right.
So maybe if you can share a little bit some these exciting
things that you are building in this new specification that
people can expect, right? Because when I watched you last
night, I'm excited myself to see, you know, wow, there are so
many cool things that I can do, you know, especially the
repository and the find annotations and all that.
I find it quite exciting, actually.
I wish I could probably have some chance to work on Java
again, but maybe... What are you writing with?
I'm currently using TypeScript more.
Yeah, yeah. Sorry, you said, yeah, yeah,
yeah, yeah. So maybe tell us some glimpse,
maybe like a marketing pitch, uh, why people should consider
this new Jakarta Repository Data and QL.
Yeah. So, um, right, so I guess the
fundamental thing is I'm not, you know, I'm never gonna tell
you you have to use this, or you have to use this.
I'm gonna say, try this out and see if it fits your flow.
So, yeah, so Jakarta Data, at least in our implementation, the
primary advantage that it offers is the ability to immediately
get that feedback of, oh, my query is correct or my query is
wrong as soon as you, as you're authoring your code.
You just press, you know, command back slash in IntelliJ,
sends it off to the annotation processor and the annotation
processor will give you meaningful error messages back.
That's to my mind the primary reason to use this.
Of course, there are people who have other reasons for liking
repositories. Some of those reasons are good
reasons, some of the reasons I find unconvincing.
Um, but, you know, one simple, one reason, which I think is,
you know, it sounds kind of silly, but actually I think it's
a good reason, is it gives you a place to put your queries,
right? Um, you know, I don't think
there's anything wrong with writing queries directly in the,
you know, controller or whatever.
Nothing wrong with it. And you know, again, it depends
on what complexity it comes back, you know?
But I see the desire to have your queries in some persistence
place, right? And so I think repositories are
a reasonable way to think about organizing your queries, right?
I think that the pre-existing approaches to repositories fail
to deliver in this respect because they have the notion
that there is a one-to-one association between repositories
and entity types. And I think that's actually
incorrect. I would go, so, you know, if I
want to take an extreme position on this, I would say, you know,
why not have repository per controller, right?
Um, and so, you know, if you have a, you know, that's likely
to be a construct with a higher cohesion, right?
Of course, I'm not advocating that you, that's what you should
literally, that's what you should do.
No, you should think about how, where do I wanna arrange,
organize my stuff? So yeah, so repositories give
you, or at least in Jakarta Data, give you a flexible way to
organize your code that I think is appealing, with this type
safety, which I think is a major selling feature is a real step
change to how productive you can be using JPA or whatever, right?
Secondly, another new thing that we're working.
It's not there yet, okay. This is, I'm talking about
Jakarta Data 1.1 now, is this issue of dynamic,
programmatically constructed queries.
So in the very early days of Hibernate, there was this thing,
we had a criteria API, where you could kind of build a tree of
restrictions on an entity and, you know.
I guess you know what I mean by a tree like query, right?
It's, you know, we don't have kind of restrictions which
involve, you know, two leaves of the tree.
And it wasn't type safe, it was all strings and it was kind of
janky. That's the weird way, daughter
taught me. And we kind of have left that in
the past. In fact, that doesn't even exist
in Hibernate 6. Um, now, there were actually at
some point I noticed when we took it away from people, we
noticed that there were people who actually really liked it and
complained that this totally rubbish thing, you know, that
from 2000 and, you know, whatever, that there were people
who were still using it and actually found it to be the most
convenient thing. What happened in JPA 2, people
wanted to have like a criteria API, which was a full model of
everything you could do in JPQL. And they also wanted to be able
to have multiple implementations so that each vendor could have
its own implementation of the criteria API.
And then I came along and I wanted it to be type safe.
And so we got this monstrous API that it's, you know, at some
point, for 10 years, I would look back at this and go, oh
wow, I really associated myself with that.
Now, funny thing it's about is that during those years, support
for annotation processes got better.
Java introduced the var keyword. We found some, a bunch of other
things we could do with static metamodel.
And now I am actually like super happy that we did that.
And in fact, the criteria API isn't as bad as it used to be.
And also people just got more used to working with generics
and the whole thing is, you know, less embarrassing, much
less embarrassing than now than I felt about it for years and
years and years. Um, but it's still nobody's
favorite API, I think is fair to say.
Um, it's quite verbose. It's quite good for vibe coding,
interestingly. Yeah, the code assistant seem to
do a good job with it. But it's not great.
So we had this, so I think for years and years and years we've
had this hole between, okay, JPQL for static queries, the
criteria API, which is the whole hog of being able to completely,
entirely construct everything about the query completely
dynamically and programmatically, and yet I
think that what most people actually wanted was something in
between those two extremes again, right?
Jesus, it's a very recurring, recurring theme here which was
that they wanted to be able to, you know, they had some search
screen and they wanted to be able to programmatically add
this, a restriction on this field, restriction on this
field, and no restriction on this other field, right?
So, uh, in JPA 1.1, we have, you know, rectified what I think,
you know, that historical mistake, I think.
And we're in the process of introducing an API, which is,
you know, in some sense you could view as a, you know, a re,
you know, a rethinking of the original API and old Hibernate 4
treelike restrictions. I think it's actually super
elegant. I don't know what other people
are gonna think. It's, again, these are APIs for.
These APIs for, uh, internal DSLs.
I know, I always forget which one's external, which one,
internal DSL, right, are naturally complicated.
Especially if you want type safety.
But I think it's, elegant. I think it's nice.
I think it's easy to use. And so I think that is gonna be
a step forward in terms of solving something that
traditionally was left, you know, unsolved.
Right. Thanks for sharing some of
these. I'm not sure how people can
follow without even trying, right, or seeing your demo,
right? So definitely, I personally,
again, I shared my experience, uh, when I saw your talk.
I'm very excited, even though I'm not a Java developer
anymore, I'm, I feel excited. And I'm sure so many other Java
developers out there who saw it, uh, will find it very exciting
and useful as well. I think the feedback loop is
really, really good, right? So I think hopefully the project
turns successful. I can see throughout the way you
explain stuff, you are, even though you try your best, not to
say that there's a best architecture, but you tend to
intentionally think about architecture.
And there's a context specific to some people, right, um, that
people need to understand before they pick a certain
architecture. So maybe if you can think or
maybe explain to us like, how do you actually explain an
architecture so that, you know, people know what's the best
thing to adopt for their context?
Because I mean, these days, so many people talk about
architecture wars, right? Okay.
I have microservice versus monolith.
I have DDD versus, I don't know what else, right?
I have, I don't know, Spring framework type versus, you know,
all the others. So maybe how Gavin actually
thinks about architecture. Maybe if you can give us, I
don't know, some advice here. Yeah.
So first of all, you know, to begin with, um, I had long had a
policy of attempting to avoid giving any advice on
architecture, because number one, I don't write application
programs and I haven't written an application program since I
was 20 something. And so whatever advice I could
possibly give is almost certain to be wrong, right?
And I think, you know, generally that our whole team had that
view that, you know, we were better off providing a library
with powerful primitives. You know, even if you look at
something, you know, you could say, look at CDI and say, okay,
CDI was this thing. That is more of a framework.
Or if you, you know, you look at the whole platform and say it is
more of a framework, okay. But, you know, I always want it
to be a very flexible framework that, you know, in fact, you
know, one of the goals of CDI was to not force you into this
layering that existed, you know, and to give you the flexibility
to introduce that sort of layering if you wanted to, but
not if you didn't wish to. My goal has always been give
people power, powerful primitives so that they can
implement whatever sorts of architectural decisions they
wish to implement, okay. Unfortunately, if you kinda
withdraw from that space of giving people advice.
What happened at is that, you know, into that vacuum caused a
deluge of people who have lots of opinions, right?
And I think I sort of see, you know, sometimes when people have
been, you know, made to feel that they have to do something
in such and such a way where the basis for that, for the idea
that they have to do it that way is just not there, right?
There is no mass. But you know, the whole
discourse around design patterns and architectural patterns lacks
foundation in logic and math. It lacks empirical foundation,
you know. Yeah, okay, this worked great
for you on your two projects, but like there is nobody out.
Like, I think what people need to understand is that this
so-called experts, there is nobody out there who has spent
10 years developing and maintaining more than two or
three projects, all right? There is nobody like that.
Why? Because people aren't that old.
So either they've skipped from project to project to project,
and never had to deal with any of the consequences of their
decisions. Or they've really only worked on
two projects. And so when you hear people
making that sort of advice, you need to understand that worked
for them in the context of the two projects they worked on.
Or, you know, or maybe they never actually even had to
maintain a system with this, with these decisions.
And in which case, I, you know, I really, you know, I'm sorry,
but I'm gonna treat their advice with a great deal of skepticism,
okay? So what do I say instead?
If you can't trust the advice of architecture experts, you know,
what should you do instead, right?
Because obviously, you have to, you have to have some basis for
making decisions, right? And so what my advice is, and
it's always been my advice, I think.
It's always been my position, but is more and more my position
recently, I've been radicalized on this lately from seeing this
discourse around DDD. Um, my now radicalized position
on this is that architecture is something that has to emerge
naturally from the code, right? The code should be pushing you
in a particular direction. If it's not, then you need to
have a different relationship with your code, right?
A relationship which is based on being very critical of it,
right? It's kind of obsessively trying
to make it beautiful, obsessively applying the, you
know, the first commandment of software engineering.
Don't repeat yourself, right? Oh God, I see recently, lately,
a particular some type of meme on LinkedIn of people
challenging DRY and saying, oh, DRY is rubbish.
You can, you can repeat yourself.
And then, and you know, until you have like three instances,
it's okay that you repeat yourself.
No, no, no, no, no. DRY is fundamental.
DRY software engineering is about dry.
It is the most basic, it is the most basic principle.
And as soon as you have two instances of the same code, you
should refactor, right? Like, I'm sorry, I, I'm, you
know, as soon as you have two instances, you have the prob,
you know, the possibility that you make a fix there and you
forget to make it there, um. So the process of arriving at an
architecture is a process of obsessively refactoring,
iteratively, you know, arriving at something that works
naturally in your context. Now, yes, it does involve
thinking about modularity. It does involve thinking about
APIs. It does involve thinking about
layering, you know. Now layering is this thing
where, you know, layers are easy to come up with when you draw
boxes and sticks on whiteboards, right?
But layers come at a cost, right?
I would never say never use, never introduce layers.
We certainly have layers within Hibernate.
But layers should be, you know, something that you introduce
with care when you can see that they actually have make,
actually make things better at the code level.
But everything has to be done. Architectures have to be
motivated from the level of the code.
If they don't make the code better and more elegant and more
flexible, then you should not be doing them, right?
And so somebody who comes in there with their massively
cooked architecture and all these patterns and says, yeah,
you should be doing things this way.
I'm sorry, but no, you shouldn't, unless you can show
me that that makes the code better.
Makes it simpler, more elegant, more, um, better factored.
That is my view. I guess the main point that you
mentioned about architecture should emerge from your code
base, right? And the kind of problems that
you're dealing with. That's the first thing.
And iteratively refactoring it. I think maybe this part is kind
of like what people don't aspire to do for some sense.
Yeah. So here's, so here's the thing,
I guess the counterpoint to everything I've just said, and I
guess the best argument against it, right?
Which is always what you should try to do.
And if you're gonna start ranting on a podcast about your
dumb opinions on something, right, then you should ask, you
know, what's the best argument against this?
And I think the best that you've exactly identified what's the
best argument against it. The best argument against it is,
oh, I don't have time for all that refactoring.
I'm just trying to solve this Jira issue, right?
So what do I think? I think issue report driven
development is a major problem for many types of projects.
Certainly for the kind of projects which we have.
You know, if everything we do is responsive to a complaint from a
user, what happens? You get a product whose
semantics have all sorts of special cases, right?
For a product like Hibernate, that is death, okay.
Like that produces a product which cannot be reasoned about
for anybody. Why?
Because it has all these little hand engineered in special
cases, for, you know, for that guy over there wanted to work
like this. That guy over there wanted to
work like this. And now I can't reason about
what is the correct behavior, right?
This is far worse, obviously, if you don't have a spec.
If you have at least a spec, right?
You know, okay, well, what does the spec say we should do?
And what can we infer from what the spec says about what should
happen in this case, even if it's not explicit?
And so to me, yes, it's important to solve issues, issue
reports, obviously, okay, um, it's very important.
But we should never just assume, we should never approach an
issue report assuming that what this user is asking for is
something we should do, right? And I piss off a lot of users,
right? Because I'll be like, no, we're
not gonna do that. I, you know, and I am, it is not
that I don't see why you want me to do that, right?
I do see it, right? I absolutely see why this is
what you need. But from, I don't wanna say high
level, but from the, well, yeah, from the broader perspective of
where does this take the semantics of this whole system,
we're not gonna do that. Um, and you know, on the side
of... I, look, I don't like people
spending time doing grandiose refactorings that, you know, you
know, I introduce some, you know, again, box and sticks on
whiteboard. Oh, we're gonna do this 'cause I
like it, right? No, don't do it that way.
But what I do really like is sitting there, spending some
time looking at this code, and spending some time and trying to
improve the code, right? And out of that should emerge,
if you do it well, an architecture or layers or at
least, you know, elegant ways of reusing functionality and
semantics, which are consistent across different, you know,
parts of the product. Yeah.
And I like the keyword that you mentioned, systems that people
could reason about, right? Don't forget you work with
multiple developers. You know, if you don't have a
one uniform way of doing stuff, I guess it's pretty difficult to
reason and evolve the system. Make code change, even bug
fixing, right? Sometimes it can be very, very
difficult. So you mentioned a little bit
about DDD, I don't know whether we should go there...
I've made it my punching bag or something recently.
But, um, look, I mean, I, look, I'm not gonna represent, put
myself on some expert on DDD and whether it works or not, I have
no idea. You know, maybe it works for
some people, you know, like I'm sure it does, you know, some
people seem to like it, okay. What I don't want is for the
assumptions behind DDD to find their way into technologies
we're using, right? And that has begun to happen in
some areas. So we see a framework which will
remain nameless, which is advocating that things have to
use aggregates and admits in the documentation that this is to
some extent, it wasn't unnatural is the word they picked.
It was a untraditional or traditionally not the considered
the normal way to work with a relational database.
I can't think of the quote off the top of my head.
That is like, that's, you know, massive red flag, alarm bells
going off as soon as I see that, okay.
As soon as somebody says that our, our framework makes, has
the expectation that you're gonna work with your relational
database in a weird way. Okay.
Um, no, we wanna work with relational databases in a
traditional, normal, um, natural way.
And so to the extent that DDD advocates this idea of
aggregates, and one of the problems in talking about, one
of the problems in talking about all this stuff is that none of
these things come with particularly robust or rigorous
definitions, okay? And so if you read the
definition of aggregate, I mean, it doesn't, I'm not even sure
that any two people agree on what it means.
And you read it and you try, you know, with the perspective,
okay, look, let's, you know, be as charitable as possible and
let's try to assign to these words the most charitable, you
know, meaning to them. And I've been through that
exercise, you know, what most charitably it could possibly
mean? You know, even then I cannot
escape to the conclusion that they think that relational
databases should be document databases, okay.
That the data exists as a discreet set of trees.
And the process of retrieving data is a process of retrieving
of the root of the tree and then working through the data from
that root. This is neither a natural, nor
is it a correct way to work with relational data.
Relational data is not made of trees.
That is a document database, and if someone can't distinguish
between what is a document database and what is a
relational database, then please be very careful about taking
their advice on data. And so yeah, that's been a
little bit of a jihad I've been running, um, recently about
against, you know, telling people no, look.
Um, aggregates don't, you know, probably don't make sense.
Yes. I'm not saying it's impossible
that you could find an aggregate, you know, you could
find a tree somewhere in your data model.
Yeah. I'm sure you can, right?
But don't try to shoehorn everything into this, okay.
Don't try to shoehorn things into aggregates.
That usually doesn't make sense. Let's not put like a doctrine
that you have follow this a hundred percent.
Always. I think any kind architecture
there'll be the plus points plus the negative points.
It's all about trade off at the-end-of the day.
So think picking the right architecture for your context
can reason probably is the most thing that people should aspire
to work on, right? Yeah.
Like trusting in some sense. That whole advice, that whole
rant was trust in your own intuitions about what's gonna
work for your system, right? Like people like, you know,
trust that it's okay, you know. When I was, how old would I be
26, 28? You know, I told my very
experienced manager, no, we shouldn't do entity beans, okay?
Even though IBM and Sun and everybody were telling the whole
world they should use entity beans, right?
No, you can be right and everyone can be wrong.
Like this is the thing that happens, right?
As long as you have good reason, as long as you do understand
your own system and what your system does and, you know, you
should do the thing that seems natural and works.
Yeah, I think that's very inspiring.
Definitely. And look what it had led you,
you know, to creating Hibernate, working on specifications and
all that. I think again, we as a community
can thank you for your contributions.
Gavin, I think it's been a great conversation so far.
I think many people would have learned a lot from listening to
this conversation. Unfortunately we have to wrap
up. Before I let you go, I have one
tradition in my podcast to actually ask this question I
call the three technical leadership wisdom.
You can think of it like an advice that you wanna give to
listeners. Maybe if you can pick the top
three version of your... I'm nervous, all these things.
Yeah. Go on.
Go and shoot. Yeah.
So yeah, maybe if you can share that would be great.
All right, so there's one thing I've been on about recently.
Um, I think I've recently seen a lot of it over the last years.
I've seen a lot of advice that would tend to tell people,
instruct people that they should be more agreeable.
And that people who are disagreeable and opinionated and
prepared to fight for what they believe with are so-called quote
unquote toxic people. Now, in my opinion, as soon as
you see someone describing someone else as toxic, then you
should be asking the question of who is the truly the toxic
person here? People have different
personalities. There are people, you know,
disagreeableness, agreeableness is a, is, you know, is one of
the big five personality traits, okay.
There are people who are more comfortable.
It's not about, you know, being insulting, but there are people
who are more confident, comfortable with disagreement,
and there are people less comfortable with disagreement.
When somebody who is a person who is comfortable with
disagreement disagrees with you, they're not attacking you
personally. They are trying to find, most
likely just trying to find a way to the best, you know, a
technically good solution, right?
The road to consensus passes through disagreement as a
necessary way point. We cannot possibly arrive at a
consensus if we don't all express forthrightly, honestly,
and with the necessary force to, you know, our opinion, our...
and not necessarily even just our opinion, but the issues that
we're concerned about that the solution has to satisfy.
And, um, and, and we have to pass through that point of
disagreement to arrive at consensus.
Otherwise, we are not achieving a consensus.
What are we are achieving is an end state where nine out of the
10 people have shut up. And so I think we need to come
back a bit from this question of some people are toxic because
they have opinions. And, um, start looking at it as
how can we facilitate, you know, how can we work to facilitate
these kind of discussions so that people are less comfortable
with this agreement can also feel safety to put forward their
views and, you know, it's not just someone bullying the
others, right? But, you know, but that also
that we're actually having these discussions and we're not just
telling, you know, young developers, they need to shut up
and do what, you know, what their boss or whoever you know,
is telling 'em to do. I think that that is the risk
with this kind of talk I see a lot on LinkedIn.
I think the risk is that you're giving people the idea that they
should shut up and go along with the, um, go with the flow,
right? And so in my opinion, that is
probably not great career advice, ultimately.
You know, your best career advice is to learn how to put
your your disagreements forward in a, in a way which generates
the least possible emotion with understanding.
There will be emotion in it, right?
There, emotion is a natural part of it, of this process.
So I know that that's something which you can take it or leave
it, you know? That's just some opinion I have
of all. Um, I'm not saying I'm a expert
at, you know, any of this. Right.
Thank you so much, Gavin. Uh, it's, again, it's a pleasure
to meet you, listened to your talk and had a chance to
actually talk to you in person for this episode.
Again, thank you so much and I hope you enjoyed this
conversation. I did.
Thank you very much, Henry, for having me on.
It's very fun.