Java

So a lot of threads begin by some noob coming along and asking is c++ or c or java going to die and almost certainly, the answer, all have stood the test of time and this is simply panic nonsense spread by the spin doctors.

http://www.infoworld.com/article/2613404/java/how-to-kill-java-dead--dead--dead.html

But then it got me seriously thinking about java. Like I said, I'm not intent on starting a flame war, but I was seriously struggling to see why I or anyone else would ever need it.

Applets, nope, cross platform GUIs nope, in fact the only time when I was convinced was when I was live chatting with SOS and he mentioned java was good for 'spring.' Banking apps use this for their backend as it simply outperforms other options and being written in java makes easy development.

OK so there is a point, but I wonder since no-one really noticed about apple not shipping java on their ios devices as all the commotion was about flash at the time, this subtle move went somehow overlooked.

But apple killed flash no-one will argue with that premise now, is the same going to happen to java? And if a company decides to cripple java then vendors will be forced to look for other options. And in any case I'm sure what java spring does can be written in native c++ to be faster.

The point is I truly believe java is going to be cooked, it may take a bit of time. Thoughts?

[mike_2000_17]

I share that feeling that Java is on its way down. It is starting to feel more and more like a legacy language. I think that much of it has to do with promises that never materialized.

The promise of "portability through the JVM" is seriously undermined by a couple of factors. First, it was promised that eventually, any computing device would be powerful enough to accommodate it, but small resource-deprived and energy-efficient devices have proliferated, not diminished, with the advent of the "smart-everything" world. Second, the rapid and reckless evolution of the versions of Java has also caused a lot of portability hell. So, the end result is that in the "uber-portable" world of Java, you have to constantly worry about the JVM versions and subsets of your target platforms. By contrast, with native applications (e.g., C++), if libraries that you need are not already installed on a system, you just pull them in, which often can't be done with JVMs.

The promise of "no leaks via garbage collection" is also a failed experiment. Garbage collectors leak memory, that's just an irremediable fact, and diagnosing the root causes of those leaks is nearly impossible. The only practical solution for long-running Java applications (e.g., servers) is to periodically shutdown and restart the JVM. And there has been virtually no progress in this domain. But in the mean time, the competition has gotten so much better. On the side of native code (e.g., C++), coding practices, memory debugging tools, and code hardening tools (e.g., address / memory sanitizers, fuzzing, etc.) have all become very mature and reliable to fix all those issues. On the interpreted side (e.g., php, python, etc.), they all use deterministic methods, basically fancy referencing-counting schemes, to completely rule out leaks. In both cases, determinism is the key, which Java throws away and claims "don't worry, be happy".

Case in point, the only big application that I use which is largely written in Java is Matlab, and I can say that the most annoying thing with Matlab is the fact that it uses Java. For one thing, the GUI is super slow, heavy and unresponsive. And then, if you run heavy programs for a few hours with it, the memory leaks in the JVM will crash your system. For example, such a JVM leak crash once caused me an embarrassing failure during a live demo for some NASA people. The "leak-free and crash-safe" claim is Java's biggest lie.

Finally, Java's promise that "performance concerns will be left in the dust of Moore's law" is another massive letdown. First, as many have pointed out, our demands for what computers need to do has grown much faster than their ability to realize them. Second, computational efficiency is directly related to energy efficiency. For a smart phone, less energy spent means longer battery life and lesser weight. For a server or data center, less energy spent means smaller electricity bills (which is why facebook is migrating most of their Java code to C++, to reduce costs).

And to the question of why anyone would choose Java, I'm pretty puzzled by it too. On one side, on the age old debate of Java versus C++, I haven't seen any new argument in favor of Java, only those old arguments that assume 90s-era C++ coding practices, and even those weren't very strong back then, and are just obsolete and debunked now. And on the other side, that of ease of development and rapid application development, I always recommend interpreted languages like Python. I think that Java could be squeezed out of existence from both sides.

