Live data from Hacker News

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

zeroturnaround.com

1–10 of 149 posts

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

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

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

#3

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…

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

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

#4

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…

Most importantly, his gcc example is taken from OSX... ugh.

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

#5

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…

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

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

#6

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…

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

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

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

Post reply on HN