Slashdot Mirror
The Reason For Java's Staying Power: It's Easy To Read
jfruh writes: Java made its public debut twenty years ago today, and despite a sometimes bumpy history that features its parent company being absorbed by Oracle, it's still widely used. Mark Reinhold, chief architect for the Oracle's Java platform group, offers one explanation for its continuing popularity: it's easy for humans to understand it at a glance. "It is pretty easy to read Java code and figure out what it means. There aren't a lot of obscure gotchas in the language ... Most of the cost of maintaining any body of code over time is in maintenance, not in initial creation."
Not as easy to read as Python though
Properly, consistently indented Java is. It's just that python has to be correctly indented to work, which is great, BTW!
Almost all programming languages are easy to read. This is not the reason of Java's success at all. A complicate algorithm in first place will not make a program easy to read whatever the language you pick to program it. If you find Java easy to read, it is only because you cope with trivial algorithms.
Achille Talon
Hop!
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.
I'll see your senator, and I'll raise you two judges.
A Stream is not a String. A Stream is a pipe which can serve you bytes as soon as some of them available.
If the InputStream.toString() will give you the full content of the stream you will have some very nasty errors. Eg. A beginner wants to read a file using a stream and is doing a toString() suddenly all the file will be loaded into memory into a big String eating all the memory. Another beginner listens to a tcp port using a stream does a toString() and suddenly the thread hangs until the client closes the channel. Plus you need a reader on top of the stream to have proper String encoding. Stream is for binary Reader is for strings.
“I find it extremely annoying to have to cast things into the right object type” This is by design, Java is strongly typed. If you find yourself casting too much then is something wrong with your code style or the library that you are using.
I'd put it differently: When you keep legibility and understandability in mind as a goal when writing in perl, the many syntax constructs available in it which are not in Java (for example) allow you to write much more understandable code in perl than you could in most other languages.
The fact that it also allows you to write stuff non-perl people cannot fathom is a problem, and any coding projects started in perl need a day-two code review and some conversations with the people involved. They need to know they're coding for the next user of the software more than they're coding for themselves. If they have trouble with that, then they're too young to be trusted with your business.