Foojay Podcast #71: Celebrating 30 Years of Java with James Gosling
InterviewsJava

Foojay Podcast #71: Celebrating 30 Years of Java with James Gosling

We are celebrating Java’s 30th anniversary this May!

This is a very special anniversary episode of the Foojay Podcast! As we approach May 23rd, marking exactly 30 years since Java’s first beta release in 1995, we’re honored to present our first-ever single-guest podcast. But we have a very special guest for you: James Gosling, the creator of Java!

Join us for this exclusive conversation as we explore Java’s beginnings, its revolutionary impact on the programming world, its continuous evolution over three decades, and James’s insights on where the language is heading. From that groundbreaking beta release over “Write Once, Run Anywhere” to powering billions of devices worldwide, this is the story of Java, told by the man who started it all, the father of Java.

Video

Podcast Apps

You can listen and subscribe to the Foojay Podcast on:

Content

00:00 Introduction

01:06 How did it start 35 years ago?

06:21 Java evolved from device controllers to server applications

10:30 How does it feel that so many people use Java?

12:12 Looking back at the Y2K problem and how it triggered more Java adoption

14:58 Does James regret any decisions in Java?

18:44 Comparing early-day Java development versus now

20:55 About the stability of Java

24:14 JavaFX is one of James’ favorites of all time

25:20 Frustrations about Android and iOS versus Java Phones

28:16 How “Write Once, Run Anywhere” was needed for Sun

29:23 Windows versus macOS versus Linux for laptops

31:32 The very first Java web service in 1994 turned into a dark story

33:17 Java in Docker and startup challenges

36:59 Garbage Collectors are amazing in many ways

39:18 Java-haters didn’t use recent versions of Java …

41:51 How Java became much more performant but lost embedded

43:08 Developers must be aware of which and how many libraries they use

47:40 James loves Kotlin, Scala, and Closure

49:42 Ethical responsibility for developers in a challenging job market

54:16 AI influence on jobs

01:00:20 Advice for junior developers

01:02:27 A few of the most remarkable moments in Java history

01:07:52 Why James is not a benevolent dictator for life

01:09:17 How Java will keep evolving

01:12:55 How much is James still involved in Java?

01:13:54 Conclusion

Transcript

Automatically generated from the audio, so it can contain errors in names and technical terms. Suggest a correction.

[0:01] Welcome to the Foojay podcast where we celebrate Java’s 30th anniversary this May. Welcome to the Foojay podcast. All your news about OpenJDK. In the previous podcast, we celebrated 5 years of Foojay. In this episode, we have another celebration. As we approach May 23rd, marking exactly 30 years since Java’s first beta release in 1995, we’re honored to present our first ever single guest podcast. But we have a very special guest for you, James Gosling, the creator of Java. Join us for this exclusive conversation as we explore Java’s beginnings, its revolutionary impact on the programming world, the continuous evolution over three decades, and James insights on where the language is heading. From that groundbreaking beta release override once run anywhere to powering billions of devices worldwide, this is the story of Java told by the man who started it all, the father of Java. Thanks for joining this recording. Thanks for your time. Thanks for starting Java 30 years ago. how is life going?

[1:16] More like 35 years ago. But yeah, maybe if we jump back 35 years ago. Why and how did you start this? It started in late 90 early 91. a bunch of us were, you know, noticing computing showing up in all kinds of different places. It wasn’t just sort of data centery things, you know, scientists work desks, that kind of stuff. and it felt like digital systems were expanding and you know we were pretty tuned into that back then but it felt like the business wasn’t paying attention that son wasn’t paying attention. Mhm. so Scott said, “Okay, grumpy people, go off and investigate this for a while.” And so we did. And, you know, one of the things that we did was we went and we talked to people from in all kinds of industries who were using, you know, computers and the stuff that they were building. and you know everything from people building VCRs to elevators and locomotives and we did a lot of touring around. I mean it was quite a fun bunch of months just going and visiting people all over the place, you know, people in Europe, people in Asia, you know, who were building

[2:58] Things. And you know, lots of things came up. Some of it was really frustrating. So, so like like like a theme with most of these folks was they were putting networking in everything, but they were reinventing networking. Mhm. You know, they were doing the kind of invention that computer science had done, you know, a couple decades before and knew why they would fail. you know, so they were doing a lot of things with serial lines. They didn’t have as as much error correction as they needed. you know, people doing these industrial automation things with 8bit addresses. It’s like, no, 8bit addresses do not scale. 16 bits is still not enough. And yet there were stuff that we was that we were learning from them in requirement stocks that we saw with folks. They would never talk about like safety and reliability.

[4:15] Not because they didn’t care about safety and reliability, but because safety and reliability were such a big deal that there was no point putting it on a on a list because, you know, it was like it was like saying, you know, oh well, let’s let’s build a house and we’ve got to remember to put oxygen in it, you know. It’s it’s it’s just like the unspoken requirement that you that is deeply not optional and at the time performance was everything in computer design and it was pretty common for people to shave off a little reliability if they could get a little performance. Mhm. You know, my and my favorite example of that arrow was the way that they did division was they used a Newton’s method solver rather than the long division you were taught in high school or at least the electronic version of that.

