エレベーターとトースターから生まれた Java――James Gosling が語る誕生秘話

Hello and welcome to the Stack Overflow podcast, a place to talk all things software and technology. My name is Ryan Donovan, and today we are talking about the origin story of Java with the man who originated, James Gosling. Welcome to the show, James. Thank you. I'm pleased to be here. Before we get into the backstory for Java, let's get some backstory on you. How did you get into software and technology? Born in Canada and Alberta in 1955, generic geek in, you know, what was at the time a pretty tech-challenged universe. We happened to live just a couple miles from the University of Calgary, and my dad had a friend who worked there. So one day he took me over there and we just kind of like wandered around. And at some point we were going through the data center and my eyes just lit up.

My brain exploded. This was like just too cool for words. I figured out how to pretend to be a student. You know, they had a computer center library and I used that to teach myself how to do stuff. And, you know, at the very beginning, it was all like punch cards and paper tape. This is in the 60s, right? Before the age of personal computers, right? Oh, long before personal computers. I mean, there were things that were kind of like the first personal computers. So one of the machines that I used a lot was a machine called a PDP-8 from Digital Equipment, which could only have one user at a time. And at some point, some people from the physics department noticed that I was playing with one of these PDP-8s, and they had a PDP-8 that needed some software. And they hired me. It's like, go to high school, then pedal over to the university. And I did that all through high school. So I had this job writing software for the ISIS-2 satellite in high school.

And that was just outrageous fun. and I got to know a bunch of very cool people from the researchers to the grad students to the other tech people and they were all just wonderful. I talked to a lot of people who got their start in computers because of games. You got your start in computers because of satellites. And doing satellite ground station software, bits and pieces of decoding the data streams and turning the data streams into images and doing error corrections on data streams and all kinds of transformational stuff and working with a bunch of physicists who knew an outstanding amount about math and stuff but who were kind of clumsy when it came to computers. I have no idea why computers were a little difficult for some of them. Yeah. But I got to know a fair amount about the Earth's magnetosphere because that's what they were studying. So, you know, got your start in high school. How did you come to be a person that was asked to create a programming language?

I was never asked to create a programming language. Oh, all right. So like I go to college, go to grad school, end up with a PhD from Carnegie Mellon, spent about a year and a half at IVF, and then ended up at Sun Microsystems. And at some point I was working on this project that we were doing with consumer electronics companies, the sort of people that made everything from elevators to PCRs. So we decided to build some prototypes, and we were doing a lot of discussions with people in the industry about what were their pain points. We kind of got into this because Sun was a company that made computers. But at some point, we noticed that there were a lot of people using computers outside of what one would normally think of as the computer industry. They were showing up in people's homes, often not looking like a computer at all. And at some point, PCs started going up.

But networking was something that most computer companies were openly hostile to. So the very first company that put a network adapter on all their computers was Sun Microsystems. Sun put networking at the heart of everything. And that was a religious conviction that I was in the middle of. And, you know, I did a bunch of different projects at Sun, but the sort of conviction about networking was a really strong thing. And, you know, we end up doing this little side quest into what people outside the conventional computer business were doing. And it got kind of interesting because there were issues that we're running into. When we started, we were doing this in C++. And this was a universe that cared deeply about reliability. And in the conventional computing industry of pre-1995,

people were pretty casual about reliability and often being willing to trade reliability for performance. And this is kind of like what happens with cars, right? If you've got a high-performance car, they break more often. You know, same thing with computers, right? Rule one is thou must not kill your customer. And that goes for everything from people who build elevators to people who build toasters. Do not kill your customer. Nothing must go wrong ever. There was that. There was the emerging interconnectedness of it. I mean, one of the amusing things that was going on at the time was that all these companies were realizing that, oh, being interconnected would be useful. So they were all reinventing computer networking. And they were all basically repeating the stupid things that people in the computer industry had tried. And I can't tell you how many discussions I got into with different companies all around the world.

And they would say, well, we've got this great networking technology that does this. And it's like, oh, I've seen that before. And it fails in this way and this way and this way. And it ain't going to work. And there's kind of a reason that the universe converged on technologies that flowed out of Ethernet and TCP IP and all of those things. I mean, the convergence to get to TCP IP was very difficult. And TCP itself has some significant compromises, but there were compromises that were rooted in limitations of the time. And the more modern protocols like QUIC, which has been replaced slowly but surely replacing TCP, they play some really interesting games that gets around some of TCP's shortcomings. And that's all lovely. But we just started down the road with these people. And at some point, we decided that we would do a prototype device because, you know, we're a bunch of engineers.

