Should we strip out `maven.compiler.target` settings from project `pom.xml`s for EQ1, EQ2?

[wtwhite]

Many of the projects in dataset.json set maven.compiler.target to a specific value (commonly 7 or 8). Empirically, this setting determines the major version number at byte offset 8 within compiled .class files output by the compiler, and whether or not bytecode-changing features like fast concatenation of string literals is applied, irrespective of the compiler version being used. This makes sense, since that number presumably specifies the earliest JVM version required to run the file -- but having it fixed like this is very likely to severely limit the bytecode variability across JDK ( = compiler) versions when generating the EQ1 and EQ2 oracles.

Should we strip out these target version settings?

Pros:

• Likely more bytecode variability
• We don't try to run the built project, so it doesn't matter if it wouldn't run after building with a different target version

Cons:

• The project maintainers explicitly decided to lock in these bytecode versions, and probably had reasons for doing so -- and we would be going against that

Furthermore: If we do strip them out, should we replace them with new target version settings (e.g., equal to the JDK version used for building)? I think yes, unless Maven does this automatically. (Empirically, "raw javac" defaults to a targeting the same JVM version as its own JDK version, while "raw ecj" defaults to targeting ancient JDK1.2 -- but probably Maven does something different.)

Note: As described here, this version information can be specified either as a property setting (<properties><maven.compiler.target>1.8</maven.compiler.target></properties> or -Dmaven.compiler.target=1.8 on the command line) or by setting the <configuration> of the maven-compiler-plugin directly.