[5:26] So the their division worked really really fast, but you know the low order bits were kind of sketchy. People were doing this all the time. And you know, even even at Sun, you know, people would make make tradeoffs that made, you know, a bunch of us a little uncomfortable. Mhm. You know, for a lot of these folks, you know, lives were on the line, right? But if you’re building the control system for a locomotive or an elevator, when things go wrong that you usually end up with blood somewhere. Rule number one is don’t kill your customer, right? Pretty important rule. Yes. Yeah. But I find it amazing that you’re talking about locomotives and toasters and people who are using Java nowadays.

[6:29] For them, it’s a server language, something you deploy on big servers and that’s the whole difference. Both directions are true at the same time. Mhm. There was a whole lot more money in the in the enterprise world and so that’s that’s kind of where Sun dumped its investment. and things kind of went a little squirly. But nonetheless, when you look at a lot of the things that people are using web services for, you know, if if it’s anything from airline scheduling to scheduling a car to pick you up to running a mass transit system, you know, it’s it’s like, you know, we had been thinking of devices like elevators and other people were thinking of devices like the London Underground. The scale is different, but you know the consequences of failure were pretty much the same if not larger. And so when things go sideways, they go badly sideways. One of my frustrations with C had been how easy it was to make mistakes that were hard to fix and would have strange consequences that were hard to diagnose. So many corner cases. Mhm. You know, when we started doing this

[8:08] Project, you know, we had sort of surveyed the landscape of things that people were doing and came to understand, you know, what people were doing. And we started building building some prototypes just because we’re engineers and we do prototypes better than white papers. Oh, yeah. You know, one of the nice things about prototypes is that they kind of force you to you know, mentally visualize the details. We had a few software engineers, a few hardware engineers. we had a really good business guy. As we kept thinking about the kind of requirements list that were coming from these peoples that we were talking to, a bunch of just sort of standard practice in the software engineering world just kept causing problems. And the biggest ones were the ones around reliability and security. reliability and security are kind of the same thing. or they’re often related because, you know, so many of the world’s security attacks are just bugs. I mean, sometimes they’re just g they’re gross stupidities, but I mean, is leaving the root password

[9:39] Blank a bug or a sign of gross incompetence? you know pick your poison you know we started using C and then it’s like yeah you started using C++ and then it’s like this is I mean these all have problems and then so I ended up being the guy in the project that was like okay let’s try to fix some of the methodology problems you know those method ology problems, you know, kept leading me further astray. Mh. You know, what started out as being fix some corner cases in C++ you know, became something quite a bit different. Yeah. Became a complete language, a complete community nowadays. Yeah. It’s one big millions of people working and using this Java that you created. How does that feel? Yeah. No, it feels really great. I mean, you know, I you know, the single best feeling I get from it is when somebody comes up to me and says, “Thank you for giving me such a great career.” I hardly know how to respond to that because it’s it’s wonderful. Well, I have to thank you myself because you’ve exactly done the same for me. I’ve been doing fiddling with computers since I was 10

[11:15] With the Commodore 64 that generation. and then found back my programming love when I was already working for some years as as a film editor. because yeah, I needed to find a way to get my video on the web. and somehow ended up doing Java and I tried different languages, but Java was the one that really catched me. I never got my head into doing C and C++. It doesn’t fit in my head. I don’t know why. But Java is the thing I create anything with it. That’s the only thing I need is Java, Java, Vix. And I can build anything that I want and landed me Yeah. in different jobs and I could build a career on this. So thank you. Sorry, I have to thank you also for this. Yeah. you know, seeing how it spread and I mean sometimes it has its downsides. I mean the whole Y2K thing was kind of terrifying. because a lot of people migrated from Cobalt to Java because of Y2K. Mhm. And you know I am the author of Javelang Date. I spent a whole like maybe maybe a whole week on it. You know, all the new all the fancy calendar classes have come since since

[12:47] The year 2000. But, you know, that night I could not sleep and I was like tuned in to every chat channel and there, you know, to try to see what was going on. Did anything go sideways? And of course we had run all kinds of drills, you know, taking computers, pushing their clock forward, you know, a month or whatever. So that we had been through Y2K like many, many times, but the real Y2K was different. Mhm. But still, you had these people who were saying afterwards, yeah, it was not so bad. They said the world would stop, but it was not so bad. But wasn’t it because all those engineers were already trying for years what could happen. Exactly. Exactly. Exactly. I mean, one of the difficulties with being an engineer is that the absolute best case for your job is that nobody notices. Yeah. Right. If you do something if something exciting happens, you have probably failed.

[14:03] Right. If you’re the kind of person who lives on, you know, agilation and adrenaline, maybe engineering is not for you. Mhm. Right. I mean, you know, you know, you have to get your thrills out of a bridge not falling down. Mhm. Right. It’s it’s like with the problem we had some years ago with Log4j there was a vulnerability so suddenly that library becomes a big problem but on the other side people put a lot of effort in that library a lot of people use it and simplified their job and then suddenly for that one thing which appears the whole system yeah it loses its fame but yeah it’s like you said if you don’t do anything you cannot do anything wrong, right? Or there’s many things like that within Java that you think I made a mistake.

[15:05] People will maybe say the null pointer or the null pointer exception. Was that a mistake? You know these things you know so many of these things they are a game of do you know what whack-a-ole is? Mhm. you know, this game where you’re you’re hitting moles that pop up and engineering is like that. And there are always tradeoffs. And you know, the trade-offs we’re best at dealing with are engineering ones, but sometimes the sociology ones are more difficult. Mhm. You know, so you know, one of the things I get hit up for a lot was generics. There was a big fight in 94 about generics that there was people who were like gotta have generics. Mhm. And I was like okay, you know, because these were people who were like using it and they had come from the C++ world, but C++’s generics were We got to do it right. And then the question is so what’s right?

[16:30] You know I talked to lots of people I mean you know generics and programming languages were like a big area of research and there was no consistent view on what would be good. Mhm. There was a contingent that said we should just not ship anything until we’ve got this generics thing. And it was pretty clear that it would cost us 2 or 3 years. Yeah. If we had delayed 2 or 3 years, the internet was exploding, right? I mean, it was in the really early stages of exploding. If we had waited a couple of years to get it right, we would have missed it. Mhm. You know, if if I just like slapped something in and it was wrong. Yeah. Which I figured there was like a 99% chance that undoing it would be difficult. There were lots of object-oriented programming languages that didn’t have generics and they worked just fine. Mhm. And then eventually you know there was this almost global competition for you know how should Java generics be done. Mhm. You know one of the big questions was you know how it interacted with introspection. Nobody came up with a solution that worked. you know it’s a it’s a debate

[18:05] The debate about what what’s called re reification. We could have made reification work if we had broken every app in existence, which totally breaks with the Java philosophy, I think. Yeah. And you know, when you’ve got a big community of users, you end up with a big responsibility to not screw them over. I hear from friends today even about you know that was a mistake and it’s like no it wasn’t a mistake it was a compromise. Mhm. Is there a big difference between how you as the founder of Java and the original creator, how you could work at those days and how the evolution of Java now goes with the JPS and the six month release cycle is it complete different approach I guess? Oh, it’s completely different. It’s completely different. you know, until the launch, I could make sweeping changes in an afternoon.

[19:14] And no harm, no foul, easy. Mhm. And I often did. There was the day I eliminated goto because I had finally had too much of how stupid it was. I mean I sort of by default sort of inherit decided to inherit a lot of what C and C++ did so that they would be familiar with people. But go to is one of these things that causes all kinds of weird corner cases and one afternoon I literally just got frustrated did some limited studies and went boom it’s gone. That was a tremendously luxurious time. There’s this really annoying engineering principle that gets used in Silicon Valley a lot that I have deeply mixed feelings about it and you hear it, you know, from people like Elon Musk and Mark Zuckerberg, right?

[20:13] Move fast and break things, right? And I’m all for that when you’re building a prototype. But once you’ve got people that are using it and that depend on it and all of that, oh man, the game changes completely. You know, I’m okay with the move fast thing. Mhm. but not a breaking. But not breaking. And often move fast is interpreted as just do arbitrarily stupid things to see, you know, how people about it. That is not a good customer experience. Yeah. You know, and that’s what a lot of people are surprised about that you can have very old Java applications still running on the newest runtimes, which is exactly one of the strong points of the old Java system. Yeah, a long time ago for a demo at something, I wrote a swing app to play solitaire. I still have that binary. It was written for like Java 7 or six or something and I still run it actually embarrassingly often because it is solitire, right? Which is sort of the game to play. Yeah. you know, the brain sucking magnet. But the thing is that, you know, that binary was compiled like 20 years

[21:50] Ago and it still works great. Mhm. you know, I I’ve played it on my brand spanking new Mac Studio, you know, on architectures and oss that did not exist at the time that the program was built. It runs great. Actually, it runs astonishingly well. I mean, all the all the graphic animations are just as smooth as as as could be. But that’s the whole right once run anywhere philosophy that was there from the beginning. Do you think that it still stands? It stands really well. Mhm. Yeah. I mean, it’s it’s not perfect, but it’s really pretty close. And you know, one of the things that I really like about it is that I don’t have to compile stuff over and over again. I don’t have to generate 20 or 30 binaries of things for all the different flavors of devices that are out there. Mhm. My solitaire program, the binary that runs on Linux is the binary that runs on Mac OS and I just have one binary. Yeah, that’s really nice. I mean, there’s there’s there are often, you know, places where things leak through. So like if you’re doing shell scripts or something then

[23:25] Ouch. But it’s not like Java is any worse than any of the other platforms. and really the only really painful outlier is Windows. Yeah. and how did that happen? Cuz Windows is unlike the others. I mean, most systems except Windows went down the down sort of the Unix path. And even even Windows now has their Linux subsystem which they kind of had to do cuz using Windows in the cloud is really expensive. I’m a big fan of Raspberry Pies. There are a bunch of them behind me and Raspberry Pi. This is a this is a Jetson Nano. Yeah, an old Jetson Nano. And also all these amazing cheap boards are perfect machines to experiment with Java and run any kind of Java. I have Java Pix applications which are very heavy with animations which just run on those platforms. Yeah. No, it’s it’s it’s really great. I mean the people who have I mean JavaFX is one of my favorite things of all time.

[24:51] Mhm. Man that crew has done such great work even you know even after Oracle basically disowned them. Do you think that Java VIX would have a bigger market share if it would get some some more love from Oracle for instance? I sure had hopes. Mhm. The world of desktop apps has become really fragmented. I find it fascinating that there are basically two, you know, for mobile devices, there are two foundational platforms, Android and iPhone, and they work just as hard as they can to be different. Mhm. You know, they really like their own distinctiveness, which I can totally relate to why those two camps want to do that. but wearing my, you know, developer hat, that just sucks. Mhm. And you know, even though Android started out as kind of a Java thing, the way that they completely broke all of the graphics and UI APIs was just I should shut up about Android cuz it just, you know, and we had the Java phone one day. Yeah. It never launched, I think.

[26:27] But could could we have Android, iOS, Java phones? Sure. Or would the A be better than than the other? Java runs great on iPhones. Mhm. The problem is that you know, from the very beginning, the iPhone terms of service don’t allow the use of Java for deployment. So people have the people who really want to do Java apps. and this is one of the place where the JavaFX folks really really went to town is that there are essentially static cross compilers that compile from the Java universe into the iPhone tool chain. Mhm. And then you can get things published, you know, you can get Java applications published on the iPhone store, but you have to go through the crazy tool chain jumping around which is indeed crazy.

[27:36] I have done too many field experiments on that matter. What do we need to make Java the platform for mobile and embedded development? H I think as as developers there’s nothing we can do. No. you know it would take you know the Android universe and the iPhone universe to start thinking about the universe completely differently. Mhm. And that doesn’t feel terrifically likely to me. There are two big companies to compete. Yeah. you know, the white right once run anywhere thing. It sort of grew out of, you know, son who was a kind of a minor player in the computer market, particularly early on. you know, trying to get people to develop software for a son was really difficult, you know, because they’d go, “Well, you have this percentage of the market, but these other guys over here have that percentage of the market, and yeah, it sucks to write software for that, but the engineers don’t get to decide this, right? the business people who go, “Yeah, but we’ll make five times more money or 10 times more money if we can sell on that platform.” When you do something like

[29:14] Like Java, you can get all the small players together and then the small players and the big players can get together. Mhm. You know, now that we’re in a universe where all the players have kind of collapsed, there isn’t nearly as much diversity in the hardware ecosystem as there used to be. You know, if you’re buying a laptop, there is only two choices really. There’s kind of a third. Mhm. But it’s only kind of a third. I mean for people like like like you and me a L Linux laptop Mhm. is a viable choice but for 99% of the public it’s not which is a bit stranger because it runs smoother on smaller and cheaper. Absolutely. So that that’s something I don’t understand why schools are all hooked on Chromebooks and Windows PCs while there are so better alternatives. But yeah, I think it’s a Yeah, it’s just marketing and they are so better in marketing. Well, it’s marketing and it’s kind of what you know. Mhm. I mean, I keep being frustrated with corporations that insist on using Windows for everything more because it’s what they know. You know, Windows has this long

[30:42] History of horrible security issues. They’re getting better, but they’re still the worst. It’s still the least secure platform on the planet and Linux is probably the most secure followed pretty closely by by MacOss and or iOS. They’re kind of the same thing in my mind. You know, Apple has the advantage that they can fix they can fix a security flaw and have it deployed everywhere around the planet in like days whereas you know the Windows folks have a much harder time. Another question as if we go back to Linux, did you ever expect that the whole cloud system which didn’t exist when you started Java thing that would run on Java for a big part? No. No. Was that a goal to have a serverside language? Believe it or not, the first Java app server was written in 1994. Mhm. All of the Java E core core APIs were actually, you know, a bunch of them were actually from 94. That’s when class servelet came out. Mhm. Yeah. So, one of the unappreciated facts is that I wrote the original I’m the person who wrote the original class serlet.

[32:26] At the time it was just like me kind of goofing around going, “Hey, this works really really well.” Mhm. Then the story gets kind of dark because I basically got told to throw that stuff in the trash because son had some partners that wouldn’t view the competition really happily. And in retrospect, I’m sure that was a violation to the Sherman Antitrust Act. but yeah, it was yeah, you I think no one could predict how all these things would evolve, right? People say, “Yeah, Java is not meant to run in Dockers.” Yeah, Dockers didn’t exist. That ID didn’t exist, I guess, when you started working on Java. So, and yet people have have figured out how to make things run in Docker contain Java to run in Docker containers really well. And it’s not like Java is the only thing that has trouble with Docker containers.

[33:50] You know the one end you know the major issue with Docker containers with Java is startup time. And you know Docker itself has horrible startup time problems. you know if only because you know it wants to boot up Linux and you know the things that they do to make Linux boot fast are pretty much exactly the same sort of things that you need to do to make Java start up fast. But you know, again, this is one of these sort of engineering compromise questions where, you know, back in the day when we were starting to do server things for real, the general model was you boot up a server and it just runs for a long time. And so you push everything into optimizing for high performance over the long haul. A lot of the things that you want to do to get that kind of performance really good fights against startup time. Yeah.

