Skip to content
This repository

Build Gatling with JDK7 #883

Closed
slandelle opened this Issue · 11 comments

2 participants

Stephane Landelle Stephen Kuenzli
Stephane Landelle
Owner

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.

Stephen Kuenzli
Collaborator

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.

Stephane Landelle
Owner

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.

WDYT?

Stephen Kuenzli
Collaborator

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?

Stephane Landelle
Owner

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.

Stephen Kuenzli
Collaborator

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.

Stephane Landelle
Owner

Master is 2.0.0-SNAPSHOT now.

Stephen Kuenzli
Collaborator

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

[1] http://maven.apache.org/enforcer/maven-enforcer-plugin/

Stephane Landelle
Owner

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.

Stephen Kuenzli
Collaborator

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.

Stephane Landelle
Owner

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:

  • 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...

Stephane Landelle
Owner

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

Stephane Landelle 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.