23 ms·

Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

104 points by mustapha 13y ago

jonstewart 13y ago
Beefs with this article: 1. Runtime-linking _is_ dynamic linking, and it's a PITA that Java doesn't have an option for static linking, especially given the inherent fragility of the CLASSPATH. 2. clang and gcc have compatible command-line option syntax. 3. The options example he lists for gcc is a pure strawman. Maybe they are necessary to compile that particular source file, but it is not necessary to use all these options in the average case. 4. The article title says "now more than ever", but there's really nothing about recent developments here. This article could have been written ten years ago. This really just seems like crappy linkbait.
- latk 13y ago
  Good point(s), especially #4. The article compares an 80s language (C++) to a 90s language (Java), not to more recent compiler toolchains. Admittedly, there aren't many options here, and e.g. Scala (which I hope will be covered in future articles) relies on the java toolchain. Edit: C++ and Java also have different cultures. The simplest compilation with g++ is "g++ foo.cpp -o foo", which isn't much more complex than "javac Foo.java". The fine-grained options clang/g++ give you are part of the “you pay for what you use”-mentality of C++.
  - pjmlp 13y ago
    Except there are 70's languages (Modula-2), 80's (Ada) and 90's (Turbo Pascal/Delphi), that offered more powerful compiler toolchains. However, given C++'s requirement to be kept compatible with UNIX toolchain model, we suffer from a 70's model in C++.
- th0br0 13y ago
  Most importantly, his gcc example is taken from OSX... ugh.
  - Roboprog 13y ago
    As the guy says he is writing music software, Mac OSX would be a pretty important platform to cover. That said, I'm a recent convert from Linux to OSX, and I like to tinker with Garbage Band from time to time :-)
- gresrun 13y ago
  > 1. Runtime-linking _is_ dynamic linking, and it's a PITA that Java doesn't have an option for static linking, especially given the inherent fragility of the CLASSPATH. It is possible to roll a 'fat' JAR with all your dependencies baked-in, which is as close to static linking as it gets in Java-land. I prefer this for stand-alone applications as it makes deployment a cinch at the expense of the size of the build artifact.
  - jebblue 13y ago
    Agreed, this is how I do my Java standalones. Eclipse makes this easy with Export | Runnable Jar providing several options for how to package the build.
    - danieldk 13y ago
      The Maven assembly plugin can also do this with the 'jar-with-dependencies' descriptor.
      - gresrun 13y ago
        I personally use the maven-shade-plugin for this because it has built-in support for handling special resource files like licenses, service definitions, and manifest entries.
        agibsonccc 13y ago
        The maven shade plugin can be dangerous if you hit the zip file limit of 65535 entries. Watch your filters.
  - jonstewart 13y ago
    Yeah, I've used jarjar before for this.
  - yaeger 13y ago
    I wonder how such a setup would play out in regards to Open Source usage. Say you create a big jar with all dependencies in there in several layers of "lib" folders. Licenses like LGPL say you have to keep the LGPL archive accessible to the user and grant permission for them to alter/update them. Would a nested hierarchy of lib folders inside your jar be viewed as hindrance? Certainly you didn't "hide" the LGPL'd components in order for the user to not alter them but I think it could be viewed as "security through obscurity". If I don't immediately see a component, how do I know its there? I guess this could be solved by a readme that lists in detail what open source components are used and where in the hierarchy they can be found.
- diminish 13y ago
  Moreover, their own banner ad at the bottom is ironic. "Java is cured, suffering from redeploy madness. Get your cure". http://zeroturnaround.com/wp-content/uploads/2013/09/660x122-JavaIsCured.jpg http://zeroturnaround.com/wp-content/uploads/2013/09/660x122...
  - pekk 13y ago
    Didn't you hear that all that changed since Twitter switched, and now it rocks more than ever?
- jevinskie 13y ago
  Regarding #1, Java 8 allows for static JNI linking. http://openjdk.java.net/jeps/178 http://openjdk.java.net/jeps/178
  - pron 13y ago
    Cool. Did not know that.