[35:05] You know and there are lots of places where you know getting startup time or consistent timing fight with throughput. Mhm. you know simple things like hashts, right? Everybody thinks of a hasht as something that’s really really fast. And if you’re fetching something out of a out of a hash table, it is really really fast. If you’re storing something, a hasht is really really fast mostly, right? Every now and then the hasht gets gummed up and you have to do some sort of restructuring of the hash table. And you know there’s a huge laundry list of variations on hashts. but at the end of the day they all have the sort of timing anomalies you know that you just have to do something in order to optimize performance.

[36:14] And almost all systems have, you know, sort of al algorithmic cheats that give you high performance, but every now and then there’s something you have to do to make that work. And you know, if you if you look at hotspot at all, it is an astonishing piece of engineering. the stuff that it does is mindblowing. And these days it’s, you know, between, you know, the code generators I find still astonishing that they’re actually beating benchmarks against LLVM, the garbage collectors are just crazy good. I that was one of the amazing when I started working for Razul, one of my very first things I had to do was write a blog post about the different garbage collectors and I have been doing Java development for over 10 years and I never bothered about garbage collector because it just did what it had to do. And then by writing that blog post and talking to people who developed those different types of garbage collectors, I realized but there’s so much in this. There’s so much knowledge.

[37:36] There’s so much technology to make sure that you as a developer just don’t need to care. Yeah, that’s the amazing thing. Garbage collectors are amazing in so many ways. I mean, they’re they make so much complexity go away. Mhm. they allow so much complexity you know so like people have been falling in love with Rust for storage management and I like rust for storage management the problem is that as soon as your data structures get complicated the rust techniques start start failing. Mhm. And if you’re if you’ve got like really complex data structures with all kinds of cross-linkings and caches that go do this and that and oh man, the Java garbage collector just makes the right stuff happen, you know, and it does it really quickly. I mean, you know, but I talk to people these days who still have this notion that garbage collectors are slow.

[39:06] Yeah. You know, that oh, it takes minutes to do a garbage collection. And I’m sorry, it hasn’t taken minutes to do a garbage collection for decades. Yeah. yeah, people people who are not a fan of Java most of the times they have been doing Java a long time ago. Yeah. And they didn’t follow up on what has happened, what the community has contributed, what all these improvements have brought in all these versions. Yeah. I mean the these days a halfdecent garbage collector will give you guaranteed maximum pause times of well under a second and the really good ones you know will give you maximum pause times in you know like 5 to 10 milliseconds and of course there’s I mean one of the reasons that there are more than one garbage collector in the world is that there’s this tradeoff between throughput and latency, right? If you want to have less overhead, you’ve got to accept more sort of bumpiness in timing. I mean, it’s it’s exactly the hasht example that I just went through, right? If you want it to go really really fast, you have to accept the fact that every now and

[40:33] Then there needs to be some data structure reorganization. You can fight it. You can do all kinds of algorithmic trick tricks, but you know, all you’re doing is smooshing the statistics. You’re not getting rid of all of the all the lumpiness. But then there are the ones where the lumpiness goes completely away. But a cost in that is throughput. 20 years ago, 25 years ago, the you know to get consistent throughput the or sort of low latency the overhead was in the like 30%. Mhm. in terms of throughput, but these days, you know, the throughput overheads to get guaranteed really tiny latencies is in like 1 2% kind of thing kind of space. You know, garbage collection is like the single most invisible technology there is in this universe.

[41:41] And yet you start reading the papers on garbage collection and my god it’s an exotic world and it’s amazing that they improved so much although on the other hand the systems became so much bigger much more memory that’s used on the other hand we also have more CPUs below it so yeah it’s it’s it’s amazing how much the all these things evolved that’s kind of one of the places where Java has kind of fallen from truth when it comes to like running on embedded systems. Mhm. In the sort of server world, nothing has a gigabyte of RAM. Raspberry Pies typically have, you know, 8 to 16 gigabytes of RAM if you buy a new one. my the my new desktop computer that’s sitting right in front of me has 256 gigabytes of RAM. And oh, for Christ’s sake, that’s a lot of RAM. Mhm. And of course, you know, the reason for all that RAM is that there are tricks you can do to make things faster. you know, if you want to fit into small amounts of RAM, there are things you just can’t do because you know, you don’t have the space for it. Mhm. And at the same time, certain kinds of, you know, engineering

[43:11] Sloppiness can be covered over by lots of RAM. Mhm. you know, in a project that I did several years ago, one of the things that just annoyed the hell out of me is that it was consuming a lot of RAM. And, you know, going into it, it’s like, oh, the Java VM is really sucking up lots of RAM. And it’s like, well, turns out, no, the Java VM doesn’t share much RAM. It’s it’s like all the libraries that you suck in and you know one of the delights of the Java ecosystem is that there’s such a selection of everything but it’s also one of the biggest pains. Oh yeah. because you know one of my favorite things to hate is HTTP. Mhm. you know, and in this one app that we went through and did a lot of analysis on, there were like five complete HTTP stacks, right? I mean, there’s the HTTP stack that comes with the JVM, the AWS library, for reasons that I don’t understand, decided they needed to have their own special custom HTTP stack. The Google folks, because you know, if you touch any Google library, you get kind of the transitive closure of the Google universe sucked

