The value of backwards compatibility

By Greg Turnquist

Greg L. Turnquist worked on the Spring team for over thirteen years and is a senior staff technical content engineer at Cockroach Labs. He was the lead for Spring Data JPA and Spring Web Services. He wrote Packt's best-selling title, Learning Spring Boot 2.0 2nd Edition, and its 3rd Edition follow-up along many others.

June 14, 2016

springI was listening to Episode 6 of the Nash Dev Cast as they spoke about bitrot, of how stuff degrades as the whole Internet upgrades around you. It really reminded me of the inestimable value of Spring’s approach to backwards compatibility.

Something that is almost unnoticeable is that the Spring Framework and its entire portfolio has backwards compatibility. Bumping up the version in your project when a new release comes out is a no-brainer. They just don’t break stuff. You may get alerted to deprecated features, but the JavaDocs will kindly direct you along the upgrade path. Moving from Spring 1.2.8 -> 2.5 -> 3.0 -> 4.0 has such little cost, that people are eager to jump to the latest.

junior-devAs a junior developer, this kind of thing doesn’t really resonate. And not because you are somehow bad. No. It’s simply because you don’t have as many war stories to share over upgrading other libraries, and having major breakage. Senior developers at conferences will share a beer and discuss some crazy upgrade that got started, and a breaking change they were forced into turned a 2-day upgrade into a 3-week effort.

Even as a senior developer who recognized this feature of the Spring portfolio, it wasn’t until I joined the team and proposed changes, that I learned of the technical challenges this team faces to enforce backwards compatibility. It really rose to the surface when I heard Juergen speak about Spring 4 being “Java 8 ready” but still working with Java 6. With scrunched eyebrows, I leaned closer as he spoke during the 2013 Birds of a Feather at SpringOne how the framework would certainly support Java 8 features, but still operate on Java 6.

That perplexed me. How could a framework take advantage of things like Optional yet blink “no problem” if you used Java 6? Digging in, I learned not only how to build a JAR file with Java 6 specs but neatly keep Java 8-based API calls inside Java 8-flagged classes that were only loaded when Java 8 was the loading engine. And I learned how hard this effort was.

I already respected the Spring team and the programming model they had developed. But this level of technical expertise combined with forward thinking plans to start ten years ago and maintain to this day, was quite impressive.

So, listening to podcasts about JavaScript open source modules, sifting through and evaluating products, and getting “left-padded” at times, made me snug and comfortable in my decision to bring onboard the Spring Framework years ago. Their decisions to invest so highly in the community have paid dividends I have no idea how to tabulate.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *