> 4. Who really cares about cross-platform code if all I do is on Linux?
Deployment happens mostly on Linux, but development happens mostly on OS X and Windows. Having guaranteed behavior, compiling it only once, being able to deploy as a simple JAR file, the same JAR file that you tested locally, is awesome.
> 5. Why does this program require 4GB of ram?
Java is actually very memory efficient, all things considering. There are Ruby developers choosing JRuby for deployment because of that efficiency. By the time Go's GC will reach the same maturity, it will behave similarly.
> 6. Must I really download and install the JVM all the time, and what is it good for anyway?
The JVM ensures consistent behavior across all platforms and is able to do optimizations based on runtime profiling, with JVM bytecode acting as a very efficient ABI, making the JVM an efficient target for multiple languages, including Scala, Clojure, Groovy, Ruby, Kotlin, Ceylon and others, languages that have been able to bootstrap easily and have a huge ecosystem at disposal because of the JVM.
> 1. Wow, I can write stuff that previously could only be done in C/C++, and I can do it almost as easily as writing Python or Ruby.
Go is not a replacement for C/C++ because it has a GC. In fact it's impossible to use Go for the same use-cases where C/C++ is required. And if you can use Go, then you can use Java as well. And in fact, because Java is more mature and has alternatives like Azul's pauseless GC, it's more amenable for projects with soft real-time constraints.
> 2. Wow, I don't need anything installed for my program to run, it just runs!
That's cool sometimes, but Java is almost as ubiquitous as POSIX and HTML5. On Linux it's basically one "apt-get install" away, just like everything else. So the advantage of not requiring a runtime for me is, you know, meh.
>Java is actually very memory efficient, all things considering
That makes me wonder about your universe of things to consider. Java's terrible memory usage was set in stone the moment they decided not to include structured value types.
Besides being planned for Java 10, there are AOT and JIT compilers for Java that are able to convert simple Java types that follow a specific value pattern into value types.
An example would be how the IBM J9 JIT converts a final Point class, just with getters and setters into a value type.
Also there are language extensions from JVMs like IBM Packed Objects or Azul Object layouts that are exploring how to involve the language into value types.
It sucks that they didn't follow the route of Mesa, Modula-3, Eiffel and Oberon in regards to value types, but they aren't holding still.
If the compiler can prove that an object is final and immutable and is never used in any other context that requires reference semantics, it could potentially use that optimization.
But then you also need data structures that can be parameterized to store such value objects as values. Otherwise you're back to square one.
No, the Java language is not set in stone. Its terrible memory usage is set in stone as long as the language doesn't have value types.
If (and that's a big if) they introduce value types in 2018, it will have been almost 25 years since that fateful decision that has done so much damage.
While it sucks that Java does not support value types like other GC enabled languages, apparently Go owner's are fine with that decision, to the point of fighting to keep using it on their products instead of replacing it with Go.
I don't think concurrent programming was ever particularly easy in Java. If you're talking about `synchronized` methods, well, they are of limited usefulness (to put it mildly) when you need to lock objects in an interleaved fashion: "lock A, lock B, unlock A, lock C, unlock B, lock D, unlock C, etc.", which isn't too uncommon a user case.
> stuff that previously could only be done in C/C++ (...) almost as easily as writing Python or Ruby
Metaprogramming, any? C++ has templates. Python and Ruby have metaclasses. What does Go have?
> 4. Who really cares about cross-platform code if all I do is on Linux?
Most developers write their code on Windows and MacOS and then deploy on Linux. I'd say this "Write once run anywhere" thing was and still is a pretty big deal.
> 5. Why does this program require 4GB of ram?
Oh no! I need to buy a $5 piece of hardware to run this Java code? What kind of nonsense is that?
> 6. Must I really download and install the JVM all the time, and what is it good for anyway?
Once or twice a year, if you really want to. You update your browser much more often.
> Oh no! I need to buy a $5 piece of hardware to run this Java code? What kind of nonsense is that?
4 GB per program absolutely destroys VM consolidation. I love the look on managers' faces when they ask for a 1 GB VM and I ask them, "Is this for a Java program?" :)
Imagine, Java is run on your phone's SIM card. Enough?
On other hand, on truly constrained embedded systems where real time is essential, no GC-based language has any business, no matter how GC is good. Even C++ is sometimes avoided.
Well 2 thing stand out for me from links you mentioned:
> The applications use a combination of Thales proprietary middleware written in C combined with Java code enabled by the Java™ Native Interface (JNI).
> AONIX has additionally delivered professional services to help PERC Ultra users at Thales optimize their applications and improve execution performance including, a customer-specific training course handled the needs of coding in Java™ with hard real time constraints.
Seems like with helping of C and Consulting on 'How to do Java right' they made it work.
> End-to-end distributed thread timing constraints measured from stimulus to response are typically under 100 ms.
Since it is slightly faster than typical (per char) typing speed on keyboard. It appears nice but terribly impressive real time Java use case.
> However, many Java language features are not supported by Java Card (in particular types char, double, float and long; the transient qualifier; enums; arrays of more than one dimension; finalization; object cloning; threads). Further, some common features of Java are not provided at runtime by many actual smart cards (in particular type int, which is the default type of a Java expression; and garbage collection of objects).
[EDIT] But I am not arguing with the overarching argument that Java proper can run efficiently on very constrained devices. It all depends on the implementation.
The point is that memory still matters, not that Java is inherently a problem. You're shifting the goalpost here - earlier your claim was that 4GB is not a big deal since we can just buy more memory, now it's that 4GB is a ridiculous number anyway.
It's not if you meet one of these typical "don't do any premature optimisations (even in the design phase of my data structures), because some important CS person said so"-designs. There's all too many programmers who think they should never have to care about hardware anymore.
If you looked at the issues and verified they're either not applicable in your case or don't affect your application, you already spent a lot of time on it. If you do install, you should verify your app still works. If not, you already spent time on analysis. The actual installation time is next to nothing compared to everything else around the "new jre came out" event.
What I'm saying is - you should care 7+ times a year. Doesn't matter if you only update twice.
1. Wow, this program runs on any platform!
2. Wow, no need to free memory!
3. Wow, threads and locks are so easy to do!
Then many years later
4. Who really cares about cross-platform code if all I do is on Linux?
5. Why does this program require 4GB of ram?
6. Must I really download and install the JVM all the time, and what is it good for anyway?
Go:
1. Wow, I can write stuff that previously could only be done in C/C++, and I can do it almost as easily as writing Python or Ruby.
2. Wow, I don't need anything installed for my program to run, it just runs!