
Reasons to be excited about Java in 2013 - eranation
http://jaxenter.com/5-reasons-to-be-excited-about-java-in-2013-45938.html
======
biesnecker
Reasons to be excited about Java in 2013: scala, clojure, jruby, groovy, ...

~~~
ExpiredLink
... which no serious developer will use. Not in 2013, not later.

~~~
thebluesky
I can't speak to the other languages, but Scala is definitely being used
pretty heavily in a number of pretty major back-end systems for stock trading,
cloud computing, banking and successful startups like Twitter, Foursquare,
Tumblr, Quora etc.

~~~
dasil003
I think by "serious" the GP must have meant literally serious developers, such
as those working in huge corporate body shops who are prevented from not being
serious by strict regiment. Certainly management in such environs would
consider authorization to use any more expressive language than Java as
tantamount to handing out dynamite on Halloween.

~~~
ExpiredLink
I can understand that esp. young developers get bored and want to try
something new and fancy. OTOH, JRuby and Groovy are, at best, niche languages
without traction. The drawbacks of Scala have been discussed widely, also here
on hn. Clojure? How many Hickey fans actually write real-world programs?

~~~
thebluesky
Many of the folks using Scala are experienced Java developers, your posts seem
to be based on personal speculation rather than actual facts.

------
nnq
Question (maybe stupid, not a Java guy nowadays...): will bytecode coming from
code using Java 8 features be runable on older VMs? Or, to put it otherwise,
are new features like lambdas just syntactic sugar / compiler sugar, or have
they significantly changed the bytecode and VM to make them work?

~~~
guard-of-terra
They add new instructions with each release so the bytecode is not backwards
compatible. But it does not matter much because most of jvm code is deployed
on the server, and the rest is delivered with bundled jvm.

However, you can have compiler generate lower version bytecode for you. If you
have a Java 8 compiler but want Java 1.4 bytecode - no problem, just ask
compiler to target 1.4. It will warn you if you use any >1.4 features. Maybe
it will even let you use lambdas (maybe not, I'm not sure).

Java is very backwards compatible. That's why it progresses so slowly perhaps.

~~~
ZoFreX
Bytecode is not made incompatible with every release, actually - for example
the generics added in 1.5 use type erasure, and so are a compile-time-only
feature, leaving the bytecode still compatible with 1.4 JVMs.

~~~
guard-of-terra
You're confusing JVM versions with Java versions. A JVM class compiled for JVM
6 target will not run under JVM 1.4. It will fail to load because of version
mismatch.

However, you can use Java 6 compiler to compile Java 6 code to JVM 1.4
bytecode. That's what you are talking about.

~~~
ZoFreX
Yes, I am. I got confused over what you meant by " It will warn you if you use
any >1.4 features" - I thought you meant language >1.4, not bytecode spec
>1.4. Thanks for setting me straight :)

~~~
guard-of-terra
I actually meant "language features that require bytecode spec >1.4". Varargs
and enums perhaps?

------
va9
JVM is definetly going to be exciting just not because of Java but all other
JVM languages.

~~~
mitchty
Yep, in a way the jvm is doing the one thing that native platforms haven't.
That is provide a universal (in java land at least) interface in java bytecode
to languages running within the jvm.

Think about the ffi annoyances with c->c++->other-lang, its so simple in jruby
to use clojure libraries, or rhino for some other stuff, or vice-versa, or
whatever.

And I'm not a java fanboy, but that fundamental aspect of the jvm as a
platform is crazy cool.

~~~
bitwize
The same is true of Mono/.NET as well; in fact the CLR was designed for this
and has features the JVM lacks, such as parametric types, invokedynamic, tail
calls, etc.

If you're into functional programming the CLR is the runtime to beat.

~~~
WildUtah
_CLR is the runtime to beat_

Except it doesn't run on any useful platforms. Java makes the effort to be
consistent and good on a wide variety of quality systems.