jgalt212 13y ago
All this is only worsened by the ‘black box’ nature of the optimization level switches. Doesn't the JIT do all sorts of crazy stuff that's not always reproducible and thus hard to profile? I know this is the case with V8, but probably also so with Java. I don't know much about compilers, but the author seems to know even less.
- brianpgordon 13y ago
  The author appears to be laboring under the assumption that enabling GCC or Clang optimizations can cause failures in programs, in contrast to Java where the guarantees are rock solid. Of course, this is not true- in both Java and C++ the compiler's optimizations are strictly standard-compliant (at reasonable O levels in GCC) and in both if you rely on undefined behavior then optimizations can break your application. His problem isn't with unreliable optimizers, it's with writing bug-free code. And yes, HotSpot can do tons of stuff, from eliminating virtual method calls, to inlining methods, to deciding whether a wait should be busy or not. And it does become a serious pain to profile, especially when you have code paths which are infrequently hit and so might not be JITed.
  - pkolaczk 13y ago
    Sure, but the number of ways to (accidentally) rely on UB in C++ is order of magnitude higher than in Java.
bcl 13y ago
Oh, shucks. I was expecting to see an article on compiling Java to machine code, not bytecode.
- pjmlp 13y ago
  Just look for a compiler design book. Compiling some form of bytecode into machine code, is part of any compiler design course worth its name.
JasonFruit 13y ago
This article didn't impress me, but from the author's bio sketch I was led to look up the eigenharp, which did.
duedl0r 13y ago
this title makes me giggle.. ok, I know...I'm too lazy to even open this link..
rsynnott 13y ago
> All this is only worsened by the ‘black box’ nature of the optimization level switches. JVM switches like -XX:CMSInitiatingOccupancyFraction=70 -XX:SurvivorRatio=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:NewSize=2048m -XX:MaxNewSize=2048m (taken from real recommended settings for an open-source project) are, of course, not opaque-to-the-average-user at all :)
- kumarm 13y ago
  http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html http://www.oracle.com/technetwork/java/javase/tech/vmoptions... The page existed for over ten years (Under different domains) and countless tutorial and presentations about hotspot covered them.
  - rsynnott 13y ago
    Sure. There is also extensive documentation on what GCC flags do. Neither JVM flags nor GCC flags refer to deep dark secrets.
  - fizx 13y ago
    Also helpful: http://www.slideshare.net/aszegedi/everything-i-ever-learned-about-jvm-performance-tuning-twitter http://www.slideshare.net/aszegedi/everything-i-ever-learned...
- pron 13y ago
  You are right, but newer Java versions have what is called "GC ergonomics": you simply define either a throughput or a latency goal, and the JVM tries to dynamically change the settings until to achieve your goals.
  - fizx 13y ago
    Some applications can be pathological, in which case you are better off setting lower-level flags. For example, Lucene both churns through tons of short-lived strings and tries to maintain caches of large arrays. The memory/gc optimizer handles this very poorly. Between modern Java tending to move caches to unmanaged memory-mapped regions as libraries mature, and the potential of G1 as a concurrent compacting collector, we're on the cusp of not having to worry about any of this anymore.
nness 13y ago
Argh. You can't use Open Sans Light as a body font...
- JasonFruit 13y ago
  For those of us who don't know fonts, can you explain why? I'd like to avoid making a similar mistake, and I wasn't bothered when reading the article.
  - misframer 13y ago
    It's thin and hard to read.
  - joshuacc 13y ago
    Typically any "light" font weight is intended to be used at larger sizes, often as part of headings. Using it as the body font will make your text harder to read unless you're using a very large font size.
  - bhauer 13y ago
    Light fonts are for accents or headers, not for body text. The body text should be normal weight and, in my opinion, should not be #5F5F5F either. That is unnecessarily punitive to the reader. Here is an image comparing the original on the left and a corrected version with black text in a normal weight on the right. Note how much easier the right side is to read. http://i.imgur.com/WMJ8zcG.png http://i.imgur.com/WMJ8zcG.png
sgt 13y ago
Java is rapidly becoming more viable as an alternative to all of these "trendy" languages these days, e.g. Ruby, Python, Go. What I mean by that is simply that a lot of developers are prejudicious against Java due to historically it being slow and having tedious development feedback cycles. We use Java extensively (and Java EE 6) in an agile IT business and it is truly an asset. I encourage others to look in the direction of Java.
- petercooper 13y ago
  One problem of many is that Java is quite verbose, and while IDEs like Eclipse help with this, there's a significant contingent of open source developers who both refuse to use typical IDEs and who also like to manually manipulate their code rather than let an IDE tweak it about. Languages like Ruby and Python make that easily manageable in a way Java doesn't.
  - Styck 13y ago
    This is one of the reasons I use Go in favour of pretty much anything running on the JVM stack. I don't have to change my workflow at all between working in Python, C, Go and JS. I can use vim for all of the above and none of them force me to have years of experience with an IDE in order to be productive.
    - lrobb 13y ago
      You can do that with Scala as well. (or groovy or clojure...)
    - pron 13y ago
      Sure. Go is pretty much a JVM-less Java. To me, it seems the exact wrong things to take from Java. Go takes the language (Go is a simplified Java, with some modern improvements) - which is only OK, but drops the JVM, which is awesome. It does have one advantage over the JVM, which is a much shorter startup time. But Java has better performance and far better monitoring tools (as well as dynamic linking and hot code swapping).
