JVM Anatomy Quarks

Google uses mocks and fakes implementations of interfaces, and provides dependency injection frameworks for managing these (Guice and Dagger).

Of course you get code bloat defining interfaces for everything you intend to implement once, and you have to enforce these rules, but this is something that could be made easier. Not in Java, but imagine a language where:

- Concrete classes can only be used in new, or in some platform provided DI container.

- Methods can only accept interface types and return interface types.

- Fields are private only, all public/protected is via properties (or getters/setters, it just has to be declarable in an interface)

- You have a ".interface" syntax (akin to ".class" but for types) that refers to the public members of a class without tying you to the concrete class itself. You can use this as a shorthand instead of declaring separate interfaces for everything.

Eg.

```

final class GDrive { ... }

public Download file(GDrive.interface drive) { ... }

class MockDrive implements GDrive.interface { ... }

```

The closest I can think of is a hypothetical typed variant of NewSpeak, but maybe something like this exists already?

Normally a JDK 21 would let you get private/final reflective access to your own “module” but not to the stdlib modules but so many libraries want private access to stdlib objects such as all the various date and time objects.

> And mocking tools have to resort to bytecode manipulation to mock the final classes

Well which is it? Presumably you use said mocking tool anyway, so it's not your effort that's being expended.

"Final all the things" really doesn't go far enough. There is little point substituting a mutable hashmap for a "final" mutable hashmap, when the actual solution is for the standard library to ship proper immutable collection classes.

In any case, I prefer to avoid mockito anyway, so it's a non-issue for me. Just do plain ol' dependency injection by passing in dependencies into constructors.

I can no longer recall exactly what Bloch said, I may have to search through some of by old writing to find it, but at one point he admitted he didn’t really understand type theory when he designed the collections API. And while I appreciate the honesty, and the reason (he was trying to illustrate that this stuff is still too hard if “even he” didn’t get it), I think it paints him rather worse.

But I already knew that about him from working with that code for years and understanding LSP, which he clearly did not.

I don’t know why they thought he should be the one writing about how to use Java effectively when he was materially responsible for it being harder to use, but I’m not going to give him any money to reward him. And there are other places to get the same education. “Refactoring” should be a cornerstone of every education, for much the same reason learning to fall without hurting yourself is the first thing some martial arts teach you. Learn to clean up before you learn to make messes.

He said at one point that he had thought of a different way to decompose the interfaces for collections that had less need for variance, with read and write separated, but he thought there were too many interfaces and they would confuse people. But when I tried the same experiment (I spent years thinking about writing my own language)… the thing is when you’re only consuming a collection, a lot of the types have the same semantics, so they don’t need separate read interfaces, and the variance declarations are much simpler. It’s only when you manipulate them that you run into trouble with Liskov, and things that are structurally similar have different contracts. The difference in type count to achieve parity with Collections was maybe 20% more, not double. So to this day I don’t know what he’s talking about.

Most APIs should only consume collections from callers, so friction against mutation in your interface is actually a good thing.

Mocking final classes is a blunder on its own. Most classes should be package private not public, so being final would have close to zero relevance. Personally I do not use mocking tools/frameworks at all.

OTOH, there is very little benefit of having final classes performance wise. Java performs CHA (class hierarchy analysis), anyways.

e.g. SecurityManager for applets will not let you setAccessible(true) on private fields of system classes

I’ve spent years writing Java and later Scala, in academia and later production. I’ve always followed to see how the JVM and the language/ecosystem has progressed. And now I don’t use it at all. Is it really that odd to take a temperature on a site filled with other tech folks? I don’t understand why you took it so negatively and use words like bloviate, or attack me as just posturing to look cool (how does one look cool on a geeky Internet forum?). One of the HN tenants is to “converse curiously,” which is exactly my mindset when I wrote my comment. And if you look at the other replies, it seems others took it that way as well with healthy discussion.

async/await is not really a revolution, so much as a bandaid bringing a modicum of parallelism to certain programming languages that don't have a good threading model.

Xmx is mostly a thing if you have very small RAM, or some sort of grievously misconfigured container setup. By default it grow up to 25% of the system RAM, which is a relatively sane default.

Is it not you who stagnated a bit?..

They deliberately took the longer route, aiming to integrate lightweight threads in a way that doesn't force developers to change their existing programming model. No need for callbacks, futures, coroutines, async/await, whatever. This required a massive effort under the hood and rework to many core APIs. Even code compiled with decade old Java versions can run on virtual threads and benefit, without any refactoring or recompilation.

> ...and/or async/await revolution of the last decade

async/await is largely syntactic sugar. Java has had the core building blocks for asynchronous programming for years, with CompletableFuture (2014, replacing the less flexible Future introduced in 2004) and NIO.2 (2011, building on the original NIO from 2002) for non-blocking I/O, along with numerous mature libraries that have been developed on top of them over time.

> Bottomless resources of developers with Java experience.

With Java experience, but what fraction have a systems outlook? What fraction have an experience with other languages to ensure that the code they write is simple and understandable and direct? My own experience is that too many come out addled by Enterprise Java idioms, and when you actually write some code in Erlang or Go you realize systems aren't as complicated as they have been made out to be.

> Managing very large codebases ...

I wonder if this is self-fulfilling. My theory is that these codebases are huge because their designs are enterprisey. The primary drivers of complexity are indirection: factories, dependency injection, microservices, these are all part of the same malaise.

No one is going to rewrite the JVM, even though there are several implementations, all of them are a mix of C, C++, Assembly and Java, zero Kotlin and Scala.

Yet as usual there is this little island of Kotlin or Scala ecosystem, with their own replacement of everything, and continuous talks how it is possible that the platform that makes their existence possible hasn't been rewriten into them.

Typescript and Clojure folks are traditionally more welcoming of the platform, they rather appreciate the symbiotic relationship with the host, and much more fun to hang around with.