Then you should not be on Comcast / Time-Warner.
When people (even in this Slashdot comments) talk about non-GC languages and compare then to GC languages such as Java, they are missing something important.
I have seen comments here comparing the language features, and concepts computer science students learn from either C or Java, etc. But they miss something very important.
When you have GC, you have something that deeply enables the ability to create vast libraries of code that interoperate well together. It is something so deeply implied in the source and binary ABI and APIs that you don't see it. Because of GC, there doesn't need to be any 'contract' in APIs about who owns what data structures. Who is responsible to delete what. What the protocols are for who is responsible for disposing of what, etc.
This cannot be overstated. This enables the creation of libraries that can create, or be passed external data structures, and can create and return data structures, without any concern for who owns what or who is responsible for disposing of what.
This is true whether the language is Java, Python, Ruby, etc, etc, etc. The GC languages are in an entirely different class than C or C++. Yes, I know that those languages have GC grafted on. But which GC mechanism? Do all of your libraries support it? Universally? What about some libraries use this memory management protocol and contract (maybe even non GC), and other libraries use a different memory management protocol and discipline?
Most modern languages now take garbage collection for granted. If you build your new language on the JVM, you get GC for free. And a GC that has been researched, developed and optimized for almost two decades. You get a choice of GC algorithms. Each GC has many tuning parameters. (More than you need.)
You're right. It's not Java that is cool. It's the JVM.
The JVM compiles the JVM bytecode to machine code. On the fly. It continuously dynamically profiles your code to determine what needs to be compiled to native code. It aggressively inlines functions. Even though all methods are virtual functions, if the JVM can prove that there is only one implementation that exists for this method, or only one implementation that could be the actual one that would be invoked at a certain point, then it compiles it as a direct non-virtual call.
But, classes can be dynamically reloaded during runtime. So other code that inlined methods from the class being reloaded now has inlined code that is obsolete! The JVM will ensure that those methods are recompiled (possibly re-inlining, or not) the code from the newly loaded class. And it will ensure that this recompile happens before the stale inlined code can be executed again.
All of this is cross platform. Because your code is compiled by a compiler that knows about the actual hardware you are running on, it can do optimizations that are impossible in an ahead-of-time compiler like C. It can use extended instructions from the instruction set of the actual processor you are using. Furthermore, since it knows the entire set of code making up the application, it can do global optimizations that are also impossible with ahead of time compilers. An ahead of time compiler doesn't know anything about the implementation of the libraries that your program will link against at runtime. If the compiler knew about the actual implementation of the libraries that your application code was calling, there are optimization opportunities that an ahead of time compiler cannot make assumptions about.
With the JVM you can have heaps that are tens of gigabytes (or hundreds with some third party JVM implementations) and have max GC pause times in the tens of milliseconds.
That is what makes 'java' cool. It's the JVM. It's also the JVM that makes Java so darned fast. Not the Java language itself. Nor the Java compiler to JVM bytecode. The JVM has a unique perfect storm of amazing features that make it so attractive.
The article summary is completely wrong -- it mentions "while you're in coverage", to mean that you can leave the device connected to the network.
But from TFA: "Plane passengers will be allowed to use electronic devices weighing less than a kilogram in offline mode from gate to gate without needing to turn them off. The devices will need to remain in flight mode and cannot be used for calls, text or data, however."
So, all this really does is confirm the findings that the FAA had -- small devices are reasonable to use in airplane mode in all phases of flight.
Maybe, has Netcraft confirmed it yet?