

Is Java the platform of the future? - suprgeek
http://markclittle.blogspot.co.uk/2012/02/is-java-platform-of-future.html

======
tomp
No. It has a flawed concurrency model. Heap objects have too much overhead.
Poor support for functional programming. Not open source.

Except for a major redesign of the JVM (is that still Java?), it's a
dying/stagnating platform.

~~~
smanek
I think Java is a pretty bad language, but most of your points are provably
wrong. You're either grossly misinformed (some of what you say was true about
a decade ago, but hasn't been since around the 1.5 release in ~'04) or
purposefully spreading lies.

You're factually wrong about the open-source thing: the primary impl of Java
is open source (<http://hg.openjdk.java.net/jdk7u/jdk7u>). Sure, some impls
like Azul might not be - but that's the joy of an Open language with a real
spec, anyone can write an impl under any license they choose.

The claim that Objects have 'too much' overhead is subjective - but also
basically wrong. Generally Objects in Java have 8 bytes of straight book-
keeping overhead, plus padding to get the size of the fields to the nearest
multiple of 8 bytes. That's expensive relative to C, but cheap compared to
almost any other object oriented, GCd language (and can often be avoided via
primitives, escape analysis, etc). For reference, CPython (the main Python
impl) has ~30 bytes of overhead on an Int between tag bits, book keeping, etc
last time I investigated.

How do you think the Java concurrency model is flawed? Almost any concurrency
model I can think of, from Erlang-style message passing (see: Akka) to the new
Fork/Join framework can be implemented in Java since its concurrency
primitives are complete. I've even done basic impls of STM on AtomicRefs.
Frankly, Java has one of the better defined and fine-grained concurrency
models I know of. C++ just got a well-defined memory model in the '11 standard
IIRC (vs '04 for the JVM).

I'm with you on the functional programming thing - syntax on anonymous inner
classes and a lack of type inference make it way too verbose. But it's
(largely) fixed via Project Lambda in Java 8. And, in the meantime, there are
plenty of great JVM languages (Scala, Clojure, etc) with better support.

~~~
tomp
Hm... I'm not trying to argue with you, you're right that I only have a
superficial overview of the Java/JVM/J2EE ecosystem, but I will try to
elaborate on the points of my original post, which was rather sparse, I admit.

As I read Wikipedia, HotSpot is opensource. I'm not sure if that includes the
best JIT compiler (what the JVM is known for) as well, or if that's still
closed/proprietary, but I'd be pleasantly surprised if it's open source as
well. Still, we have the patents issue, i.e. the current legal battle between
Google and Oracle. Releasing the source but suing anyone who uses it is not
the way to do open source, IMGO (true, the source was release by Sun, and
Oracle is the one who's suing, but still).

I believe that a general purpose programming language (suitable for business
applications) has to be able to perform as well as C for heavily optimized
code. What I mean is that you have to be able to write algorithms that run
very fast. You can probably do that with C# (supports unboxed structs) and
maybe even Objective-C (supports MemoryPools, and method lookup caching), but
not Java (AFAIK). Sure, you can always link to external C libraries, but then
you have to face dependency hell and portability issues.

The issue that I see with Java's concurrency model is not that it is not
powerful enough, but that it is _too_ powerful. It allows synchronization on
any heap-allocated object, which probably has a lot of overhead (used to be
performance overhead, but HotSpot was heavily optimized for that, so after a
lot of programmer-hours overhead, the performance overhead was lowered).
However, I think that this kind of threading model is not scalable to
massively parallel/distributed environments. Synchronization/sharing will have
to be limited, e.g. as in Erlang/WebWorkers/Rust, using GCD in Objective-C,
using MVar (Haskell) or transactional variables (Clojure). Java probably can
never do that, without sacrificing backwards compatibility.

Lack of support for functional programming was meant more on the JVM level.
There are no tail calls, no fast object allocation, no true polymorphism, and
I'm guessing that since closures have to be represented as objects, they are
not particularly cheap.

~~~
smanek
Hotspot is the most commonly used JVM impl I was referring to. Last I looked
into it (probably a year ago), some of the graphics libraries it includes
weren't open source - but everything important (including the JIT) is.

The patent issues are regarding Dalvik AFAIK, so I don't see how it's relevant
to this discussion ... (although, from what I've heard, it seems like Oracle's
being a jerk ...)

If you think that a general purpose language has to be able perform as well as
C without calling native code (JNI, FFI, etc), I guess I'd have to agree Java
isn't 'general purpose' . But I'd contend neither are Python, Ruby, Erlang,
Javascript, etc under that definition. Therefore, that's probably not the
right definition, since it excludes most general purpose languages ;-)

Being able to synchronize on any object is actually really efficiently
implemented (8 bytes of Object overhead total, neat optimizations like biased
locking, etc). And, if you don't want to share state between threads, Java can
do pretty clean actors/message passing
(<http://doc.akka.io/docs/akka/2.0/java/untyped-actors.html>) or transactional
variables (AtomicRefs are built in). Java concurrency _does_ give you the
ability to shoot yourself in the foot if you use it wrong, but so will any
sufficiently powerful tool.

Re the JVMs support for FP:

\- JVM7 added an InvokeDynamic instruction which I believe addresses your
polymorphism concerns.

\- It sucks that there isn't a bytecode instruction to allow TCO. But, in
practice, many JVM languages will convert recursion to iteration at compile
time with constructs like
[http://clojure.org/special_forms#Special%20Forms--(recur%20e...](http://clojure.org/special_forms#Special%20Forms--\(recur%20exprs*\))

\- What do you mean by 'fast object allocation'? I'm not familiar with the
term ... Creating objects is fairly fast in Java though. A quick test suggests
I can alloc around 200 million objects per second on the heap once the code
path is JIT'd on my laptop. Incidentally, it's surprisingly tricky to fool the
JVMs escape analysis and force a heap (not stack) allocation, without
introducing too much extra work in a microbenchmark ;-).

\- AFAIK, you're right that closures require an object allocation - but how
else would you do it? When I was writing Common Lisp, we had to avoid creating
closures in tight loops for the same reason

~~~
gtani
I checked (FMI, For My Info, the non-open pieces are the launcher, Iced Trea
vs. javaWS, and fonts which are replaced by FreeType in OpenJDK

[http://www.reddit.com/r/scala/comments/m1dks/poor_performanc...](http://www.reddit.com/r/scala/comments/m1dks/poor_performance_and_high_memory_usage_make_sure/)

------
lukeholder
does the author maybe mean JVM is the future? good video on the subject:
[http://www.confreaks.com/videos/684-rubyconf2011-jruby-
polyg...](http://www.confreaks.com/videos/684-rubyconf2011-jruby-polyglot-
heaven)

------
AlexFromBelgium
I can't seem to find it, but I read an article about a compiler that brings
another language to the python virtual machine!! "Is Python the platform of
the future?"

EDIT: here's a language running on rubinius (a ruby VM)
<http://rubini.us/2011/02/23/introduction-to-fancy/>

------
dirkdk
maybe. The virtual machine makes it possible to develop completely different
languages like Scala and compile into Java bytecode. Play does a decent job of
rivaling Ruby on Rails in productivity, but it is still Java no Ruby. JRuby?

ah, and as java on the desktop has been dead for a couple of years, I think
security holes are a minor issue. We've got firewalls for that!

------
darklajid
I believe that the JVM might be 'the future'. Java the language gets too much
bad press in our community, but isn't really bad. Just slow to change to suit
our trends of the month/year by now.

That said and rather meta: That blog had the most mobile friendly layout I
encountered so far.

~~~
soc88
> but isn't really bad

I keep hearing this from PHP people, too. :-) Yes, it is not as bad as PHP,
but probably just 15 years behind modern language design.

------
lancelotj
Don't forget Java has a bunch of patents associated, and you will get sued by
Oracle if you implement JRE yourself like google.

------
Radzell
Java is still the most used language in the world
[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html).
It used on the web, mobile, and desktop. Java problem can be fix and have made
strides to modernize like the play framework which modernizes a lot of the
things in Java to make it work more like typical web frameworks. Not to
mention android which is done in Java which is the most widely used mobile
platform. How can a language thats being used more than ever be dying to
languages who can crack the top ten most used programming languages.

~~~
bromagosa
While I agree Java is used everywhere, I think the reasons are very similar to
why VHS was much more popular than BETA, or why COBOL still represents a
_HUGE_ share in programming language usage. Javascript is also used in the
web, mobile and desktop. I see the latter much better suited for the future.

~~~
Radzell
Javascript from my experience is just a bad language. I know that just like
objective-c and java aren't going away on desktop or mobile because the
underpin a lot of the tech that runs those platforms despite javascript may be
running on top. Html 5 needs to fully conquer the web anyway before taking
mobile and desktop on which won't be one for a while.

------
robwgibbons
Sure hope not.