[44:50] In. And so you end up with the Google HTTP stack and then there’s you and then you start using any Apache library and Apache has their own HTTP stack. It’s easier for, you know, one of these organizations to just make their own HTTP stack than it is to start negotiating with other people to make sure that there’s one HTTP stack that makes everybody happy. And we could easily have done that, but you know, it’s it’s, you know, move fast and break things. Yeah. It’s also responsibility of the developer. I’ve been in projects where we had three three different XML libraries. Oh yeah, that’s that’s easy, you know, or JSON libraries. I mean, one of the saving graces in the Jason universe is that the Jackson libraries won early and they won really soundly. except of course that there are two Jackson libraries, Jackson and Jackson Jr.

[46:09] And Jackson is way larger, but it’s also much faster and you know, for good reasons. but it also has a bunch more features than Jackson Jr, right? So, so, so in that same project where we had like all these h all these HTTP stacks, we also had both versions of Jackson because, you know, some like, you know, I tend to be fairly meticulous about only using Jackson Jr. but lots of other folks, they really like the Jackson features. So, so then you start and I like the Jackson features, too. I’m just I’m just a crotchety penny pincher when it comes to bites. I mean, I tend to count bites of ram one at a time. Mhm. but you know, you watch these things go and of course Jason is one of these things where you know, at least for a Jason writer, you don’t need anything more than than than print f. Yeah, I actually kind of like that style of generating, Jason.

[47:33] Which I know mo many of my compatriots find rather disturbing. You briefly mentioned Rust as a competitor, but how do you feel about the languages which were created on top of the GVM because we’re now talking the whole time about Java as the language, but actually it’s the language and the runtime. And then you have Cotlin, Scala, Closure, which were all created on top of that same virtual machine. How do you think about about I like all of those. Mhm. Scola was a really early early success story that I quite liked. but it, you know, I guess I never found it compelling enough to sort of drop what I was doing. I mean, you know, I’m not somebody who follows trendy styles pretty quickly. I mean, I’m a t-shirt and jeans guy.

[48:39] Closure is pretty cool. I think for cool points, I like closure a lot. Mhm. The problem with closure is that it’s really different than the way that most people think. I mean, it’s this, you know, lisp syntax with really strict functional approach to life. And I I’m a big fan of functional programming. Mhm. but there I mean there are places where a functional style works great and places where it doesn’t. And I tend to write Java code in a functional style, which is another thing I do that drives other engineers completely batshit crazy. I would much rather use recursion than an array, but that’s just me. a completely different topic. I saw on one of your messages on LinkedIn that you also ask people to think about their job and the responsibility of their job.

[49:57] Yeah, if you’re working as a programmer in a company and you get asked to do something which you can consider as evil strange marketing tricks and stuff like that. How responsible are we as developers of how we are using our tools, our developer power? If your corporate leadership asks you to do something unethical, I’m a strong believer that you just walk away. I mean, start with an with having a discussion with them about do you really want to do that? Do you really understand the consequences of that? And occasionally you might get them going, oh, you’re right. Mhm. We shouldn’t be over our customers. We didn’t really think about the long-term consequences of that. But more often what you get is, “Oh, yeah, that’s fine.”

[51:02] And you know, you meet people who have worked for like like health insurance companies and you just get these stories that it’s like they do what that sort of rubs up against reality because, you know, if you’re in a period where jobs are easy to find, which has been pretty common for software engineers, is the case. Yes. Then just walking out on the job is easy. Mhm. But right now, the job market is really really different. Mhm. particularly in the US. I mean the US is just so screwed right now. One of my LinkedIn posts was on the concept of you money. This has been around for centuries, right? It’s is like, you know, do you have enough money saved so that you can just say you to your employer and just walk out because if you don’t have you money, you’re basically a slave. Mhm.

[52:16] You know, slavery comes in other forms too, right? So, if you’re a parent and you have a child that’s got serious medical issues, given the way that the American health care system works, if you leave your employer, you’re potentially impacting the health of your child, that’s one of the advantages from an employer’s point of view of the totally up American health care system, right? is that it makes employees dependent on their employer in a way that’s you know maybe not technically slavery but it can feel pretty close to that. I have to admit from I live in Belgium the European Union it feels so strange to see how things on the other side of the ocean work. I I’m I’m Canadian, right? So, so, so you know, I grew up with a similar sort of thing. And when I went to grad school eons ago, I was completely clueless about about the bizarness of the American health care system. And I came down with an illness. ended up having to go to the emergency room D. And I had no clue that this was going to reduce me to absolute poverty.

[53:48] And I mean it completely drained every penny I had. I mean it was horrible. You know, it just turns into a nightmare. Mhm. And so if you’re if you’re an engineer and you’re trying to live an ethical life, which I would like to think most people are, you end up with these really, really, really hard choices. Mhm. Will choices not become even harder with the whole competition we have from AI for a lot of for a lot of directors, engineers, for a lot of bosses. They think that they won’t need any more software developers and I think they’re kidding themselves. Absolutely. Yeah. And I think it’s I mean some of it I find almost comical. that a bunch of the AI folks have been saying you know that you know the open AIs of the world have been saying ah you don’t need copywriters and you don’t need this is and that is and those is because AI can do it all AI can do some of it so far the re the results are like really bad you classic examples like the law firm that thought thought that they could just use AI to write legal briefs and the legal briefs sounded