petercooper 13y ago
I'd argue it's more the JVM and its ecosystem that rocks more than ever. Sure, Java is getting better, but it's the JVM and its ecosystem that seem to be impressing people and bringing fresh blood in nowadays.
hakcermani 13y ago
like a university professor, dusting off some old notes for a 'new' lecture. Students are meanwhile doing crazy exciting stuff out there.
- pjmlp 13y ago
  while the university professor earns per month what the students get per year.
moron4hire 13y ago
I rather much thought that "DLL Hell" was a solved problem. I haven't had to worry about DLLs on my Windows box in years, basically since Win2k an XP.
- jebblue 13y ago
  Depends, for some no: http://www.drdobbs.com/windows/no-end-to-dll-hell/227300037 http://www.drdobbs.com/windows/no-end-to-dll-hell/227300037 I think some form exists even in Java, software is hard at times, it's just the nature of a complex computer world that doesn't play by the rules of any other industry.
  - devonkim 13y ago
    Old-school Java programmers are familiar with JAR hell during deployments with simple, naïve classloaders that just pick the first JAR with the desired class in it and don't provide versioned separation and ignore manifest files. The legacy solution is to write your own classloader and to use facades to get the correct class dependencies loaded more or less. JARs with correctly written manifests help but a lot of the Java convention system is not well adhered to even with widespread tool support. It's solved in modern app container based deployments of Java webapps at least.
topbanana 13y ago
A more interesting question is how much other languages rock in comparison to Java. (As I was in the middle of this reply, the Java Auto-Updater popped up and stole my focus!)
waynecochran 13y ago
Note that the debugger (jdb) isn't listed -- for a good reason. I never understood why jdb is so poor being such a critical tool.
- Roboprog 13y ago
  Reason number 1 to get an IDE for Java. Having a working [c/e]-tags replacement would probably be reason 2.
pekk 13y ago
Why Big Band Music Rocks More Than Ever: Part 1 - You Can Dance To It There are still fans of Big Band music! Java fans (or maybe I should say, employers) who want to keep exhuming this dead horse might be well served to emphasize "you can get a job" and "it's enterprise" and "JIT makes Java faster than Assembly" as they have been doing for decades, rather than tarting it up (a Java logo with an electric guitar, seriously Dad?) and comparing it to languages which are even more ancient. Java is closing in on 20 years old...
- pkinsky 13y ago
  More like Why Stadium-Scale Sound Systems Rock (even if you play shit music on them). JVM != Java
  - pron 13y ago
    Oh, absolutely, but even the Java language is quite fine. Even new languages like Go and Dart are essentially modified forms of Java, and Java 8 is a welcome improvements. Those programmers who like the Java gradual-improvement philosophy and find Java 8 lacking, should try Kotlin. Others who want a truly beautiful, elegant and modern language, should try Clojure (and for those who like Haskell but find it too easy, or prefer a truly complicated language with a lot of power but no coherent philosophy whatsoever other than a collection of lots-and-lots of haphazard features – there's Scala ;)).
- this_user 13y ago
  Ruby is 18, Python is 22, what's your point? I'd very much like to hear your valid criticism towards Java. From my point of view that language and ecosystem is alive and well and newer iterations of Java EE have been giant leaps forward in terms of productivity.
  - halostatue 13y ago
    Ruby’s 20. Just FWIW.
  - latk 13y ago
alkonaut 13y ago
I don't know if the whole oracle/sun debacle is to blame for the complete stagnation of the jvm and the java language, but the development pace is laughable these days. We're still waiting for proper lambda expressions after all these years. We still have a runtime without generics. And so on. The irony of the article is that ZeroTurnaround not only make money from the java community, but does so by selling tools that work around shortcomings of the jvm. So not only is it in their interest to have a large dev community on the jvm, if you are a bit mean you could say its in their interest to have a crap jvm :)
- levosmetalo 13y ago
  I never understood what's the big deal about runtime generics. It's clear that some minority of people thinks that it's so important that it's almost the sole reason why "java sucks", but it's just a tradeoff that's decision that is controversial at best, with lots of people being completely happy about that. For lambdas, I agreed though. Also, basic type inference, at least in a form already provided by project Lombok, is still sorely missing.
  - alkonaut 13y ago
    The type erasure is just a bad match with what's essentially a quite weak type system withq few other design flaws in it. Had the type system been good otherwise, it wouldn't have been that bad, but the way java works with for example array covariance and so on makes it a poor design. That, and of course the fact that all AnyCollectionType<T> should work with primitive types without performance penalties. Having to use an MyFancyIntTree rather than MyFancyTeee<int> is a bloody disgrace.
