19 ms·

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 l

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.

dkuntz2 13y ago
I'm fairly certain Java and C++ have comparable speeds, and I think in someways Java's faster.
- jordanthoms 13y ago
  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.
  - acomjean 13y ago
    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.
    - cageface 13y ago
      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.
      - pjmlp 13y ago
        Being discussed for Java 9 and already available on IBM J9 JVM. http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120 http://www.slideshare.net/mmitran/ibm-java-packed-objects-mm...
      - danieldk 13y ago
        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.
        cageface 13y ago
        For sure. Mixed value/reference semantics add a lot of complexity to C++.
        n3rd 13y ago
        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. http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120 http://www.slideshare.net/mmitran/ibm-java-packed-objects-mm... and http://www.slideshare.net/ZeroTurnaround/ryan-sciampaconeruntimeinnovationnextgenninjahackingofthejvm-24613149 http://www.slideshare.net/ZeroTurnaround/ryan-sciampaconerun...
  - bradleyjg 13y ago
    I've read that you can call asm from java directly using jni (i.e. without a c wrapper) though I've never done it myself.
    - frozenport 13y ago
      And nobody else has too. You use jni to call libraries somebody else made (opengl?), you don't plan your project around using jni.
  - pjmlp 13y ago
    > C++ does give you the ability to more easily use processor extensions (SSE, AVX, etc), which you can't use from Java AFAIK 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.
    - exDM69 13y ago
      > 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.
- Guvante 13y ago
  The lack of non-heap objects makes you bend backwards more than you should though.
  - n3rd 13y ago
    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)
- Aldo_MX 13y ago
  Can you please provide real benchmarks?
- axaxs 13y ago
  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?
  - 0x0 13y ago
    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. Which one has the advantage?
    - axaxs 13y ago
      C to both of your questions. 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.
      - bcoates 13y ago
        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. [3] http://www.catb.org/jargon/html/story-of-mel.html 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.
- 10098 13y ago
  Many painful minutes spent with slow-like-sloth-taking-a-shit Java desktop software lead me to believe that your statement isn't entirely true.
  - threeseed 13y ago
    Your ignorance of the difference between server and client side Java leads me to believe that you're probably wrong.
  - sliverstorm 13y ago
    This usually seems to be due to bad code, or bad GUI libraries (which Java seems to be the king of)
    - pjmlp 13y ago
      And bad developers using those libraries.
      - artsrc 13y ago
        The fact that this sluggishness is not present in Visual Basic programs implies this is the library, not the programmers or the language.
  - danieldk 13y ago
    IntelliJ, which is a large Java Swing application, certainly works fine and quick on all of my machines.
smrtinsert 13y ago
are these the same thought leaders that ditched ruby for scala or node or clojure? ill be coding with libgdx and pushing to html5 and android while the thought leaders decide their next move.
- kamaal 13y ago
  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.
  - smrtinsert 13y ago
    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.
ww520 13y ago
So which hip languages are these "thought leaders" using now?
- jaggederest 13y ago
  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.
  - EpicEng 13y ago
    Javascript? Really? "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.
    - jaggederest 13y ago
      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.
      - xerophtye 13y ago
        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.
gaius 13y ago
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.
- teh_klev 13y ago
  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.
- jasallen 13y ago
  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.
RivieraKid 13y ago
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.
- Tloewald 13y ago
  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?
  - pjmlp 13y ago
    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.
  - nl 13y ago
    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. Scary but true.
markokrajnc 13y ago
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...

dkuntz2 13y ago

I'm fairly certain Java and C++ have comparable speeds, and I think in someways Java's faster.

jordanthoms 13y ago
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.
- acomjean 13y ago
  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.
  - cageface 13y ago
    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.
    - pjmlp 13y ago
      Being discussed for Java 9 and already available on IBM J9 JVM. http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120 http://www.slideshare.net/mmitran/ibm-java-packed-objects-mm...
    - danieldk 13y ago
      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.
      - cageface 13y ago
        For sure. Mixed value/reference semantics add a lot of complexity to C++.
      - n3rd 13y ago
        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. http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120 http://www.slideshare.net/mmitran/ibm-java-packed-objects-mm... and http://www.slideshare.net/ZeroTurnaround/ryan-sciampaconeruntimeinnovationnextgenninjahackingofthejvm-24613149 http://www.slideshare.net/ZeroTurnaround/ryan-sciampaconerun...
- bradleyjg 13y ago
  I've read that you can call asm from java directly using jni (i.e. without a c wrapper) though I've never done it myself.
  - frozenport 13y ago
    And nobody else has too. You use jni to call libraries somebody else made (opengl?), you don't plan your project around using jni.
- pjmlp 13y ago
  > C++ does give you the ability to more easily use processor extensions (SSE, AVX, etc), which you can't use from Java AFAIK 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.
  - exDM69 13y ago
    > 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.
Guvante 13y ago
The lack of non-heap objects makes you bend backwards more than you should though.
- n3rd 13y ago
  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)
Aldo_MX 13y ago
Can you please provide real benchmarks?
axaxs 13y ago
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?
- 0x0 13y ago
  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. Which one has the advantage?
  - axaxs 13y ago
    C to both of your questions. 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.
    - bcoates 13y ago
      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. [3] http://www.catb.org/jargon/html/story-of-mel.html 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.
10098 13y ago
Many painful minutes spent with slow-like-sloth-taking-a-shit Java desktop software lead me to believe that your statement isn't entirely true.
- threeseed 13y ago
  Your ignorance of the difference between server and client side Java leads me to believe that you're probably wrong.
- sliverstorm 13y ago
  This usually seems to be due to bad code, or bad GUI libraries (which Java seems to be the king of)
  - pjmlp 13y ago
    And bad developers using those libraries.
    - artsrc 13y ago
      The fact that this sluggishness is not present in Visual Basic programs implies this is the library, not the programmers or the language.
- danieldk 13y ago
  IntelliJ, which is a large Java Swing application, certainly works fine and quick on all of my machines.

smrtinsert 13y ago

are these the same thought leaders that ditched ruby for scala or node or clojure? ill be coding with libgdx and pushing to html5 and android while the thought leaders decide their next move.

kamaal 13y ago
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.
- smrtinsert 13y ago
  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.

ww520 13y ago

So which hip languages are these "thought leaders" using now?

jaggederest 13y ago
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.
- EpicEng 13y ago
  Javascript? Really? "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.
  - jaggederest 13y ago
    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.
    - xerophtye 13y ago
      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.

gaius 13y ago

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.

teh_klev 13y ago
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.
jasallen 13y ago
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.

RivieraKid 13y ago

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.

Tloewald 13y ago
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?
- pjmlp 13y ago
  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.
- nl 13y ago
  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. Scary but true.

markokrajnc 13y ago

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...