And by the way, when languages like Java and C# show up really high on lines of code counts worldwide, it's mostly because Java and C# are super verbose languages, compared to most, and because of the cohorts of CS students writing garbage code and disseminating it like the plague.

I think as time has gone by I feel more aversed to framework, JVM languages, but I guess python has a virtual machine, why I don't hate it as much as java - I don't know. Perhaps the future for business apps developed in house is for a compiled language with easy to use syntax... Google go looks tempting. Just needs a good GUI toolkit.

Who knows, at the end of the day these are just essentially wrappers on top of c++ which is always the engine.

Would love to hear the opinions of some java users to give a balanced side.

[Slavi]

Nice 1 Mike, but it still stands strong and I definitely agree that universities are part of the problem, for example I am forced to do my projects in java. I've seen increase of jobs for c# developpers lately

http://benchmarksgame.alioth.debian.org/

An interesting comparison of languages while we wait for the java devs to reply.

[mike_2000_17]

I love those benchmarks, they were very well done. I hope someone could redo this work on more up-to-date platform / compilers / etc... I was a bit suprised by the lack of competitiveness of Fortran (compiled with Intel) compared to C (with gcc). It would have been nice if they had also included benchmarks of C compiled with ICC. The compiler really matters a lot. Take for example Pascal which ranks really bad, even though the language itself permits pretty much all the same optimizations as C, but it is orders of magnitude slower because there hasn't been a good new Pascal compiler for decades.

As for Java, one thing that is apparent is that the memory overhead is huge. I mean, you constantly hear people complain about the memory overhead of C++ compared to C, which is about 1KB. It appears that the memory overhead of Java is anywhere between 25MB and 1GB of RAM. Python is also suprisingly high on that. I guess that the rule of the benchmark's implementations were to write the code purely in the language, not relying on bindings to C/C++ library code. That's where Python shines, i.e., the seamless integration with C/C++ library code, which makes most Python code just very thin (and easy / convenient) high-level code on top of a C/C++ infrastructure of library code.

[vegaseat]

Java is very well entrenched in the CS teaching apparatus. It will take a while for this to modernize.

I'm really surprised by the lack of defence from the java developers. None whatsoever... Perhaps this is a real threat looming?

After a lot of thought and research I've basically come to this conclusion.

These are my predictions. I think the creators of google go were onto something real important. They've also realised the massive cons with using JVMs such as java and dotnet frameworks.

They've also realised the goodness of writing simple syntax code like python and ruby - but appreciate as an interpreted language it will never be good enough for production. Mike where 'D' has failed I think google go has stepped in to fill this void.

I personally, feel the desktop gui apps we see in dotnet and java will soon become nothing more than a novelty item.

All major software apps like photoshop and word and whatever - we use on a day to day basis - will still be written natively to that platform, this will never change. But your joe blogs programmers, like the dotnet and java programmers won't be using technology like java or dotnet in the future, to build apps.They'll be using something like google go for the backend. And for the front end...

Essentially, there already is a platform that is cross platform, lightweight and does what it says on the tin. That's html5 + css + javascript. I think that these front ends will be packed into a binary using go-bindata. Don't forget with css and html, it is possible to build fluid scaleable UIs that resize on demand, something java apps or dotnet apps don't do well. In the future it won't be uncommon for users of ERP software to be creating invoices on their phones etc. It's just a hunch but google go hasn't invested any real time or effort into providing a GUI toolkit for go, and this doesn't surprise me given my previous point.

Go is brilliant because it is compiled and I love what they've done with go routines. So that's the future.

The whole philosophy that java and dotnet set out with was nice at the time. But the future won't include them. Similarily, I think the same is even true for python and php. These languages will also become redundant to google go.

What are your thoughts?

https://www.youtube.com/watch?v=Pw07q3e4jEY
https://www.youtube.com/watch?v=FTl0tl9BGdc