> you could in theory make an Enterprise class application in GWBASIC.

In theory you could make Enterprise applications in assembly language. Or write the direct machine instructions in Hex. An IDE might help. But the language you use also plays a large part. Perhaps larger than the IDE. The IDE is a lever that helps leverage the power of the language that you start with. If the language you start with (GWBASIC or machine code) isn't that high level, abstract or powerful, then the IDE can only help you leverage what you have, which isn't much.

You seriously have no clue what Java is used for nor how huge its ecosystem is. For years and to this very day Java is always shifting between the number one and number two spots of most widely used programming languages. The amount of enterprise software written in Java is so large that Java may never go away. There are certain things that Java is very good at, which is why it is used. It's not perfect for everything. If there were one perfect language, everyone would already be using it.

VirtualBox keeps getting updated regularly. A new VirtualBox 5 is in beta even as version 4 upgrades come out regularly.

For C users:

#define while if // makes code faster
#define struct union // makes data use less memory

Yes, it is a function of the IDE. But the language itself has something to do with why this was easy enough to implement for Java that it was done long ago and not just recently. I'm sure that even for the Java language it is not easy to implement. But the language is statically typed. You cannot reference members via strings (like in JavaScript). The meaning of an identifier does not depend on anything that happened at runtime prior to that identifier being used. It is possible to statically analyze the code easily without so much research into what might affect the meaning of the code you're looking at. No operator overloading (that also affects readability, or ability to abuse things).

Way to go Barney Buzzkill!
Next you're gonna try to tell us that gremlins aren't real.

no, MONEY is speech.
sourcecode is munitions.

Pascal would be 1970's.

The read() function (and writeln()) are not even functions. They are built ins in the compiler. Sure, they compile to calls in the pascal runtime library. But you cannot control where read/write go to except through implementation specific tricks, if at all. In Java there is no behind the scenes magic.

Every part of the operation, the I/O, the parsing, the byte to character conversion (using what char encoding?) is explicit. And all these small pieces can be wired together in infinite ways. You get access to all the small nuts and bolts. In Pascal you don't get access to what ever integer parser that was used by read().

I'm not saying there is anything wrong with Pascal. I loved it for a dozen years covering the 1980's and into the 1990's.

In Java you can in just two or three lines of code make your own simple to use read() function using the basic parts.

I think you are not understanding the insight behind the maintenance remark.

Tools that work on the Java source code can be exact in what they do. No ambiguity exists. A method call foo() is understood by the compiler to be exactly one certain method. It doesn't matter how many other foo() declarations there are, or that there may also be variables and classes named 'foo'. The tooling makes maintenance tasks like refactoring very easy.

If I am reading some dynamic languages, I might have to do some searching or research to determine exactly what is being called by this foo() function call. Java tools can tell you exactly, prior to compile time, what method is being called -- and that it is declared, and where it is. The tooling doesn't get confused no matter how badly the code might be structured.

Maintenance becomes a big factor on a huge code base. The cost of maintenance can truly dwarf the cost of initial development.

You do not know what you are talking about.

Java has not stagnated. It is one of the top programming languages. You would know this if you had looked at the article. You might not like Java, and that is fine. But at least get your facts right.

Write once run anywhere is also true for large projects. You could move a major web server project between OSes without even recompiling it. I have personally moved installed my employer's web application on a different OS than it is officially deployed on just for amusement. Because it could be done. I also tried it on a Raspberry Pi (prior to the 2) and it 'ran' (in the sense of how a snail can 'run'). But it actually worked and connected to a database server running on a big box running a different OS.

GC on Android is not a problem. Billions of devices are in daily use. What kind of 'problem' are you talking about? Something hypothetical?

Java at Google may be a fork, but it can't be any worse the the multiple dialects of other languages and compilers like C / C++ or Python 2 / 3 and other examples.

Java is not perfect for every problem. If there were a perfect programming language, everyone would already be using it. But at least get your facts right. Java is going to be around for a very long time. The language has just gotten some major new features in the last couple releases. More major improvements are on the horizon. The sheer size of Java codebases alone is proof enough that it will be around for a long time.

