You can clone with
It seems we can't compile with JDK7 but target 1.6 bytecode.
I get an exception javacTask: source release 1.7 requires target release 1.7 when compiling the recorder, using JDK7 parameterized classes.
javacTask: source release 1.7 requires target release 1.7
The underlying problem appears to be that we are not parameterizing our use of JComboBox, an instance of http://www.scala-lang.org/node/11272
Sadly, it looks like we cannot support both JDK6 and JDK7 at the same time.
AFAICT, it appears that Scala itself recently (9 days ago) became build-able with JDK7 (scala/scala#1791) on master, which is slated for release in 2.11.0-M1. It may make sense to hold on this issue until updating to scala 2.11.
scalac can target JDK7 bytecode, but JDK6 is the default.
I'm in favor of building with JDK7 (Apple made it a hell to have multiple JDK versions), but I think we should keep on producing JDK6 bytecode. My concern is that people might have issues running Gatling on Jenkins if their project is built with JDK6.
The exception is the recorder: there's much better chances that people have JDK7 on their desktop.
I agree about JDK7 being painful on OSX. Would it be possible to side-step the problem by creating a JComboBoxFactory class in Java to make the kinds of instances required by the recorder?
What would that change? We would still have to emit JDK7 bytecode, right?
For the record, the problem is not only with JComboBoxFactory but also with DefaultListModel.
Yeah, I think you're right. If you want to mitigate surprises with the JDK switch, I'd perform the switch on a significant release, like 2.0 and (maybe) 1.5.
Master is 2.0.0-SNAPSHOT now.
Right -- it seems like now is a good time to switch to JDK7 on master. One thing that may help users make the transition is for the gatling maven archetype to enforce JDK7+ using the enforcer plugin .
I think that enforcing people to migrate to JDK7 would be a bad move. IHMO, Gatling is no position of doing so. On the contrary, I think it would shy people away.
I'm in favor of building with JDK7, as most people willing to build from sources would probably use it, but keep on emitting JDK6 bytecode.
We then have the case of the recorder. We can either have it only JDK7 compatible, as there's better chance people have JDK7 on their desktop, or fork the classes that pose problem.
Yes -- I agree that forcing users to migrate to JDK7 is a risky proposition. I think your suggestion of building with JDK7 and emitting JDK6 bytecode for the bulk of the project and then handling the recorder separately is a good approach.
My bad: scalac is only able to produce jdk6+ bytecode since scala 2.10. Default in scala 2.9 is -target:jvm-1.5. In the end, the only class that gets compiled with javac is org.codehaus.plexus.util.SelectorUtils shipped in the recorder.
However, I can't have the build succeed with JDK7 if I don't set maven.compiler.target to 1.7 (I don't understand why as scala code is compiled with scalac into JDK5 bytecode?!)
Here are the different possibilities:
The third option would be the best...
Actually, too painful to migrate such crappy code. Will find another way.
Have Gatling built with JDK7, close #883