[55:25] Pretty good except that they were complete hoie and they got sanctioned and but for software engineering I think it’s a it’s a really different thing Because there’s this interesting thing about software engineering as a career, which is that, you know, we have libraries, right? If you do something over and over again, normally you put it in a library somewhere. And if you’ve got something that lots of people use, it ends up as an open source library. It’s really uncommon for software engineers except when they’re learning to do something that somebody else has already done. you know, it may might be kind of like what somebody else has already done, but if it really is what somebody else has already done, you can probably just find a library out there that already implements it.

[56:28] And so, you know, the way that all these Genai systems work is that they end up you know, in their heart, they’re they’re trained on gobs of code that’s out there and, you know, they can fill in, you know, based on stuff that’s out there. They’re really good at kind of interpolation, but interpolation is not the easy part of software engineering, right? And most software engineering is about extrapolation. And you know, so like like if you’re a civil engineer and you’re building bridges, you know, once you’ve built one bridge, you have to do engineering again for the next bridge and engineering again for the next bridge. In software engineering, you have to do all this complex engineering for the for like the first bridge, but then copying a piece of software engineering and making like the next bridge and the next bridge, that’s free. Mhm. And one of my favorite things about software engineering is that more often than not, you you’re doing things that nobody has done before.

[57:46] And maybe when you’re a student, you you’re you’re you’re always doing things that people have been done before. The usages I’ve seen for things like chat GPT have mostly been in like learning stuff. I found myself using it as kind of an automated help system. Mhm. Just like how do I write a piece of code to connect this to that? It’s got some probability of being accurate all the way forward. Yeah. You know, so it’s like a really sophisticated grip o over all the source code in the universe. But that’s really really different than writing truly new code and what people forget what the developer the main task for the developers is finding out what the exact problem is that needs to be solved. So you first need to go through that process of people ask me to do something but why do I need to do it? What is the exact problem that I need to fix? So you need to understand the problem before you can implement it and that’s not something which I think a chat system will do very fast. Yeah. I mean you know if you’re given clear instructions for what to do yeah maybe but you’re never

[59:15] Given clear instructions. Sometimes you are given clear instructions and in my experience the clearer the instructions are the more likely they are to be just completely wrong. You know, usually if you’re a manager, your skill set is about dealing with people. most people who are good engineers are not really good people people, you know, and so sometimes you get managers who think they know what they’re doing when it comes to engineering, and occasionally they do. Mhm. but mostly they’ve just got an eco problem. and they’re telling you how to do your job. And in truth, they’re just full of it. There are very few things as as as painful as a bad manager. Mhm. what advice would you give to junior programmers if they’re dealing with bad managers if they have to choose a language? Have you do you have some good advices for starters? You know, things are always easy easier when you enjoy them. And I’ve often I’ve always found that I do a lot better if I’m you know working on projects that I find just really fascinating. And one of the nice things about software engineering is that, you

[1:01:00] Know, software is a tool. and it’s used in a lot of different industries. So, I tend to pick jobs more about the environment that they’re picked in, that they’re embedded in. I’m kind of like a space nerd. I really enjoy sailing and boats and things and I’ve had the good luck to have some jobs that let me sort of bump up against a lot of those those things when I’ve, you know, had the luxury of being able to, you know, actually pick a job. I’m not good enough at math to be a physicist, but I can work for a physicist and have a really good time if you’re lucky enough and you’re, you know, you can find environments where that sort of thing works for you. When you’ve got tight job markets like like right now, it’s kind of beggars can’t be choosers. Mhm.

[1:02:12] And then you know it can often just be suck it up. Mhm. Do what you need to do and wait for a better time. Yeah. Wait for a better time. If you look back at 30 35 years with when you started Java, can you point out a few of the significant moments? Probably a lot of them, but can you pick a few of them? Well, I mean, they’re all the obvious ones like launching it, the kind of crazy relationship with Netscape, bizarre relationships with the rest of the industry. You know, one of the things we were getting criticized for was not going open source earlier. Mhm. We were actually distributing the source from the very beginning but we didn’t have a weren’t using a license that you know the open source priesthood really liked and you know there were variety of issues there but you know from our point of view the big issue was man there are some big competitors who want nothing more than to crush us. Mhm. A truly open- source license would have given them a license to kill. Mhm. And you know there were half a dozen such companies that we worried about and you know then you end up with

[1:03:54] This place where you know that things would be better if you were in an open source license except that you would be dead. Mhm. That was not pretty. Mhm. you know, for points that had drama, it’s kind of hard to beat the some of the standards committee meetings. You know, standards committee meetings are they tend to be about the most boring things you can imagine. But you know, we had been doing these negotiations with ECMA for Java to become an ECMA standard. Mhm. And what we didn’t know was that three large corporations that will remain anonymous, but you can probably guess who they were. had been working with ECMA in the background, you know. So, we had this agreement with ECMA for what it would look like, and we had this one meeting where we were going to finalize it all. And the ECMA representative, who we had had dinner with the night before and was all on board with what we wanted to do, announced that the plan was that Java would be split into three pieces.