You'd think that the industrial strength JVM might also have something to do with it.

You can have a JVM with a heap of tens of Gigabytes and with a modestly tuned (not extremely tuned) configuration, have Garbage Collection times in the tens of milliseconds. If you need hundreds of Gigabytes in your heap, Azul can sell you a JVM that can do this with GC pauses of about 10 ms.

The JVM dynamically compiles the bytecode down to native code. Not like a C compiler does ahead of time. But it compiles it for the actual processor and features that your hardware has. The JVM compiler aggressively inlines methods instead of making function calls. So there is no drawback to writing lots of small methods. Even tiny methods like getters and setters. You can dynamically reload a class binary at runtime. But what if the new class has a new implementation of a method that some other foobar method had inlined by the compiler? No problem. The JVM knows this and it de-optimizes the class that had the foobar method so that it no longer has inlined a 'stale' version of the code in the class that was just now dynamically reloaded. If dynamic profiling reveals that the foobar method truly is a hotspot for the cpu, then the JVM will again compile it to native code -- based on the now current conditions of what code is in the overall system. It's like having a global -O 5 optimizer that can dynamically change / recompile any or every thing based on any code changes dynamically made to the running system. Want to change from a carburetor to caffeine injection while driving down the road at 70 mph? No problem.

Call me when a dynamic language or other system can do that.

Is it any wonder that so many languages other than Java also run on the JVM? The JVM might even stick around longer than the Java language.

The JVM and Java run on the smallest systems to big iron. The SIM card in your phone is a tiny self contained secure tamper proof computer -- running Java. It verifies certificates using a private key that was forged inside the SIM and never leaves the SIM. Your Blue Ray player runs Java. You can write a Java program that provides the 'menu interface' for your disk. Old flip phones from 2000 run Java.

Serendipity could also mean that it was in the right place, at the right time, and that is why the base of code written in Java become so huge. It solved a problem. And did so better than other solutions at the time. And arguably, still does.

Other solutions may look sexy. And for smaller projects, they probably are.

But long term maintainability is important. Does your project still need to work in ten years? Twenty?

Having a compiler is also probably a major factor to Java success. If I make a typo in my code that breaks something, red flags start appearing on files in the source code tree all over the project for files that no longer will be able to compile. Lots of things that dynamic languages don't discover until runtime (or hopefully unit testing) are immediately discovered by the compiler. In a sense, the compiler is the zeroth step of unit testing before you even run the unit tests. The compiler effectively provides the first most basic set of 'tests' on the codebase.

People who don't understand why Java sticks around also don't comprehend the sheer size of some Java code bases. I would like to see what would happen if a dynamic language were used to write a system that had hundreds of different forms or over a thousand; and maybe thousands of different reports it could produce.

I'm not saying there is anything wrong with other languages. Just that Java does have a place. It is a solution to a real problem.

If there were one perfect programming language, then everyone would already be using it.

Readability goes along with 'toolability'. The fact that tools can 'understand' Java code and therefore can correctly make so many kinds of automated changes to the source code is a major sign of readability. If it is not possible to make tools that can do precise and sophisticated manipulations of the source code, then chances are that humans cannot understand it easily.

As an example of what I mean by 'toolable'. When I rename a variable in Java, every instance of that variable throughout the entire project are changed. This is not a dumb 'search and replace'. It is a precise change made by tools that use most of the Java compiler front end in order to make these changes. Similarly if I rename a method, the change is precisely made throughout the source code. It doesn't matter if there is a variable, or a class or even another method elsewhere with the same name, there can be no possible confusion. Just as the compiler has no confusion about what identifier 'foo' in some line of code refers to, the renaming and refactoring processes are equally precise. That is what is meant by toolable.

Digital Convergence, the company that brought us our beloved ::Cue::Cats, also had a technology that could capture an audio-encoded link from your computer's microphone port.

Man I miss the oughts... I lived in a house back then...