3

We are developing a Java library which is available in a Java 6 version and in a Java 8 version. The Java 8 version provides a few additional classes but also some classes provide new functionality not available under Java 6. We like to maintain the code under a single repository.

Currently this is achieved via Maven where a profile is activating additional source folders (using a build-helper). The directory layout is

  • src/main/java - source files common to both versions
  • src/main/java6 - source files only active when building Java 6 version
  • src/main/java8 - source files only active when building Java 8 version

(and the same for src/test). This works quite nice. However, I still have the question:

What is the best practice for maintaining two JDK specific source files for the same class in a single Java project?

Specifically for Maven: What is the preferred naming convention?

Christian Fries
  • 16,175
  • 10
  • 56
  • 67
  • 2
    what youre doing right now seems fine to me. just make sure to add a qualifier to the artifacts produced so that different builds dont overwrite each other in maven repositories – radai Nov 20 '13 at 21:21
  • Curious: How do you avoid DRY violations with this set up? Obviously there's a ton of code that *could* be reused. – Daniel Kaplan Nov 20 '13 at 21:26
  • 2
    My suggestion - split your project into three Maven projects: common code; Java 6-specific classes; Java 8-specific classes. The two version-specific projects would depend on the common project. No funny naming convention under `src/` needed. – pobrelkey Nov 20 '13 at 21:29
  • @pobrelkey - that would either produce 2 jars or you'll end up playing funny games with packaging. – radai Nov 20 '13 at 21:30
  • I think I would do it a bit differently using maven. Have two projects which are java6 and java8 and specific to that. Then in the main have a dependency to either java 6 or java8. Did you end up with a similar structure under test as well? I'm guessing unit tests would be specific too. – codesalsa Nov 20 '13 at 21:31
  • @ tieTYT: This is a very good point. In C or C++ I would just use a preprocessor directive around the methods I like to add. Actually I asked for that http://stackoverflow.com/questions/17252454/best-practice-for-developing-under-multiple-jdks - the above is my current solution (using Maven). It is a DRY violation, but the violation can be handled. Some files are very different, but others are very similar and can be kept in sync easily – Christian Fries Nov 20 '13 at 21:32
  • @pobrelkey: The common code does not build without the JDK specific code. It's not a clear dependency hierarchy. – Christian Fries Nov 20 '13 at 21:36
  • @ChristianFries can't you extract interfaces that the JDK-specific classes would implement? Anyway, just my suggestion. – pobrelkey Nov 20 '13 at 21:38
  • @pobrelkey: There are JDK-specific interfaces to the JDK-specific classes :-). Just that this is not s.th. very special: consider a Collection class and some interface. The Java 8 version now supported Lambdas and new Iterators, while the Java 6 version does not. – Christian Fries Nov 20 '13 at 21:46
  • @ChristianFries Ah. :-) – pobrelkey Nov 20 '13 at 21:53
  • Have you considered creating two git branches: one with the Java 6 version of the library, and one with the Java 8 version? The build and the architecture would be simpler, and features and bug fixes would easily be merged from one branch to the other. – JB Nizet Nov 20 '13 at 22:15
  • @JB Nizet: But then, committing a "common" file to one of the branches would require merging (isn't it? I am still a heavy subversion user and maybe I don't see how git helps here). – Christian Fries Nov 21 '13 at 08:11
  • Yes. Every change to the Java 6 branch would have to be merged to the Java 8 branch. Subversion is fine as well, but git is a bit smarter when dealing with branches and merges. – JB Nizet Nov 21 '13 at 08:14
  • @JB Nizet. We came from this and it creates a lot of uneccesary work and actually the code is duplicated without reason. One problem you face in this situation: A "common" file is changed in the Java 8 branch using an IDE set to Java 8. The change breaks compatibility to Java 6, but this is not notices until the merge is performed. However, if you have one repository you may use two IDE projects referencing the same files and a change to the common file will immediately reflected in the Java 6 project and show an error in the IDE.... – Christian Fries Nov 21 '13 at 12:43
  • 1
    You should have a look at how the Spring Framework manages to support Java 8 but still runs on Java 7 (no different source files needed) - http://stackoverflow.com/questions/22659866/how-does-spring-use-java-8-classes-yet-it-runs-on-java-7 – FrVaBe Jun 20 '14 at 07:16

0 Answers0