
Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler - mustapha
http://zeroturnaround.com/rebellabs/10-reasons-why-java-now-rocks-more-than-ever-part-1-the-java-compiler/
======
jonstewart
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.

~~~
gresrun
> 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
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
The Maven assembly plugin can also do this with the 'jar-with-dependencies'
descriptor.

~~~
gresrun
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
The maven shade plugin can be dangerous if you hit the zip file limit of 65535
entries. Watch your filters.

------
rsynnott
> 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
[http://www.oracle.com/technetwork/java/javase/tech/vmoptions...](http://www.oracle.com/technetwork/java/javase/tech/vmoptions-
jsp-140102.html)

The page existed for over ten years (Under different domains) and countless
tutorial and presentations about hotspot covered them.

~~~
rsynnott
Sure. There is also extensive documentation on what GCC flags do. Neither JVM
flags nor GCC flags refer to deep dark secrets.

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

~~~
alayne
The 20-50x performance tradeoff is a hard pill to swallow though. I'd love to
see a better performing dynamic language that isn't as minimal as Lua.

~~~
PuercoPop
It is called Common Lisp

~~~
pron
Or Clojure.

~~~
pjmlp
Common Lisp has the advantage of having native code compilers available.

On the other hand, it suffers from not having a big ecosystem.

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

~~~
marcioaguiar
It's impossible to deal with ANY LARGE PROJECT without an IDE.

If you don't use an IDE, your project is not large yet.

~~~
apw
Would you call the Linux kernel a large project?

~~~
pekk
It is not enterprise enough. If it used Java EE then it would really scale,
like a stadium sound system.

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

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

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

~~~
latk
Java isn't a bad language, but the point is that it doesn't offer much what
other languages don't. It's unique selling point is that it is there, and that
it's widespread.

Said politely, Java is “conservative” to include new features. Take for
example lambdas, which make writing async code, inversion of control, and yes,
functional programming _much_ more easy. All modern competitors to Java have
lambdas: C++11 and C# (LINQ! need I say more?), plus basically everything
except C. Java 8 has still to ship. A more flexible object system, e.g. using
traits, would not be impossible to implement, but I doubt this will show up
before C++ has them ;-)

Ecosystem? Well, that is a good argument, but other languages have ecosystems
as well.

~~~
pjmlp
Well, interfaces with default methods in Java 8 are a form of traits.

------
jgalt212
_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
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
Sure, but the number of ways to (accidentally) rely on UB in C++ is order of
magnitude higher than in Java.

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

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

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

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

------
topbanana
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!)

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

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

~~~
bhauer
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)

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

~~~
pjmlp
while the university professor earns per month what the students get per year.

------
waynecochran
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
Reason number 1 to get an IDE for Java. Having a working [c/e]-tags
replacement would probably be reason 2.

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

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

------
RivieraKid
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
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
My impression was that e.g. support for multiplatform GUIs or Mono's speed
wasn't as good as Java.

~~~
eatporktoo
Mono's speed is a valid point, but I think that's more of a Mono
implementation issue than a C# problem.

~~~
RivieraKid
Yes, C# as a language is without question better than Java but in terms of the
whole ecosystem, it's not that clear...

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

