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.
> 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.
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++.
> 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 :)
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.
By the way, I'm not complaining about Java here. I _like_ Java (or at least I like the JVM; the language is something one puts up with, or sometimes not, for the JVM). I just don't think it's terribly fair to say that c compilers require all these arcane options for performance, without noting that JVMs have their own just-as-arcane (or maybe moreso; garbage collection is harder to wrap your head around than compiler optimisation, and can hurt you more) options which are required for performance.
If you're using the new G1 collector which ships in JDK 7, the only configuration parameters you really need to care about are the minimum and maximum heap sizes (-Xms and -Xmx) and perhaps the latency target (-XX:MaxGCPauseMillis).
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.
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.
As a Java and Clojure developer, I wholeheartedly agree, but your premise suffers from HN/GitHub bias. The amount of software written in Java (and you can add other JVM languages too), both in terms of developers as well as total features worldwide handily dwarfs Ruby and Python combined, possibly ten times over.
Just to get a sense for this bias, consider that IBM alone employs more than the number of employees in Google, Facebook and Twitter combined, multiplied by 9. If you add banks' huge IT departments, defense companies and more, you'll find that the entire Web software ecosystem is on the order of a few percents of the entire software industry.
What I like most about Java is that you can switch more easily to certain fashionable languages (Scala and Clojure) which have good interopability with Java because they use the JVM.
Counterpoints:
Couldn't find any data on how well Clojure works with Java apps.
Scala's decent interoperability appears to stem from a Maven plugin rather than directly from its ability to use the JVM.
Convention over configuration, scaffolding similar to RoR (or better with Forge) and advanced meta-programming via annotations have reduced the effort to produce CRUD applications to a level similar to the trendy languages and frameworks.
While J2EE was painful (10 interfaces and classes for some Entitys), JavaEE is fun to work with and (for the most part) intuitive as it's focused on POJOs and includes DI (CDI). Now I focus on my business logic, and let the rest of the pieces fall into place naturally!
Nobody has ever used Ruby because he thought it might be faster than Java. Java primarily competes against C++, not against “scripting” languages like Ruby and Python which have significantly shorter edit-(compile)-run cycles. Each of these languages also have unique features that are difficult or cumbersome to model in Java (functional programming, metaprogramming, modern object systems).
I do not doubt that there can be cases where a transition like Python → Java can make sense, but it would be silly to assume this would generally be a good idea.
This. Java's syntax and core API is pretty much stable compared to the hot languages championed by so many HN readers. Updating applications written with the "hipster languages" is like pulling teeth. It has a serious impact on an application's maintainability when the language's core API is constantly changing.
Have you ever programmed anything substantial using java outside the enterprise/agile IT environment? Any type of project on your own time? Have you every built anything in Ruby, Python, or Go? I'm asking to try to discern what you mean by "more viable".
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.
> 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.
> Its next impossible to deal with any large Java project without an IDE
True, but I don't see it as a problem (for me).
> The verbosity of the code is mind boggling.
I don't find Java that verbose (especially with lambda functions in Java 8).
> method calls are 4 - 6 layers deep
I don't understand, do you mean nested method calls?
> 90% of that is machine generated through eclipse.
Definitely not 90% and lot of the generated code would have to be written manually in languages like Python.
> The only reason to use Java these days is ...
Libraries, tools, speed, multiplatformity. Also, Java is a pretty good language by itself. It lacks in many ways, but for a LOT of projects, it's a great choice. What language would you suggest as a Java alternative?
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.
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...
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.
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.
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 :)
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.
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.
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.
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.
[+] [-] jonstewart|12 years ago|reply
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.
[+] [-] gresrun|12 years ago|reply
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.
[+] [-] latk|12 years ago|reply
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++.
[+] [-] jevinskie|12 years ago|reply
[+] [-] diminish|12 years ago|reply
http://zeroturnaround.com/wp-content/uploads/2013/09/660x122...
[+] [-] th0br0|12 years ago|reply
[+] [-] rsynnott|12 years ago|reply
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|12 years ago|reply
The page existed for over ten years (Under different domains) and countless tutorial and presentations about hotspot covered them.
[+] [-] pron|12 years ago|reply
[+] [-] rsynnott|12 years ago|reply
[+] [-] sluukkonen|12 years ago|reply
So it's not all bad.
[+] [-] agibsonccc|12 years ago|reply
Higher throughput when you have lots of short lived objects.
[+] [-] sgt|12 years ago|reply
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|12 years ago|reply
[+] [-] pron|12 years ago|reply
Just to get a sense for this bias, consider that IBM alone employs more than the number of employees in Google, Facebook and Twitter combined, multiplied by 9. If you add banks' huge IT departments, defense companies and more, you'll find that the entire Web software ecosystem is on the order of a few percents of the entire software industry.
[+] [-] James_Duval|12 years ago|reply
Sources for this claim: http://www.slideshare.net/tackers/how-we-mostly-moved-from-j... http://java.dzone.com/articles/moving-java-scala-one-year
Counterpoints: Couldn't find any data on how well Clojure works with Java apps. Scala's decent interoperability appears to stem from a Maven plugin rather than directly from its ability to use the JVM.
[+] [-] smoyer|12 years ago|reply
Convention over configuration, scaffolding similar to RoR (or better with Forge) and advanced meta-programming via annotations have reduced the effort to produce CRUD applications to a level similar to the trendy languages and frameworks.
While J2EE was painful (10 interfaces and classes for some Entitys), JavaEE is fun to work with and (for the most part) intuitive as it's focused on POJOs and includes DI (CDI). Now I focus on my business logic, and let the rest of the pieces fall into place naturally!
[+] [-] latk|12 years ago|reply
I do not doubt that there can be cases where a transition like Python → Java can make sense, but it would be silly to assume this would generally be a good idea.
[+] [-] trailfox|12 years ago|reply
[+] [-] abvdasker|12 years ago|reply
[+] [-] ReverendBayes|12 years ago|reply
[+] [-] pekk|12 years ago|reply
It's not prejudice when it is true.
[+] [-] saosebastiao|12 years ago|reply
[+] [-] kamaal|12 years ago|reply
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|12 years ago|reply
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|12 years ago|reply
True, but I don't see it as a problem (for me).
> The verbosity of the code is mind boggling.
I don't find Java that verbose (especially with lambda functions in Java 8).
> method calls are 4 - 6 layers deep
I don't understand, do you mean nested method calls?
> 90% of that is machine generated through eclipse.
Definitely not 90% and lot of the generated code would have to be written manually in languages like Python.
> The only reason to use Java these days is ...
Libraries, tools, speed, multiplatformity. Also, Java is a pretty good language by itself. It lacks in many ways, but for a LOT of projects, it's a great choice. What language would you suggest as a Java alternative?
> super low cost devs
Java devs are among the most expensive.
[+] [-] marcioaguiar|12 years ago|reply
If you don't use an IDE, your project is not large yet.
[+] [-] rsynnott|12 years ago|reply
This is hardly the fault of the language, more of the community, which tends to fetishise certain patterns a bit.
[+] [-] petercooper|12 years ago|reply
[+] [-] pekk|12 years ago|reply
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...
[+] [-] this_user|12 years ago|reply
[+] [-] pkinsky|12 years ago|reply
JVM != Java
[+] [-] jgalt212|12 years ago|reply
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.
[+] [-] alkonaut|12 years ago|reply
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|12 years ago|reply
For lambdas, I agreed though. Also, basic type inference, at least in a form already provided by project Lombok, is still sorely missing.
[+] [-] JasonFruit|12 years ago|reply
[+] [-] moron4hire|12 years ago|reply
[+] [-] jebblue|12 years ago|reply
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.
[+] [-] saejox|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] topbanana|12 years ago|reply
(As I was in the middle of this reply, the Java Auto-Updater popped up and stole my focus!)
[+] [-] nness|12 years ago|reply
[+] [-] JasonFruit|12 years ago|reply
[+] [-] hakcermani|12 years ago|reply
[+] [-] pjmlp|12 years ago|reply
[+] [-] waynecochran|12 years ago|reply
[+] [-] bcl|12 years ago|reply
[+] [-] pjmlp|12 years ago|reply
Compiling some form of bytecode into machine code, is part of any compiler design course worth its name.
[+] [-] RivieraKid|12 years ago|reply
- Python: slow, dynamic typing
- Scala: slow compilation, very complex syntax, worse tooling,
- C#: MS-centric (but other than that C# is superior to Java)
[+] [-] duedl0r|12 years ago|reply