kamaal 13y ago
One of the things I see with Java today, how difficult things have gotten with the language. Its next impossible to deal with any large Java project without an IDE. The verbosity of the code is mind boggling. Often method calls are 4 - 6 layers deep, which in itself makes is very difficult to remember or even implement even if you read the documentation well. The resulting code is massive walls of text. 90% of that is machine generated through eclipse. This is an indication that the language idioms are unable to support the current complexities in application programming trends. And you have to interplay with them heavily to squeeze out usable programming logic. That doesn't end there. Perl is older than Java, yet despite that I see Perl can support a lot of idioms far far better than Java can with its bulky frameworks. Its just that the language is beginning to show its age. The only reason to use Java these days is basically availability of super low cost devs, Legacy code, tooling etc. Basically for reasons as with any tool that has an advantage with age.
- vivin 13y ago
  > Often method calls are 4 - 6 layers deep, which in itself makes is very difficult to remember or even implement even if you read the documentation well. I think that's a symptom of bad design than a problem with the language. The language doesn't force you to create abstractions on top of abstractions and it is not necessary. Having method calls like that is a bad code-smell. Java does have a verbosity problem and some of it being addressed in Java 8 with lambdas. > The resulting code is massive walls of text. 90% of that is machine generated through eclipse. This is an indication that the language idioms are unable to support the current complexities in application programming trends. And you have to interplay with them heavily to squeeze out usable programming logic. I have never had to autogenerate code. I use IntelliJ and it doesn't generate walls of text. It does autogenerate some stuff if you want it to, but those are usually just stubs. > That doesn't end there. Perl is older than Java, yet despite that I see Perl can support a lot of idioms far far better than Java can with its bulky frameworks. Well, Perl is strongly typed and has a rich (and ambiguous) grammar. I don't think it's a fair comparison with Java. Furthermore, Perl has a bunch of other issues. I love Perl, but I wouldn't really think about writing a huge application in Perl; it's usually a maintenance nightmare if you don't have a shop of disciplined Perl-coders. > The only reason to use Java these days is basically availability of super low cost devs, Legacy code, tooling etc. Basically for reasons as with any tool that has an advantage with age. Not really. You can build lots of full-featured webapps with Java and there are a lot of new applications that use Java. What I think is happening more and more though, is that the JVM is turning into a platform and there are numerous languages that run on it. What Java has going for it is its rich ecosystem via core APIs and numerous third-party libraries. You have access to all of this if your language runs on the JVM. For example, Nashorn (the replacement for Rhino) has access to the standard API, as do languages like Jython and JRuby which also run on the JVM.
RivieraKid 13y ago
Java as a language is not that great, but the alternatives are usually even worse: - Python: slow, dynamic typing - Scala: slow compilation, very complex syntax, worse tooling, - C#: MS-centric (but other than that C# is superior to Java)
- eatporktoo 13y ago
  Not sure why you think that C# is MS-centric. There is nothing about the language that is particularly MS or Windows specific and the .Net Framework was written to be general and cross-platform.
  - RivieraKid 13y ago
    My impression was that e.g. support for multiplatform GUIs or Mono's speed wasn't as good as Java.
    - eatporktoo 13y ago
      Mono's speed is a valid point, but I think that's more of a Mono implementation issue than a C# problem.
      - RivieraKid 13y ago
        Yes, C# as a language is without question better than Java but in terms of the whole ecosystem, it's not that clear...
  - pjmlp 13y ago
    Mono does not provide support for some stuff like WPF, for example.
saejox 13y ago
Java is the definition of enterprise level language. Very newbie friendly. It's nice for the newbies but it's verbosity and small set of features kills it for any experienced programmer. Please don't tell me about the fabled Java 8. Google doesn't care about new java versions, so we are stuck with Java 6. Most people will move to other languages until Java 8 gains any traction.
Nekorosu 13y ago
The author forgot to state in his title that he compares Java to C/C++/Objective-C languages (he does state it in the comments though). In this context the article is a joke. Java Rock More Than Ever, my ass! The author compares one old technology to the other old technology using a 10 year old list of features.