Several of us had PhDs in engineering. You got to do an experiment. You got to build something. So we started doing this experiment in C and C++. And at some point, I realized that a bunch of the problems were just problems with software engineering tools. So there was nobody that asked me to go off and write Java. There was just me and a half dozen friends, and I sort of came to the realization that, yeah, we've got to fix some of this compiler technology problem. Yeah, because you're building that custom device. This was a world of very, like, proprietary hardware, proprietary software, right, back in the early 90s. The people who were building these devices, they hated the proprietary hardware thing. The interesting people to talk to were like the purchasing agents, the people who just bought the parts because they're building circuit boards and boxes that they put the circuit boards into and stuff like that.

So an engineer writes in the bill of materials that we need a resistor of this spec and a capacitor of that spec. And the purchasing guys go and they look at all the different people that make resistors and capacitors or inductors or whatever. And they're interchangeable. So you can actually make a purchasing decision across multiple different candidates. But when it came to computer CPU chips because every one of them was proprietary and weird this drove them crazy because the engineers would pick something for one reason and the reason was often kind of cheesy It was like, well, we've already got the software tools for that, or gee, this one has that feature. And the management above the engineers, they all wanted to optimize for different things, and most often it's a combination of cost and power. but the software engineers don't care. And so this was always setting up these food fights,

which viewed from the outside were kind of hilarious, but viewed from the inside, there was pain and real money. And because of a thesis proposal that failed that I had done when I was in grad school, I kind of had this idea for a way to build this sort of abstract machine that could break the dependency between the physical processor and the software that people wrote. And at the same time, we were having these horrible problems with security and reliability. And a lot of the time, security and reliability are kind of the same problem. Because if you look at, certainly in the early 90s and certainly today, the vast majority of security vulnerabilities, they're not design issues. They're just bugs, right? They're stupid human tricks. And those are mostly pretty solvable from the language point of view. I mean, an awful lot of them are memory corruption. Sure, memory issues are all over the place, right?

The memory issues are just everywhere. And then a big bunch of them are things like getting floats and integers confused. This is a world where nobody cared how fast it was to build a prototype. The only thing that they cared about was how fast you could get to something that was solid and working and dependable. That really argued strongly for things like garbage collection, strong typing, a really strong position on what arithmetic means. In the 90s, one of the things that was comical for me is that if you opened up the spec of almost any programming language and you looked at the parts that talked about arithmetic, they all said implementation specific. It's like, we won't tell you what 2 plus 2 is. You just have to sort of trust that whoever built that piece of hardware. And fairly remarkable consistency on what 2 plus 2 meant.

But once you get to the fine details, they started to diverge. Why was arithmetic something so difficult? Every computer company did it differently. People had pretty much converged on floating-point arithmetic, but different companies did it differently. But one of the things that had happened in the late 80s is that the IEEE 754 standard came out, and companies started moving over to that. So if you looked at the programming language specs that were around in the 70s and 80s, They said implementation defined because IBM did floating point completely differently from digital equipment, completely differently from HP, you know, all these companies that mostly don't exist anymore. And there was this war about what 2 plus 2 meant. It eventually converged in IEEE 754, but there was some ongoing food fights in IEEE 754.

You get companies like Intel who decided, yes, IEEE 754, but the spec hadn't quite frozen. They kind of launched early, and that meant that some of the things that they did weren't quite right. And if any of you listening to this remembers the strict FP keyword, That was all because of some discrepancies and disagreements in the way that rounding worked in IEEE 754. I do believe I have seen sell questions about different floating point types and why they're different. Now, strict FP has disappeared from Java. Thank God, because, you know, a bunch of years ago, Intel converted over to doing rounding consistent with everybody else. Unfortunately, what it meant for Intel was that because they have like a lot of backward compatibility, they're old style rounding and then there's the consistent rounding.

One of the other kind of odd things that happened was that in the evaluation of sine and cosine, there's this process called range reduction, because only from plus or minus pi makes any difference if you're larger than that. It's a function that repeats. And so range reduction gets it in. Because Intel's early launch and some restrictions on what you could do with silicon that time, they used an incorrect version of pi. Because you have to take the angle mod 2 pi, and they had a slightly incorrect version of pi. And that numerical analysis community, if you're doing something like a rotating shaft in a motor or a prop on an airplane and you take RPM times time and then you try to convert that into an angle, you end up doing like a sine and a cosine of a very large angle. You know, what would seem like such a minor, minor nip, you start out at the beginning of the day thinking, okay, let's deal with some issues that people have with moving software across wildly different proprietary platforms.

