The only thing worse than launching the JVM from the command line, with it's looooooooooooong and inexplicable load time, was hitting a web page and having it lock the browser for that amount of load time.

I remember a few decades ago somebody saying the JVM was incredible technology, and as a user and programmer I still have zero clue what the hell they could have been thinking was good about the JVM.

I hear that now, decades into Java, they have figured out how to launch a program without slowing a computer down for 10+ seconds, but I'll be damned if I find out. There are still so many rough edges that they never even bothered to try to fix about launching a .jar with classpath dependencies. What a mess!

▲

another_twist 3 days ago | parent | next [-]

I understand the sarcasm but this take is devoid of fact. Modern Java loads fast, Java 21 has pretty good functional programming featurez. The ecosystem churns out language level features at a pace and a budget that would put most large funded startups to shame.

Java is also the workhorse of the big data ecosystem and moves enough money either as product revenue or as transactions than most nations GDP. They didn't figure out startup times for 10+ years, they were busy dealing with Oracle and its messy management. I think it will simply continue to get better given that Java has endured through so many language fads. It has its ways to go but it will end up like SQL - here before we were alive and will be here when most of us are dead.

▲

eru 3 days ago | parent | next [-]

Mostly agreed that Java, warts and all, has gotten better, and will stick around. It's the new COBOL, for better or worse. (I still wouldn't want to use it voluntarily, but if someone pays me enough money, sure.)

However:

> Java is also the workhorse of the big data ecosystem and moves enough money either as product revenue or as transactions than most nations GDP.

The global financial system moves so much money around that comparisons to GDP are a bit silly. Financial transactions dwarf GDP by so much that even a bit player of a technology will facilitate more transactions than global GDP.

