If Java Wasn't Cool 10 Years Ago, What About Now? 511
10 years ago today on this site, readers answered the question "Why is Java considered un-cool?" 10 years later, Java might not be hip, but it's certainly stuck around. (For slightly more than 10 years, it's been the basis of the Advanced Placement test for computer science, too, which means that lots of American students are exposed to Java as their first formally taught language.) And for most of that time, it's been (almost entirely) Free, open source software, despite some grumbling from Oracle. How do you see Java in 2014? Are the pessimists right?
I don't care about Java (Score:4, Interesting)
Java is moving into archaic irrelevance faster than ever. That is, the language itself.
The JVM, however, is now more useful and relevant than it ever was. It used to be naught but an implementation detail. Now, rather, it's central to an entire ecosystem of languages that will inevitably send Java the way of C: used only when the greatest speed is necessary.
Scala [scala-lang.org] is basically a next-generation Java. Java with functional programming, or really, vice versa. JRuby [jruby.org] make Ruby actually scalable, given the presence of native threads and interoperability with existing enterprise libraries that commonly only ship in the form of Java or C# libraries. Clojure [clojure.org] enables LISPers of yore and Schemers of new import explore functional programming as it used to be, without having to drop the wealth of Java libraries available. Ceylon [ceylon-lang.org], Groovy [codehaus.org], Jython [jython.org], and dozen of others [wikipedia.org] are paving a way to give the JVM much more to do after Java becomes obsolete.
Java will never die - it'll just become like COBOL, Fortran, and C before it: used in enterprise software, operating systems, and outdated educational assessments.
Language VS The Virtual Machine VS Client (Score:5, Interesting)
There almost needs to be two separate considerations. From a language standpoint Java is a bit middle of the road. It has some well known pain factors, but more or less it's one of the easier OO languages to master. It's used in a lot of high profile web site.
The VM on the other hand does a lot of interesting things under the covers that make the language quite fast. When JRuby hit the scene it was faster than the core ruby project at quite a few things because the VM was doing all sorts of optimizations behind the scenes. Also, because the Java OP code is so stable with relatively few changes per major release you have a bit of a boom in languages you can run inside the Java VM. You get all the benefits of the R&D Sun and Oracle put into JIT, while retaining the ability to do interesting and contemporary things with your language.
Clojure, Groovy, Scala, Python being the primary languages with another 16 that can compile to Java Op code.
Were Java fails mostly is as a client application, running with some sort of Windows GUI. Sure, you can do it, but it realistically people who do Java Swing apps are writing some sort of thick client that could almost always could run inside a contemporary browser without any plugins.
Re:What's the point? (Score:5, Interesting)
The alternative view is that it is fast enough to do the things that need to be fast and cleaner than all those scripting languages.
Here's the thing. Java applications are VERY EFFICIENT. It may be difficult (not impossible but a pain in the ass) to write Java code which performs a specific task in a deterministic period of time. In other words it is not really a real-time sort of thing. OTOH if you want a perform a large number of operations with maximum overall throughput and a fairly stable task completion time then you cannot beat Java. You could do it in C/C++, but you'll spend a lot more time and effort to get the same results. 10 years I coded large high capacity high speed feed handlers in Java and people said I was crazy, but that application continues to exist and outperform anything that tries to rival it while being highly portable, scalable, and superbly reliable.
The thing with scripting languages is they are for small projects. Sure, its MUCH easier to whip out a perl script or something to do a small job. Its faster at run-time as well, but as soon as that task grows to somewhere in the 5-20k lines of code range you simply cannot do it using a scripting language anymore and stay sane. Inconsistencies creep in, problems pile up, the code starts to have to be used and understood by many people, and its just not possible to maintain the level of determinism required of a large code base. At this point you NEED something like Java.
And yes, C# is a perfectly nice language, but it is only really usable on Windows in any consistent fashion. I see no reason to be limited to that platform. Most of my customers are perfectly comfortable with *nix systems and for high reliability high capacity line-of-business applications no version of windows holds a candle to RHEL and isn't even on the same planet with Solaris.
Re:I hope not (Score:3, Interesting)
I wouldn't state that C# is superior to Java from a language perspective, both are essentially derived from Ada and C with influences from C++.
If Ada had been more open and better promoted then it would have been a far better choice.
Re:Nope (Score:5, Interesting)
Those "suits" you refer to included every major hardware vendor on the planet. Java was only sold as a silver bullet for portability, not speed, not efficiency, not scalability, but solely for it's ability to be shifted from one vendor's platform to another's.
When it comes to straight forward business service and batch job processing, it succeeds admirably at that goal, which is rather rare for what you claim was a "silver bullet."
The "problem" is that all kinds of people have visions of Java doing this, that, and the other thing, ranging from the addition of database bindings that don't allow for stored procedures to 3D graphics. Java's "problem" is that it's gradually becoming too much of a "kitchen sink" instead of staying focused on what it was designed for: portable business programming.
Re:What's the point? (Score:4, Interesting)
A big problem with duck-typed scripting languages, such as Python, is that the absence of explicitly stated type requirements in the source code. Using types in function signatures and variable declarations is an extremely useful tool for developers to indicate not only how a system is decomposed, but also what potential future usages they intend to support vs. not support.
I've worked on reasonably large Python, C++, and Java projects. The Python code was by far the hardest to make sense of due to the duck typing and other Python idioms (metaclass, i.e. self-modifying code).
Re:Nope (Score:5, Interesting)
It sorta got there. It's an unmitigated disaster on the browser, for example. It is also awfully touchy about what version of java you're running. The desktops with native java CPUs never happened.
Java definitely isn't Hip and never will be. It is, however, the new COBOL which means it'll be around for a long time.
The one exception is it's use in Android. I wouldn't say the language is hip there but it is tolerated because mobile is hip.
Re:What's the point? (Score:4, Interesting)
Duck typing is a mixed bag. You can make the requirements clearer in comments and the doc string. It also has great advantages in being more concerned with attributes than declared type or lineage. It allows modules to deal with classes that weren't even imagined when they were written.
The problem is that by an large, code can't be automatically checked against doc strings. (If it could be, then you'd just have a classic type system again.)
As far as supporting unplanned extensibility, it seems to me that interfaces (or pure virtual base classes in the case of C++) provide that functionality in more statically typed languages, so I don't see that as an advantage peculiar to duck-typing.
Re:Language VS The Virtual Machine VS Client (Score:4, Interesting)
Sure, you can do it, but it realistically people who do Java Swing apps are writing some sort of thick client that could almost always could run inside a contemporary browser without any plugins.
Swing is where I do all of my Java GUI programming, and I find it to be an excellent fit for that purpose (and so do my customers). I find running Java inside a browser to be, to put it politely, fucking retarded.
Re:What's the point? (Score:5, Interesting)
LOL, I don't know what sort of disasterously bad Java shop you work for... I've got a VERY large Java code base. We use a number of the tools you mention and they are quite powerful and useful. There's nothing in the 'steaming mass' category about it. Perhaps you need some new developers! OTOH The last big project I did with a dynamic language became hideously complicated with constant undocumented dependency issues and bizarre almost untraceable bugs that it was finally just literally delivered by the prime contractor as it was. Luckily the whole issue became largely moot as external forces cut the project back. It IS still in use, 7 years later, but if I were to do that sort of project today I wouldn't even consider a dynamic language. Not with the schema complexity and other aspects of it as it was. Java has a vastly more powerful infrastructure for dealing with complex data for one thing.
It's not Java, it's the JVM (Score:4, Interesting)
Java as a language is a pain to develop with. Java selling points have always revolved around the JVM itself and a bullet proof, over-engineered backbone that is needed for "enterprise" workloads. In big company's who don't have urgent timelines where they are willing to invest time to micro-engineer solutions it's used very heavily. For applications under heavy workloads, the high stress parts are usually built in Java for maximum efficiency but it's been the JVM, JDBC, server infrastructure and the polished library of tools around it that have buoyed it's success.
With the ability to run other languages on the JVM and get ALL those benefits without actually being required to code in Java though...now that's pretty cool. jRuby, Scala, Groovy, Clojure, etc are making the Java world a heck of a lot more interesting. If the early rumblings around the dramatic gains that jRuby is making with Java 8 are true you might just see the world implode at the idea of Java performance with Ruby development timelines. Early public benchmarks on Techempower are already looking about 30% faster than Scala.