104 points by mustapha 13y ago

Beefs with this article: 1. Runtime-linking _is_ dynamic linking, and it's a PITA that Java doesn't have an option for static linking, especially given the inherent fragility of the CLASSPATH. 2. clang and gcc have compatible command-line option syntax. 3. The options example he lists for gcc is a pure strawman. Maybe they are necessary to compile that particular source file, but it is not necessary to use all these options in the average case. 4. The article title says "now more than ever", but there's really nothing about recent developments here. This article could have been written ten years ago. This really just seems like crappy linkbait.

latk 13y ago
Good point(s), especially #4. The article compares an 80s language (C++) to a 90s language (Java), not to more recent compiler toolchains. Admittedly, there aren't many options here, and e.g. Scala (which I hope will be covered in future articles) relies on the java toolchain. Edit: C++ and Java also have different cultures. The simplest compilation with g++ is "g++ foo.cpp -o foo", which isn't much more complex than "javac Foo.java". The fine-grained options clang/g++ give you are part of the “you pay for what you use”-mentality of C++.
- pjmlp 13y ago
  Except there are 70's languages (Modula-2), 80's (Ada) and 90's (Turbo Pascal/Delphi), that offered more powerful compiler toolchains. However, given C++'s requirement to be kept compatible with UNIX toolchain model, we suffer from a 70's model in C++.
th0br0 13y ago
Most importantly, his gcc example is taken from OSX... ugh.
- Roboprog 13y ago
  As the guy says he is writing music software, Mac OSX would be a pretty important platform to cover. That said, I'm a recent convert from Linux to OSX, and I like to tinker with Garbage Band from time to time :-)
gresrun 13y ago
> 1. Runtime-linking _is_ dynamic linking, and it's a PITA that Java doesn't have an option for static linking, especially given the inherent fragility of the CLASSPATH. It is possible to roll a 'fat' JAR with all your dependencies baked-in, which is as close to static linking as it gets in Java-land. I prefer this for stand-alone applications as it makes deployment a cinch at the expense of the size of the build artifact.
- jebblue 13y ago
  Agreed, this is how I do my Java standalones. Eclipse makes this easy with Export | Runnable Jar providing several options for how to package the build.
  - danieldk 13y ago
    The Maven assembly plugin can also do this with the 'jar-with-dependencies' descriptor.
    - gresrun 13y ago
      I personally use the maven-shade-plugin for this because it has built-in support for handling special resource files like licenses, service definitions, and manifest entries.
      - agibsonccc 13y ago
        The maven shade plugin can be dangerous if you hit the zip file limit of 65535 entries. Watch your filters.
- jonstewart 13y ago
  Yeah, I've used jarjar before for this.
- yaeger 13y ago
  I wonder how such a setup would play out in regards to Open Source usage. Say you create a big jar with all dependencies in there in several layers of "lib" folders. Licenses like LGPL say you have to keep the LGPL archive accessible to the user and grant permission for them to alter/update them. Would a nested hierarchy of lib folders inside your jar be viewed as hindrance? Certainly you didn't "hide" the LGPL'd components in order for the user to not alter them but I think it could be viewed as "security through obscurity". If I don't immediately see a component, how do I know its there? I guess this could be solved by a readme that lists in detail what open source components are used and where in the hierarchy they can be found.
diminish 13y ago
Moreover, their own banner ad at the bottom is ironic. "Java is cured, suffering from redeploy madness. Get your cure". http://zeroturnaround.com/wp-content/uploads/2013/09/660x122-JavaIsCured.jpg http://zeroturnaround.com/wp-content/uploads/2013/09/660x122...
- pekk 13y ago
  Didn't you hear that all that changed since Twitter switched, and now it rocks more than ever?
jevinskie 13y ago
Regarding #1, Java 8 allows for static JNI linking. http://openjdk.java.net/jeps/178 http://openjdk.java.net/jeps/178
- pron 13y ago
  Cool. Did not know that.

jgalt212 13y ago

All this is only worsened by the ‘black box’ nature of the optimization level switches. Doesn't the JIT do all sorts of crazy stuff that's not always reproducible and thus hard to profile? I know this is the case with V8, but probably also so with Java. I don't know much about compilers, but the author seems to know even less.

