Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Build Gatling with JDK7 #883

slandelle opened this Issue · 11 comments

2 participants


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.

@slandelle slandelle was assigned

The underlying problem appears to be that we are not parameterizing our use of JComboBox, an instance of

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 [1].



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 to 1.7 (I don't understand why as scala code is compiled with scalac into JDK5 bytecode?!)

Here are the different possibilities:

  • leave it like this and have the recorder only compatible with JDK7
  • move SelectorUtils somewhere else where it will be compiled with JDK5+
  • migrate SelectorUtils to scala (warning: it's a thing of beauty, JDK2 style, with tons of returns everywhere)

The third option would be the best...


Actually, too painful to migrate such crappy code. Will find another way.

@slandelle slandelle closed this in 62d93a9
@slandelle slandelle referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.