And that turns into deep diving into how sign and cosign are evaluated. Right. When I first saw Java, I was struck by the virtual machine aspect of it. But I wonder how you transformed this idea of the abstract machine into actual implementations. Like how different were the virtual machines you had to produce? Mostly not terrific. I mean, it depends on the ones you're comparing, right? So the virtual machine that runs in your credit cards, because most credit cards these days, believe it or not, have a Java virtual machine inside them because that's part of the smart card standard. Those virtual machines are totally unlike the virtual machines that show up in most other places. That's the core of it. It's really interesting how we did a lot of virtual machines for compact devices like cell phones. And on the one hand, yeah, that worked and it worked great.

But in the cell phones of the 90s, they didn't have much RAM. So the virtual machine itself was pretty much the same. What was different was the set of libraries. So there was a lot of squawking about, well, couldn't we just run the full-up virtual machine? Which is really the full-up set of libraries. That explosion got even worse. In the data center universe, RAM is essentially infinite and teams are really large and they're often compound teams, right? So if you're a company like FedEx, you have giant teams, hundreds of thousands of engineers, and you have projects all over the place. That works really well. There's a lot of stuff that's in Java that was about how do you make the coordination across large teams work smoothly. And a lot of that was about how interfaces work, classes work. And the bits that got interesting were the social effects.

One part of this that I find really aggravating is that, you know, you take HTTP, which has become the absolute bedrock of networking these days. even though there's a lot you could say about HTTP that is pretty disparaging because it's got a whole lot of leftover crap from the 90s, which Quick tried to solve, but old stuff never dies. So there was like an HTTP stack that came bundled with Java, and then there would be a group of people who would say, you know, it should be just completely different. So they'd write another one. And then another group of people would say, well, those are crap. We'll write another one. And if you take a large Java app and you pick it apart, you'll often find that there's three, four, sometimes even five or six complete implementations of HTTP, right? And it's all because the people couldn't get together and have a conversation.

So I curious about some of the design of the language because it seems like some of it is reactive or responding to C In my college I had a C class first and then I had a Java course and I was like I saw all this difference in how it was thought about and organized, right? You didn't have the memory management. You could open threads. You had direct I.O. access. How much were you actually responding to in C++ as, like, these are mistakes. I want to fix them. A fair amount of it was. It wasn't so much about C++, but what it had inherited from C. The biggest issue was pointers, the fact that you could commit all kinds of crimes with pointers. And I had spent quite a long time as a C programmer. And I can't tell you how much of my life was taken up by hunting down memory leak bugs, memory corruption bugs. Because always something goes wrong, but you don't get any symptoms until like millions and millions and millions of instructions later, right?

You have a less than or equal to instead of a less than on a loop that's walking over an array and setting all the elements to zero. and because it was less than or equal to, you go one element too far and that smashes the header of the next allocated object in the heap. And then that doesn't commit any problems because it's just the header in the heap until that object gets deallocated and it's got no header. The header is corrupted and it could be a long time later before that happens. and there are a bunch of tools now that help with that. But, you know, why have fancy tools when you can just not make the mistake in the beginning? Well, you have the fancy tools because you made the mistake at the beginning, right? Yeah. So you had the set-top box or whatever the device was. How much of your initial vision made it to this sort of final release of it? How much rubber hitting the road changed the language?

There was a pivot that happened in there. Because we started being all about things outside the data center. It was only stuff in the data center. By the time we got into the late 90s, most Sun executives couldn't recognize the computer that was outside of a data center if you smacked them over the head with it. And there's a certain amount of sort of skewing that happened. But, you know, all the concerns about security and reliability and all of that was all very real. at consistency, you know, uniformity, portability. Portability turned into a really useful thing. There's a piece of portability that people don't often think of, which is that the portability exists at the binary level, right? When you have a Java class file or an archive of Java class files, you can compile that and then you reuse that artifact in other applications. So the other

