Java was not underhyped in 1997 (2021)

> Java and JVM's WORA "Write Once Run Anywhere" will kill Microsoft's Evil Empire because it will render Windows irrelevant.

There was the sentiment but this doesn’t fully capture what the hype was about. Java out of the gate had Suns network vision built in via jndi, rmi and object serialization. The hype was about moving applications onto the network and off of windows or any particular vendors OS.

And this did come to pass, just not how Sun was selling it with Java. For example; Office, Microsoft’s crown jewel and anchor into a lot organizations is now almost entirely web based.

> Java will make lower level languages with manual memory allocation like C/C++ obsolete because CPUs are getting faster.

Except that this actually happened wrt. a whole lot of application code. Sure, Java was slow and clunky but at least it was free of the memory unsafety that plagued C/C++. What was the mainstream "safe" alternative? There was no Rust back then, even Cyclone (the first memory-safe C style language) was only released in the mid-2000s.

I’m a professional programmer now, but I was not in the early 2000s and I remember looking at my girlfriend’s computer science book. I saw the unnecessary boiler plate and leaky abstractions of 90s style OOP and wasn’t sure if I was wrong or ‘serious’ programming had become insane. It was nearly a decade before I worked out the Java had nothing to do with the Alan Kay’s original concept of OOP and the rest of the industry started to abandon it.

> It was ridiculous. They seriously wanted to rewrite everything in Java, including office and web browsers.

There's another perspective. Many people were looking for something like Java well before it was released: VM-based, portable, modern object-orientation features, etc.

Case in point: databases. In the early 1990s I worked on a project at Sybase that attempted to rewrite SQL Server from the ground up to bring in object [relational] support. The team focused on VM-based languages as a foundation, which were an area of active academic research at the time. Built-in object support, portability, and ability to support code generation for queries were among the attractions. The project started with Smalltalk (slow!), then moved to an acquired VM technology (it was bad!), and finally a VM we designed and built ourselves. These gyrations were a key reason why the project failed, though not the only one.

When Java came out in 1995--I got access to the alpha release in September--it met virtually every requirement we were trying to fulfill. At that point most attempts to build new databases on other VM tech became instantly obsolete. (Other vendors were also looking at VMs as well.)

Not coincidentally Nat Wyatt and Howard Torf, a couple of key engineers from our project, founded a start-up called Cloudscape to pursue the Java route. They created the database we know today as Derby.

Somewhat more coincidentally, Java became dominant in American DBMS development after 2000. Examples including Hadoop, Druid, Pinot, HBase, etc., are just a few of the examples. I say "somewhat more concidentally" because at that point most of us saw Java as simply more productive than C/C++ alternatives for building reliable, high-performance, distributed systems. That view has obviously evolved over time, but between JIT, dev tooling, and libraries it was definitely true in the early 2000s. It helps to remember how difficult C++ was to use at that time to understand this perspective.

In summary, a lot of the hype was the usual new technology craziness, but Java also met the needs of a population of people that went far beyond databases. There was a basis for our excitement. Just my $0.02.

Edit: typo

Two points:

The hype accomplished something that would be otherwise impossible: it established Java as a language in what was likely record time. Consider another popular language: Python. It was created about 5 years earlier, yet it rose to prominence about a decade later. Or consider Rust. It is, in many respects, as significant as Java. While major developers were shipping significant applications written in Java within 5 years, Rust is only creeping into important software a decade after its introduction.

The second point is its easy to underestimate the dominance of Microsoft in those days. You think that Microsoft is dominant today, well, that's nothing compared to the late 1990's. Microsoft's market share was closer to 95% for the PC market. The workstation market was starting to crumble due to competition from Microsoft and Intel. About the only thing that was safe were mainframes, and that was highly dependent upon one's definition of safe. Nearly everyone who was competing against Microsoft wanted to see a chunk taken out of them, which meant pretty much everyone since Microsoft had its fingers in so many markets. And, as it turns out, nearly everything did have to be rewritten. Sometimes it was to deliver SaaS over the Internet and sometimes it was to target mobile devices.

RIIR is justified in most of the cases because in the past the only reason to use a GCd language was memory safety for most of the apps.

RIIJ was justified too, because people believed the web will end up being java applets all the way down.

Well all the parts that you didn’t write in XML and XSLT, etc.

I remember some greybeards hyping the CPUs that could run Java bytecode (it existed for a short time). I was a junior C++ fanboy at the time and I already knew that they were wrong.

There are design decisions you can reasonably question in Rust but the big one that justifies its existence is memory safety. It's simply too important. Not everything needs it but key infrastructure, most notably Web browsers, do.

I predict we will be having buffer overrun CVEs in C/C++ code for as long as we have C/C++ code.