brianpgordon 13y ago
The author appears to be laboring under the assumption that enabling GCC or Clang optimizations can cause failures in programs, in contrast to Java where the guarantees are rock solid. Of course, this is not true- in both Java and C++ the compiler's optimizations are strictly standard-compliant (at reasonable O levels in GCC) and in both if you rely on undefined behavior then optimizations can break your application. His problem isn't with unreliable optimizers, it's with writing bug-free code. And yes, HotSpot can do tons of stuff, from eliminating virtual method calls, to inlining methods, to deciding whether a wait should be busy or not. And it does become a serious pain to profile, especially when you have code paths which are infrequently hit and so might not be JITed.
- pkolaczk 13y ago
  Sure, but the number of ways to (accidentally) rely on UB in C++ is order of magnitude higher than in Java.

bcl 13y ago

Oh, shucks. I was expecting to see an article on compiling Java to machine code, not bytecode.

pjmlp 13y ago
Just look for a compiler design book. Compiling some form of bytecode into machine code, is part of any compiler design course worth its name.

JasonFruit 13y ago

This article didn't impress me, but from the author's bio sketch I was led to look up the eigenharp, which did.

duedl0r 13y ago

this title makes me giggle.. ok, I know...I'm too lazy to even open this link..

rsynnott 13y ago

> All this is only worsened by the ‘black box’ nature of the optimization level switches. JVM switches like -XX:CMSInitiatingOccupancyFraction=70 -XX:SurvivorRatio=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:NewSize=2048m -XX:MaxNewSize=2048m (taken from real recommended settings for an open-source project) are, of course, not opaque-to-the-average-user at all :)

kumarm 13y ago
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html http://www.oracle.com/technetwork/java/javase/tech/vmoptions... The page existed for over ten years (Under different domains) and countless tutorial and presentations about hotspot covered them.
- rsynnott 13y ago
  Sure. There is also extensive documentation on what GCC flags do. Neither JVM flags nor GCC flags refer to deep dark secrets.
- fizx 13y ago
  Also helpful: http://www.slideshare.net/aszegedi/everything-i-ever-learned-about-jvm-performance-tuning-twitter http://www.slideshare.net/aszegedi/everything-i-ever-learned...
pron 13y ago
You are right, but newer Java versions have what is called "GC ergonomics": you simply define either a throughput or a latency goal, and the JVM tries to dynamically change the settings until to achieve your goals.
- fizx 13y ago
  Some applications can be pathological, in which case you are better off setting lower-level flags. For example, Lucene both churns through tons of short-lived strings and tries to maintain caches of large arrays. The memory/gc optimizer handles this very poorly. Between modern Java tending to move caches to unmanaged memory-mapped regions as libraries mature, and the potential of G1 as a concurrent compacting collector, we're on the cusp of not having to worry about any of this anymore.

nness 13y ago

Argh. You can't use Open Sans Light as a body font...

JasonFruit 13y ago
For those of us who don't know fonts, can you explain why? I'd like to avoid making a similar mistake, and I wasn't bothered when reading the article.
- misframer 13y ago
  It's thin and hard to read.
- joshuacc 13y ago
  Typically any "light" font weight is intended to be used at larger sizes, often as part of headings. Using it as the body font will make your text harder to read unless you're using a very large font size.
- bhauer 13y ago
  Light fonts are for accents or headers, not for body text. The body text should be normal weight and, in my opinion, should not be #5F5F5F either. That is unnecessarily punitive to the reader. Here is an image comparing the original on the left and a corrected version with black text in a normal weight on the right. Note how much easier the right side is to read. http://i.imgur.com/WMJ8zcG.png http://i.imgur.com/WMJ8zcG.png

sgt 13y ago

Java is rapidly becoming more viable as an alternative to all of these "trendy" languages these days, e.g. Ruby, Python, Go. What I mean by that is simply that a lot of developers are prejudicious against Java due to historically it being slow and having tedious development feedback cycles. We use Java extensively (and Java EE 6) in an agile IT business and it is truly an asset. I encourage others to look in the direction of Java.

petercooper 13y ago
One problem of many is that Java is quite verbose, and while IDEs like Eclipse help with this, there's a significant contingent of open source developers who both refuse to use typical IDEs and who also like to manually manipulate their code rather than let an IDE tweak it about. Languages like Ruby and Python make that easily manageable in a way Java doesn't.
- Styck 13y ago
  This is one of the reasons I use Go in favour of pretty much anything running on the JVM stack. I don't have to change my workflow at all between working in Python, C, Go and JS. I can use vim for all of the above and none of them force me to have years of experience with an IDE in order to be productive.
  - lrobb 13y ago
    You can do that with Scala as well. (or groovy or clojure...)
  - pron 13y ago
    Sure. Go is pretty much a JVM-less Java. To me, it seems the exact wrong things to take from Java. Go takes the language (Go is a simplified Java, with some modern improvements) - which is only OK, but drops the JVM, which is awesome. It does have one advantage over the JVM, which is a much shorter startup time. But Java has better performance and far better monitoring tools (as well as dynamic linking and hot code swapping).

