It feels like I have to micromanage my JDKs. What can I do about it?

I'll give an extremely contrived example of something I struggle to deal with.  Assume I start a project with the following Gradle build config...

apply plugin: 'base' def jdkVersionInUse = System.getProperty("java.version") assert(jdkVersionInUse.startsWith('1.6')) if(project.hasProperty('buildServer')) {     assert(jdkVersionInUse.equals('1.6.0_43')) }

Also assume I have a very simple TeamCity install with one agent and one build configuration.  The agent has v1.6.0_43 of the JDK installed and the build configuration does not override it.

Now say I want to upgrade to v1.7 of the JDK, so I update my Gradle build configuration, update my project to use v1.7 language features, and update my build agent to use v1.7 of the JDK.  Doesn't that break my ability to go back and build an old revision of my project?

I have similar trouble with things like Apache Thrift where it's not portable (on linux at least).  I can use environment variables and agent requirements to make it work right now, but it's really easy to get my project into a state where the build server and the (version controlled) build configuration don't agree on the state of the build environment, especially when I update to a new version of a build tool.

What are some good strategies for dealing with my example of updating to a new JDK?

Please sign in to leave a comment.