(And that's fine. Many of these transactions are offsetting, and that it's a sign of an efficient market that the mispricings are so small that participants needs giant gross flows to profit from them.

Somewhat related: a single high capacity fire hose (at about 75kg of water per second) moves about the same number of electrons as you'd need to power the total US electricity consumption at 120V. Obviously, your fire hose also sprays plenty of pesky protons which completely offset the electrical current from the electrons.)

▲

another_twist 3 days ago | parent [-]

> The global financial system moves so much money around that comparisons to GDP are a bit silly.

Agreed. I guess its comparing production capacity to distribution capacity. Distribution capacity will equal n_tx * tx_amt. Having said that, another metric to look at is how much of software infrastructure is built on Java. Simply adding AWS to this equation proves the value added by Java backed systems. Hard to say that about any other langauge. Also we can look at versatility, Java is used to write very large data processing systems, CDN networks, API servers and even widely used consumer apps (IntelliJ products). Its very hard to find any other language that has had an outsized impact across domains. Of course the counter being Linux written on C powers all of the internet. True but C doesnt have the cross domain impact that Java has had.

So I disagree with the assessment that Java is a terrible langauge performance or productivity wise or it wouldnt have had this impact.

	▲	Sardtok 3 days ago \| parent [-]
		You could easily say the same about C/C++, as the operating systems and most databases are written in the language(s).

▲

epistasis 3 days ago | parent | prev [-]

There's zero sarcasm in my comment.

The JVM is quite different from Java language features or Scala language features. I've written entire programs in JVM bytecode, without a compiler, and I see very little of value in it. A stack based machine? Why? Not a huge blocker, it's weird, but usable. The poor engineering around the JVM for many use cases? That's a blocker for me, and where are the alternatives in implementation that don't have the atrocious launch performance and interface for specifying class path and jars?

Java may be used a lot, but so is Windows. It's an accident of history, of early adoption and network effects, rather than being inherently good technology. Java, the language, made a very wide and broad swath of programmers productive, just as Windows lets a very wide and broad set of IT people run IT systems, without having to learn as much or know as much as they would need to with, say, Linux. But Java's low-barrier-to-entry is quite distinct from the weaknesses of the JVM...

▲

writebetterc 3 days ago | parent | next [-]

> A stack based machine? Why?

The JVM being a stack-machine is probably the least controversial thing about it. Wasm, CPython and Emacs all also have a stack-based bytecode language. The value, of course, comes from having a generic machine that you can then compile down into whatever machine code you want. Having a register machine doesn't seem very useful, as it's completely unnecessary for the front-end compiler to minimize register usage (the backend compiler will do that for you).

Specifying classpath isn't fun, I agree with that. Launch performance isn't good, and is generally a consequence of its high degree of dynamicism and JIT compiler, though of course there are ways around that (Leyden).

> I've written entire programs in JVM bytecode, without a compiler, and I see very little of value in it

I agree, I also see very little value in manually writing JVM bytecode programs. However, compiling into the JVM classfile format? Pretty darn useful.

	▲	Skinney 3 days ago \| parent [-]
		> Having a register machine doesn't seem very useful... Requires fewer instructions, so potentially faster evaluation, which is good for short-lived programs that ends before the JIT kicks in. Stack machines requires less space per instruction, however, which reduces the size of the program (faster to load).

▲

eru 3 days ago | parent | prev | next [-]

> Java may be used a lot, but so is Windows. It's an accident of history, of early adoption and network effects, rather than being inherently good technology.

Going on a tangent: Windows is an interesting example to bring up, because the Windows versions everyone uses today have about as much to do with the 'accident of history / early adoption' versions that were based on DOS as using Wine on Linux has.

It would perhaps be like today's JVM being register based, when the first version were stack based.

I don't actually know how much the JVM has changed over time.

▲

another_twist 3 days ago | parent | prev [-]

> I remember a few decades ago somebody saying the JVM was incredible technology, and as a user and programmer I still have zero clue what the hell they could have been thinking was good about the JVM.

I see what you mean. In that case we can add Scala backed systems as well to the JVM balance sheet. If we simply look at the JVM and the systems it backs, there's very little evidence that it isnt a marvel of technology. It powers more impactful systems than few other technologies.

▲

netsharc 3 days ago | parent | prev | next [-]

I guess in the era of SSDs (vs. spinning disks) and multi-GHz cores, the startup really isn't a big issue anymore?

I wonder how long Teams or Slack would take to launch when it's on a 5400rpm disk on a 2000 era computer...

	▲	nrhrjrjrjtntbt 3 days ago \| parent [-]
		I remember my 2000 computer could play an mp3. But thats it. Your system is 100% utilized. No way it could even think about a modern gas guzzling app.

▲

matsemann 3 days ago | parent | prev | next [-]

So your lack of technical knowledge or curiosity means Java wasn't incredible? That's certainly... a take. I'm almost curious: why did you end up holding strong beliefs like these, instead of actually investigating? As a curious person, when I hear something I don't know I like to learn - not just dismiss it. FYI, your .jar complaint is almost a decade out of date.

▲

bhaak 3 days ago | parent | prev | next [-]

The JVM proved to the mainstream that a virtual machine good be as fast (sometimes even faster) than a compiled binary. Because of that it took a lot of the market share of C/C++ in the 90s.

You got a buffer overflow safe language without compromise of speed. After it has been loaded, of course. But that's why Java had such a tremendous effect in Web services where the load times are negligible to the run time.

▲

eru 3 days ago | parent [-]

Of course, eliminating buffer overflows is orthogonal to using a virtual machine.

▲

bhaak 3 days ago | parent | next [-]

You also got a language easier to use and learn than C/C++.

With universities almost immediately jumping to Java as an introductory language you got way more potential employees.

▲

writebetterc 3 days ago | parent | prev [-]

No, it's not? Using a VM is one way of preventing buffer overflows, it's not orthogonal.

	▲	eru 3 days ago \| parent [-]
		You can prevent buffer overflows even when you don't use a VM. Eg it's perfectly legal for your C compiler to insert checks. But there are also languages like Rust or Haskell that demand an absence of buffer overflows. You can design a VM that still allows for buffer overflows. Eg you can compile C via the low-level-virtual-machine, and still get buffer overflows. Any combination of VM (Yes/No) and buffer-overflows (Yes/No) is possible. I agree that using a VM is one possible way to prevent buffer overflows.

▲

lenkite 3 days ago | parent | prev | next [-]

> There are still so many rough edges that they never even bothered to try to fix about launching a .jar with classpath dependencies.

Feels like you are still living in year 2010 ?

▲

forgotpwd16 3 days ago | parent | prev | next [-]

>I still have zero clue what the hell they could have been thinking was good about the JVM.

Running one packaged program across every platform. Write once, run anywhere was Sun's slogan for Java. (Though oftentimes ended up being debug anywhere.) As for the slow start part, programs can either be often-launched short-running or seldom-launched forever-running. Assume because enterprise software falls to the later part (and runtime performance > startup time + memory use), focus was there.

▲

anthk 3 days ago | parent | prev | next [-]

Java wasn't that bad for crappy 2D adventure games, but for the rest it was atrocious. Even TCL/Tk looked faster with AMSN than trying to use Java based software which was like trying to run Gnome 4 under 1GB of RAM.

▲

kakacik 3 days ago | parent | prev | next [-]

What the heck are you writing about, you clearly have no clue about last 2+ decades of Java or topic in general but felt the urgent need to emotionally vent off because... ?

	▲	anthk 3 days ago \| parent \| next [-]
		We were there. It still was atrociously slow compared to most TCL/Tk stuff I've used. TCL and Tk improved a little on speed and it almost looks native on tons of software, meanwhile with Java if you have to run some biggie software on legacy machines you are doomed by watching the widgets redraw themselves in some cases. And, on its Android cousin... pick any S60 based Symbian phone (or anything else)... and try telling us the same. The lag, the latency, the bullshit of Java we are suffering because, you know, for phone developers, switch from J2ME to another Java stack was pretty much an easy task, but hell for the user. Even Inferno would have been better if it were free and it had a mobile ecosystem developed for it.
	▲	bigbuppo 2 days ago \| parent \| prev [-]
		Yeah, I'm going to re-learn Java just to spite the guy.

▲

morshu9001 3 days ago | parent | prev [-]

And it hogs all your RAM or runs out of heap space, and online help says to pass more -Xmxwhatever flags that flip it between those two.