applications don't need to see source code. It's nice if the source code is available so you can look at it. Doing a build on a piece of software can be an extremely delicate operation because you have to have all the right tools in all the right places. And building up that stack so that you can do builds consistently is really hard. And builds used to take a long time. And the fact that Java could do incremental builds of just little pieces. And these days, it's felt like people are going back to only distributing software as source and doing full builds of the entire universe. You know, every time I talk to people doing large Rust projects, their build times have exploded. But I feel like Rust is another one of those that use that portability with crates, right? You can send crates and little pieces of it.

But it's all done at a source code level, and you have to get the whole build environment right. And in the Java universe, I got so used to changing one source file in a large system and being able to run that large system 10 seconds later. For back in the day, that's pretty incredible. Yeah, but that was normal. And being able to get that build cycle that tight was a real goal. Java's been around for 30-some years now. How involved have you been in its passage from then to now? I mean, I started it in 92. I was pretty much the only person that worked on it until about 95. And then as we went through the late 90s, I started having to do other stuff. I turned into a walking, talking head that would give talks all the time. And when you're giving talks, you can't be doing engineering. Although I must admit, laptops on long intercontinental flights are a great way to get peace and quiet.

What do you think of Java's progress to today? It's a very popular backend language. I hear people talking about it. Like you said, there's a Java virtual machine and credit cards. It has gained a sort of ubiquity. A lot of the features have to do with scale, and I don't think anything's coming close to it for issues of scale. And I think one of the hits to Java was when Oracle took over Sun. That got a lot of people really concerned. But looking at it in hindsight, Oracle did a much better job than I think many people were expecting. They've done a lot of good things. They continue to have good releases, and they thought about their release schedules. And I've talked to George Shobbs, who's running that now, and it seems like they're just trying to make it ever more modern, you know? Yeah, and they've been doing a good job of that. And actually, some of the stuff I'm most excited with is a bunch of their performance work.

The modern code optimization is pretty amazing, and the garbage collectors are just stunning. so much faster than malach and free. Aren't most garbage collectors better than manually malach and freeing? Better in terms of reliability? Absolutely. Better in terms of like raw CPU performance? It's spotty. The Java collectors are just a thing of wonder. What makes them so amazing, do you think? They deal with large memories and they deal with concurrency. And in a normal garbage collector, there will be times when the system sort of pauses. And the modern Java garbage collectors, you can kind of pick what pause rate you want. And you can get into small numbers of milliseconds maximum pause time.

And one of the things that spending time in the real-time world shows you is there's a real trade-off between performance and deterministic timing. So a really good example is hash tables. So people love hash tables because doing a lookup or insertion takes roughly constant time, almost always. And the problem is in the use of the word almost, right? So if you're doing insertions, it'll be constant time, and then the hash table overflows, and you have to do a restructure. There are a thousand different ways of doing that restructuring, and a thousand different tricks that people play to try to get the restructuring simple and fast. nonetheless one insertion in a million or whatever the number is depending on the hash table size will cause a blip in the timing and you can go through thousands of algorithms and they all have

this timing bumpiness to them so if you're trying to do something where you cannot afford to ever bump in time. So say you are controlling a motor with a modern electric motor. There's a computer in there that's controlling how the magnetic fields swing or the timing in a gasoline engine. And you cannot be off by a millisecond. Timing matters and you must never, ever miss. So in that universe, the way you think about programming is different, right? So you can't really use a hash table At some point your timing will not be right If you only get a bump once in a million times and you doing stock trading that might not be so bad But if you controlling a jet engine a few hundred people may fall out of the sky. It is such a different universe. Whenever I talk to people about Java,

they almost always have a strong opinion. Some people love it and they're like, this is the only language you need. And some people say you should never use Java again. Why do you think it inspires such strong feelings? It's hard to know. I mean, the things that I hear over and over again the most often are ones about Java being strict about things. People who use C or Python, they're like, Python doesn't get in my face about things that break. And in Java, I had sort of taken this position that when things go wrong, you ought to pay attention. One of the classic sources of errors in C is you say file descriptor equals open of something or other, and then you use that file descriptor to read and write. And the open could fail, in which case the file descriptor you get returned does not work for reading and writing. And bad things ensue.

So people go, oh, I don't give a f***. If you're just writing a class project or something that just has to run once, then yeah, that's okay. But if it has to run every freaking time, like in C, I mean, the number of times I felt like I had to punch somebody in the nose because they didn't check the return value from open. Oh, right. They just trust it, right? They just trust it. It's creating a file somewhere, and then you take this program and you try to run it on another machine. Well, if they're creating a file in slash temp, yeah, that's probably okay. But if they're creating it in developer's home directory, which is the most common failure point, slash user slash JAG slash threat, and then you try to run that on some other machine and the thing crashes mysteriously. But it doesn't really crash mysteriously because it probably just doesn't work correctly because you get the file descriptor from open.

