Java 8: Will It See More Rapid Adoption?
Historically, organizations have tended to move to a new version of a language slowly (witness the looming crisis in Visual Basic 6). However Java 8 is arguably the biggest update to the language in many years and we therefore wondered if it might see a more rapid adoption. We would like to know what version of Java you currently use in production and to gauge your interest in moving to the new version.
- Java 1.4 or earlier
- Java 5: Released in 2004 it includes support for Generics, Autoboxing/unboxing
- Java 6: Released in 2006 this included Scripting Language Support, Java Compiler API, GUI improvements
- Java 7: Released in 2011 we gained invokeDynamic, Automatic resource management, Catching multiple exception types
- Java 8: Released a couple of weeks ago it features Lambdas, Date and Time API, Nashorn
Oracle’s Georges Saab and Spring Framework project lead Juergen Hoeller have publicly expressed somewhat opposing views on this. When we interviewed Saab, vice president of software development, Java Platform Group, he told us
Over the last 6-9 months, I have spoken at conferences around the world, and each time I ask folks what version they are using. Based on this informal and unscientific survey, most Java developers are using Java SE 7 today, with a clear (but non negligible) minority still on 6, and a small number on versions older than that. From a developer perspective, Java SE 8 comes with very compelling reasons for fast adoption in the form of new language features and APIs. With IDEs like NetBeans, Eclipse and IntelliJ IDEA working hard to provide great tooling for those features in their upcoming releases, I would expect to see developers embrace it quickly.
With Java EE servers, there is usually an upgrade showstopper in the form of a bundled JDK version. With WebSphere, even on WAS 8.5, the default JDK is still Java 6, with Java 7 as an opt-in choice. With WebLogic, recent releases are more strongly Java 7 based already. However, neither of those servers lets you freely choose the JDK generation to use.
As deeply integrated as an application server stack typically is with a specific JDK version, it's not advisable to simply run it against a different JDK installation. A current-generation application server is not likely to survive even a startup smoke test against JDK 8.
With flexible offerings such as GlassFish and JBoss AS, you'll probably be able to point them to a JDK 8 installation and get the server up and running. However, that is typically only true when using "-target 1.7"; once you start using Java 8 language features, some parts of the server and some integrated service providers are going to choke on "-target 1.8"...
Perhaps in the comments you can add a bit more information about what frameworks and application server or servlet container you use. Does the size of the company you work for have a bearing on the speed at which you are able to add a new Java version to production? Are you using another JVM language exclusively? Again let us know in the comments.