Java may not be dying, but it does take off early on Fridays for golf.
Java is not dying the same way Cobol was not dying 10 years ago. It has a lot of legs left but nobody is 'hoping' to use it, they are told to do so.
Java is and always has been almost completely a corporate tool. Again, like Cobol, so the 'cool kids' are not going to give it much love. It's too slow to execute to compete with C++, its too slow to write to compete with Groovy or Scala. And all the cool kids pick an extreme and vote that way.
Java is not 'dead', but thought leaders aren't using it right now. The people who inherited the decision of thought leaders of 15 years ago are using it, so the writing is on the wall, its just going to take a while to be read.
Well, yes and no. I'm old enough to remember when Java was launched, and I was getting paid to write Java in '96. At the time it was going to be a whole new way to write software - modular software made of components downloaded on the fly whenever you needed them. That is why package names work like that , com.sun.java.blah meant a class called Blah that you would grab from the server java.sun.com when you first instantiated it. Of course it didn't work out like that, it was only in the late 90s that Java morphed into a corporate back-end language. You can pinpoint when this happened when they rushed out the JDBC spec.
I was at that birthing as well....and had the joy of using CORBA, I can see my copy of The CORBA Reference Guide by Alan Pope sitting in the "candidates for landfill" area of my bookshelf.
Don't get me wrong, the guys at Sun were quality geeks, and they never set out to create the Corporate Back End Language of record. But that's how it gained its huge head of steam.
Another reason I failed to mention that Java is in decline is that the geek / utility-driven folks at Sun had essentially said "Java is a mature language now" and were focusing on other languages for the platform. Then the sales and marketing people at Oracle got involved and realized that was not the best way to bilk their existing customers.
Comparing Java to Cobol is ridiculous. I'm in the cool kids category and I like Java. If you don't want to / can't use C#, there's simply no alternative for bigger projects.
Groovy - slower, much worse toolability
Scala - less readable, slower, slow compilation, worse toolability, too complex.
If you don't want to / can't use C#, there's simply no alternative for bigger projects.
People keep repeating this as it was some sort of axiom. My feeling is that people mean that it's hard to write large Java-like projects outside Java. It's not the the problems can't be solved without Java, it's that you "can't" solve them the Java-way without using Java or C#.
You mean that "static typing allow better tools"? That's a fact ;) It allows IDEs to do smarter autocomplete, better refactorings, more static error checks, etc.
"You want to switch out the horse? How are you going to get around? Show me something that has at least four legs, can run as fast, eats less and has more stamina!"
The car or the plane looses this comparison.
Point is that all that "stuff" Java programmers are used to might be missing in other languages & ecosystems. And that might be a real issue. But some of that stuff only exists in Java-land to fix issues with Java, and the fact that it's not needed is actually a feature.
I'm sure someone, somewhere, complained that the first cars didn't have feces collection system =)
This is a widely repeated myth. Static typing does enable a few additional autocomplete capabilities, but most of the other things you probably think of as fancy IDE features are completely possible for dynamic languages.
For example, using Common Lisp with emacs and SLIME, I have:
Function/method name completion, Variable name completion, Jump to definition, Show callers, Rename (heuristic, but usually better than static analysis), Extract method, All sorts of interactive debugging capabilities, Documentation lookup, and Numerous compile-time static analysis checks including type errors!
Scala is a great alternative. The Java interop is great and the tooling is good, certainly good enough. It's statically typed, but much more expressive and productive than Java.
What are these bigger projects which can only be implemented in java? The linux kernel? Photoshop? Facebook? Or some kind of godawful tiered corporate thing that's big and unwieldy precisely because it's implemented in java?
What are these bigger projects which can only be implemented in java?
can is probably an overreach, but I expect the author was referring to the wide range of projects like Hadoop, Solr, etc.
If you want static typing, decent performance (and especially if you want a wide range of people who can work on your software) then you have C++/C# or Java. Or you are feeling adventurous or are ex-Google then maybe Golang.
There are other languages of course, but for most you are going to be struggling to find programmers who know them and library support isn't there, so you are writing lost of stuff yourself. If that's what you like, then fine.
If you don't want static typing, then there's a much broader range of course.
Or some kind of godawful tiered corporate thing that's big and unwieldy precisely because it's implemented in java?
Believe me, godawful corporate things are unwieldy in whatever language they are written in.
Have you ever seen a corporate Rails app? The saying "it compiles so it must work" is supposed to be a joke, but I've seen Rails apps where a large amount of the app would never have compiled if Ruby had a compile step. But then they did claim that Rails was an improvement because they could develop faster with out the compile cycle. Most of the app didn't work, but yes.. I concede that not having to make sure it worked did let them get in on servers faster.
> Believe me, godawful corporate things are unwieldy in whatever language they are written in.
No question this is generally true. But note that it's no worse for government than the private sector. The thing that bugs me is that government seems to take the worst aspects of the private sector (e.g. secrecy). If we've built a fabulous claims processing engine, why not give it away to other government departments?
IntelliJ IDEA or Android. Of course, you could use any language for a big project but unless you have specific requirenments (usually C-like performance), Java / C# is the best choice.
Photoshop - Needs C-like performance for image processing parts. If they started development today, I think they would go with a C# / C++ hybrid.
Facebook - The fact that they had to write their own PHP compiler is telling. PHP is nowdays quite similar to Java without the tooling, performance and massive ecosystem.
Enterprise projects with minimum of three development places, 30 to 100 developers on project, with two to three year duration, lots of off-shoring and attrition among developers.
> there's simply no alternative for bigger projects
I absolutely, completely don't understand where is this coming from. There are so many languages that there has to be a choice.
It of course depends on a given project, but I'd think that it's bigger projects which are more flexible in choosing the technology. I mean, if you have heaps of cash and many developers, than having to write three or ten additional libraries shouldn't matter. And then suddenly OCaml and Haskell are starting to look nice. Ask Jane Street.
In the projects I was involved in we had different set of constraints - we needed to ship something quickly, with small team and limited financial support. In such case how much more performant the Java would be, how much better tooling it has and so on was irrelevant and sheer speed of development in Python, Ruby or Racket was a win.
I get a feeling that this sentiment that "there is no alternative" for Java comes from people who are being forced to use Java at work (even for things it's not suited for) and who want to console themselves. It's something like "ok, I use Java as a templating language, but that's how it has to be". Well, I think it's not.
On the other hand, if you know what you want is Java - go for it. It's always the same old "best tool for the job". Just don't artificially narrow the choice of tools.
Java is the common, business oriented language of today. How do you you think it's not like the original COmmon Business Oriented Language? It's being used by the same sorts of guys to write the same sorts of apps, no?
Same is true of the original COBOL. If you can imagine back as far as the 1960, COBOL and FORTRAN are the cutting edge, every talented and ambitious programmer is trying to get in on this new tech, they are amazed at the productivity and they are writing apps that do hitherto impossible things.
You are no different from them, you were just born a few decades later (same for me). Except, you can look back and learn from their experiences, if you are wise.
If Google is a "thought leader" why didn't they use another language for Android?
The more you digg into the languages, the more you see, that Java rules them all... I've tried MANY, MANY languages (from assembler, Basic, Pascal, C, C++, Smalltalk, C#, Python, Ruby/Rails, Groovy, PHP, Perl, awful JavaScript which shouldn't be called a language at all, because it has bugs built in it and many others) and nobody is forcing me to use Java, but I program my Rasberry Pi-s only in Java...
With latest Rasbperian Wheezy where Oracle JDK is included I can tell you it is super cool and super fast for this small ARM processor... I will not use Python on it... Either Java or C - nothing else do I need...
Python, Ruby, Javascript, JVM-hosted languages like Clojure, Scala, and newer languages still in development like Elixir, I'm sure I'm missing some. Haskell is perpetually 10 years ahead in programming research but sadly it functionally lacks support for day-to-day scripting tasks.
"Thought leaders" are hopefully just using the best language suited for the job. It often comes down to what kind of code you are writing and what it needs to run on.
You're doubting that Javascript is a popular language for people pushing the forefront of software development? I'd cite for you a ton of the work being done on node, ember, knockout, backbone, jquery, even some embeddable hardware thing I read about on here the other day. There's a huge amount of energy in that area, lots of extremely smart people.
Or are you just being snobbish about javascript? It's a pretty solid language, and has interpreters installed on virtually every computer on earth with built-in distribution.
My friend, JS has a virtual monopoly on what it does. If there are other client-side browser languages, i have not heard of them.
>It has built-in interpreters (read "Browsers") on every computer.
JS is pretty slow (It uses an interpreter!). The notion of using it on the backend is debatable. "A lot of people are putting a lot of effort in to it" isn't a valid argument. u said it yourself: "people are told to/forced to use it"
As for the hardware thing, didn't you read the HN discussion about that? no body thinks that's a good idea. It just a way to let web devs do something on the hardware without bothering to learn an actual low level language.
>> JS is pretty slow (It uses an interpreter!) The notion of using it on the backend is debatable.
It is pretty fast. It has a world class VM with an optimising JIT compiler. V8 is considerably faster than many other interpreted language, Ruby, Python etc. It's being used on the backend by many smart companies.
>> As for the hardware thing [...] It just a way to let web devs do something on the hardware without bothering to learn an actual low level language.
I know C. I use it when necessary but I'd rather write JS. Apparently so would plenty of other people. It's not about laziness.
"It's a pretty solid language" - can you remind me what should I use "==" or "===" and why should I care? More here: http://wtfjs.com
"has interpreters installed on virtually every computer on earth with built-in distribution" - which means we are stuck with it, thanks very much for "open" web.
JS is, in general, a relatively poorly designed language which is forced upon us (thankfully, not me). Given the choice people would jump ship in a heartbeat.
Indeed, when compare Java with Python, Ruby, Javascript using the tool that the OP used for showing that monthly commits to Java were stable for the last 7 years it shows how quickly they are catching up:
Haskell has multiple concepts that are so compelling that I do not understand why most of the new languages make no use of them. Very handwavy, here are a couple of them.
- Type inference: strong typing at the convenience of weak typing. (Some languages are moving towards this. C++ stapled on `auto` keywords, Rust is designed using it)
- Type classes: unifying things that "can do X", allowing the programmer to write functions that do similar things but work on many different types. A "sort" function can then be written for all things that "are containers of elements that can be compared". (Again, Rust adopts this.)
- Allowing separation of pure and impure functions. Imagine having a "pure" keyword that guarantees that a function doesn't have side effects. The benefit of this cannot be overstated in a multithreaded environment.
Yes, there are languages that also have these features, the puzzling part is why not all of them do (except those that may have good design reasons not to).
Its hard to implement type inference and type classes unless you carefully design the language to accommodate it from day 1. For example, return-type polymorphism (functions like `read` or `return`) is particularly tricky, specially in the more dynamic languages.
"- Type classes: unifying things that "can do X", allowing the programmer to write functions that do similar things but work on many different types. A "sort" function can then be written for all things that "are containers of elements that can be compared". (Again, Rust adopts this.)"
You don't become a thought leader by being stuck in the past. You have to evolve and move on, and need to realize that there is zero benefit in tool religion.
Java is so big today because at one point for all the marketing money by Sun and C++ incompetence among programmers, it had a field day. I remember an architect who made Java compulsory in a program because as he was tired of C++, he just couldn't get it and neither any of his team members.
Today Java is, what C++ was at its times. Its showing age, and merely adding features and bloating won't fix it. There is tons of Java around, just like there was tons of C++. So people will be using Java for a while. But the creamy projects will be moving on to newer languages and there won't be growth or progress in Java world anymore. And sooner or later people will realize they don't want to associated with tools on their resume, only to be hired as 'migration engineers'.
Before that happens, its better to move on to something better.
Java is big today because its static typing with a focus on performance led to the some of the best free tooling in the industry married to some of the strongest performance metrics. Religion its not.
Java runs about 2x slower than C++ for general CPU-bound stuff - (although it does use much more RAM). That sounds slow, but it's faster than most other languages out there. However, C++ does give you the ability to more easily use processor extensions (SSE, AVX, etc), which you can't use from Java AFAIK - which makes a big difference in performance for certain applications.
> C++ does not support any processor extensions, they are not defined anywhere in ANSI/ISO C++ language standard.
> They are a language extension not guaranteed to be available in all C++ compilers in the same form, thus not portable.
This is true only if you're a language lawyer, but there's very little point to sticking pedantically to a language standard and not take advantage of the ubiqtuitous language extensions available. All the popular compilers out there support all the latest CPU instruction sets with the same syntax, etc. E.g. xmmintrin.h for SSE, avxintrin.h for AVX.
> Java can make use of processor extensions by writing a small Assembly snippet callable via JNI.
While this is true, you destroy any performance gain with the complexity of the JNI calling convention. It only pays off if you're doing a quite long stints of SSE/AVX/NEON code at once. Wrapping a small vector dot product or matrix multiplication in JNI will not yield any performance gain in practice. So while you can call native code via JNI, it's nowhere near as practical as writing it with intrinsics in C code. In addition, you get compiler optimizations to your native code if you use intrinsics from C, if you do it via JNI you lose all interprocedural optimization.
I think generally the libraries in Java help programmers use data structures that make the language seem faster (trees/hashes) .
These structures exist in c++ but aren't as easy to use so aren't used as frequently.
Those processors extensions will make mathy c++ code significantly faster. When I was on an ada project all the mathy code was written in c/c++ for speed. Pretty amazing the difference.
What? C++ comes with robust trees & hashes via the STL, along with a pretty extensive library of algorithms that work on all the STL containers. And, unlike Java, C++ lets you pack value objects contiguously in memory, which can be a massive performance win due to better cache behavior/no pointer chasing.
And, unlike Java, C++ lets you pack value objects contiguously in memory, which can be a massive performance win due to better cache behavior/no pointer chasing.
Certainly, and it is one of the features that I am often missing in Java. Rather than having an array of structs, you need to make n parallel arrays, where n is the number of struct fields. And sometimes such hacks are necessary to make things compact and fast.
But I do understand why they don't provide value types. Say, that I am allocating an array of foobar_t. And foobar_t is defined in another library. If the author of the other library changes the layout of foobar_t, you get ABI breakage. This is what brought the whole PIMPL/d-pointer mess that is often necessary in C++ and to some extend C libraries.
IBM's Java 7 and 8 beta's already have this. It's called Packed Objects and it lets you have have high density data with no pointer chasing along with a much cleaner interface to off-heap languages like C/C++/C# and even languages like Fortran/COBOL etc.
Java is not as fast or faster than C(++). The assertion always makes me cringe. I won't say Java is slow(though the startup time is annoying for some tasks), as it does perform better than many languages. But how does it make sense to you that a platform written in C can produce results faster than C is capable of?
There is no contradiction that a compiler written in a language with expensive semantics (say python), could compile a program written in another language (say C) to produce highly efficient machine code.
The JVM operations, such as JIT compilation and garbage collection, are bound by the performance of C code.
The performance of the code you write depends significantly on the quality of the machine code produced by the JIT compiler. This quality of this code is not theoretically dependent on the implementation language of the JIT.
> There is no contradiction that a compiler written in a language with expensive semantics (say python), could compile a program written in another language (say C) to produce highly efficient machine code.
Maybe not a contradiction in logic, no. But in practice the compiler has to solve a problem that is much harder than the problem the programmer would have to solve to write efficient C code for this one case. It's also one that has different complexity.
So you're in the situation now that a few compilers (VERY few, though this is very very hard to do) will actually beat stupid programmers in optimization, but there is nothing any compiler can do to beat the optimizations a good programmer will implement.
As for startup time, the sad part of that is that is one area where you could really improve C/C++ : startup time. Right now a C program has 4 distinct things that need to run before main() starts, and involve quite a bit of calculation, C++ has a lot more (the various kinds of initializers which can cause arbitrarily complex calculation).
A lot of these initializers result in constant (and small) memory layouts, and could in fact be run at compile time. What you generally do in initialization phase is to calculate registered classes (e.g. for serialization, or protocols) and make indexes of them. Maybe even compile regexes. All of that could be optimized to occur at compile time (as long as memory usage of the code is reasonable).
You think I am saying that a compiler can do optimization better than a human.
What I assert is that the implementation language of a the tool that generates machine code guarantees nothing about either the source language, or the quality of the generated code. This was the assertion of the parent that invalid. He said that because the Java JIT compiler was written in C, that necessarily implies that the generated machine code would be slower that C.
Consider an Assembler, written in C, that generates machine code. By your logic you can't argue that assembly code is always less efficient than C.
Or alternatively Fortran compilers, written in C, which produce machine code that outperforms code generated from C for many tasks.
What language do you think your favorite C compiler is written in?
Now compare that C compiler to the jvm compiler, which has the benefit of using detailed information about the exact system configuration and other runtime behaviours during its compilation phases.
The JVM compiler compiles for the JVM, which is written in C. So, how again can something written in C perform faster than...something written in C?
I'm not claiming that line by line transcription, C will always perform each particular operation faster than Java. But the fact that you could write the entire JVM in C means that you could recreate the exact platform and replicate the results. Is that sane? No, not really.
Comparing languages is typically silly, as it mostly boils down to implementation. If you -really- intend to compare speeds of languages, it would necessitate writing the best possible code in both languages, which may or may not even resemble each other. Under those circumstances, Java is not capable of beating C. Ever.
I don't understand why this is an argument anymore, it doesn't really even make much sense...unless my definition of 'language speed' is unusual.
The JVM compiler compiles for the JVM, which is written in C. So, how again can something written in C perform faster than...something written in C?
Well, first of all, the JVM generates machine code, not C.
Apart from that, you can easily be shown to be wrong. If you are compiling a binary with C, you are compiling for the lowest common denominator. Say, if you are compiling for x86_64, you are probably compiling for all x86_64 CPUs. You can optimize for newer instances of x86_64 (say Core i3), but you cannot use any instructions that are not available on e.g. Core 2, if that is the lowest common denominator that you support.
The Java VM could, on the other hand, decide to use instructions during the compilation of hot spots which are available on a Core i3 and not on a Core 2, when it detects that the CPU is a Core i3.
> The JVM compiler compiles for the JVM, which is written in C
This is absurd.
First of all, there isn't one JVM. There are dozens to chose from, many of them certified. Each implemented in whatever language their designers have chosen.
Some JVMs are meta-circular, meaning they are also written in Java. For example, Squawk, Maxime, Jikes RVM.
Second, even if you mean Oracle's JVM, the embedded version is not the same as the desktop/server one, one uses C the other C++.
Not to mention that after Java 8's release, Hotspot might be replaced by Graal, the new JIT compiler written in Java as well.
Currently being developed and already in use by AMD for their Java/GPGPU work.
Both the JVM and a C compiler produce native machine code that is executed by the processor directly. Neither is an interpreter in the classic sense[1]. It doesn't matter what language they're written in -- you could write C compiler or a JVM in PHP (assuming it can make the syscalls to load object code at runtime). No matter how awful the performance of the PHP runtime is, it would not prevent the C or Java program executed from being fast (in the long run).
Because the eventual target is native code, the only limit on performance[2] is what program transformations the compiler is willing to perform. This is limited by how much information the compiler has, and what sort of transformations are valid in the language.
For the first, it's about a wash. Java has a mix of 'safety' features that may obligate inserting checks at runtime that C would assume away, but it also forbids a lot of things that a C compiler would have to accept that limit the ability to optimize programs. In particular, a C compiler has to make a lot of pessimistic assumptions about what all those pointers are doing and what happens to memory across an external function call.
JVMs have a solid advantage in the second -- it performs the equivalent of profile guided optimization at runtime against real usage patterns, something that AFAIK no C compiler even attempts... and the runtime tooling needed to turn C into something you could JIT-optimize would result in something I don't think most C programmers would recognize.
A third issue is GC, which is on by default in Java-land and off by default in C: if your program is under very little memory stress and has very complex memory access patterns, the overhead of malloc()/free() is going to be huge compared to the cost of running the occasional GC. But, if your program is under strong memory stress and the logic to determine when to malloc() and when to free() is trivial, GC overhead will be a serious issue.
None of this means a given Java environment is faster than a given C environment but there's not really anything you could assume from first principles that makes one faster than the other. Neither reaches the ultimate "speed of light" of computation that is self-modifying hand-tuned machine code favored by all Real Programmers[3].
But the real bottom line for performance is which language has faster library implementations, and which has idioms that programmers actually use that produce faster or slower code. Those considerations are probably going to be way more important than the hypothetical top speed of a perfect program made by cycle-counting weenies. It's also the sort of thing you'd have to run actual experiments at large scale to answer.
[1] the JVM might interpret Java bytecode that isn't frequently run based on some optimization heuristic, but it doesn't have to. A 100% JIT emitting JVM could exist, and might even be a JVM flag for all I know.
[2] if you ignore the time JVM spends optimizing at load/JIT time, which you can in most cases aside from startup time.
> So, how again can something written in C perform faster than...something written in C?
Easy. JVM has runtime information it can use that C compiler simply doesn't have. There are some synthetic benchmarks that show how "java is faster than C".
There's far more than branch prediction optimization, which AFAIK, is bread and butter of profile-guided optimization.
Even that assumes that your program does not significantly shift its behavior mid-execution--in fact, you're optimizing for the average, not the current case.
One of the coolest JIT things is ability to inline virtual calls. Think about that, I could have my code calling a 3rd party library calling another 3rd party library thru 10 levels of stack and if all that call ever returns is "false", then JIT will optimize right through all that.
I don't believe PGO does virtual call inlining. That's a C++ nonstarter. In C, the equivalent would be inlining for function pointer calls.
doesnt matter,the jvm takes a lot of resources which is problematic is some situations.raw speed is nothing without the memory footprint or AAA games would be written in java.they are not for a good reason:lack of direct memoy management.
I am not saying one should use it or not, or how it is strictly better than something else, just saying I can easily see _in theory_ how a jit compiler written in C can be faster than plain C.
> But how does it make sense to you that a platform written in C can produce results faster than C is capable of?
It's actually quite easy.
Now, of course for every Java program there exists a C++ program that performs at least as well – proof: the JVM – but that doesn't mean that that program could be written by humans at acceptable cost. The JVM does a lot of optimistic inlining that's simply not possible in C/C++ (in those languages you'll need to write the same code lots of times).
But in any case, it's perfectly possible that a platform written in C could produce results faster, because it's not an interpreter but a compiler that translates the application directly to machine code, and which could benefit from optimizations not available ahead-of-time.
If by "lack of", you mean "4 choices":
DirectByteBuffers (Azul/IBM/OpenJDK/Oracle etc)
Packed Objects (IBM)
Real-time Java (Azul/IBM)
Unsafe (Azul/Oracle/IBM/OpenJDK etc)
I'm surprised nobody has mentioned Android yet. When you add in the Android factor, Java is probably still one of the most widely used programming languages today.
It's funny the article straight away brings up the verbosity argument as well. You want to talk about verbosity - take a look at Objective-C and Cocoa (again, hugely popular today!)!
Popular in terms of use, yes, but liked? I don't know, I doubt it. Android and iOS essentially force you to use Java or Objective-C respectively. I don't hate Java, but I don't like it either. It lacks quality of life features that other, similar languages have had for years. I can't stand writing code in it if I don't have to (and don't get me started on Objective-C...)
From what I hear from others and read on a weekly basis, few people enjoy writing Java code. It may not be dying in terms of numbers, but given an option to use something else those numbers would likely drop very quickly.
I find that he is in a good position to do so because C++ evolved based on feedback from people using it and he was responsible for the first version(s).
Nowadays the consensus is that C++ introduced more problems into the industry than it solved. Moreover it keeps introducing more and more problems with each new revision.
In this light his statement is merely an attack upon his critics e.g. "Haters gonna hate..." while ignoring the possibility that criticism of "his" programming language is well founded.
Sure people bitch about every language sometimes. Hell I bitch about languages I use now and then, but I keep using them.
While systems programmers are fleeing from C++ back to C(!!!) and to newer languages like Go (for which the core design principle could be described as "Not C++").
To me his statement sound like a chronic alcoholic saying "There are only bad kids and kids you don't have."
> While systems programmers are fleeing from C++ back to C ...
Really?
GCC is now developed in C++.
Clang is developed in C++.
Mac OS X I/O Kit makes use of a C++'s subset.
Windows drivers can be done in C++ since Windows Driver Kit 8, while most new native APIs since Vista are COM based. With Microsoft only supporting enough C99 to comply with C++11/14, while helping porting FOSS C projects to Windows.
OS/400, BeOS and Symbian make use of C++ on the kernel.
"While systems programmers are fleeing from C++ back to C(!!!)"
Example? I know of new developments in systems programming written in C++ (LLVM, clang, WebKit, FireFox (or did that start in C?)), I know of some that moved from C to C++ (gcc, maybe FireFox), I know of new developments in C (Linux, git), but I not aware of any system going from C++ to C. They may exist, but I would need more than a few examples to be convinced of the existence of a general trend.
Looking at http://images.content.ubmtechelectronics.com/Web/UBMTechElec..., I can see where that argument comes from. Looking solely at the C++ data across the years, slides 20 and 21 can be seen as indicators that C++ peaked in 2011. If that's the case, however, C peaked in 2012.
Also, for C, there seem to be fewer 'next' projects than 'current' projects, while for C++ those numbers are about equal.
Extrapolating like mad on almost no data, one could argue that C is on the way out in favour of Python, Java, and C#.
.Net is on the decline, though, so there either must be tremendous growth in the use of Mono in embedded software, or that data must be taken with a grain of salt. My money is on the latter, but surprise me.
I'm a systems guy and I love C for its simplicity. There certain problem domains which C++ is better suited for, but everything being equal, I'll chose C every time for its simplicity (don't give me the whole "shoot your foot off" argument. I know, but this is not much of an issue for experienced and competent C devs)
So by not changing X they are automatically and implicitly disagreeing with any complaints referring to X? You're reaching.
EDIT: In case my point wasn't apparent, the language is under active development by an open, international standardisation committee, of which Stroustrup is an active and prominent member. They are well aware of the complaints, but the problem is that every change involves a tradeoff, and sometimes that tradeoff is just not worth it.
I find the descriptive nature of method signatures to be quite delightful. Unlike other languages like C++, I don't always have to go looking for the function definition to see the types of the parameters it takes, and what exactly was the order again? Combined with Xcode's autocomplete, it saves a lot of time.
I shed a small tear every time I have to call a C API with and endless parade of (NULL, NULL, 0, NULL).
In C99 it's possible to use compound literals to implement something like named parameters. You create a struct with all of your parameters, and only include the ones you want to set in the compound literal. Anything not explicitly specified in the compound literal gets set to 0, so the caveat is that 0 can't be a valid value for your parameters.
I have been using Scala for both server-side and Android projects. Android doesn't have such a capable VM and Scala is a little wasteful in terms of short-term objects, but using Scala while being mindful about performance implications of the code you write is still better than Java. In fact on Android you can use pretty much any language under the sun, including languages that don't run on top of the JVM. The development experience may not be as great as when using Java, sometimes you suffer from interoperability issues and so on, but for personal projects it's OK.
iOS doesn't force you to use Objective-C either. For example many top games or apps have been built in C#, by means of Unity or MonoTouch. The problem with iOS is Apple's developer agreement, as they first didn't allow apps written in anything else than Obj-C, after which they changed that to not allowing apps doing JIT compilation, but now they only enforce this rule when banning apps that download and execute code on the fly. For this reason, when embedding a WebView inside an app, Javascript will not have the same performance as Safari's Javascript engine, which is kind of stupid. So many devs prefer native compilation to avoid any problems. There's nothing wrong with iOS as a platform, what's wrong is with Apple's restrictive policies.
We've got a parable in our country about a lazy bastard, that couldn't do anything out of laziness to the point of dying from hunger. One day a woman offers to help him, to give him shelter and food. To which the lazy man asks in response ... will you soak my bread? (sounds much better in Romanian)
Fuck dude. You're a developer. If you want productivity, make shit happen.
I think that they are saying that Scala is the proverbial bread being offered to you, and your concerns about productivity are akin to insisting that your bread be soaked so that it's easy to eat.
If that is what they're saying, I disagree with them.
Unfortunately, most of these polls don't really talk about the context. I don't think I've ever been as unhappy as a developer (in terms of the tools) as when I was required to use Spring, Hibernate, Eclipse, and so forth to do web development. There was absolutely no reason we couldn't be using Rails or Django for our needs - this was a top down management situation, and I'm sure my political frustrations contributed to my unhappiness.
However, a recent coursera course on Data Structures and Algorithms used Java, and I really didn't mind it at all. I'd even say I found it reasonably pleasant to use Java.
when it comes to large, complex, distributed, long-living projects, java is the best choice. sure, I can build a quick prototype using python, php, node, ruby, its hard to rely on them when the project becomes large, distributed, complex etc.
IMHO its the only language that allows to create great server side programes, awesome desktop GUI applications, mobile applications or embedded applications. All in one language.
I'll agree there of course; as an ecosystem it's hard to match due to the availability of libraries and ease of platform swapping. My original comment was targeted purely at the language syntax and semantics. Like I said, there are many reasons to use Java, but I'd rather use something else given the choice
> You can use many languages which compile down to Java Byte code.
And then you end up with subpar performance and application size :(
I had high hopes for Mirah for Anrdoid development few years ago, but it unfortunately fade away. It was basically Ruby like language that compiled down to pure java bytecode without a need for any runtime. That would fit Android perfectly.
If Java wasn't the most used language out there, Android almost certainly made it so.
I quite like Java too, besides C#, I don't think there's any good alternative for bigger projects.
My dream would be Ceylon replacing Java some day. After looking into many newer languages aiming at a similar market as Java (Scala, Clojure, Dart, Kotlin), I believe that Ceylon is the best-designed statically typed programming language out there.
They've made incredibly good and pragmatic trade-offs between features, readability, verbosity, expressivness, speed, toolablity, familiarity, etc.
Android doesn't really count as java, as it doesn't use the JVM.
But even if you do choose to count it, it's only a very small part of the java ecosystem. Applets are dead, and java desktop applications unpopular, but without you necessarily seeing it, enormous amounts of server side software are made with java. If it hadn't been Java, it would have been some other language, but the fact is that there is such an enormous ecosystem of high quality libraries, tools, infrastructure and experienced programmers, architects and devops built around Java and the JVM that I don't see anything toppling it from the #1 position any time soon.
C#, being a better designed and more rapidly evolved language, might have displaced it if Windows rather than Linux had become more popular as a server OS, but it didn't, and now it won't, so that is moot.
> I'm surprised nobody has mentioned Android yet. When you add in the Android factor, Java is probably still one of the most widely used programming languages today.
Except that Oracle was right into suing Google, after all.
Google hasn't improved the language level beyond Java 6 grammar.
So nowadays one is forced to write in Java 6 when targeting Android, which is really a pain, specially when writing libraries.
This will only get worse when Java 8 gets released. No lambdas or other Java 8 goodies for Android developers.
Plus, they haven't bothered to improved GC and JIT on Dalvik past the Android 2.3 release.
They seem to care only about pushing libraries for Google APIs nowadays.
> Google hasn't improved the language level beyond Java 6 grammar.
That's because Oracle has been suing them over it. Dalvik hasn't changed in years thanks to that lawsuit. Google was steadily improving Dalvik right up until that lawsuit happened, then it came to a screeching halt. That's not a coincidence.
And really, what Java 7 language level features were there that makes it problematic that Android still runs Java 6? The good stuff was dropped from 7 and pushed to 8. 7 is boring.
> That's because Oracle has been suing them over it. ...
Sun just did not sue them, because they lacked the money. James Gosling confirmed this.
> And really, what Java 7 language level features were there that makes it problematic that Android still runs Java 6? The good stuff was dropped from 7 and pushed to 8. 7 is boring
- Strings in switch
- Try with resources
- Multiple exceptions in catch
- Simplified IO
- Diamond type inference
- invoke dynamic optimizations
Any Java library targeted for Java 7, even without the new language features, is also not usable in Android projects, because Dex cannot understand the new Java 7 bytecodes.
<quote>
In his testimony last week, Schwartz explained his "grit our teeth" strategy after Android had its public debut as an incompatible variant of Sun's Java. "We saw a handset bypass our brand and licensing restrictions...we decided to grit our teeth and support it so anyone supporting it would see us as part of the value chain," he said. Apparently, continuing to seek a way to work with Google -- to turn lemons into lemonade, as Gosling wrote -- was preferable to engaging in a costly lawsuit.
</quote>
So Sun chose not to sue Google, because it would be costly (and because they knew they'd lose). They could have afforded it, but they chose not to.
History shows that was probably the right decision - As previously mentioned Google kept Android Java close to Sun Java, while now they have stopped updating it and may be considering other platforms.
BTW, you realise Gosling isn't exactly an impartial player here, right? He's always been against open sourcing Java (and open source generally: the EMACS wars probably had something to do with that), and sees what Google did as justification for his opposition. Others (including myself) see Google's actions as vindication of the Java Open Source strategy: it expanded the Java ecosystem into new fields, and made Java more important, not less.
Simplified IO is a library feature, not a language feature, and Android has its own IO stuff anyway.
Diamond type inference is cute, but hardly important. You could do the same thing with a save macro in your IDE.
Try with resources is about the only thing in that list that would be actually useful in Android.
> Any Java library targeted for Java 7, even without the new language features, is also not usable in Android projects, because Dex cannot understand the new Java 7 bytecodes.
So target Java 6 if you're making a library. Which is what people do anyway, because not everyone has immediately jumped to 7.
And none of them will run on J2ME which Sun/Oracle never upgraded past 1.3 for Pete's sake. If not upgrading Java was worthy of a lawsuit, we should be class action'ing the hell out of Oracle for the crime against humanity that was J2ME.
BlackBerry was also 1.3 right up until the end.
Android right now is only using a version of Java that's ~1 year out of date. That's still a shitload better still than Sun ever managed to do on mobile.
> Google is a corporation like any other.
Cows go moo.
Saying irrelevant facts is fun! You're on to something here I think.
Actually, you can use the following on Android from Java 7 and 8:
- Case/Switch Strings
- Auto closing files handlers (via adding a few classes/interfaces). Also known as "try with resources"
- Integer literals
- Multiple exceptions in a catch block
- Lambdas via RetroLambda[2], which compiles Java 8 bytecode into 7 or 6
Used them all in several projects with 20-100k+ downloads with no user reported errors related to their usage. New Android projects though, I rather just use Scala, but older things I don't want to convert, I use the above to make Java easier to manage.
I actually wrote an essay about this few months ago, Android was indeed one of my major points: https://medium.com/i-m-h-o/da3b2c180e9c (Why Java Is Still Relevant)
There's a lot wrong with Java, but even while having moved on and learned / used professionally many other languages I keep coming back to it and its ecosystem. There is still not another language / platform that provides the same level of a variety of things that are important to me:
* platform independence
* performance
* low level features
* simplicity and clarity (for reading, writing not so much)
* infrastructure/tools (IDE, visualvm, etc)
Admittedly, I lean more and more into JVM languages like Groovy and Scala these days. But even then I still drop into Java to write parts of the code that I want to be as fast as possible.
I hope I get no down votes from the following comment. This is not true, C# can be thought as superior to Java, only if you intend to be completely immersed in the Microsoft stack and this assertion is still debatable. I personally like Java more than C# just because Java is truly platform independent and fully open source. When you have two similar software products the one which is open source will always be a better choice. I think Java has a bright future.
I have done less than 10 hours of .NET programming in my life so I have no idea here... but my impression is that MONO substantially less accepted than a standard Java port... not trying to bash, just explaining my view. I'm moving a significant production Java app from a Linux box to Windows in the next 3 months. My expected work is about 2-days, and frankly my management wouldn't expect more, and I'd have a hard time justifying more (it's probably padded already... don't tell). The portability of Java apps is wonderful. I'd guess MONO could do the same thing, Windows to Linux, but just explaining the run-time to my management or Change Management would require testing, which is cost, which is probably waste, but is also necessary... a Oracle JVM on Linux or Windows, doesn't require the same due diligence.
I have done less than 10 hours of .NET programming in my life so I have no idea here... but
Then don't comment. Your comment is comparing something you know to something you have no idea about. How can anyone legitimately make such a comparison?
I can tell you I've done 10 minutes of C# programming in my life, while addressing a StackOverflow comment, and in that 10 minutes I found something that worked on Microsoft's .NET runtime but not on Mono. You don't need experience to find evidence.
True, but you can't spruik that and then tell us in the next breath about the wonderful developer tools and Intellisense, etc., because most of that doesn't exist outside Windows. With Java it's not just the JVM that is cross platform - the whole developer ecosystem and culture is from the ground up. Every IDE, every compiler, every tool, all runs on every platform. It has it's holes, but largely Java actually achieves this, which when you need it, is a huge win.
Heh, I didn't even realise it was Australian slang. The meaning from your link is correct - to sell, extoll the virtues of or try to convince other people to buy something.
Infrastructure of Mono is not in any way comparable to proper c#. Also how come MonoDevelop's latest version doesn't work on Linux? On Windows it became Xamarian and it is ok ish, but I would not use it for a major project, refactoring tools are more or less non existant. On Linux they are stuck with the old version of MonoDevelop
Yes. However, C# uses the convention that capitalized "fields" are actually properties, and lowercase ones are true fields.
For example,
Foo.X might be an x position, returned from a getter method, and set with a setter method. Internally, the class make use the Foo.x field to store it, in which case the getter and setter are trivial. In fact, C# will write them for you
The property could look like:
int X{
get;
set;
}
(Though my syntax might not be completely correct, I haven't used C# in a while). C# will automatically create a private field to store the value for x, and the getter and setter will work as expected.
Classes should, as a general rule, only expose properties and methods to the outside world. All fields should be private. Yes, accessing a property calls a method, but so does a Java getX().
Java uses the same rule, except getters and setters are implemented using setX(int) and getX(). C# properties are the equivalent. The client of a class should not care how the class stores values, but that the getters and setters work.
I've written a lot of C# and Java (and others of course). It's really not an issue. If you're doing something expensive in a property getter or setter you're doing it wrong. If the function call doesn't get inlined and becomes a bottleneck in some tight loop you can just change it. Anecdotally, I have yet to see this occur in practice.
Also, as the guy below me pointed out, by convention you know that Foo is a property.
Exactly. It's (at least from what I've seen/read) common convention to make sure that getters/setters should be quick and have minimal side effects.
Your application shouldn't hang from a database call when you pull a property from an object. And obviously, methods doing such things should be documented appropriately.
Huh? Of course it is a feature. My point is that if something as innocent looking as property access can be an arbitrary method call, it may make understanding a piece of code more difficult. From the point of view of debugging existing code, which I've done a lot lately, hiding details that may matter in corner cases is not something that I want the language to encourage.
Umm... Isn't that just an IDE feature and not a language thing? IntelliJ IDEA 12 has pretty amazing IntelliSense features. 90% of the time it knows exactly what i want to type from the first few Letters (even though this Enterprise Level Software has tons of similarly named classes/objects etc) Apparently it observes patterns to know which classes are used with which classes most often.
I primarily use java in my day job, and although there's a lot not to like about it, some standard complaints are somewhat overblown. For example, nothing really forces you to use long variable/method names, but even if you do, a modern IDE -- I use IntelliJ -- with auto-completion makes these fairly painless. It's not like you have to type every letter of "SomeClass.veryLongMethodName()" -- rather, you type "SomeClass.v" and then hit tab.
Similarly, I never type "for (int i = 0; i < blah; i++)." I type "cmd-J, fori, return." Etc....
So, I'm not particularly persuaded to the "you have to type a lot" complaints.
Similarly, Spring has simplified a lot of stuff that J2EE had previously made overly complicated.
That's not to say that Java doesn't have problems or isn't suboptimal for a certain set of problems. (In fact, it's unclear to me where java might be optimal.)
Most standard complaints are over 10 years old, people should just get over it. The IDEs are a little fat and I/O hungry. If you don't have a beefy machine, just get a SSD, and that problem is gone.
Spring is great, but JavaEE6 simplified things further standardising things like CDI, JPA, JSF, Jersey, etc... (also, JavaEE7 was just released).
It's actually a pleasure to write web apps in Java nowadays. Great IDEs, debugging tools, lots of mature options, unlike some cool kids..
Jersey is a true joy. It's really a nice way to write restful apps.
I never liked Spring. And large enterprise apps' source code makes my eyes hurt. However, none of this is a reflection on Java or the JVM itself. I think we'll have another 40 years of people predicting the end of Java until we realize it's interwoven into every aspect of computing and can't be tossed out any more easily than C or C++ can be. The JVM will probably be healthy for a very long time, and as long as the JVM is around, Java will probably be chosen for new projects (and maintenance on Java apps will probably be a nice retirement income for many of us now).
Jersey is a true joy. It's really a nice way to write restful apps.
It's actually mostly JAX-RS which is a joy, and allows you to swap out Jersey for e.g. RestEasy with very little work.
I never liked Spring. And large enterprise apps' source code makes my eyes hurt. However, none of this is a reflection on Java or the JVM itself.
I agree. I hate Spring. Spring, J2EE and pre-JIT Java have probably done most damage to Java's public image. JAX-RS is very nice and lightweight. Play is brilliant, if you can deal with mixing in Scala here and there.
I think you hit the nail on the head... it's always been the "enterprise" apps that bugged me about Java. Java may be entirely capable.. but, for example getting an application setup in Eclipse + Java has always just seemed painful to me.. I mean an existing app. Ant + Tomcat + X + actually getting a working debugging session.
VS has usually been get latest from source control.. open sln and click debug... wait for ever it seems like for enterprise code.
Probably why I've been so taken/enamored with nodejs lately. For the most part it's not enterprise platforms... it's well tested, small modules put together like lego blocks stacked together. Event streams and pipes are awesome.
It is sometimes surprising how many deeply nested versions of npm modules are in other modules.. it's still better than having to dig through a dozen projects to update a common dependency they all share.
Java and C# will be around for a very long time, cobol is still pretty widely used... that doesn't mean I want to green field something in it.
Also, Gulp (or even Grunt) with npm is far less friction than anything I've seen in the Java space.. and nuget (.net) doesn't really compare well.
> I'm not particularly persuaded to the "you have to type a lot" complaints.
I haven't used Java in anger in a long time, but my beef was never that you had to type a lot, but that it was verbose. Verbosity impacts on typing, sure, and as you've said, IntelliJ makes typing it out painless.
The flip side of verbosity, though, is reading the code. There's no "hit tab" or "Cmd-J, fori, return" to increase comprehension speed. And reading tends to be far more common than writing.
Well, there are programming languages and then there are conventions. I think a programming language is more like an alphabet, and programming conventions are the real languages.
I can scroll through code at high speed and understand it at a mere glance once I "get" both the language and the convention that was used (if only the doc and comments didn't get in the way all the freaking time...) Things that feel out of place immediately stand out for more careful inspection.
Autocomplete, code snippets, common refactor options etc, pretty much everything an IDE does automagically for programmers, those are a boon for enforcing conventions as well, once you're proficient with them and how they're configured for a project you can pretty much "see" the history of the code without even looking at the commit history.
I once had a boss who used to say this: "I love looking at programmers reading code. It's like that guy from The Matrix, he's looking at undecypherable numbers and says 'my, my, look at that brunette in the sexy red dress'!"
> Well, there are programming languages and then there are conventions. I think a programming language is more like an alphabet, and programming conventions are the real languages.
I like this. As a thought experiment, consider the idea of transforming a convention into another "letter" in the alphabet. A simple example would be the natural numbers. If our alphabet is "a", then we can represent 1 as "a", 2 as "aa", 3 as "aaa", and so on (unary). If we expand our alphabet with a "b", then we basically have binary. And in the case of "aaaaaaaa", "baaa" is a an improvement. But there will be a an optimal point somewhere, where the load of expanding the alphabet is greater than the benefit of the more compact representation. This explains to a small extent why we (programmers) use hex, and didn't really go to higher bases (digits + alpha could get us to base 36!)
The analogy starts to fall apart when we think about the ability to add to the alphabet, using the conventions. We can't invent new letters, but we can create/repurpose words that encapsulate a lot of meaning.
I'm not really sure where I was going with this anymore!
> I can scroll through code at high speed and understand it at a mere glance once I "get" both the language and the convention that was used.
The issue for me is that the boilerplate is noise. I don't want to see the similar parts, I want to see the parts that differ. Pseudo-C example:
x = [1,2,3,4,5]
product = 1
for (int i = 0; i < x.length; i += 1) {
product *= x[i]
}
sum = 0
for (int j = 0; j < x.length; j += 1) {
sum += x[j]
}
vs pseudo-Haskell:
x = [1,2,3,4,5]
product = fold (*) x
sum = fold (+) x
With the latter example, there are objectively less places for bugs to be present. Sure the definition of fold is somewhere else, but there's only one implementation, whereas the pseudo-C has two implementations. Of course, I'm sure modern Java is much better than this, but it's still a step down.
I'm pretty sure we could configure an editor to expand the second one into the first, but then we come back around to writing-vs-reading.
An interesting experiment would be to have your raw input, eg. msluyter's example of "cmd-J, fori, return" as the editable source file rather than the generated Java output.
Aye, I won't bother critiquing the example, I see what you mean with the boilerplate as noise and part of me agree with you.
One of the main points of programming is to reduce the noise to enable higher levels of code, while keeping an easy access to what's under the hood to fine tune or add new functionalities. A programming language is merely a list of things that will make you lose your temper while you do all that.
It's really cons lists that are harmful -- foldl and foldr are just ways to operate on them. GP's example would work fine with conc trees and a divide-and-conquer reduce instead.
Back in college when I was interviewing for jobs sometimes interviewers would first ask you to write any executing Java class because some interviewees said they 'knew' Java and couldn't do even that simple task.
A couple years later when Eclipse came out I told a coworker this anecdote and he joked that it was 'main' + ctrl-spacebar followed by 'sysout' + ctrl-spacebar. I lol'd.
You can shorten it even further to typing 'fori' then triggering the expansion by pressing tab.
Best shortcut that every IntelliJ user should know is "Find Action" (ctrl + shift + a on Win), press and start typing what you want to do. Will even present shortcuts in the list for next time.
Eclipse has something similar, which it calls "code templates." Features like these leave me wondering why "excessive typing" is often cited as a criticism of Java. As far as I can estimate on the fly, I type less than half of the characters that make up my Java code.
And as the article points out, for readability, verbosity is arguably a good thing. I sure believe it is, perhaps because I am more distracted by poor symbol selection and syntax than most programmers I know. Speaking of, I don't particularly like the C-lineage syntax, Java included. I don't like the braces and parentheses. I prefer a syntax with fewer symbols and more keywords. Crazy, I know.
Excessive typing isn't the issue. The problem with verbose code is that code gets read way more than it gets written. In Java you're often reading 15 lines of code for something that could be 2-3 in other languages.
And still, I have seen plenty of Java code which is perfectly readable and Haskell, Perl, or Ruby code (2-3 lines) that resembled line noise. And I am a Haskell fan :).
The worst offender in Java are IMO anonymous inner classes. But IntelliJ shows them abbreviated. E.g. IIRC Runnables are displayed in Java 8 lambda syntax.
> In fact, it's unclear to me where java might be optimal.
I'd say server side processing of whatever. That's what we use it at work for, and I don't see how any of the mainstream languages would be much, if any, better. Our software has to run on our customers' servers, so portability is of utmost importance since we don't want to need to compile it for random OS's. This rules out languages that need native binaries. Performance is also important, since people don't want to buy bigger machines just because you wrote your software in Python/Ruby/whatever and is 10+ times slower than it needs to be. Also, our software is old enough that C# didn't even exist for many years.
Python/Ruby/whatever will most likely get faster as access to tools like LLVM and the JVM itself is getting more common these days. You'll still get the HUGE bump in development times (due to the inherent expressiveness of the languages) and at least a good portion of the speed benefits you'd reap from Java itself.
"You'll still get the HUGE bump in development times (due to the inherent expressiveness of the languages)"
Not sure if that is true. Maybe for small typical web-projects or server-side scenarios that benefit from thin scripting layer (like at Google). If it is true though, then Haskell and OCAML/F# would be even better because you get expressiveness without loosing the obvious advantages of strong static type systems.
Those language are too cryptic for people to adopt them en masse.
There's a reason why Ruby/PHP/Python are so pervasive, 95% of people simply do NOT care about monads and poly-variadic fix-point combinators for mutual recursion.
Java hands down is the most obvious choice for any applications that require performance, yet are too complicated to write and support in C/C++/other lower level languages. Java JIT is very mature unlike JITs for most other languages, which largely remain at the level of experimental projects and fall short on key production requirements.
Given that the entire Hadoop ecosystem is based upon Java as well, it is here to stay for anything that has to deal with "Big Data"
Like Erlang's GC what all with the 5 9's of uptime it was designed to handle. I mean, come on, the GC algorithm it uses may be battle tested and far simpler than the GC beast that is the JVM but simple is bad, right?
If you're writing complex code java is rarely the answer as it requires so much complexity itself.
Hint: Most java projects just appear to be complex because of the poor quality of the language (and developers).
Java is hands down the choice for simple projects written by way too many poor quality developers. The JVM can barely manage 12 GB of memory, Java is a piece of crap when it comes to anything that's actually complex.
I would venture to say, with no facts or figures mind you, that if you were to evaluate the number of lines of code dedicated to kernel programming to that of applications running applications on the Internet, that the resultant figure would be so small for kernel code that it would look like kernel development doesn't even exist.
Saying that developers who use Java are poor quality is also an awful thing to say. Yes, there are many "poor" Java developers. But, it's only because there are so many Java developers in the first place. So, of course when you take even a small percentage of such a large number there will still be a large enough sample to look significant. It's the same for all other languages.
Java has been my primary language for the last 14 years. During that time I have worked with countless individuals who I would regard as some of the smartest and most competent programmers (who develop using Java) I have known or heard of. These people make your banks, file sharing sites, massive online market places, electronic billing etc. work. So, go ahead and bash all the developers from Google, Sun, SpringSource, Apache Contributors, Oracle and the other 10,000+ companies out there, but empirical evidence has shown that the language and platform work.
Your statement is just so "trollish"... seriously?
Edit: capitalized Internet. Letting the run-on sentences and bad grammar fly.
What about java makes it better for high performance / complexity code?
I never said there isn't a lot of java code, or that it doesn't work, my assertion is that java is not the hands down choice for high complexity / performance work.
If you've got a bunch of mediocre programmers who can't be trusted to make + add things together then sure java is a great choice.
It's a natural fit for enterprise programming where time to implement is usually key and logic is endlessly extended to accommodate whatever new business requirements emerge after the last round was deployed. And robustness is valued more highly than raw performance. Use Java - pay for twice the servers and get ten times the uptime? Done.
That means that days or weeks spent hunting your latest memory corruption issue makes C a non-option for these applications.
As for mediocre programmers - sure, and a large bunch of mediocre programmers scales, whereas a small team of star programmers doesn't. Someone has to tweak the UI. Someone has to implement all that tedious persistence logic. You need star programmers for that? No.
I'm excited to see if Go intrudes on this field, but it's a big field and Go's just starting out.
In the kind of situation GP describes, what matters is probably the well-established practices for extending the behavior of an already-built system without breaking what's already there. A lot of Java practice has built up around having behavior determined dynamically (OOP is a nice fit for that, whereas C does not have great facilities for it). Much of the "ceremony" involved in using the big, complex Java frameworks is about preparing a piece of code for eventual extension. When some behavior is hard-coded in, it's difficult to change later, so the code is parameterized over anything and everything that might eventually change. Of course this looks silly when you do it for small things that won't change -- no need for FizzStrategy and BuzzStrategy interfaces when the only thing you'd ever want to do is print "fizz" or "buzz".
Quite a bit of that programming practice did develop in C++, but Java as a language provides stronger safety guarantees than C++ (lots of memory-related errors are difficult to impossible to have in Java) without sacrificing all that much performance. When you ask for a reasonably performant, statically-typed, memory-safe, object-oriented language, you're going to get pointed at Java (and C#). So that's what people use in that domain.
Oh please, Workday uses a JVM managing 160GB. Lucene/Solr are not simple projects, by any yardstick, for example. I do agree Java the language is somewhat cumbersome, but saying that its a piece of crap for anything thats complex is naive
It solves the problem of using mediocre developers to get code into production. Clunky, slow and overly complicated is infinitely better than a segfault.
Automatic memory management (especially with a garbage collector) is antithetical to high performance. I like the JVM (for Scala, mostly; Java-the-language can go screw), but there is nothing there really remotely close to C++ and C, and the garbage collector is a very large part of why.. Rust might horn in on C++'s bailiwick, but until then, it's gonna be a while.
I strongly disagree that Boost really adds "so much complexity"--and, by the way, shared_ptr and friends are in C++11, and by extension within the standard library. So you don't even need this, unless your goal is to target extremely old platforms. But honestly, if you seriously need shared_ptr, your code design is probably just Not Very Good.
I'm not just namechecking the Disruptor pattern. I have extensive experience with it. It's about 10% slower than what could be achieved with C -- which is to say, the benefits of not having to program in C far outweigh the 10% loss of performance. And its performance is almost always far higher than what's needed, i.e. the bottlenecks are elsewhere.
I strongly disagree that Boost really adds "so much complexity"
We'll have to agree to disagree, I think. Importing Boost is often a sign that something is awry with the design goals of the project. Either the choice of language is wrong, or the project is too ambitious. Though there are some aspects of Boost that are pretty good, such as its unit testing framework.
if you seriously need shared_ptr, your code design is probably just Not Very Good.
> It's about 10% slower than what could be achieved with C
What does that even mean?
Are you saying that you have a proof of the theoretically fastest C program that would implement the same functionality and it's 10% slower than that? Does the C you're comparing it against use the Disruptor pattern too? Or is this just a comparison against a naive, single-threaded C program? How does that number vary with the overall heap size of the program?
Numbers like this get thrown around that strike me as incredibly dubious.
Good luck doing manual memory management in whatever language (C, Pascal, C++, ...) with distributed teams, using developers of disparate skill levels.
Hunting for memory leaks and pointers gone berserk will become someone's full time job.
I like C++, but don't miss using it in enterprise projects.
Sigh. This again? A good garbage collector will always reach a higher throughput than "manual" dynamic allocation/deallocation in C/C++. Pauses are a different matter, and can impact latency; in cases where latency is crucial, Java programs either resort to manual memory management or use a commercial low-latency GC.
If you're comparing the JVM's GCed heap with some specific, user-managed allocation scheme, then know that the latter can be done (and is often done) in Java too.
C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction. Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency.
You shouldn't really use the term "always" either. You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead.
> C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction.
Modern machines have, I don't know, say, 64GB RAM? How much of that can you use for thread stacks? 1GB tops? Modern applications work with really big heaps. Stack allocation is irrelevant for most of what the application is doing.
> Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency.
Yeah, it seems that way, but it turns out that it isn't. Previous attempts to allocate Java objects on the stack showed little or no improvements.
A heap allocation in Java is a pointer bump, and deallocation of a short-lived object is free (Well, this is not quite true, because many allocations will trigger a young-generation collection which, in the JDK's GCs – though not in some commercial ones – takes linear time in the size of surviving objects)
> You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead.
You have the same option in Java, too, and it's pretty much the same amount of work.
> Stack allocation is irrelevant for most of what the application is doing.
Well I disagree with that. In C++ it is quite common for most objects to be allocated on the stack. I have never heard stack allocation being described as irrelevant. Of course if the language puts everything on the heap then that statement might be true.
> In C++ it is quite common for most objects to be allocated on the stack.
Most objects? You have 64GB of RAM! You want to tell me that you can take advantage of all that RAM with thread stacks? You're unlikely to even use 4GB of stack.
If you don't, then you're talking about a small application.
Languages like Matlab are best suited for expressing calculus. Why are you choosing a poor tool for the job?
Most Java programmers don't care about expressing calculus. They care about expressing interactions between web services, sql, and applying rules as the data flows through their modules. Or between user interface elements and service requests. It's all about moving data around, working on that data when you've got it, and triggering actions.
The problems of pushing bits from one server to another aren't that complicated and the pomp and circumstance of java gets in the way of actually accomplishing those things.
As you point out when you have a reasonably complicated problem like applying functions java fails miserably and other languages are a much better choice.
No offence, but it's clear you have no idea about the domains in which server-side Java is typically used. Very large enterprises have all kinds of weirdness and the Java ecosystem has a bunch of libraries found in no other language ecosystem that make things manageable. Java-the-language is sadly verbose and tedious but that's not why people choose it.
So server-side Java lives in a niche and I would never suggest it for, say, anything client-side or basic web apps.
I'd say that NodeJS or Ruby would be decent alternatives depending on your need. npm and gem are really nice in this space and cover just about any need you might have without weighing your system down in pomp and circumstance.
The runtimes aren't that much slower, and for I/O bound tasks, odds are Node is going to run just as fast with less application complexity.
Actually, part of the problem is the academic experience of believing that applying functions is hard and pushing bits is simple. It deceives delusional academics like yourself into believing it's just a matter of doing the work and not really a real computation problem at all.
No, in the real world, it's exactly the opposite. Nobody cares about writing a function because generally that's the simple part. Do it however you want. Deploying the system to take inputs and feed outputs, now that's the hard part. Where do those inputs come from? In what form? Are there security requirements to gather or push data? Do you store-and-forward or don't you? What protocol? Stateful or not stateful? Transactional or not transactional? The problems involved in "move these bits in this format on this machine to those bits in that form on that machine over there" are in fact so complex that you can't even prove it to be an NP-complete problem because the problem itself transcends algorithmic analysis. It is much more a social problem than a technical problem, but the social problem is so massive that any simple-minded technical approach will fail to address the scope of the issue and in every case I've ever seen, simply makes the problem worse.
The "ceremony" you're talking about has nothing to do with the language itself and everything to do with the community. You can write Java and not use the factory pattern, you know.
Hell, Scala is one INSANELY complicated language. It's got about every feature under the sun. Java is simple and to the point...unless you really want to use spring or something of the sort.
Anyway, you've got a really contorted view of Java, and you are conflating some fundamental things.
Community is a big part of the language. Else we would be writing in our self invented languages. You can write Java like anything you want, but that will make you an alien in a big world. Code reviewers won't accept your code for being the odd-one-out.
And its not about complexity or features in a tool, its about how those features interplay with the base design of the tool.
You seriously don't know what you're talking about.
Virtually all serious software that uses complex concurrent data structures is written in Java nowadays, because the JDK is pretty much the only runtime that supports state-of-the-art, envelope-pushing, concurrency.
Erlang is awesome, but only offers high-level concurrency constructs (actually, just a couple), it does not support low level ones (CAS). You can't write, say, a good concurrent hash-map in Erlang. Or in Haskell, for that matter.
I'd like to see any language withstand the combination of big project, lots of managers, mixed levels of experience and expertise on the team, and over-reliance on structure and methodology versus having the right people. It just happens that Java gets picked for those kinds of projects.
Oh come on. To say it is the "obvious" choice is heavy editorializing. I agree it's not going anywhere. As others have pointed out there is a fine language called C++. In point of fact Java is not the obvious choice, that's bit much. There are some very good arguments of Java that may or may not be deal breakers but are still issues ... There must be a middle ground from the power of C that is not OOP gone awry. :)
I just wish they'd fix the generics - Been writing some c# recently, and the lack of type erasure is a really nice advantage.
The decision to do it that way because of backwards compatibility issues looks really shortsighted now - virtually nobody runs JVMs from before they introduced generics, but we still have this hack in place to maintain compatibility with them. Would have been better to break the compatibility and introduce a little temporary pain, but have a better result 10 years later.
I've run the Java Users' Group in Philadelphia for almost 14 years, and I specialized in Java recruiting between 1999-2010. I know a lot of Java pros.
Our meetings still get pretty strong attendance (80-120 per meeting), but I'm seeing far fewer new sign ups and the faces are much the same. There could be several reasons, but young engineers that I speak with rarely have any interest in Java work (though JVM is still popular).
Some members have taken to coming up to me and saying "Java is dying, you know?" at meetings. It will become harder and harder to find engineers to maintain the Java code as the first generation of Java pros start to move on to other languages or retire. Java needs some new blood and better PR to maintain interest from younger devs, and Android may be the best hope.
This is fairly common it seems, and one of the reasons my JUG (and some others) have modified our guidelines from a Java language focus to a focus on anything Java language or JVM. It has opened things up and allowed us to dive into some topics that will keep our audience more engaged.
I think interest overall in software development has plateau'd recently. I go to software events and think, "of five million people in the area, these are the fifty really interested in software development. Half are probably hobbyists, and the other half are probably already employed. A person that needs to hire a developer has big problems."
I'd disagree with that. In my area, the software dev population has just become segmented as different languages and tools became popular. When I started the JUG, there was an active Perl group and a Linux group but little else that drew a crowd. Now there is a strong Python group, 2 Ruby groups, a Scala group, a Clojure group, an FP group, a big data group, a Node group, Android and iOS groups, and probably a handful I've not even considered.
I know most of the other groups still draw smaller crowds than JUG, and there are several possible theories or justifications for that which have nothing to do with language popularity.
This of course is anecdotal and represents Philadelphia, but I'd imagine other locations have some similar experiences.
Stopped reading the article when he referred to Scala as a scripting language. Clearly the author has no idea what he is talking about. Sure, you can use Scala for scripting (I never do) but its main value is in software design, whereas scripting usually is not about design, but about a quick solution.
How many of you are actually handling big Java projects ? Mine is not that big but big enough to have 15 sub projects, 200 dependencies, 5 people for maintenance, batch, GUI, JEE stuff. The only thing I can say is taht although Java is nice, the maven, release mgmt, spring stuff it needs to be actually manageable is absolutely enormous (the question is, how would I manage that in another language ?). Contrast that with interpreted/dynamic languages... No type safety ? But I don't have to wait 3 minutes 30x a day for my build to complete in order to check that my code is actually running... So well, there's room for compromise.
For me the tru force and problem with the java ecosystem is that it allows to separate concerns in the enterprise : a team to provide some Eclipse plugins, a team to handle release management, a team to deploy thnig on servers, a team for development, etc.
One of the huge advantages of Java's static typing + somewhat boring/verbose syntax is that it makes writing powerful tools for manipulating Java code far, far easier than any of the C-based languages with preprocessors or any dynamic languages.
After working in IntelliJ for a while with its phenomenal refactoring tools going back to any other coding environment feels somewhat stone age in comparison.
I don't use IDEs, but it seems that there are only 2 or 3 that really work: Visual Studio for C/C++, and Eclipse/Intellij for Java. Do you use one of those?
Between writing less code with a text editor and writing loads of verbose code with a powerfull IDE i'd chose the former. How much text processing would you write in Java vs Python/Ruby ? This is a no brainer for me. Dynamic languages have their advantages,though i find Scala to be a good compromise.
>A recurring prejudice in the forums where the cool kids hang out (Hacker News, Reddit, etc.) is against Java, the language.
Maybe I've been reading a different Hacker News, but I haven't seen this sentiment at all one HN, especially with the love for everything JVM (Clojure, Scala) and all the Database/Big Data tools written in Java (Cassandra, Hadoop, HBase)
I disagree with you and think the statement that you quoted is entirely accurate. People can like the languages and tools built on top of the JVM and implemented in Java, without liking coding in Java the language itself.
No, now I'm not one to fall on either side here but there is certainly ... a lack of love for Java on HN. I mean its definitely there. If you hnsearch, you'll see. I agree, the JVM is a different issue.
When I was attaining my degree during the end of the last century, Java (and XML) was being trumpeted as the saving grace for all soon to be software professionals. We were all in love OO programming and this scratched us right where C++ left an itch. Oh Java Beans and Servlets, how we loved thee.
It’ll take decades before all the code created by those who came right before me and soon after is gone and we’re gone before Java is considered dying/dead.
From what I see the new generation wasn’t forced to learn Java and doesn’t want to use Java.
A bit of everything. My classes used Scheme, Java, C, ASM, Python, Lua[1], JavaScript, Prolog, OCaml, Coq... Whatever fits any given subject best. And of course you have a bunch of classes like algorithms and theory which do not use a real programming language at all.
[1]: Okay, not really Lua but a custom language heavily based on it.
I just started university and it's still all Java. I found out one university in my country (Germany) teaches Scheme in their introductory course, but sadly I had already enrolled at a different one at that time.
The high school CS curriculum here is also basically an introduction to Java.
I just looked up my old university's curriculum and it must be another university - our 'Programming 101' is half C, half Java now. I bet our students will never hear of recursion on campus anymore.
From what I heard as a student assistant, there were all sorts of reasons for dropping Scheme. First, professors have to use half of their time for research, and there isn't much useful research left in programming languages (given that the industry is decades behind that research, anyway). Second, many of our old professors started out in mathematics, unlike the new generation. Third, everything is being dumbed down. :(
I know why they do it: Java is the closest we have to an "industry standard" programming language. But, given the high failure rate in computer programming teaching (c.f. the FizzBuzz test) there's no excuse for putting beginners on such a steep learning curve.
I'm going for my undergraduate degree in CS. Java is the language used in the general programming courses, e.g. Intro to Programming (CS 101) and Advanced Programming (CS 210).
I'm taking a C++ class but it was one out of a selection of courses I could take. The java classes are required for everyone going for a CS degree.
I think Java is still the main teaching language at most colleges, at least in the beginning courses. I don't think that's going to change for awhile either.
I don't think the industry is driven by academia. Plus, no CS degree program worth the paper it's printed on even claims to teach Java. If yours did, I'd ask for a refund.
Typically schools USE Java to teach computer science topics, for instance my university used it in the Intro course, where we learned program flow control and some OO principles, and in our Data Structures course where it was nothing more than a tool to complete assignments. We used Scheme to explore other programming paradigms, ASM for our architecture courses, C for our OS course, etc. Other than that we could use any language we wanted for other courses.
Basically if you come out of school claiming you "learned" Java, or any language, it probably means you are lying or went to a bad school.
All of our (the CS degree program I attended) 100s/200s courses in the late 90's were taught using C. From what I remember they didn't "claim" to use any particular language and basically if they did I wouldn't have known what they were referring to anyway.
Java came onto the scene with much fanfare. It was a big thing and all the professors were quick to foist it upon us.
On a side note, it’s funny for me whenever anyone says they chose the JVM for speed. It’s still ingrained into me that this is not the case. I have to take a second and assure myself this is not 1998, Java is fast now.
I also remember all of the courses taught in C (with some C++ for OOP).
I find it really odd, though, working in a University environment and seeing the massive number of students in Java courses while IT is trying to limit the installation of the JVM on clients (especially Windows), as it's one of the major infection vectors on the campus (another being Flash).
Personally, I learned Java for Android/Blackberry development (guess that makes it half dead for me), but I also learned Objective-C for iOS/OS X development. I don't really see myself using either for any other environment, though.
I guess I'm just glad I never really dreaded learning/using any particular language.
You'd be shocked at how many bad schools exist. I graduated from a university that tried to drop "Data Structures and Algorithms" because it didn't translate well to the workplace, and that university is deemed to be okay for Computer Science in the UK. I ended up taking it, but a lot of other students in my class weren't happy. We even complained to the British Computer Society, as the Computer Science degree was accredited by them, but nothing came from it.
My university pushed Java down our throats whenever they could. We also spent a lot of time with Prolog and C, but Java was taught as if it was a perfect language for anything a developer could possibly want to do. I joined a Masters degree programme at a top ten university in the UK and I was blown away by the difference. The facilities were no better, the lecturers no better, and the students no better. The only real difference was the curriculum, and the administration. At bad schools the curriculum is focused on raising the hiring numbers and the adminisration deal with so many kids that they couldn't give a shit about their needs, whereas at good schools they try to stay true to the subject and those running the degree programme have done a good job, and will make things run smoothly.
I would say that students from bad universities probably end up just as good at programming as those from good universities. The big difference is how they cope when they leave their comfort zone. I'm a .NET developer and I've seen some students brought up in Java really struggle, which is fairly shocking when you consider the similarities between the Java language and C#. A good student from either will adapt either way.
I have been taking CS classes over the past few years. Java and C++ are the mainstay languages, but we have had some Python and assembly well. Then a little bit of some other languages like Common Lisp and Prolog.
>When the JVM implementation of Ruby, JRuby, added native support for this instruction, its performance zoomed past the C-based Ruby VM, which for years has been the Ruby reference platform. As JRuby's performance continues to pull ahead, I fully expect it to become the reference implementation. Certainly, it will become the vehicle by which most organization first try out Ruby.
This was true at some time, afaik the MRI Ruby on 1.9.3+ is faster-than or about-the-same-as the equivalent JRuby implementation. I also know zero people who were first exposed to Ruby via JRuby.
JRuby is awesome btw. I just think this article has a bit of a defensive tone...
Scala is awesome but not a scripting language. Running Scala as script is insane as it takes 1 or 2 seconds to start the JVM/Compile/Execute a fairly large Scala file.
You dont want to use that on your server for scripting purposes.
Ruby,Python or PHP are more suited for scripting tasks(especially Java code generation,i'm writing an Android app generator right now,since i was tired of all the boilerplate : json+php script = Activity classes , resources files , ContentProviders generated in less than 0.2 seconds no matter how many tables I need for my apps,saves me hours of work).
Dr. Dobb's puts out a monthly PDF issue. It's smaller in terms of content than the paper issues of the 90s, but it's in that mold. Also, the website posts new feature articles every Tuesday, covering a fairly wide range of programming topics. Most articles have code.
Yes, I know about the PDF issues, and I also realize that there are so many great resources on the web that having a dedicated general purpose programming magazine doesn't make business sense anymore.
It is quite possible that what I miss is really my childhood and the excitement of waiting for the magazine and learning about things (most of which I didn't fully understand) with wide-eyed wonder. But of all the computer magazines I have ever encountered I think it was Dr. Dobbs' that struck the best balance between CS academia and the hands-on world of programming. It straddled that world between abstraction and application perfectly in my opinion.
It would be a wonderful role to resurrect in the age of big data and increasing statistical and algorithmic sophistication. Won't happen, though. So I'll just wallow in my moment of nostalgia :-)
With Hadoop, Lucene, Solr, etc. written in Java, there is no doubt that Java is here to stay. None of these libraries (or many others) have competing implementations written in other languages.
"None of these libraries (or many others) have competing implementations written in other languages."
Except the ones they were written to copy. Each example you give is an open-sourced clone of an pre-existing version implemented in a different language.
That's not true at all, Lucene is a Java project from the beginning, and has since been copied to virtually every other environment because it is such a kick-ass indexing engine.
I am really sick of these articles. "Java is alive and well", "Brand new exciting things that tell you Java is still a leader" blah blah blah. To me Java is a great tool, the JVM an even better tool. No one said your favourite language is dying and if they did, they are naive. These articles only give me a small hint that you think java is dying and are trying to do your part to keep it alive.
I guess what boils down to is that I hate articles that give me the impression of desperation. Maybe this is my own problem in the long run so I don't know why I wrote this comment.
I agree. It's link-bait, battling the other link-bait about how Java is dying and { x, y, z } is the #1 language, will dominate any day now, and anyone not coding in it is inferior.
Unfortunately, as technology has matured, it has become just as politicized and petty as anything mainstream. Countless people make their reputation and/or income writing blog posts and churned articles, living in the tech periphery like leeches, without creating any actual value. I think this is part of why I have so much nostalgia for the 80's and 90's.
Code in whatever makes your life least painful, and learn whatever's in demand for your desired career path.
I'm just getting back into Java (both platform & language) and I'm really excited about it. It has really matured over the past 10 years both in tooling and application
architecture philosophies. I'm really looking forward to pick up Java, Spring, Hibernate (maybe I settle for JPA, not sure yet) and my old trusted friend Tomcat.
Oh, and I might throw in some Scala, Groovy and JRuby in here and there as well.
The best thing about java is the ecosystem around it - a massive range of mature and robust open source libs to do just about anything you like (parsing HTML, part of speech tagging, search indexes, neural networks, fast caches, networking tools, web servers/containers, email servers etc etc) Does any other language have this variety available?
I use Java, C, C++, Python, Ruby/jRuby, bash, Perl, etc.
The right tool for the right job. Anybody making unconditional statements about the decline (or not) of a language is a fool (IMHO).
Likewise saying the "C++ is better than Java", or "Java is better than Python" or ... is devoid of any meaning without specifying the domain of the problem to be solved.
Java is not dying, it has just started its long slow decline like COBOL did back in the 1980s. But COBOL is still with us and so will Java be with us for a long time. But the momentum is picking up on alternate JVM languages, in particular Grovy, Scala and Clojure. Of course there is also Python(Jython), JRuby, PHP and many others that run on the JVM, but Groovy, Scala and Clojure are the triumvirate that is picking up steam and will end up pushing Java down into the depths where, like C, it will remain as the tool of choice for building JVM libraries.
The Oracle JVM is also not the only JVM available these days and there are even some commercial JVMs that are higher performance than Hotspot. I think one could make a strong argument that the JVM will outlive Java itself by a large margin. Say, Java fades out of common usage by 2050 but the JVM is still going strong in 2150.
"Java is dying" is wishful thinking. It's not the case, but we can only hope it will be. Currently, it does a good job of marketing to developers too good for Ruby and Python and not good enough for C.
Welll, the reasoning behind it might be from two facts - a) Ruby and Python both are far better beginner/learner languages than Java & others - I mean, if some kid wanted to learn programming, I'd suggest to start in those because they don't have distracting boilerplate; and (b) other things being equal, Java does get you better execution performance than Ruby/Python; not on C level but it's halfway in between.
But still "developers too good for Ruby and Python" is an interesting statement; IMHO the only ones who'd claim to be 'too good' for Python/Ruby would be authors of their own languages or maybe the hardcore Lisp or Haskell crowd.
There is Java and there is the JVM. Both are doing well, but Java is progressing slowly, and more and more developers -why actually now what they are doing- are looking into alternatives. These may also be languages running on the JVM though.
Java as a languages is getting old, in terms of concepts and verbosity.
Functional programming is what is -the next big thing-. And most java-only developers don't know how todo that.
While it is still thriving, there is an unstoppable move to newer, more functional languages (which can run on the JVM too).
I haven't programmed in Java but I sometimes read Java source code. I must admit that I like the language which to me is a better C++. However I don't like the way it is used i.e. tooling, libraries and programs. I don't like AbstractProxySingletonFactories, XML configuration files, long method names and lots of other things. That being said I believe that a change in the programming culture surrounding Java may lead to more pleasant programming experience.
Java is a pretty boring language, it must be said. But that's what makes it so good for real world usage - its got a lot of library support and many issues tend to have been ironed out already. Couple of weeks ago I was using Selenium's WebDriver SDK with a Ruby client program. It failed in some obscure TCP/IP stack error coming out of the C Ruby implementation. Using a java client just worked.
But look at the beginning of Java, at that time it was "cool" and growing.
Now Java is an adult and not cool, other languages grow, build new communities, new tools and new possibilites, that's why they offer more fun and many people think java is dying.
Java will be there for many many years, Cobol still there too ;-)
But someday it will die, that's normal life.
I searched various job sites by programming language, and Java always came out on top (by a significant amount) for listings, except on the startup job boards.
Technologies with giant backers (e.g. Java or Windows) have massive inertia keeping them seemingly alive for years (or decades) after losting their soul.
I think C has kind of hit equalibrium, in that it's not often used for things outside its "niche", but with no other language threatening it within its niche.
Not really. Forth is nowadays only used for tiny embedded systems.
In contrast, C is the glue language for pretty much everything. Even the latest operating systems like iOS and WinRT use C as the base level API language that is callable from anywhere. They do have significant libraries and conventions to manage that (Apple uses CoreFoundation, Microsoft uses COM), but it's still C.
Java isn't new anymore. It wasn't really groundbreaking even when it was new in 1995:
* Object-orientation: Simula-67 mid 1960's, CLU 1974, Smalltalk 1980
* Garbage collected memory: In Lisp since 1959 !!
* JVM: UCSD Pascal had a similar idea in 1974.
* Syntax: Java's was a basic evolution of the Algol-68 -> C -> C++ chain
* Performance: in 1995 Java was too slow and too big
* Write once, Run everywhere: other than assembly language, all languages strove for this.
Nothing in the language was that special. Most of it's features weren't new, but it went on to be one of the most important programming languages because the engineers at Sun had put together a good, solid, language on a good, solid, implementation. They had a vision, largely realized now, of a language to support professional software developers. It is now very fast, the size of it's run-time doesn't seem so significant in 2013, it's current garbage-collector is state-of-the-art, and it's eco-system of libraries and frameworks is now unsurpassed.
Java may have already peaked. This doesn't change the fact that it has been so important and that experiences with it will shape the future of software engineering. I was impressed with Rob Pike's talk on the Go language: "Language Design in the Service of Software Engineering" [1]. It seems to me that Java's success was driven by largely pragmatic thinking and that the designers of Go are now attempting a similar path to success.
Public service announcement: Don't squabble. If you program in C, be happy, your language is the very best for embedded systems and kernel development. If you program in C++, be happy, your language is the very best for developing programs that deal with complex data structures and must run as fast as possible while using memory efficiently. If you program in Objective-C, be happy, your language is the very best for IOS and Mac OS X programming. If you program in C#, be happy, your language is the very best for developing Microsoft .NET applications. If you program in Python, be happy, your language is the very best for rapid prototyping and exploring big-data. If you program in JavaScript, be happy, your language is the very best for client side web programming. If you programming in Haskell, be happy, your language is the very best for exploring reliable software through detailed specification of types. If you program in Ruby, be happy, your language is the very best for putting together Rails apps (and yay, it's getting faster). If you program in Lisp, be happy, your language is the very best for getting the most out of Emacs. If you program in Visual Basic...be happy, there are better languages you can learn.
Java is dying because it requires more and more resources to make it work. People look at the growing resource requirements and think "wow, look at how Java is growing! We even are teaching middle schoolers Java now!"
Wasn't the point of Java to release developers from having to worry about memory? Well, now we have to worry about everything else. It's a failed abstraction and now we have to live with it.
"Wasn't the point of Java to release developers from having to worry about memory?"
I think you're thinking of releasing them from worrying about pointers, which it basically did. When it first came out, its stated goal was to release developers from having to worry about portability, which it did.
Java is not dying the same way Cobol was not dying 10 years ago. It has a lot of legs left but nobody is 'hoping' to use it, they are told to do so.
Java is and always has been almost completely a corporate tool. Again, like Cobol, so the 'cool kids' are not going to give it much love. It's too slow to execute to compete with C++, its too slow to write to compete with Groovy or Scala. And all the cool kids pick an extreme and vote that way.
Java is not 'dead', but thought leaders aren't using it right now. The people who inherited the decision of thought leaders of 15 years ago are using it, so the writing is on the wall, its just going to take a while to be read.