petercooper 13y ago

I'd argue it's more the JVM and its ecosystem that rocks more than ever. Sure, Java is getting better, but it's the JVM and its ecosystem that seem to be impressing people and bringing fresh blood in nowadays.

hakcermani 13y ago

like a university professor, dusting off some old notes for a 'new' lecture. Students are meanwhile doing crazy exciting stuff out there.

pjmlp 13y ago
while the university professor earns per month what the students get per year.

moron4hire 13y ago

I rather much thought that "DLL Hell" was a solved problem. I haven't had to worry about DLLs on my Windows box in years, basically since Win2k an XP.

jebblue 13y ago
Depends, for some no: http://www.drdobbs.com/windows/no-end-to-dll-hell/227300037 http://www.drdobbs.com/windows/no-end-to-dll-hell/227300037 I think some form exists even in Java, software is hard at times, it's just the nature of a complex computer world that doesn't play by the rules of any other industry.
- devonkim 13y ago
  Old-school Java programmers are familiar with JAR hell during deployments with simple, naïve classloaders that just pick the first JAR with the desired class in it and don't provide versioned separation and ignore manifest files. The legacy solution is to write your own classloader and to use facades to get the correct class dependencies loaded more or less. JARs with correctly written manifests help but a lot of the Java convention system is not well adhered to even with widespread tool support. It's solved in modern app container based deployments of Java webapps at least.

topbanana 13y ago

A more interesting question is how much other languages rock in comparison to Java. (As I was in the middle of this reply, the Java Auto-Updater popped up and stole my focus!)

waynecochran 13y ago

Note that the debugger (jdb) isn't listed -- for a good reason. I never understood why jdb is so poor being such a critical tool.

Roboprog 13y ago
Reason number 1 to get an IDE for Java. Having a working [c/e]-tags replacement would probably be reason 2.

pekk 13y ago

Why Big Band Music Rocks More Than Ever: Part 1 - You Can Dance To It There are still fans of Big Band music! Java fans (or maybe I should say, employers) who want to keep exhuming this dead horse might be well served to emphasize "you can get a job" and "it's enterprise" and "JIT makes Java faster than Assembly" as they have been doing for decades, rather than tarting it up (a Java logo with an electric guitar, seriously Dad?) and comparing it to languages which are even more ancient. Java is closing in on 20 years old...

pkinsky 13y ago
More like Why Stadium-Scale Sound Systems Rock (even if you play shit music on them). JVM != Java
- pron 13y ago
  Oh, absolutely, but even the Java language is quite fine. Even new languages like Go and Dart are essentially modified forms of Java, and Java 8 is a welcome improvements. Those programmers who like the Java gradual-improvement philosophy and find Java 8 lacking, should try Kotlin. Others who want a truly beautiful, elegant and modern language, should try Clojure (and for those who like Haskell but find it too easy, or prefer a truly complicated language with a lot of power but no coherent philosophy whatsoever other than a collection of lots-and-lots of haphazard features – there's Scala ;)).
this_user 13y ago
Ruby is 18, Python is 22, what's your point? I'd very much like to hear your valid criticism towards Java. From my point of view that language and ecosystem is alive and well and newer iterations of Java EE have been giant leaps forward in terms of productivity.
- halostatue 13y ago
  Ruby’s 20. Just FWIW.
- latk 13y ago

alkonaut 13y ago

I don't know if the whole oracle/sun debacle is to blame for the complete stagnation of the jvm and the java language, but the development pace is laughable these days. We're still waiting for proper lambda expressions after all these years. We still have a runtime without generics. And so on. The irony of the article is that ZeroTurnaround not only make money from the java community, but does so by selling tools that work around shortcomings of the jvm. So not only is it in their interest to have a large dev community on the jvm, if you are a bit mean you could say its in their interest to have a crap jvm :)