[1:05:24] The language, the virtual machine and the libraries. And each of these three companies would take the lead on those. And Sun had no role in anything. The each of those three companies could do whatever they wanted without consulting anyone. What a bad idea. An idiotic idea, right? So we walked out and then you know all these other people were like son they’re such they don’t want to standardize it and it’s like you guys don’t actually know what happened in the room. Mhm. Right. And oh man, you know, fortunately I was I mean I was in the room but I hadn’t been deeply involved in all the negotiations with the standards committees and you know we had tried the tried variations of this with some other standards organizations and they all went the same way and the one with ECMO was like the last one and we just felt so completely screwed over. I don’t know how it got so weird.

[1:06:49] But I think you already mentioned it. Egos at some point, some people pushing their ideas. It’s competition, right? It’s it’s money. It’s control. It’s, you know, some of it is ego, but, you know, when it comes to corporate stuff, ego isn’t as big a deal as greed, the money. you know, pretty much greed conquers all. And it’s sad. Mhm. But I’m happy that didn’t happen. splitting that thing into three pieces because now we have one clean consistent Java GVM ecosystem around it and all these you know and the thing about stuff like this is that they’re ecosystems all the pieces influence all the other pieces you know one of the things that really worked well for Java over the years you know because one of the questions I keep getting asked is so why didn’t you become benev benevolent dictator for life? Mhm.

[1:08:01] And besides the fact that would have completely screwed over my life and I would never get to do anything else again in my life, you know, I really, you know, it really mattered to me that all the different people who were writing software in Java, they had concerns and I really wanted their voices to be heard because the only way you can build something that people want to use is to listen to what they want and give their expression of their wants some legitimacy, right? And that’s how you end up with something like the Java community process, right? Which ends up, you know, it on the one hand it’s a little annoying because you end up with these rooms with people sort of duking it out. on the other hand and then it can get slow and messy and but on the other hand the voices come out you know it’s it’s kind of like that line about democracy. Democracy is the worst form of government ever except for all the others. And is that how Java works nowadays? Is there a good system? Will it evolve in the right direction in the next in the next 30 years? I’ve been

[1:09:28] Surprised at how well it’s been working. Mhm. Were you surprised with how well the six-month release cycle worked? I actually don’t think that the six month release cycle changed anything. Mhm. Because before the six-month release cycle, when it was kind of like a three-year release cycle, during that three years, there were builds always being posted. Mhm. And a lot of people were using these intermediate builds and I was sure certainly using them a lot. You know, the intermediate bills were usually pretty damn solid, just like 24, 23, the ones in between the long-term support versions we have now, right? So, so, so now Yes. Okay. So, there’s a release every every six months, but you know, there’s a long-term release every what, two or three years now? Two years. Yeah. Yeah.

[1:10:26] So, it’s a bit the same, but in a different form. Yes. So, so it basically is the same thing, but you know, at least the current release cycle, it’s very predictable. It’s Yeah, it’s it’s more predictable. The one thing that I’m kind of annoyed about with it is that, you know, there are all these preview features and sometimes things stay in preview for a really long time, right? And so before the six-month cycle, the way it used to work was big complicated new features could only be proposed at the beginning of the cycle. Mhm. And then there would be all these little little releases that people could experiment with. But the next time there was, you know, the 2 or 3 year release, it was solid. There was no preview anything and finished it, you know. So, so now I find myself using all these preview features, which on the one hand is great because most of the interesting stuff is a preview feature. but you never really, you know, the fact that they put that they allow things in long-term releases to still be in preview kind of sucks. Mostly, you know, when things are

[1:12:03] In preview, they converge pretty quickly, but some things kind of explode. And you know certainly the you know dot double quote thing. Mhm. Which I found found found myself falling in love with and using in perhaps slightly odd ways and then that just got completely blown up and then it’s like oh god now I can’t use the latest VM. I can’t use the latest version of Java unless I like go and do some major changes which you know it’s like okay Brian’s got a point usually does are you still involved in the discussions sometimes. Are you officially retired? I am officially retired. I am unemployed. I listen to no higher master than my wife. And how big of a master is Java still for you?

[1:13:18] Not much really. Mhm. you know I you know I’ve been you know out of the Java organization for 15 years now. And you know the people who are looking after it right now I highly respect them. They’re really good and the and the community keeps them in line. So, that’s lovely. And I’m usually I’m I’m a person that that’s not someone who likes to go around yelling and screaming at people. Any any last message you have for the Java community? to close this interview, have fun. Keep building. Mhm. And keep building is what we will do. Thanks James for the great talk and for creating Java and the GVM. Thank you for listening. Please subscribe to the Foojay podcast in your favorite app or on YouTube. Keep an eye on Foojay for future articles and podcasts about the development and everything related to the Java world. See you next time. Be the friends of OpenJDK.

Found a mistake, or something to add? Edit this page on GitHub

Written by

Frank Delporte

Frank Delporte is a Java Champion, Java Developer, Senior Technical Writer at Azul, Blogger, Author of "Java Programming for Raspberry Pi - A Hands-On Guide to Electronics and IoT Projects", and Open-Source Contributor for Pi4J, Lottie4J, Sheetmusic4J, …

Related posts

Join the discussion