4 ms·

Lots of people hate Java. It's unsuitable for those people. There are certain things you might have trouble getting Java to perform, such as strict latency re

Lots of people hate Java. It's unsuitable for those people. There are certain things you might have trouble getting Java to perform, such as strict latency requirements. Another language might be more suitable for that. But that generally doesn't describe business software. Desktop software is somewhere you probably don't want to use Java. Although if it's business desktop software, it might be a good fit since it can be cross platform (but ugly - but if it's business, it might not matter). We've built several desktop apps for warehouse computers in Java. Getting the JVM on a machine may or may not be a hurdle. This is one of many reasons why Go is getting popular - you can just build a binary. The positive of Java is that if you want to do something in it, someone else has probably tried. It has several large organizations backing professional quality libraries and frameworks that have had a ton of resources poured into them. It's easy to build on the shoulders of giants while relying on 3rd party libraries that don't have a bus factor of 1 - this is rare in many other languages. If you want stability and well trodden paths, it's hard to go wrong with Java. We've had projects that continued to just work from Java 1.4 to Java 8 - a span of almost 15 years without ever having to touch the code. Java 9 was a bit of a hurdle because of project Jigsaw.

the_af 6y ago
> Lots of people hate Java. It's unsuitable for those people. Understood, but I'm specifically excluding those opinions because they tell me nothing and are unrelated to suitability. Some Smalltalk folk will tell you nothing that is not Smalltalk is suitable for anything; how much would you value their opinion when determining whether a language is suitable for development? "I hate $LANGUAGE, therefore it's unsuitable for $DOMAIN" is the lowest, less useful form of opinion. It belongs in the realm of flamewars, not of informed decisions. Suitability to me is not related to whether I hate or like a language. I hate COBOL. I've worked with it. I'd never in a million years argue it's not suitable for banking systems, because that would run contrary to established history. As for other applications: I agree Java is not suitable for everything. I specifically argued about business software. That said, what about Minecraft, a hugely successful desktop game? :)
alexhutcheson 6y ago
> Getting the JVM on a machine may or may not be a hurdle. jlink[1] makes it pretty easy if you're using a recent JDK. [1] https://docs.oracle.com/javase/9/tools/jlink.htm https://docs.oracle.com/javase/9/tools/jlink.htm
MaxBarraclough 6y ago
> Getting the JVM on a machine may or may not be a hurdle. This was/is one of Java's mistakes. It's always been oddly hostile to JVM bundling, although some projects do so anyway (e.g. Jira). More generally, Java makes the mistake of making itself known to the user. The user is expected to install a JVM, rather than one being bundled with the application, and they're then expected to ensure it updates itself appropriately, complete with an annoying taskbar icon and always-resident auto-updater (on Windows, that is). The user shouldn't even know the word 'Java'. Applications written in Pascal, for instance, are just applications. The user isn't made aware of the technology used. Especially unfortunate considering that, as far as I can tell, JavaFX is really a pretty good GUI toolkit (I've only dabbled). Perhaps things will change as ahead-of-time compilation for Java becomes more mainstream.
- the_af 6y ago
  > Perhaps things will change as ahead-of-time compilation for Java becomes more mainstream I understand JIT compilation is pretty advanced these days. Wouldn't this go against it? Or maybe the approach can be mixed, but if so, you'd still need the runtime environment ("the JVM").
  - haxen 6y ago
    If you ever try to write a bash script that calls a Java program in a tight loop, you'll know the limitations of a fat interpreting runtime with JIT compilation. Another relevant use case is the Stateless Lambda server-side architecture.
    - MaxBarraclough 6y ago
      I believe Java (OpenJDK at least) is slow to start even if you disable the JIT and go with pure interpretation, and even if you disable runtime bytecode verification. It's just generally heavyweight and slow to get off the ground. I imagine JIT compilation should help with this, as you suggest.
      - deleted 6y ago

the_af 6y ago

> Lots of people hate Java. It's unsuitable for those people. Understood, but I'm specifically excluding those opinions because they tell me nothing and are unrelated to suitability. Some Smalltalk folk will tell you nothing that is not Smalltalk is suitable for anything; how much would you value their opinion when determining whether a language is suitable for development? "I hate $LANGUAGE, therefore it's unsuitable for $DOMAIN" is the lowest, less useful form of opinion. It belongs in the realm of flamewars, not of informed decisions. Suitability to me is not related to whether I hate or like a language. I hate COBOL. I've worked with it. I'd never in a million years argue it's not suitable for banking systems, because that would run contrary to established history. As for other applications: I agree Java is not suitable for everything. I specifically argued about business software. That said, what about Minecraft, a hugely successful desktop game? :)

alexhutcheson 6y ago

> Getting the JVM on a machine may or may not be a hurdle. jlink[1] makes it pretty easy if you're using a recent JDK. [1] https://docs.oracle.com/javase/9/tools/jlink.htm https://docs.oracle.com/javase/9/tools/jlink.htm

MaxBarraclough 6y ago

> Getting the JVM on a machine may or may not be a hurdle. This was/is one of Java's mistakes. It's always been oddly hostile to JVM bundling, although some projects do so anyway (e.g. Jira). More generally, Java makes the mistake of making itself known to the user. The user is expected to install a JVM, rather than one being bundled with the application, and they're then expected to ensure it updates itself appropriately, complete with an annoying taskbar icon and always-resident auto-updater (on Windows, that is). The user shouldn't even know the word 'Java'. Applications written in Pascal, for instance, are just applications. The user isn't made aware of the technology used. Especially unfortunate considering that, as far as I can tell, JavaFX is really a pretty good GUI toolkit (I've only dabbled). Perhaps things will change as ahead-of-time compilation for Java becomes more mainstream.

the_af 6y ago
> Perhaps things will change as ahead-of-time compilation for Java becomes more mainstream I understand JIT compilation is pretty advanced these days. Wouldn't this go against it? Or maybe the approach can be mixed, but if so, you'd still need the runtime environment ("the JVM").
- haxen 6y ago
  If you ever try to write a bash script that calls a Java program in a tight loop, you'll know the limitations of a fat interpreting runtime with JIT compilation. Another relevant use case is the Stateless Lambda server-side architecture.
  - MaxBarraclough 6y ago
    I believe Java (OpenJDK at least) is slow to start even if you disable the JIT and go with pure interpretation, and even if you disable runtime bytecode verification. It's just generally heavyweight and slow to get off the ground. I imagine JIT compilation should help with this, as you suggest.
    - deleted 6y ago