Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby.
Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine.
Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff.
What do you get for all of these tradeoffs? Speed, memory safety. But with that you still still have dynamic invocation capabilities (making things like interception possible) and hotswap/live redefinition (things that C/CPP cannot do).
Perfect? No, but very practical for the real world use case.
show comments
nelup20
I personally appreciate Java (and the JVM) much more after having tried other languages/ecosystems that people kept saying were so much better than Java. Instead, I just felt like it was a "the grass is greener" every time. The only other language that I felt was an actual massive improvement is Rust (which so far has been a joy to work with).
It's a shame imo that it's not seen as a "cool" option for startups, because at this point, the productivity gap compared to other languages is small, if nonexistent.
show comments
mark_l_watson
Right on, James Gosling's work is amazing, and he and the whole Java ecosystem have my gratitude: I went to the first Java World Tour conference and wrote a little blog article about it that was linked on Sun's home Java page for about a year. I was very lucky, and since I was the first search hit for 'Java consultant' for a very long time that gave my wife and I the freedom to live in a rural area and I could get remote work for a decade.
As long as I am expressing gratitude, I would also like to call out the Clojure team for developing a wonderful ecosystem in top of Java and the JVM.
It must be wonderful to do work that positively affects the lives of millions of people.
show comments
PathOfEclipse
I've been working in .NET/C# for the past few years, and while I'm happy with it, I still think the JVM/Java are the best ecosystem overall I've worked in. It's amazing how many things the Java ecosystem gets right that .NET gets wrong.
For instance, Java introduced the fork/join pool for work stealing and recommended it for short-lived tasks that decomposed into smaller tasks. .NET decided to simply add work-stealing to their global thread pool. The result: sync-over-async code, which is the only way to fold an asynchronous library into a synchronous codebase, frequently results in whole-application deadlocks on .NET, and this issue is well-documented: https://blog.stephencleary.com/2012/07/dont-block-on-async-c...
Notice the solution in this blog is "convert all your sync code to async", which can be infeasible for a large existing codebase.
There are so many other cases like this that I run into. While there have been many mistakes in the Java ecosystem they've mostly been in the library/framework level so it's easier to move on when people finally realize the dead end. However, when you mess up in the standard library, the runtime, or language, it's very hard to fix, and Java seems to have gotten it more right here than anywhere else.
show comments
w10-1
Java is a great success story. Though, to be fair, James Gosling was the spark but has not been the steward.
Even as early as Java 1.1 and 1.2 he was not particularly involved in making runtime, library, or even language decisions, and later he wasn't the key to generics, etc.
Mark Reinhold has been the hand's-on lead since 1.1, first integrating early JIT's, HotSpot, the 1.2 10X class explosion, and has been running the team all the way through Oracle's purchase, making the JVM suitable for dynamic language like Kotlin and Clojure, open-sourcing, moving to a faster release cadence, pushing JVM method and field handles that form the basis for modern language features, migrating between GC's, and on and on.
As far as I can tell, everything that makes Java great has come down to Mark Reinhold pushing and guiding.
I went to a Java school. I remember my operating systems class involved writing simulated OS code in Java (for example, round robin for context switching). The argument was that it would be easier to understand the algorithms if the hardware complexities were minimized. I understand that sentiment, but I don't think Java was the right choice. Python would have accomplished the same task even better (understanding algorithms). I think there was a huge influence from industry to teach college students Java from day one. I had taught myself BASIC and some C back in high school, so it was a bit of a step backwards to learn a high-level language just to do simulated low-level OS programming.
show comments
toprerules
I admire Java as a success story, but I still have a deeply ingrained aversion to it for many reasons. I will admit that many of the reasons are due to Java's legacy as the language of bloated corporations, and its creation of overly verbose, magic fueled frameworks and poorly written code. Java as a language goes hand in hand with the idea that code is coal to be shoveled into the furnace, and we should all throw our aspirations away and embrace mediocrity.
My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA with standard ops tools like strace, gdb, etc. The JVM's over allocation of memory robs the kernel of real insight as to how the workload is actually performing. When you use the JVM, you are completely locked in and god help you if there isn't a JVM expert to debug your thing and unravel how it translates to a platform implementation.
Then of course there's the weird licensing, it's association with Oracle, managing JDK versions, it's lack of it factor in 2025, and a huge boatload of legacy holding it back (which is not unique to Java).
I have successfully navigated my career with minimal exposure to Java, and nowadays there's a glut of highly performant languages with GC that support minimal runtimes, static compilation, and just look like regular binaries such that the problems solved by something like the Java or Python VMs just aren't as relevant anymore - they just add operational complexity.
To reiterate, I admire JG just like any tech person should. Java's success is clear and apparent, but I'm glad I don't have to use it.
show comments
rootbear
When Gosling was at Sun, he was one of two principal architects of the NeWS Window system. The X Window system was designed for "dumb" display devices and so the display elements were all static, not requiring much work from the server. NeWS was designed to run on a (Sun) workstation, where there was a lot of computational power available, so it was based on Postscript. A NeWS client would send a program to the server, not just static commands.
Gosling, unsurprisingly, designed Java with the NeWS model in mind, where web pages were programs, not just static HTML documents. When I got him to sign my copy of "The Java Programming Language", I asked him if Java was the revenge of NeWS. He just smiled.
show comments
pjmlp
> Gosling primarily uses the NetBeans IDE for development, praising its open source, Apache-licensed nature and dedicated community. He expresses frustration with developers who cling to outdated tools: “The thing that drives me nuts the most are people who are madly grasping the ’80s or the ’70s — people who still want to use Vi, which was high-tech in the ’70s.”
From one of the key developers in the Emacs history, and genesis.
He moved on, others keep trying to live in the past.
show comments
jcadam
Been coding on the JVM for a good chunk of my career. Though the last several years has been in languages other than Java - Scala, Clojure (my personal favorite), and Kotlin.
Finally managed to get a job offer (after being unemployed for a bit) doing Python. It's starting to look like demand for JVM experience is beginning to wane. Might be time to move on anyway :shrug:
I'm old... as long as there's a steady paycheck involved, I'll code in whatever language you say.
Though, currently working on a little personal project in Scala. :)
rr808
Java is completely revitalized now and is my favorite platform.
The main problem is the legacy code and attitude out there, dependency injection, using Spring or Spring Boot etc SUCKS. VertX is/was good but now with virtual threads you dont need all the async complexity.
nunobrito
Oh, this marks 16 years that I'm writing Java in that case.
My only complaint is the flop with JavaFX. It should have remained as part of the JDK to replace Swing and continued development there.
Without that, Java is thrown as the forever backend platform.
Anyways: good interview.
snovymgodym
Java, especially modern Java, is a fine language. The JVM is an awesome runtime. I'm tired of pretending it isn't.
show comments
throwaway7783
Java stagnated for a while, but has now picked up steam. With things like GraalVM, the stellar ecosystem, generally very good performance and changes to the language, it is more and more pleasant to use.
It may not be cool to use Java for startups, but we do and are immensely productive with it.
SoftTalker
Gosling also developed a version of Emacs back in the early 1980s.
"Gosling Emacs was especially noteworthy because of the effective redisplay code, which used a dynamic programming technique to solve the classical string-to-string correction problem. The algorithm was quite sophisticated; that section of the source was headed by a skull-and-crossbones in ASCII art, warning any would-be improver that even if they thought they understood how the display code worked, they probably did not."
neom
James Gosling, Robert Pike and Geoffrey Hinton are my top 3 "Canadians who meaningfully changed things in technology" (tho, I should probably make it a top 5, add Brian Kernighan and figure out someone else)
show comments
theanonymousone
I have heard it about the situation in 1995, but it probably also holds to a good extent now: You appreciate Java (only) after you have experienced/experience other languages.
cloudking
Why is Java so popular in enterprise?
show comments
kubb
Worth remembering how much marketing effort and money there was in pushing Java in the 90s:
Ode to Java. Boy, I love Java. When I switched jobs way back, a condition was that the new project was going be using Java.
GC. Single file modules. No "forward". The Collection suite. Fast compiles.
The magic of the ClassLoader. The ClassLoader, that was insightful. I don't know how much thought went into that when they came up with it, but, wow. That ClassLoader is behind a large swath of Java magic. It really hasn't changed much over time, but boy is it powerful.
When I started Java, I started it because of the nascent Java web stack of the day. Early servlets and JSP. I picked because of two things. One, JSPs were just Servlets. A JSP was compiled down into a Servlet, and shazam, Servlet all the way down. Two, single language stack. Java in JSPs, Java in Servlets. Java in library code. Java everywhere. In contrast to the MS ASP (pre .NET) world.
Mono-language meant my page building controller folks could talk to my backend folks and share expertise. Big win.
Servlets were a great model. Filters were easy and powerful. Free sessions. Free database connection pools in the server. I mean, we had that in '98, '99.
And, of course, portability. First project was using Netscapes server, which was spitting up bits 2 weeks before we went live, so we switched to JRun in a day or two (yay standard-ish things...). Then, Management(tm) decided "No, Sun/Oracle, we're going NT/SQL Server". Oh no. But, yup, transitioned to that in a week. Month later, CTO was fired, and we went back to Sun/Oracle.
Java EE had a rough start, but it offered a single thing nobody else was offering. Not out of the box. Not "cheap", and that was a transaction manager, and declarative transactions on top of that. We're talking about legit "Enterprise grade" transaction manager. Before you had Tuxedo, or MS MTS. Not cheap, not "out of the box", not integrated. JBoss came out and gave all that tech away. Then Sun jumped on with early, free, Sun Java Enterprise 8 which begat Glassfish which was open source. Glassfish was amazing. Did I mention that the included message queues are part and parcel of the integrated, distributed transaction model for Java EE? Doesn't everyone get to rollback their message queue transactions when their DB commit fails? Message Driven Beans, sigh, warms my heart.
There were certainly some bad decisions in early Java EE. The component model was far too flexible for 95% of the applications and got in the way of the Happy Path. Early persistence (BMP, CMP) was just Not Good. We punted on those almost right away and just stuck with Session Beans for transaction management and JDBC. We were content with that.
The whole "everything is remote" over CORBA IIOP and such. But none of that really lasted. EJB 3 knocked it out of the park with local beans, annotations in lieu of XML, etc. Introduction of the JPA. Modern Jakarta EE is amazing, lightweight, stupid powerful (and I'm not even talking Spring, that whole Other Enterprise Stack). There's lots of baggage in there, you just don't have to use it. JAX-RS alone will take you VERY far. Just be gentle, Java Enterprise offers lots and lots of rope.
None of this speaks to the advances in the JVM. The early HotSpot JIT was amazing. "Don't mind me, I'm just going to seamlessly sneak in some binary compiled code where that stack machine stuff was a nano-second ago. I've been watching it, this is better. Off you go!" Like presents from Santa. The current rocket ship that in JDK development (this is good and bad, I still do not like the Java 9 JPMS module stuff, I think it's too intrusive for the vast majority of applications). But OpenJDK, the Graal stuff. Sheesh, just get all light headed thinking about it.
Along with the JVM we have the JDK, its trivial install. Pretty sure I have, like, 20 of them installed on my machine. Swapped out with a PATH and JAVA_HOME change. The JVM is our VM, the Servlet container is our container. Maven is our dependency manager. Our WAR files are self-contained. And all that doesn't go stomping on our computer files like Paul Bunyan and Blue making lakes in Minnesota.
It's no wonder I was struggling to grok all the talk about VMs, Dockers, and containers and all that stuff folks mess with to install software. We never had to deal with that. It just was not an issue.
I can distribute source code, with a pom.xml, and a mvnw wrapper script, and anyone can build that project with pretty much zero drama. Without breaking everything on their system. And whatever IDE they're using can trivially import that project. It's also fast. My current little project, > 10K lines of code, < 3s to clean/build/package.
Obviously, there's always issues. The Stories folks hear are all true. The legacy stuff, the FactoryInterfaceFactoryImpl stuff. The Old Days. It's all real. It's imperfect.
But, boy, is it impressive. (And, hey, portable GUI folks, Java FX is pretty darn good...)
show comments
klim2media
My biggest gripe with Java is the only really viable IDE option is from a for-profit company and that it routinely gobbles up my RAM. I used Eclipse and Netbeans back in the day but IntelliJ is superior before it becomes unusable.
jbellis
On my list of programmers I want to meet before it's too late, along with Brian Kernighan.
lkuty
I am wondering what was the role of Guy L. Steele in the creation of Java if he had any. From the article, it looks like it was Gosling alone. I did not cheat by checking on Wikipedia
show comments
kaliszad
The java.net.Inet4Address and Inet6Address could be more lightweight.
For a simple IPv4 address normally representable using 4 bytes/ 32 bits Java uses 56 bytes. The reason for it is Inet4Address object takes 24 B and the InetAddressHolder object takes another 32 B. The InetAddressHolder can contain not only the address but also the address family and original hostname that was possibly resolved to the address.
For an IPv6 address normally representable using 16 bytes/ 128 bits Java uses 120 bytes. An Inet6Address contains the InetAddressHolder inherited from InetAddress and adds an Inet6AddressHolder that has additional information such as the scope of the address and a byte array containing the actual address. This is an interesting approach especially when compared to the implementation of UUID, which uses two longs for storing the 128 bits of data.
Java's approach is causing 15x overhead for IPv4 and 7.5x overhead for IPv6 which seems excessive. What am I missing here? Can or should this be streamlined?
show comments
geodel
> Growing up with “pretty close to zero money,”
Zero money programmers >> Zero interest rate programmers :-)
kazinator
Mr. Gosling; please hunt down and release the source code for Ace: a syntax-driven C preprocessor.
You can keep the Java, thanks.
dreamcompiler
Java frustrates the absolute shit out of me. An objectively terrible language coupled with insanely great garbage collectors, insanely great JIT compilers, and insanely great IDEs.
Why couldn't we have had these things for Lisp?* I mean, if 1/1000 of the intellectual horsepower that's been thrown at Java had been thrown at Lisp, we'd all be driving to work in orbit-capable flying cars that used a teaspoon of fuel per year.
* Of course Lisp invented the insanely great IDE around 1984 but then everybody forgot about it and had to rediscover the idea 30 years later.
zombiwoof
Legend
voidhorse
The java ecosystem is great, and the JVM does deserve the appellation of technical marvel, Java the language on the other hand...questionable.
Many of Java's novel language choices have proven unfavorable in the long run (e.g. everything is a class, and even its syntax was needlessly verbose and ceremonious from day one) and all of what makes it a halfway decent language these days are good ideas that originated in other languages, often eons ago, which Java, for some reason, often elects to rebrand with its own terminology.
That said, the maintainers also do a phenomenal job managing the evolution of the language and preserving compatibility, but from a pure programming language design standpoint it's largely a messy amalgam of great ideas from a bunch of other places awkwardly realized. Great, robust ecosystem, great platform, great management, mediocre language design.
lysace
The JVM was the first VM I got to know, at uni in like 1996 or so. Had fun building stuff using the Jasmin "assembler". Seems like it's on Github now: https://github.com/davidar/jasmin
> Jasmin was written because, at the time that we wrote the Java Virtual Machine book for O'Reilly, Sun had not published an assembler format for the Java virtual machine.
> Generating a binary Java .class file is pretty fiddly. Its like creating an a.out (or .exe) file by hand. Even using a Java package like JAS (a Java API for creating class files, used internally by Jasmin and written by KB Sriram), you need to know a lot about the philosophy of the Java Virtual Machine before you can write something at the Virtual Machine level and generate a Java class.
> We wanted something that made it very easy for a student or programmer to explore the Java Virtual Machine, or write a new language which targets the VM, without getting into the details of constant pool indices, attribute tables, and so on.
Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby.
Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine.
Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff.
What do you get for all of these tradeoffs? Speed, memory safety. But with that you still still have dynamic invocation capabilities (making things like interception possible) and hotswap/live redefinition (things that C/CPP cannot do).
Perfect? No, but very practical for the real world use case.
I personally appreciate Java (and the JVM) much more after having tried other languages/ecosystems that people kept saying were so much better than Java. Instead, I just felt like it was a "the grass is greener" every time. The only other language that I felt was an actual massive improvement is Rust (which so far has been a joy to work with).
It's a shame imo that it's not seen as a "cool" option for startups, because at this point, the productivity gap compared to other languages is small, if nonexistent.
Right on, James Gosling's work is amazing, and he and the whole Java ecosystem have my gratitude: I went to the first Java World Tour conference and wrote a little blog article about it that was linked on Sun's home Java page for about a year. I was very lucky, and since I was the first search hit for 'Java consultant' for a very long time that gave my wife and I the freedom to live in a rural area and I could get remote work for a decade.
As long as I am expressing gratitude, I would also like to call out the Clojure team for developing a wonderful ecosystem in top of Java and the JVM.
It must be wonderful to do work that positively affects the lives of millions of people.
I've been working in .NET/C# for the past few years, and while I'm happy with it, I still think the JVM/Java are the best ecosystem overall I've worked in. It's amazing how many things the Java ecosystem gets right that .NET gets wrong.
For instance, Java introduced the fork/join pool for work stealing and recommended it for short-lived tasks that decomposed into smaller tasks. .NET decided to simply add work-stealing to their global thread pool. The result: sync-over-async code, which is the only way to fold an asynchronous library into a synchronous codebase, frequently results in whole-application deadlocks on .NET, and this issue is well-documented: https://blog.stephencleary.com/2012/07/dont-block-on-async-c...
Notice the solution in this blog is "convert all your sync code to async", which can be infeasible for a large existing codebase.
There are so many other cases like this that I run into. While there have been many mistakes in the Java ecosystem they've mostly been in the library/framework level so it's easier to move on when people finally realize the dead end. However, when you mess up in the standard library, the runtime, or language, it's very hard to fix, and Java seems to have gotten it more right here than anywhere else.
Java is a great success story. Though, to be fair, James Gosling was the spark but has not been the steward.
Even as early as Java 1.1 and 1.2 he was not particularly involved in making runtime, library, or even language decisions, and later he wasn't the key to generics, etc.
Mark Reinhold has been the hand's-on lead since 1.1, first integrating early JIT's, HotSpot, the 1.2 10X class explosion, and has been running the team all the way through Oracle's purchase, making the JVM suitable for dynamic language like Kotlin and Clojure, open-sourcing, moving to a faster release cadence, pushing JVM method and field handles that form the basis for modern language features, migrating between GC's, and on and on.
As far as I can tell, everything that makes Java great has come down to Mark Reinhold pushing and guiding.
Just going to remind y'all of this: https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...
I went to a Java school. I remember my operating systems class involved writing simulated OS code in Java (for example, round robin for context switching). The argument was that it would be easier to understand the algorithms if the hardware complexities were minimized. I understand that sentiment, but I don't think Java was the right choice. Python would have accomplished the same task even better (understanding algorithms). I think there was a huge influence from industry to teach college students Java from day one. I had taught myself BASIC and some C back in high school, so it was a bit of a step backwards to learn a high-level language just to do simulated low-level OS programming.
I admire Java as a success story, but I still have a deeply ingrained aversion to it for many reasons. I will admit that many of the reasons are due to Java's legacy as the language of bloated corporations, and its creation of overly verbose, magic fueled frameworks and poorly written code. Java as a language goes hand in hand with the idea that code is coal to be shoveled into the furnace, and we should all throw our aspirations away and embrace mediocrity.
My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA with standard ops tools like strace, gdb, etc. The JVM's over allocation of memory robs the kernel of real insight as to how the workload is actually performing. When you use the JVM, you are completely locked in and god help you if there isn't a JVM expert to debug your thing and unravel how it translates to a platform implementation.
Then of course there's the weird licensing, it's association with Oracle, managing JDK versions, it's lack of it factor in 2025, and a huge boatload of legacy holding it back (which is not unique to Java).
I have successfully navigated my career with minimal exposure to Java, and nowadays there's a glut of highly performant languages with GC that support minimal runtimes, static compilation, and just look like regular binaries such that the problems solved by something like the Java or Python VMs just aren't as relevant anymore - they just add operational complexity.
To reiterate, I admire JG just like any tech person should. Java's success is clear and apparent, but I'm glad I don't have to use it.
When Gosling was at Sun, he was one of two principal architects of the NeWS Window system. The X Window system was designed for "dumb" display devices and so the display elements were all static, not requiring much work from the server. NeWS was designed to run on a (Sun) workstation, where there was a lot of computational power available, so it was based on Postscript. A NeWS client would send a program to the server, not just static commands.
Gosling, unsurprisingly, designed Java with the NeWS model in mind, where web pages were programs, not just static HTML documents. When I got him to sign my copy of "The Java Programming Language", I asked him if Java was the revenge of NeWS. He just smiled.
> Gosling primarily uses the NetBeans IDE for development, praising its open source, Apache-licensed nature and dedicated community. He expresses frustration with developers who cling to outdated tools: “The thing that drives me nuts the most are people who are madly grasping the ’80s or the ’70s — people who still want to use Vi, which was high-tech in the ’70s.”
From one of the key developers in the Emacs history, and genesis.
He moved on, others keep trying to live in the past.
Been coding on the JVM for a good chunk of my career. Though the last several years has been in languages other than Java - Scala, Clojure (my personal favorite), and Kotlin.
Finally managed to get a job offer (after being unemployed for a bit) doing Python. It's starting to look like demand for JVM experience is beginning to wane. Might be time to move on anyway :shrug:
I'm old... as long as there's a steady paycheck involved, I'll code in whatever language you say.
Though, currently working on a little personal project in Scala. :)
Java is completely revitalized now and is my favorite platform.
The main problem is the legacy code and attitude out there, dependency injection, using Spring or Spring Boot etc SUCKS. VertX is/was good but now with virtual threads you dont need all the async complexity.
Oh, this marks 16 years that I'm writing Java in that case.
My only complaint is the flop with JavaFX. It should have remained as part of the JDK to replace Swing and continued development there.
Without that, Java is thrown as the forever backend platform.
Anyways: good interview.
Java, especially modern Java, is a fine language. The JVM is an awesome runtime. I'm tired of pretending it isn't.
Java stagnated for a while, but has now picked up steam. With things like GraalVM, the stellar ecosystem, generally very good performance and changes to the language, it is more and more pleasant to use.
It may not be cool to use Java for startups, but we do and are immensely productive with it.
Gosling also developed a version of Emacs back in the early 1980s.
https://en.wikipedia.org/wiki/Gosling_Emacs
"Gosling Emacs was especially noteworthy because of the effective redisplay code, which used a dynamic programming technique to solve the classical string-to-string correction problem. The algorithm was quite sophisticated; that section of the source was headed by a skull-and-crossbones in ASCII art, warning any would-be improver that even if they thought they understood how the display code worked, they probably did not."
James Gosling, Robert Pike and Geoffrey Hinton are my top 3 "Canadians who meaningfully changed things in technology" (tho, I should probably make it a top 5, add Brian Kernighan and figure out someone else)
I have heard it about the situation in 1995, but it probably also holds to a good extent now: You appreciate Java (only) after you have experienced/experience other languages.
Why is Java so popular in enterprise?
Worth remembering how much marketing effort and money there was in pushing Java in the 90s:
https://m.youtube.com/watch?v=NVuTBL09Dn4
Ode to Java. Boy, I love Java. When I switched jobs way back, a condition was that the new project was going be using Java.
GC. Single file modules. No "forward". The Collection suite. Fast compiles.
The magic of the ClassLoader. The ClassLoader, that was insightful. I don't know how much thought went into that when they came up with it, but, wow. That ClassLoader is behind a large swath of Java magic. It really hasn't changed much over time, but boy is it powerful.
When I started Java, I started it because of the nascent Java web stack of the day. Early servlets and JSP. I picked because of two things. One, JSPs were just Servlets. A JSP was compiled down into a Servlet, and shazam, Servlet all the way down. Two, single language stack. Java in JSPs, Java in Servlets. Java in library code. Java everywhere. In contrast to the MS ASP (pre .NET) world.
Mono-language meant my page building controller folks could talk to my backend folks and share expertise. Big win.
Servlets were a great model. Filters were easy and powerful. Free sessions. Free database connection pools in the server. I mean, we had that in '98, '99.
And, of course, portability. First project was using Netscapes server, which was spitting up bits 2 weeks before we went live, so we switched to JRun in a day or two (yay standard-ish things...). Then, Management(tm) decided "No, Sun/Oracle, we're going NT/SQL Server". Oh no. But, yup, transitioned to that in a week. Month later, CTO was fired, and we went back to Sun/Oracle.
Java EE had a rough start, but it offered a single thing nobody else was offering. Not out of the box. Not "cheap", and that was a transaction manager, and declarative transactions on top of that. We're talking about legit "Enterprise grade" transaction manager. Before you had Tuxedo, or MS MTS. Not cheap, not "out of the box", not integrated. JBoss came out and gave all that tech away. Then Sun jumped on with early, free, Sun Java Enterprise 8 which begat Glassfish which was open source. Glassfish was amazing. Did I mention that the included message queues are part and parcel of the integrated, distributed transaction model for Java EE? Doesn't everyone get to rollback their message queue transactions when their DB commit fails? Message Driven Beans, sigh, warms my heart.
There were certainly some bad decisions in early Java EE. The component model was far too flexible for 95% of the applications and got in the way of the Happy Path. Early persistence (BMP, CMP) was just Not Good. We punted on those almost right away and just stuck with Session Beans for transaction management and JDBC. We were content with that.
The whole "everything is remote" over CORBA IIOP and such. But none of that really lasted. EJB 3 knocked it out of the park with local beans, annotations in lieu of XML, etc. Introduction of the JPA. Modern Jakarta EE is amazing, lightweight, stupid powerful (and I'm not even talking Spring, that whole Other Enterprise Stack). There's lots of baggage in there, you just don't have to use it. JAX-RS alone will take you VERY far. Just be gentle, Java Enterprise offers lots and lots of rope.
None of this speaks to the advances in the JVM. The early HotSpot JIT was amazing. "Don't mind me, I'm just going to seamlessly sneak in some binary compiled code where that stack machine stuff was a nano-second ago. I've been watching it, this is better. Off you go!" Like presents from Santa. The current rocket ship that in JDK development (this is good and bad, I still do not like the Java 9 JPMS module stuff, I think it's too intrusive for the vast majority of applications). But OpenJDK, the Graal stuff. Sheesh, just get all light headed thinking about it.
Along with the JVM we have the JDK, its trivial install. Pretty sure I have, like, 20 of them installed on my machine. Swapped out with a PATH and JAVA_HOME change. The JVM is our VM, the Servlet container is our container. Maven is our dependency manager. Our WAR files are self-contained. And all that doesn't go stomping on our computer files like Paul Bunyan and Blue making lakes in Minnesota.
It's no wonder I was struggling to grok all the talk about VMs, Dockers, and containers and all that stuff folks mess with to install software. We never had to deal with that. It just was not an issue.
I can distribute source code, with a pom.xml, and a mvnw wrapper script, and anyone can build that project with pretty much zero drama. Without breaking everything on their system. And whatever IDE they're using can trivially import that project. It's also fast. My current little project, > 10K lines of code, < 3s to clean/build/package.
Obviously, there's always issues. The Stories folks hear are all true. The legacy stuff, the FactoryInterfaceFactoryImpl stuff. The Old Days. It's all real. It's imperfect.
But, boy, is it impressive. (And, hey, portable GUI folks, Java FX is pretty darn good...)
My biggest gripe with Java is the only really viable IDE option is from a for-profit company and that it routinely gobbles up my RAM. I used Eclipse and Netbeans back in the day but IntelliJ is superior before it becomes unusable.
On my list of programmers I want to meet before it's too late, along with Brian Kernighan.
I am wondering what was the role of Guy L. Steele in the creation of Java if he had any. From the article, it looks like it was Gosling alone. I did not cheat by checking on Wikipedia
The java.net.Inet4Address and Inet6Address could be more lightweight.
For a simple IPv4 address normally representable using 4 bytes/ 32 bits Java uses 56 bytes. The reason for it is Inet4Address object takes 24 B and the InetAddressHolder object takes another 32 B. The InetAddressHolder can contain not only the address but also the address family and original hostname that was possibly resolved to the address.
For an IPv6 address normally representable using 16 bytes/ 128 bits Java uses 120 bytes. An Inet6Address contains the InetAddressHolder inherited from InetAddress and adds an Inet6AddressHolder that has additional information such as the scope of the address and a byte array containing the actual address. This is an interesting approach especially when compared to the implementation of UUID, which uses two longs for storing the 128 bits of data.
Java's approach is causing 15x overhead for IPv4 and 7.5x overhead for IPv6 which seems excessive. What am I missing here? Can or should this be streamlined?
> Growing up with “pretty close to zero money,”
Zero money programmers >> Zero interest rate programmers :-)
Mr. Gosling; please hunt down and release the source code for Ace: a syntax-driven C preprocessor.
You can keep the Java, thanks.
Java frustrates the absolute shit out of me. An objectively terrible language coupled with insanely great garbage collectors, insanely great JIT compilers, and insanely great IDEs.
Why couldn't we have had these things for Lisp?* I mean, if 1/1000 of the intellectual horsepower that's been thrown at Java had been thrown at Lisp, we'd all be driving to work in orbit-capable flying cars that used a teaspoon of fuel per year.
* Of course Lisp invented the insanely great IDE around 1984 but then everybody forgot about it and had to rediscover the idea 30 years later.
Legend
The java ecosystem is great, and the JVM does deserve the appellation of technical marvel, Java the language on the other hand...questionable.
Many of Java's novel language choices have proven unfavorable in the long run (e.g. everything is a class, and even its syntax was needlessly verbose and ceremonious from day one) and all of what makes it a halfway decent language these days are good ideas that originated in other languages, often eons ago, which Java, for some reason, often elects to rebrand with its own terminology.
That said, the maintainers also do a phenomenal job managing the evolution of the language and preserving compatibility, but from a pure programming language design standpoint it's largely a messy amalgam of great ideas from a bunch of other places awkwardly realized. Great, robust ecosystem, great platform, great management, mediocre language design.
The JVM was the first VM I got to know, at uni in like 1996 or so. Had fun building stuff using the Jasmin "assembler". Seems like it's on Github now: https://github.com/davidar/jasmin
> Jasmin was written because, at the time that we wrote the Java Virtual Machine book for O'Reilly, Sun had not published an assembler format for the Java virtual machine.
> Generating a binary Java .class file is pretty fiddly. Its like creating an a.out (or .exe) file by hand. Even using a Java package like JAS (a Java API for creating class files, used internally by Jasmin and written by KB Sriram), you need to know a lot about the philosophy of the Java Virtual Machine before you can write something at the Virtual Machine level and generate a Java class.
> We wanted something that made it very easy for a student or programmer to explore the Java Virtual Machine, or write a new language which targets the VM, without getting into the details of constant pool indices, attribute tables, and so on.