It's a minus one. And then if you just like trust that, then you do a write for some data. The write, it will fail and it will return a failure code. But almost certainly the person who didn't check for the open file descriptor didn't check for the read. Right. So people who just don't give a shit about whether their software works, you know, I've been a software engineer for a very long time and a senior software engineer for most of that. And when you start having to deal with doing code reviews of stuff that fails because somebody was just freaking lazy, that gets pretty frustrating. And on the one hand, people bitch and moan about the exception system. Then other people go, oh, wow, that alerted me to something that could fail that I hadn't paid attention to. Yeah, and you gave me a whole trace for it. It gave me the trace, but it gave me the trace like early, right?

The way that you're doing the example with an open and some writes, you're getting no errors, no traces, until mysteriously somebody realizes that there's a log file that's not getting written. And then they try to figure out where did the log file go? They probably have a try-catch in there that does nothing, right? Well, in C, they can't do that. And the program will appear to work correctly, except that the log file is empty. I care about software that works, and it works every time. That's an interesting way to put your finger on it, because people have those feelings about Rust and other things that are very strict about what you can and can't do, where it's like they either love it or they hate it. I see people doing things like large language models only hallucinate occasionally. If it's occasionally hallucinating in a court filing, which has become items of comedy when people use LLMs to file documents, it's like, guys, you've got to get it right.

What do you think about everybody using coding agents to write code? Well, part of me is thrilled because for the longest time, people have not been paying any attention to tools for software developers. When I worked at Amazon, there was this whole culture of all I need is VI and nobody was using IDEs. And so some of these coding agents, if you look at them sideways, they're IDEs that occasionally hallucinate and they've been getting a lot better. I mean, when I started playing around with them, you know, you'd look at the code they would generate and it would just be hilariously bad. I looked at a lot of co-generated code like a year ago and it was terrible. Some of it's style points. Some of it's kind of the worst of cut and paste coding. They have gotten better. They're still nowhere near as good as a human that knows what they're doing. If you're a human that's not very good at coding, can definitely get you a leg up.

Except that stuff tends to be kind of buggy. Powerful tools don't make you a better coder, right? So if you're doing simple stuff, I think it's fine. The place where I find these coding tools really excels is gotten to where I treat them like a help system. Because, you know, when you're learning a new language, the programming language is not the hard part. The programming language is often, you know, you spend half an hour learning the tweaks of the way the type system works or whatever. The hard part is always the APIs, is the collections of libraries. And different communities have different documentation standards. So a while ago, I was getting very frustrated building plugins for Blender. And, you know, that plugin environment, it's all Python. And Python's a perfectly serviceable language. But the APIs in Blender are, they're unusual and they're oddly documented.

And one of the quirks in the documentation is that often, you know, there's the official documentation, which is a little shallower than it would be to be. And if you start searching on the net, start looking at Stack Overflow, which has been a common place for me to go look for things, a lot of the information on the net is kind of out of date. One of the rules in the Java universe has been don't break s***. Right. Right. So the APIs remain consistent and you don't just like randomly change them. You think harder about how you evolve the APIs. And in a bunch of communities, they just randomly change stuff because the old stuff was stupid. And they're generally right when they say the old stuff was stupid. Yeah, I mean, Python is one of those that broke compatibility between major releases, right? Yeah, and so in the Java universe, we were extremely careful about not breaking stuff.

It's a time of the show where we shout out somebody who came on to Stack Overflow, dropped a little knowledge, shared some curiosity, and earned themselves a badge. Today we're shouting out the winner of a famous question. Somebody asked a question that got 10,000 views or more. So congrats to Zane Hassan for asking a Java exception question, java.security.certpathvalidatorexception. trust anchor for a certification path not found in React Native. So if you're curious about that, we will have the answer for you in the show notes. I'm Ryan Donovan. I edit the blog, host the podcast here at Stack Overflow. If you liked what you heard today, please leave a rating and review. And if you want to reach out to me directly, you can find me on Stack Overflow. Well, thanks for having me. There's a really great Java documentary that dropped just a few months ago, done by an actual professional firm that does documentaries. It's really well done. Well, I hope you all check out the documentary,

and thank you for listening. We'll talk to you next time.