levosmetalo 13y ago
I never understood what's the big deal about runtime generics. It's clear that some minority of people thinks that it's so important that it's almost the sole reason why "java sucks", but it's just a tradeoff that's decision that is controversial at best, with lots of people being completely happy about that. For lambdas, I agreed though. Also, basic type inference, at least in a form already provided by project Lombok, is still sorely missing.
- alkonaut 13y ago
  The type erasure is just a bad match with what's essentially a quite weak type system withq few other design flaws in it. Had the type system been good otherwise, it wouldn't have been that bad, but the way java works with for example array covariance and so on makes it a poor design. That, and of course the fact that all AnyCollectionType<T> should work with primitive types without performance penalties. Having to use an MyFancyIntTree rather than MyFancyTeee<int> is a bloody disgrace.

kamaal 13y ago

One of the things I see with Java today, how difficult things have gotten with the language. Its next impossible to deal with any large Java project without an IDE. The verbosity of the code is mind boggling. Often method calls are 4 - 6 layers deep, which in itself makes is very difficult to remember or even implement even if you read the documentation well. The resulting code is massive walls of text. 90% of that is machine generated through eclipse. This is an indication that the language idioms are unable to support the current complexities in application programming trends. And you have to interplay with them heavily to squeeze out usable programming logic. That doesn't end there. Perl is older than Java, yet despite that I see Perl can support a lot of idioms far far better than Java can with its bulky frameworks. Its just that the language is beginning to show its age. The only reason to use Java these days is basically availability of super low cost devs, Legacy code, tooling etc. Basically for reasons as with any tool that has an advantage with age.

vivin 13y ago
> Often method calls are 4 - 6 layers deep, which in itself makes is very difficult to remember or even implement even if you read the documentation well. I think that's a symptom of bad design than a problem with the language. The language doesn't force you to create abstractions on top of abstractions and it is not necessary. Having method calls like that is a bad code-smell. Java does have a verbosity problem and some of it being addressed in Java 8 with lambdas. > The resulting code is massive walls of text. 90% of that is machine generated through eclipse. This is an indication that the language idioms are unable to support the current complexities in application programming trends. And you have to interplay with them heavily to squeeze out usable programming logic. I have never had to autogenerate code. I use IntelliJ and it doesn't generate walls of text. It does autogenerate some stuff if you want it to, but those are usually just stubs. > That doesn't end there. Perl is older than Java, yet despite that I see Perl can support a lot of idioms far far better than Java can with its bulky frameworks. Well, Perl is strongly typed and has a rich (and ambiguous) grammar. I don't think it's a fair comparison with Java. Furthermore, Perl has a bunch of other issues. I love Perl, but I wouldn't really think about writing a huge application in Perl; it's usually a maintenance nightmare if you don't have a shop of disciplined Perl-coders. > The only reason to use Java these days is basically availability of super low cost devs, Legacy code, tooling etc. Basically for reasons as with any tool that has an advantage with age. Not really. You can build lots of full-featured webapps with Java and there are a lot of new applications that use Java. What I think is happening more and more though, is that the JVM is turning into a platform and there are numerous languages that run on it. What Java has going for it is its rich ecosystem via core APIs and numerous third-party libraries. You have access to all of this if your language runs on the JVM. For example, Nashorn (the replacement for Rhino) has access to the standard API, as do languages like Jython and JRuby which also run on the JVM.

RivieraKid 13y ago

Java as a language is not that great, but the alternatives are usually even worse: - Python: slow, dynamic typing - Scala: slow compilation, very complex syntax, worse tooling, - C#: MS-centric (but other than that C# is superior to Java)

eatporktoo 13y ago
Not sure why you think that C# is MS-centric. There is nothing about the language that is particularly MS or Windows specific and the .Net Framework was written to be general and cross-platform.
- RivieraKid 13y ago
  My impression was that e.g. support for multiplatform GUIs or Mono's speed wasn't as good as Java.
  - eatporktoo 13y ago
    Mono's speed is a valid point, but I think that's more of a Mono implementation issue than a C# problem.
    - RivieraKid 13y ago
      Yes, C# as a language is without question better than Java but in terms of the whole ecosystem, it's not that clear...
- pjmlp 13y ago
  Mono does not provide support for some stuff like WPF, for example.

saejox 13y ago

Java is the definition of enterprise level language. Very newbie friendly. It's nice for the newbies but it's verbosity and small set of features kills it for any experienced programmer. Please don't tell me about the fabled Java 8. Google doesn't care about new java versions, so we are stuck with Java 6. Most people will move to other languages until Java 8 gains any traction.

Nekorosu 13y ago

The author forgot to state in his title that he compares Java to C/C++/Objective-C languages (he does state it in the comments though). In this context the article is a joke. Java Rock More Than Ever, my ass! The author compares one old technology to the other old technology using a 10 year old list of features.