9 ms·

Excerpt of email reply from Nathan Myhrvold is mostly correct: >The new Java applications are NOT credible threats to traditional PC software any time soon. [.

• mysterydip 5y ago
  IMHO this was because the JVM at the time had bad performance compared to native apps. I certainly avoided Java apps on my machine as much as possible if there was a native alternative, the extra load on consumer machine resources at the time just wasn't worth it.
  • sydthrowaway 5y ago
    When did JVM switch to the insanely fast HotSpot JIT?
    • acdha 5y ago
      Later, but HotSpot to this day means “less slow” - it’s a lot better than it used to be but you still need considerably more RAM and CPU than native apps.
      • bayindirh 5y ago
        I don't think the need is that larger when compared to today's applications, esp. Electron based applications. Eclipse still uses less resources than VSCode/Atom while juggling more balls at the same time.
        • oriolid 5y ago
          Just because someone managed to come up with a worse alternative doesn't make Java good. The main problems, initial JIT time and fixed heap size still remain.
          • jpgvm 5y ago
            Java has always been tunable to be more aggressive at returning memory to the OS if you are worried about the resident memory size. Newer versions of Java with the more advanced GCs are even better at it. Ultimately Java's runtime performance wasn't really to blame for it's lack of success but rather the awkwardness of JRE distribution, garbage applet sidetrack and lack of high quality GUI toolkits that actually felt native rather than attempting to do "platform independent look and feel".
            • oriolid 5y ago
              How does the tuning work? To me it still seems that JVM (or at least the version bundled with JetBrains IDEs) keeps allocating memory until it's near max heap size and it's up to the user to find the value that's large enough stop the app getting stuck doing full GC but leaves memory for other apps.
              • bayindirh 5y ago
                JVM can be tuned via the command line during startup. Eclipse comes with 512MB as the heap size, and you can enable a small gauge to see how it's doing. I've never seen "This heap is small, please give me more space" error from Eclipse. Also, latest versions of Java (starting with 16 IIRC) doesn't grind to halt during large GC passes. I've developed enough applications in Eclipse during past 20 years, and it has become from being an absolute lead ball to something agile for its size, both in macOS and Linux. I've found an infinite loop bug in CDT, and only with that I was able to make JVM throw the towel, and call it quits. JVM is very smart and resilient in memory management, I've seen some stuff during my life.
                • 5y ago
      • zmmmmm 5y ago
        This is only partly true. HotSpot is pretty amazing performance wise. For certain code patterns it really does produce assembly competitive and even better than what you get from the equivalent vanilla C++ solution. The issues are (a) it only kicks in once something gets profiled quite a few times (so your first encounters with a function - the one you base your impressions of usually, are at its worst), (b) the overhead of JIT weighs down the machine further at exactly the moment (a) is occurring. And then (c) there are quite a lot of code patterns and in particular architectural styles encouraged by the Java ecosystem that are hostile to this whole process. I do wonder why Java has not gone the python direction of caching the JIT output in binary form so at least the 2nd time you launch an app it doesn't need to be redone every time.
        • kaba0 5y ago
          It did actually work for a time that you could point the jvm to precompiled class files, but it got discontinued (it was part of GraalVM which has a different pace to OpenJDK) But imo that is only relevant for startup - otherwise the problem with Java’s JIT compilation is the identity of objects, which makes it much harder to do some optimizations. Hopefully with valhalla we will see quite a boost.
        • native_samples 5y ago
          It's complicated to do binary caching for various low level reasons. Amongst other things, the generated binary code is specific to the precise location in memory and makes lots of assumptions about the state of the runtime like what classes have been been initialized. Still, HotSpot has been slowly (too slowly) getting AOT-like optimizations in the form of AppCDS. It doesn't actually store compiled code but a lot of other internal data structures can be stored to disk in native form and just mmapped at startup. It's usually a 30% win or so, which isn't bad.
    • dtech 5y ago
      HotSpot took 2 decades to get to its current performance, and while its JITted performance is good, for desktop apps cold boot performance is at least as important.
      • jjoonathan 5y ago
        Moore's law didn't hurt either. I think there's a big confounding factor, though: people self-select into platforms depending on what they care about. People who self-selected into Java didn't value perf. They were then inclined to ignore their own performance problems for the same reason they selected Java: they didn't value perf. That's why so many Java GUIs chug so hard, even today, when it really can't be blamed on Java itself. For instance, Ghidra: if you leave a filter active in a GUI box and run an analysis tool, sometimes the runtime of the tool explodes from minutes to days because it refreshes the GUI after each of the zillion model tweaks the analysis tool needs to perform. It's not Java's fault that nobody put in the code to throttle GUI updates, but the same list of priorities that led the creators to choose Java also led them to ignore a massive perf landmine sitting in the middle of the road for all to see and occasionally hit. I recently fired up LibreOffice Sheets to see how it compared to Google Sheets. It took four entire seconds to switch to editing mode in a cell. Every time, not just the first. If I were to root cause the issue, I'm sure it wouldn't be Java's fault -- but I bet that the same priorities that led the project to choose Java led them to ignore a four second stall in their most critical user interaction path. Both of these projects are free, so I'm not upset about getting what I paid for, but I have plenty examples from corporate Java GUIs as well. I don't think this is a Java problem, I think it's a priorities-held-by-Java-programmers problem.
        • lawl 5y ago
          Reminds me of this post: https://nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html?m=1 https://nibblestew.blogspot.com/2020/03/its-not-what-program... In the case of java though in my opinion the problems start at the std library that sometimes forces you to write really inefficient code, or reimplement everything yourself.
        • zmmmmm 5y ago
    • raverbashing 5y ago
      The JVM can be as fast as you want, Swing would make your app drag along
• izacus 5y ago
  I think you're ignoring the giant world of custom, bespoke, enterprise software which is majorly written in Java (and these days on web) - the fact which makes Windows in the Enterprise (Microsofts main money maker) much much less sticky as they would have liked. The little bubble you're talking about is far from Microfts main concern. Luckly, Linux and macOS never really could grow out of their niches to really hurt Microsoft.
  • ancientsofmumu 5y ago
    > Luckly, Linux and macOS never really could grow out of their niches to really hurt Microsoft. "Kind of" (indirectly as others pointed out) - the Dotcom bubble from a systems perspective was based on "Put these words on your VC funding paperwork and we'll throw money at you: Netscape Enterprise Webserver, ATG Dynamo (or similar), Solaris 5/6/7 on Sun E250s and E450s, Oracle Database and Java". I was at a services company doing systems work for Java engineers and built countless versions of this stack; java code was written on Windows workstations and deployed to the Sun servers (this might help explain why Java is deployed the way it is - many devs just zipped up a directory, uploaded it and unzipped it remotely). Then Blackdown JDK[1] entered the room and changed the game - it gained it's first release right after the Dotcom bust and turned that stack on it's ear; now you could use Apache, Tomcat and MySQL (because Java developers could run MySQL on Windows, it "won the war" against Postgres at that time) creating a way to survive in the money-vacuum years following the Dotcom bubble crash when things were very scrappy and people were looking to just survive the storm if they could. My services company had to lay off some 80% of employees because all the clients dried up during the bubble burst. There was a shot right here to have Java production workloads run on Windows Server (NT etc.) since all the java devs were doing it personally, but running on Linux was a much higher performing stack at the time and of course pennies compared to the previous stack even in the kernel's younger years or paying for Windows licenses (and more hardware). Red Hat's IPO in 1999 preceded the Dotcom bubble, putting them in the right place to handle these workloads post-Dotcom as they had a mature Linux offering with a business plan to Enterprise minded shops (appeal to the business folks - save money, have someone to blame if it breaks). Techs loved it because we'd been doing Linux for a decade and here it was about to take over the server world, and Java workloads were helping make that happen. [1] https://en.wikipedia.org/wiki/Blackdown_Java https://en.wikipedia.org/wiki/Blackdown_Java
• sydthrowaway 5y ago
  As an end user, you could definitely tell Java apps looked janky as hell.
• pjc50 5y ago
  Java didn't kill the desktop. The web - Javascript - has put a huge dent in it, especially via the medium of smartphones which were never going to run Windows desktop software. (+). The desktop limps on but it's not quite as dominant as it once was. You can run an entirely successful multibillion dollar software business without a single Windows machine being involved at either the client or the server or developer ends. (+ don't mention Continuum or UWP or Windows Phone)
  • goatlover 5y ago
    You mean the native app stores on smartphones? Because that's what competes with desktop software now that people user their phones for computing. But you can still get the app version of windows desktop software.
    • pjc50 5y ago
      Store apps, or just web apps in general. > you can still get the app version of windows desktop software. Not really - you get app versions of portable software, which may be entirely rewritten from a similarly-named desktop app, but they're not the desktop app. It is as you say a separate version that requires separate maintenance. What you can't do is take a 1996-era Windows app and run it on a smartphone without a complete rewrite. Surprisingly, you could do this with Windows CE for handhelds, like the Compaq Pocket PC which ran ordinary MFC apps with minor tweaks and a recompile. Microsoft had one last go at desktop/phone unification with UWP, and that lost in the market.
  • panny 5y ago
    >Java didn't kill the desktop. The web - Javascript - has put a huge dent in it Nah, I disagree. Mobile killed the desktop, 85% of that is Android, and most Android apps are written in Java. So yeah, Java did eventually "kill" the desktop. But I would point out it was mostly low cost, battery powered, untethered mobile, not the Java language or runtime. What Java solved was a chicken/egg problem where there are no developers because there's no market because there's no developers... The web never killed the desktop. There are no high end games on the web. There are no native features on the web. The web provided forms and ssl; an e-commerce platform. That's it. Everything outside of e-commerce on the web is ad supported which leads back to e-commerce. All roads lead to Rome. That sums up the total contribution of the web on humanity as a whole IMO. Yes, you can list off small exceptions, but most people using the web are participating in e-commerce at some level.
• hiptobecubic 5y ago
  Google has a TON of Java. Some of the largest, most widely used systems in the world are written mostly in Java.
• seanalltogether 5y ago
  > Desktop apps are still C++ and some newer apps are Javascript(Electron) I think the reason java failed on desktop and electron works is because electron is an entire runtime packaged into the app. The java team failed to recognize that people want to install an app without worrying about external dependencies. Later on the Adobe AIR team failed to realize this as well and while AIR had a promising start it flopped as well due to external dependencies.
  • zaphirplane 5y ago
    That’s a jar web start enabled a user to double click to install (well cache) and run a Java application
  • native_samples 5y ago
    Modern Java does work this way with bundled runtimes. But it made the transition quite late, indeed.
• phillipcarter 5y ago
  > Desktop apps are still C++ and some newer apps are Javascript(Electron). Just a nit, but .NET is used for significantly windows desktop apps than C++. I otherwise agree very much with your comment.
  • slt2021 5y ago
    QT (C++) is very popular for desktop apps, and they feel much faster than anything on NET or Java
• brundolf 5y ago
  I’ve always wondered why Java didn’t take off more for desktop apps. Was it a compromised user experience vs native apps? Was Swing bad to work with? Did Web 2.0 come in and steal the show right when it was starting to gain traction?
  • Longhanks 5y ago
    Well, do you consider Electron a compromised user experience? Swing is/was the same, and computers had way less power to make up for it in the early 2000s.
    • brundolf 5y ago
      I don’t personally, but what matters here is that Electron has taken off and Java-for-desktop didn't seem to really. Maybe it was the tech, maybe it was user expectations at the time, but something was different. I’m just curious what that was.
  • pmontra 5y ago
    It was a PITA to manage for end users. They had to install the JVM and update it when the JVM updater told them so. Many people didn't update (slow connections for a file size comparable to today's one, no time, etc.) Then the application had its own non native widgets and was noticeably slower than native ones. Then (more importantly IMHO) developers discovered that HTML interfaces were good enough even 25 years ago and being able to update a web application (they were no app back then) even only once per month was so much better than having to distribute thousands or millions of copies of a desktop application. Game over. BTW that was web 1.0.
  • mr_tristan 5y ago
    I think it's the core, the 2D engine, just never got the love it needed to be a great place to start. Nobody seemed to prioritize making that happen. Like, the antialiasing was noticably fuzzy. I never found an applet that looked like it belonged on the webpage. And when I built a few, it was a lot of work to even get font rendering to not be horrendous. And even then, you'd see what the browser rendered vs what the applet rendered and they were always off. I remember using images instead of font rendering sometimes. So, if you made a swing app, it was easy to put together, but hard to make look "professional". By the time of the Oracle acquisition, I'm pretty sure everyone just realized the browser and mobile "won" and that's why we just had JavaFX get broken off the platform and basically put out to pasture. But it's not like much went into the core platform itself to make building great UIs easy. The underlying 2D rendering just a great place to start. I mean, even today, there's some serious performance issues with IntelliJ on 4k monitors with scaling. https://youtrack.jetbrains.com/issue/JBR-526 https://youtrack.jetbrains.com/issue/JBR-526 When I look at where JetBrains is going, it sure seems like they are building on top of a better 2D engine, in this case, skia: https://github.com/JetBrains/skija https://github.com/JetBrains/skija.
• lern_too_spel 5y ago
  From Gates's email: > I am literally losing sleep over this issue since together with a move to more server based applications it seems like it could make it easy for people to do competitive operating systems. Gates was talking about server applications, and he was right. Within 10 years, people were using Gmail instead of Outlook and Google Docs instead of Word. Both are written in Java on servers not running Windows, exactly as Gates feared.
  • warner25 5y ago
    I mean it's also a lot of client-side JavaScript, but yeah, I thought this line was the most prescient. As I've moved back and forth between Windows and Linux over the past 15 years, I've found it increasingly easy to do everything on Linux, and that's mostly because more and more of what I do is just in the browser. At this point, it's Linux on my personal laptop with a Windows virtual machine for only two or three Windows-only desktop applications that I still occasionally require. As long as Firefox and Chrome are cross-platform, the OS matters less and less.
• a-dub 5y ago
  my understanding was that java was originally envisioned as a runtime for iot. i remember reading a lot about how they were expecting it to land in cell phones, set top boxes and other internet connected devices. they started with applets in the browser. at the time javascript was incredibly immature and used mostly for client side validation of form fields; but was hated by users and developers alike because browser support was inconsistent leading to spaghetti code and bad ux. java applets were also frowned upon. the jvm was quite heavyweight and would struggle to start up on the pcs of the time. the immaturity of the technology made the uis sluggish and fragile. i don't think anyone expected it at first, but using java in web backends became very popular. i suspect this was because performance was reasonable once a server was warmed up and it was sort of turning into an ecosystem that a lot of money was being poured into. the microsoft ecosystem for internet stuff at the time was buggy and terrible, with its "systems built to run internally on corporate networks" lineage showing. on the backend, iis was known to be insecure and hard to code for and on the front end, nobody wanted to aid microsoft lock-in with client side vbscribt and activex. the geeks wanted internet native unix based servers and the well trod options there were java, perl and php (or bespoke options built on them). nobody wanted to do strings in c/c++, further pushing towards high level languages of which java could be a performant one for heavy workloads. ironically, the java iot dream was eventually realized by google with android. even more ironically, it's probably the most complicating and complained about part of the platform.
  • myth_drannon 5y ago
    I don't know the numbers but mid 2000's J2ME was a very popular mobile platform. Don't know why it fizzled out.
    • a-dub 5y ago
      ahh yeah. forgot all about the wapiverse. afaik there was really only one application, and that was the wap browser which was really simple except for ssl support. i think most people didn't even realize their phones had something browserlike back then and even if they did it was tough to use. i never used it. google's sms gateway was more useful for my purposes.
• corpMaverick 5y ago
  It didn't happen because Microsoft was able to kill it. See, for a few years MS had a tight control over the browsers and they refused to upgrade the JVM in IE when they lost their infamous lawsuit against Sun. So Java Applets never flourish. Microsoft control was broken when Google decided create Chrome. Chrome is what allowed javascript to flourish.