Reasons to be excited about Java in 2013(jaxenter.com)
jaxenter.com
Reasons to be excited about Java in 2013
http://jaxenter.com/5-reasons-to-be-excited-about-java-in-2013-45938.html
9 comments
Reasons to be excited about Java in 2013: scala, clojure, jruby, groovy, ...
My thoughts exactly. Scala seems to be the JVM language gaining the most traction at the moment. The JVM is an extremely impressive piece of engineering. Very reliable, great tooling and it's the fastest VM out there for any language.
After 17 years of Java the language many Java devs. have built up skills around the JVM and java class libraries. Many of us are now looking for a more modern language which lets us leverage our existing knowledge. Scala + friends are pretty hard to ignore these days.
After 17 years of Java the language many Java devs. have built up skills around the JVM and java class libraries. Many of us are now looking for a more modern language which lets us leverage our existing knowledge. Scala + friends are pretty hard to ignore these days.
> Very reliable, great tooling and it's the fastest VM out there for any language.
The JVM also has a very rich open source ecosystem. If your language-of-choice runs on the JVM, very likely you can leverage any Java-based library right out of the box.
The JVM also has a very rich open source ecosystem. If your language-of-choice runs on the JVM, very likely you can leverage any Java-based library right out of the box.
... which no serious developer will use. Not in 2013, not later.
Absolutely ridiculous comment. You added nothing to the discussion and gave no justification for a frankly ignorant standpoint. I can speak for two of them: JRuby is an absolute godsend even if you aren't massively interested in Ruby - Java libraries/classes + a REPL is a phenomenally powerful combination and makes learning new libraries incredibly easy. Groovy I am not a fan of for significant development, but it's great for DSLs, and in particular gradle is the nicest way I've found to manage dependencies and project setup.
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.
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.
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?
Many of the folks using Scala are experienced Java developers, your posts seem to be based on personal speculation rather than actual facts.
Crap! I'm not serious then :(
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?
The lambda implementation requires the MethodHandle/invokeDynamic work introduced at 7, and run time components introduced at 8. There is also some significant work being done on the inliner to support better optimisation for lambdas. Further to that 8 introduces default implementations to interfaces to allow lambda exploiting features to be added to the standard Java APIs while allowing old code to be run without requiring recompilation.
Though changes to the instruction set do not happen at every release there are normally changes to the class file format - so although generics were implemented by type erasure at Java 5 so did not need an instruction set change new signature information was added to the class file format to describe the type parameters, and annotations were introduced which required further class file format changes.
Though changes to the instruction set do not happen at every release there are normally changes to the class file format - so although generics were implemented by type erasure at Java 5 so did not need an instruction set change new signature information was added to the class file format to describe the type parameters, and annotations were introduced which required further class file format changes.
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.
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.
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.
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.
However, you can use Java 6 compiler to compile Java 6 code to JVM 1.4 bytecode. That's what you are talking about.
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 :)
I actually meant "language features that require bytecode spec >1.4".
Varargs and enums perhaps?
At a bytecode level, everything including and above assembler is syntactic sugar.
I don't think there's any theoretical reason for the bytecode or the bytecode assembler language to need to change. Just like there's no reason lisp and c can't both be compiled to IA32 bytecode, even though lisp has lambdas and c does not.
Rather the issue is going to be at the compilation stage, where support for anonymous methods will need to be added. From my limited knowledge of compilers two ways it could be done are:
* just give the lambda methods a namespace that is unique from the namespace programmers have access to (eg a variable with a space or a tab in its name). Now lambdas will be handled like regular named methods, but the namespace for them will be invisible to the programmer, and the compiler will be modified to have two method namespaces/an expanded namespace for functions.
* Make all methods lambdas and then bind method variables to the lambda methods similar to how atomic/primitive (eg integer, float, chars) and other non-atomic/reference (objects, arrays) variables are bound to their anonymous objects. This is similar to how anonymous objects are handled. An anonymous object is what's returned by constructors, which are then bound to some variable. In this case the compiler needs to support methods that aren't bound to a variable.
That said, it's entirely possible that making changes to the bytecode and the jvm will allow for faster running code, but those changes wouldn't be required out of some theoretical necessity for supporting lambdas.
I don't think there's any theoretical reason for the bytecode or the bytecode assembler language to need to change. Just like there's no reason lisp and c can't both be compiled to IA32 bytecode, even though lisp has lambdas and c does not.
Rather the issue is going to be at the compilation stage, where support for anonymous methods will need to be added. From my limited knowledge of compilers two ways it could be done are:
* just give the lambda methods a namespace that is unique from the namespace programmers have access to (eg a variable with a space or a tab in its name). Now lambdas will be handled like regular named methods, but the namespace for them will be invisible to the programmer, and the compiler will be modified to have two method namespaces/an expanded namespace for functions.
* Make all methods lambdas and then bind method variables to the lambda methods similar to how atomic/primitive (eg integer, float, chars) and other non-atomic/reference (objects, arrays) variables are bound to their anonymous objects. This is similar to how anonymous objects are handled. An anonymous object is what's returned by constructors, which are then bound to some variable. In this case the compiler needs to support methods that aren't bound to a variable.
That said, it's entirely possible that making changes to the bytecode and the jvm will allow for faster running code, but those changes wouldn't be required out of some theoretical necessity for supporting lambdas.
Yes, the reasoning makes sense.
I was actually thinking at this from a "language evolvability" p.o.v. : if, hypothetically, a language like Python would be bytecode compiled and the bytecode compatible v2 to v3, you could evolve the language syntax much faster without the worry for complicated "transitions": You could then use python 2 libraries in a python 3 program and so on...
I'm in the initial stages of a (not so serious) language design project - a language "designed for accelerated evolution of both syntax and semantics", and I was considering the hypothesis that a "bytecode" compiled language could evolve much faster than either an interpreted or compiled-to-machine-code one.
I was actually thinking at this from a "language evolvability" p.o.v. : if, hypothetically, a language like Python would be bytecode compiled and the bytecode compatible v2 to v3, you could evolve the language syntax much faster without the worry for complicated "transitions": You could then use python 2 libraries in a python 3 program and so on...
I'm in the initial stages of a (not so serious) language design project - a language "designed for accelerated evolution of both syntax and semantics", and I was considering the hypothesis that a "bytecode" compiled language could evolve much faster than either an interpreted or compiled-to-machine-code one.
I have a better question: when is the Oracle JVM going to support caching of JIT'ed code profiles from the last run so the JVM can start up faster and doesn't have to warm up? This will make running Eclipse soooo much smoother.
The gains for this approach are usually marginal as disk IO is expensive vs generating code in memory using the JIT.
JVM is definetly going to be exciting just not because of Java but all other JVM languages.
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.
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.
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.
If you're into functional programming the CLR is the runtime to beat.
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.
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.
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.
Its an open spec that can be implemented on any other platform that cares. Mono is available on many platforms btw
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.
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.
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...
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...
>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?
Only at the very limited level of "versions of the JVM before x have a bug that makes this package not work.
>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?
No, never. I know one should never overestimate enterprise software vendors, but you'd have to try really hard to make something that crap.
Only at the very limited level of "versions of the JVM before x have a bug that makes this package not work.
>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?
No, never. I know one should never overestimate enterprise software vendors, but you'd have to try really hard to make something that crap.
>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?
No, never.
You mean two different JVMs, from different vendors? Who uses those anymore?
I use HotSpot and JRockit. There's performance differences between the two but I've yet to run into something that works on one and breaks on the other.
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.
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.
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.
Really? No one uses Linux? And you're talking about Java and JVMs? That just looks silly.
This is true, but Mono has always lacked implementations of a bunch of APIs and had not quite as nice dev tools.
If there had been a true first party (i.e provided by MS .Net CLR) for other platforms it would probably have had massive traction.
If there had been a true first party (i.e provided by MS .Net CLR) for other platforms it would probably have had massive traction.
No, it wouldn't. Let's be honest, people would say it's from Microsoft and not use it for that very reason. Could be better than JVM and still most wouldn't use it. Linus was right, the hatred of Microsoft is a disease, and a lot of people in the open source community suffer from it.
Microsoft cast it upon itself. When you cry wolf all the time, nobody comes to help.
Microsoft can't let go. They can't say "this code is now open and no strings attached". They can say "but not really". They can say "but don't touch anything". Microsoft can't open.
What they can do is okay for consumers. Consumers will download whatever software available and use that. Developers? Hell no. Developers don't trust openness that can be revoked. Because this means their product stops working.
Microsoft can't let go. They can't say "this code is now open and no strings attached". They can say "but not really". They can say "but don't touch anything". Microsoft can't open.
What they can do is okay for consumers. Consumers will download whatever software available and use that. Developers? Hell no. Developers don't trust openness that can be revoked. Because this means their product stops working.
Then how do you explain that with mono? It's open source, but since it used MS's specs, with OS license, it has been vilified by the open source community. The reality of the matter is that while developers like to think they're rational, they're just as emotional as any non-developer. Their decisions are driven by emotions, by their hatred for MS or some other company / technology, hence the disease Linus was talking about.
How is it vilified? De Icaza loved it and pushed everywhere. Gnome played with it.
But mono is not .Net. I mean, if you look at Java, there is a very strict process which a JVM implementation must undergo in order to be called Java (and still there are a dozen of such implementations). It means it behaves predictably and have every one of the required APIs. And most of development tools are written in Java.
On the other hand, with .Net we have Microsoft implementation on Windows - and we have everything else. .Net on Windows has a massive number of APIs (many of those system dependent), hatches into COM, can easily use native code and libraries. Most .Net tools only work on Windows and are written as a mixture of native code, bytecode and COM. And mono is a second class citisen forever. It will never have all those limitless APIs and will never have all the tooling. It is extremelly unlikely that developers (of proprietary, in-house, server software) who use OS X or Linux as their development environment will ever adopt it. Nobody likes to be second class. Programming is painful enough even without that.
But mono is not .Net. I mean, if you look at Java, there is a very strict process which a JVM implementation must undergo in order to be called Java (and still there are a dozen of such implementations). It means it behaves predictably and have every one of the required APIs. And most of development tools are written in Java.
On the other hand, with .Net we have Microsoft implementation on Windows - and we have everything else. .Net on Windows has a massive number of APIs (many of those system dependent), hatches into COM, can easily use native code and libraries. Most .Net tools only work on Windows and are written as a mixture of native code, bytecode and COM. And mono is a second class citisen forever. It will never have all those limitless APIs and will never have all the tooling. It is extremelly unlikely that developers (of proprietary, in-house, server software) who use OS X or Linux as their development environment will ever adopt it. Nobody likes to be second class. Programming is painful enough even without that.
It has been, and it still is, thankfully to a somewhat lesser degree. Even Stallman said "we should discourage people from writing programs in C#". This, of course, is just the tip of the iceberg.
Whether .NET is different from Mono is not what I argue. Mono brought a MS-inspired technology to Linux so they got under the MS hatred umbrella. There was and still is a purely knee-jerk / emotional reaction to whatever they bring to the table.
Whether .NET is different from Mono is not what I argue. Mono brought a MS-inspired technology to Linux so they got under the MS hatred umbrella. There was and still is a purely knee-jerk / emotional reaction to whatever they bring to the table.
That would mean that there aren't any .net developers.
I don't think that necessarily true. Maybe it is for "the open source community" in terms of Stalanites.
OTOH lots of people use and love OSS including very profit driven startups and Apple "fanboys". Being able to write C# using Visual Studio under OS X and deploy to Linux would be killer app for a lot of startups and of course whatever stack gets used by the popular startups will be lionised.
OTOH lots of people use and love OSS including very profit driven startups and Apple "fanboys". Being able to write C# using Visual Studio under OS X and deploy to Linux would be killer app for a lot of startups and of course whatever stack gets used by the popular startups will be lionised.
>Its an open spec that can be implemented on any other platform that cares.
Which is something a lot different than an a project actively developed and supported on multiple platforms by Microsoft.
Xamarin is OK, but it's tiny (in resources and reach) compared to Microsoft.
Which is something a lot different than an a project actively developed and supported on multiple platforms by Microsoft.
Xamarin is OK, but it's tiny (in resources and reach) compared to Microsoft.
Mono supports everything under the sun.
invokedynamic is new in JDK 7. It still has some maturing to do, but JRuby is already targeting it.
Scala provides tail call optimization and invoke dynamic has been in the JVM for years (since JDK7). The JVM is also considerably faster than the CLR and unlike Mono is heavily used in industry.
Why would MS make .NET really cross plateform ? MS is here to sell Windows and Windows Software, nothing more. Mono is an unofficial hack and can be shut down anytime by Microsoft , i would not bet my career on that stuff.
Is the same true of LLVM?
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?
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.
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.
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?
Yes, but you will need a time machine
Aren't you?
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?
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?
What about the memory wall ? being limited to few gigs because of the GC stop-of-the-world is not very exciting.
how much is all of this tied to Oracle? is openjre and other non-oracle jvms ready for prime time?
About the JVM not the language ...