~~~
jiggy2011
I think MS missed a beat here, if they had pushed for the .Net CLR to be a
first class and equal citizen on OS X , iOS and Linux they would probably be
in a much more relevant position in the future.

~~~
YeahKIA
Its an open spec that can be implemented on any other platform that cares.
Mono is available on many platforms btw

~~~
shadowmint
It's rubbish though.

Not the mono runtime; the fact that there are two runtimes.

The official MS one, and the Mono one, and although they're kind of
compatible, in that your C# can be compiled to run on either of them (mostly,
sometimes, if you haven't done anything fancy, if you're not using MVC, if
you're not using a UI layer that isn't portable, if the version of mono you're
using from A is the same as from B ( >_> unity...) ), this is _FAR_ away from
the java JVM, where you can ship an application that just runs on all the
platforms.

Don't get me wrong, you can do that with C# too... if you use Mono only, and
flip off the official M$oft .Net runtime.

...but the mono runtime is behind the curve, always playing catchup to the
'official' runtime, supporting a subset of the features, and everywhere runs
different versions of the mono runtime. It's a mess.

You've got to admit, the JVM is 100% superior in this regard.

~~~
sk5t
I suppose you've never had a problem with two JVMs that ran a package but
didn't behave quite the same way, to disastrous effect? Or dealt with software
that only worked with one very specific version of the JRE that was exclusive
from the equally specific JRE required by another bit of software?

To compare Mono to the MSFT CLR and call it rubbish by way of contrast to
Java-land strikes me as hilarious. I'll choose .NET every time given that
choice...

~~~
pretoriusB
> _I suppose you've never had a problem with two JVMs that ran a package but
> didn't behave quite the same way, to disastrous effect?_

No, never.

You mean two different JVMs, from different vendors? Who uses those anymore?

~~~
jiggy2011
Well there's weirdness between Oracle and OpenJDK, thought to be fair I
haven't had a problem with OpenJDF for a while. I don't imagine it's that
unusual to find a server running Oracle JVM though.

~~~
thebluesky
In all seriousness most Java devs. regard the OpenJDK package as "that weird
jvm that comes with the OS that nobody actually uses". First thing we do is
download the latest JDK from Sunoracle.

~~~
drivebyacct2
What? That's not true. "Most Java devs" (that I know) prefer Linux and
primarily utilize OpenJDK for development. (Deployment is a mess left to other
people).

Really? No one uses Linux? _And you're talking about Java and JVMs?_ That just
looks silly.

~~~
thebluesky
I only develop on Linux, think you got confused by the way I phrased it. I
meant that hardly anyone uses the OpenJDK package, not that hardly anyone uses
Linux.

------
joshAg
Can someone who knows more explain how java will do gpgpu? Is it going to make
the jvm runnable on a gpu, or are they going to do something like compiling
jvm byte-code to C/++/assembler code that will handle all the memory
management it takes to run code on the gpu?

~~~
seanmcdirmid
They could always do some fancy operating overloading to produce expression
trees that are then converted into GPU codelike I did in this C# library I
made a while ago (basically, call it a staged embedded DSL):

<http://bling.codeplex.com/>

The idea works well for functional code (what pixel and vertex shaders
basically are) but it doesn't really map well to more imperative GPGPU code.

------
DaNmarner
If "JVM languages go from strength to strength" is a reason to get excited
about Java in 2013, should I be already excited in 2012?

~~~
finnw
Yes, but you will need a time machine

------
buzaga2
exciting if you're still a Java developer, right?

Java getting lambdas is cool, I'd be excited if I still was a Java
Developer... but it's like at least 3 years I'm using lambda functions
everywhere else, almost all the other reasons sound like old news too... "Java
now is 'cloud'!", really?

------
bulgroz
What about the memory wall ? being limited to few gigs because of the GC stop-
of-the-world is not very exciting.

------
caycep
how much is all of this tied to Oracle? is openjre and other non-oracle jvms
ready for prime time?

------
camus
About the JVM not the language ...

