#232 - Hibernate Creator on Why Developers Hate ORM (And How We're Fixing It) - Gavin King

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.