The realities of writing safe, multithreaded C/C++ on processors with out-of-order processing, context switching and branch prediction is simply too complex to get right 100% of the time. Rust makes writing certain code difficult because it is difficult to do/ C/C++ fools you into believing something is safe because you've never encountered the circumstances where it isn't.

We have tools like valgrind to try and identify such issues. They're certainly useful. But you'll be constantly chasing rabbits.

I've seen thread and memory bugs in production code written by smart, highly-paid engineers at big tech companies that have lain dormant for the better part of a decade.

That's why Rust exists.

I was excited about ApplixWare Anyware Office[0] around 1999-2000. I'm pretty sure I got a copy bundled in a boxed copy of SuSE or RedHat. It was the first time I'd really seen a real productivity application written as an applet. It was an interesting idea that was eventually delivered by JavaScript.

[0] https://www.applix.com/applixware/anywareoffice.html

Agreed. I lived through it and it was seriously overhyped.

> Both because it was a young language, and had all the problems of a young language like poor library support for just about everything, and because the hardware in 1997 wasn't ready to deliver on the hype.

Outside of Perl’s CPAN, library support in 1997 sucked for all languages. Being able to write a hash-table or linked list C was a valuable commercial skill as nearly every single code base would include custom versions of these sorts of very basic data structures rather than pull them from a commonly used library.

“Using a 3rd party library” meant copying a bunch of source code downloaded from who-knows-where into your source control repo and hacking it to work with whatever funky compiler and/or linker your project used.

I've been a "mainly" Java programmer for 15+ years (I've used several other languages, but Java has remained the main one over all this time). I only did something like 1 year using Spring in one of my early jobs. So, when I saw some people online talking like "you ain't a Java programmer if you don't do Spring" I used to think they're complete idiots, I am living proof you can write lots and lots of Java and basically never encounter Spring.

However, since then I've seen several surveys of JVM programmers, and apparently Spring is used in something like 80% of Java projects, so it's not surprising a majority of people, even Java developers, think that Spring is somehow mandatory if you're a Java programmer. But of course, it's just a framework, one of many, it's just the most popular one. Can you "do JS" professionally without knowing Javascript today? I'd think so. I guess React is about as dominant in the JS-world as Spring is in the Java-world.

I used to think that way too, but there’s a good argument to be made that overflowing your integer types to negative values instead of to small (or large) positive values avoids a lot of silent bugs you’d otherwise have with unsigned types. A language solving that would need to work with static proofs of non-overflow, and have any desired overflow to be explicit.

Java in the meantime has gained all the unsigned operations as methods in the Integer and Long classes, so the relatively rare cases when you need them are straightforward to handle.

The only real annoyance is that byte is signed. At least there’s a bit of unsigned support in the Byte class now.

Lastly, minor point, Java actually has an unsigned 16-bit integer type, called char.

Other than unsigned types for FFI or wire formats (which Java supports just fine) or for bitfields (which Java doesn't have), what do you want unsigned numerics for?

The risk of unsigned types (even without the C or C++ issues around mixing with signed types) is that too many people make the mistake of using them to express the invariant of "a number that must be positive", which modular arithmetic types are a really bad fit for.

One possible use is for a memory-efficient storage of small positive values, say in a byte. But then you have to make a choice between forcing the value into a signed type for arithmetic (which Java easily lets you do with Byte.toUnsignedInt) and allowing signed and unsigned types to be mixed.

I'm doing Java for my main work, and boy, this still doesn't sit right with me after decades in the space. just give me my properly unsigned bytes, please

The problem with having unsigned integer types is that it introduces new type conversion issues. If you call a method that returns an unsigned int, how do you safely pass it to a method that accepts an int? Or vice versa? A smaller set of primitive types is preferred, since it has fewer conversion issues.

Unsigned integer types are only really necessary when dealing with low-level bit manipulation, but most programs don't do this. The lack of unsigned integers makes low-level stuff a bit more difficult, but it makes the language as a whole much easier. It's a good tradeoff.

Java is still the only go-to language for almost all of the fortune 100 (or 500) companies other than perhaps .Net. No other languages including Go, Rust (Difficult to get devs from consulting companies), Python, Typescript (Considered inferior by enterprise backend dev bros) are being used for building core backend APIs. Almost all the devs for these large enterprises are outsourced from large consulting companies like Infosys, Accenture, TCS, Wipro etc and all of them are still doing Java. I know it by working in large Banks and later trying to sell a non-Java platform to these companies and failing just because it was not written in Java..

Also most of the large enterprises need distributed transactions as they use multiple databases and message queues in a monolith architecture - and no other language have the lib/tooling that can beat Java.