4 ms·

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 l

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!

netsharc 11mo ago
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 11mo ago
  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.
kakacik 11mo ago
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 11mo ago
  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 11mo ago
  Yeah, I'm going to re-learn Java just to spite the guy.
another_twist 11mo ago
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.
- epistasis 11mo ago
  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...
  - eru 11mo ago
    > 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.
anthk 11mo ago
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.
bhaak 11mo ago
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 11mo ago
  Of course, eliminating buffer overflows is orthogonal to using a virtual machine.
  - writebetterc 11mo ago
    No, it's not? Using a VM is one way of preventing buffer overflows, it's not orthogonal.
    - eru 11mo ago
      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.
  - bhaak 11mo ago
    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.
matsemann 11mo ago
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.
forgotpwd16 11mo ago
>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.
morshu9001 11mo ago
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.
lenkite 11mo ago
> 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 ?

netsharc 11mo ago

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 11mo ago
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.

kakacik 11mo ago

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 11mo ago
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 11mo ago
Yeah, I'm going to re-learn Java just to spite the guy.

another_twist 11mo ago

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.

epistasis 11mo ago
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...
- eru 11mo ago
  > 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.

anthk 11mo ago

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.

bhaak 11mo ago

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 11mo ago
Of course, eliminating buffer overflows is orthogonal to using a virtual machine.
- writebetterc 11mo ago
  No, it's not? Using a VM is one way of preventing buffer overflows, it's not orthogonal.
  - eru 11mo ago
    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.
- bhaak 11mo ago
  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.

matsemann 11mo ago

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.

forgotpwd16 11mo ago

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

morshu9001 11mo ago

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.

lenkite 11mo ago

> 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 ?