Gatling 1 is JDK5 compatible and so far, Gatling 2 milestones targeted JDK6.
However, we’re considering enforcing JDK7.
Here are our arguments:
JDK7 has been out there for quite a long time and has tons of improvements, inside the JVM, like G1 GC, and in Java, like new stuff in java.util.concurrent
Gatling is not your critical IBM server that you don’t know how/fear to to upgrade
Though, we’d love some feedback from our community.
Should we make this move? Should we not? Why?
Please take a few minutes and share your thoughts.
I think, as you mention, that this is not like production servers that are more difficult to test for regression. And maintaining code for java versions that are out of support is always a pain. I’d move 100% to java 7
The only reasons not to move there are that some oranizations are still using java 6 in their servers and operations are not willing to install other versions of java, but the developers can always bundle the java 7 folder with gatling and use that java folder as JAVA_HOME just modifying the init script when deploying
Many new features, like G1 are young, and we know in this area, it
take time to fix and finely tune.
And many companies still stick with Java 6 because their Ops just know
how it very well.
Questions :
- How many features Gatling 2.x will use specific to Java 7 ?
- Why not consider Java 7 for Gatling 3, providing a clean path for
users, Java 5 G1, Java 6 G2, Java 7 G3. Then you could deprecate and
put EOL G1.
What would JDK7 give you over and above JDK6 (except G1 and that’s debatable as to whether it is an improvement)? I mean, are you using any of the new language features directly? Does Scala?
How many features Gatling 2.x will use specific to Java 7 ?
NIO fixes go in recent JDK versions
String implementation has changed in 7u6
JDK8 is around the corner: the more fragmentation, the more potential messes and then work for us
In current master, we have to backport some JSR166 features (some from JKD7, some from JDK8), but then, we have to copy Doug Lea’s repository (can’t copy JDK classes due to Oracle license). That means being aware of improvements, ship them in a library, deploy it on maven central. Doable (we already do it) but pita
Scala w/ JDK7
No, Scala doesn’t directly benefit from JDK7.
It will benefit from JDK8 if the Typesafe gods manage to make use of the new stuff that’s been introduced for Java 8’s lambdas.
I guess Scala will come in 2 flavors: for JDK8 and for older versions, so will Gatling.
The problem that is being overlooked here is security. Using JDK6 exposes organisations to known, well documented, actively misused security problems that are no longer getting patches from Oracle.
For this reason even big conservative financial institutions are switching their servers to 7. They simply cannot afford the risk.
Dropping support for that makes sense. Immature features are not a problem if you’re not using them. Security holes however, are.
“Java SE releases are updated for the public with bug fixes, security fixes, and minor updates for a period of at least 3 years before the release reaches end-of-public-updates (EOPU)”
End of public updates is on March 2015.
I’d definitely go with jdk7. On my last two projects, we’ve been using jdk7.
In addition, except for a few minor things, jdk6 was more or less the same thing as jdk5, whereas jdk7 brought the platform forward, just like jdk 8 will.
Furthermore, it seems like more and more open source projects are dropping jdk6 support, and moving forward. I’m actually involved in one, where we’re about to drop support for jdk5 and 6.