If Java Is Dying, It Sure Looks Awfully Healthy
drdobbs.com
drdobbs.com
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.
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.
Groovy - slower, much worse toolability
Scala - less readable, slower, slow compilation, worse toolability, too complex.
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 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!
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.
Scary but true.
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?
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.
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 used by a lot of extremely productive programmers and some brilliant apps are written in it.
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.
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...
"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.
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.
>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.
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.
"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.
http://www.ohloh.net/languages/compare?l0=java&l1=javascript...
Although it looks like Ruby isn't growing as quickly as JavaScript and Python.
It will be interesting to see if perceptions change after JavaScript and Python overtake Java.
I miss thought leaders using French, or Latin :-(
- 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.
C# also sort of implements type classes. For your example, there's IComparable in C#; implement it and a List<SomeObject> can be directly sorted.
For pure functions, there's the [Pure] attribute, but it isn't enforced by the compiler, it's just a contract, a promise.
This is what templates do in C++.
ill be coding with libgdx and pushing to html5 and android while the thought leaders decide their next move.
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.
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.
Java can make use of processor extensions by writing a small Assembly snippet callable via JNI.
Which is actually similar to what is required in C and C++ code, when writing "portable" code that should compile in various compilers.
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.
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.
http://www.slideshare.net/mmitran/ibm-java-packed-objects-mm... and http://www.slideshare.net/ZeroTurnaround/ryan-sciampaconerun...
http://www.slideshare.net/mmitran/ibm-java-packed-objects-mm...
You use jni to call libraries somebody else made (opengl?), you don't plan your project around using jni.
http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...
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.
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).
I am not making any kind of sufficiently smart compiler claim (http://c2.com/cgi/wiki?SufficientlySmartCompiler).
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.
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).
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.
Which one has the advantage?
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.
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.
[3] http://www.catb.org/jargon/html/story-of-mel.html
[4] Despite this extensive apology for Java, I despise it and if I never have to touch it or the JVM ecosystem again it will be too soon.
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.
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.
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".
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.
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!)!
Personally, I quite like Java.
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."
"People complain about my language, because they use it. If it wasn't good (enough) they would not have used it."
Thus the complaints are relegated from feedback to proof that the choices made were right thus invalidating complaints.
itsNotTheLanguagesFaultPerSe:butIfTheFunctions:andTheirParameters:werentNamedLikeThis:itWouldBeBearableI shed a small tear every time I have to call a C API with and endless parade of (NULL, NULL, 0, NULL).
http://books.google.fr/books?id=_EdbrocXX9MC&lpg=PA183&ots=D...
That's because you get it inline for you with Xcode's autocomplete. IDEs do this for other languages, and the effect is the same.
langFaultFuncParamNameWBB()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.
Exactly. I'm pretty sure that switching to something like Scala wouldn't improve my productivity.
Fuck dude. You're a developer. If you want productivity, make shit happen.
https://i.imgur.com/toGKy21.jpg
In fact, it's likability percentage is worse than PHP!
I think the issue may stem from the fact that given a choice, few people use Java in their own projects but have no choice at work.
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.
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.
You can use many languages which compile down to Java Byte code.
> 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.
But the combination of iOS and Android gently pushes you in the Mono/F#/C# direction. Come to the light side!
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.
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.
Personally I really like Java - coming from a C++ developer (11 years in the games industry). I wouldn't mind working with it everyday...
Dalvik is not. It can't run java classes compiled with a regular java compiler
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.
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.
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.
Google is a corporation like any other.
http://news.cnet.com/8301-1035_3-57423754-94/java-creator-ja...
<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>
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.
- 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.
[1] https://github.com/yareally/Java7-on-Android (small guide I set up to explain how to add all the features above)
Thanks for the tips, though.
Secondly, Android's base classes and AIDL are a significant advance in Java.
* platform independence
* performance
* low level features
* simplicity and clarity (for reading, writing not so much)
* infrastructure/tools (IDE, visualvm, etc)
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?
A language is much more than just syntax.
With mono, one ends up writing C# code similar to C and C++, with #ifdefs, or having to search for .NET libraries that are cross platform.
UI for example. Pure Java UIs plain suck; you can use Gtk# in C# for the same thing, but none will be up to the platform's UI standards.
Besides, the JVM isn't available on iOS and Android, so it isn't universally available either.
Scala,Groovy,Xtend,etc... there is enough languages on the jvm one doesnt have to use any MS related tech.
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;
}
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.
If only. In http://msdn.microsoft.com/en-us/library/vstudio/ms229043%28v..., Microsoft advocates:
"The PascalCasing convention, used for all identifiers except parameter names, capitalizes the first character of each word"
Also, as the guy below me pointed out, by convention you know that Foo is a property.
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.
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.)
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..
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).
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.
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 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.
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'!"
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]
}
x = [1,2,3,4,5]
product = fold (*) x
sum = fold (+) x
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.
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.
As someone who didn't realize this existed in Intellij, I think you may have just changed my life :)
There's no need for Cmd-J, just write a few characters and press TAB. Try "sout"<TAB>, "psvm"<TAB>, "iter"<TAB>, "itli"<TAB>, and so on.
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.
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.
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.
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.
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.
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.
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"
Isn't Java the choice for things that aren't performance critical but are too complicated to write in C?
Java survives because thats actually most things.
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.
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.
You can't have a medium to large Java thread on this site without a lot of people deriding Java developers. It's practically a law of nature.
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.
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.
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.
Here's the 12 GB of memory...
http://www.datastax.com/docs/1.0/operations/tuning
As far as the language is concerned...
What problem of high performance & complexity apps does Java 7 solve that C++11 doesn't?
"Just use Boost" is not a viable strategy when it adds so much complexity in and of itself.
I'm not defending Java, but it's helpful to know what the limits of each tool are.
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.
The LMAX Disruptor pattern would like to have a word with you.
http://lmax-exchange.github.io/disruptor/
http://martinfowler.com/articles/lmax.html
http://stackoverflow.com/questions/6559308/how-does-lmaxs-di...
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.
This I fully agree with.
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.
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.
Java does have some unfortunate complexity, but I don't think it is in the same league.
Java also includes a library that is more extensive in some areas than the vanilla standard C++ one.
The JVM is also more robust to some types of programmer errors than any run time for C++ that I know of.
Most of what the code does is hidden behind ceremony.
Imagine Newtown writing out instructions on how to calculate gravity instead of just writing: F = G((m1 m2)/(r^2))
I really don't understand how a language that can't succinctly express calculus from 300 years ago would be regarded as suitable for complex code.
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.
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.
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.
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.
Here's my previous discussion with haberman on the subject: https://news.ycombinator.com/item?id=6505853
Though if you were only affirming that it isn't a language construct you are correct.
Define complex?
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.
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.
The JVM on the other hand, with things like JRuby and being able to use popular Java libraries and things like TorqueBox, is incredibly cool.
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.
I know it is not very reliable but Tiobe index is still a decent metric.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
When Visual Basic dies I would start believing that Java could die.
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.
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.
Almost all Basic, C, C++ and Pascal IDEs from Borland for MS-DOS and Windows
The initial releases of Delphi IDE
Visual Studio, only after 32 bit support, not earlier
The first releases of C++ Builder
KDevelop
Anjunta
Eclipse
Netbeans
Smalltalk environments
Lisp environments
Native Oberon environment
And a few more not worth remembering.
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)
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.
[1]: Okay, not really Lua but a custom language heavily based on it.
The high school CS curriculum here is also basically an introduction to Java.
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. :(
At least my job is secure...
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 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.
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.
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 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.
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.
Also,
>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...
There are some areas where JRuby is 3 times faster and the areas where it's 2 times slower. Not impressive, compared to native Java implementations:
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
Where you can get even two orders of magnitude speedup.
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).
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 :-)
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.
Though I agree with OP - these projects and Java are here to stay for the foreseeable future.
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.
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.
Oh, and I might throw in some Scala, Groovy and JRuby in here and there as well.
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.
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.
Not trying to pick a fight, just would like you to elaborate.
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.
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).
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.
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.
* 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.
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.
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.
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.