Java at 30: Interview with James Gosling

The GC would be the least of your problems.

Java is neat, but the memory model (on which the GC relies) and lack of operator overloading does mean that for games going for that level of performance would be incredibly tedious. You also have the warm up time, and the various hacks to get around that which exist.

Back when J2ME was a thing there was a mini industry of people cranking out games with no object allocation, everything in primitive arrays and so on. I knew of several studios with C and even C++ to Java translators because it was easier to write such code in a subset of those and automatically translate and optimize than it was to write the Java of the same thing by hand.

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, 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...)

"Your deadlock scenario is related to synchronization contexts and can be avoided by ..."

rather than:

"You clearly don't know what you're talking about (but I won't bother telling you why)"

Then we could have had a much more productive and pleasant conversation. I would have responded with:

"Sorry, that article wasn't the right one to share. Here is a better one. The issue I am talking about isn't synchronization context-related at all. It's actually much more insidious."

Java's tools are really top notch. Using IntelliJ for Java feels a whole new different world from using IDEs for other languages.

Speaking of Go, does anyone know why Go community is not hot on developing containers for concurrent data structures? I see Mutex this and lock that scattering in Go code, while in Java community the #1 advice on writing concurrency code is to use Java's amazing containers. Sometimes, I do miss the java.util.concurrent and JCTools.