DevOps Zone is brought to you in partnership with:

I am the founder and CEO of Data Geekery GmbH, located in Zurich, Switzerland. With our company, we have been selling database products and services around Java and SQL since 2013. Ever since my Master's studies at EPFL in 2006, I have been fascinated by the interaction of Java and SQL. Most of this experience I have obtained in the Swiss E-Banking field through various variants (JDBC, Hibernate, mostly with Oracle). I am happy to share this knowledge at various conferences, JUGs, in-house presentations and on our blog. Lukas is a DZone MVB and is not an employee of DZone and has posted 233 posts at DZone. You can read more from them at their website. View Full User Profile

Jenkins (and Others) About Dropping Support for Java 5

07.27.2013
| 3793 views |
  • submit to reddit

As an Open Source developer, I’m used to trying to support as many reasonable things for my users as possible. However, this has never included support for Java 5, which itself is hardly supported by popular Java vendors anymore. Hence jOOQ requires Java 6 or more to compile and run.

There is now an interesting initiative by Kohsuke Kawaguchi, the creator of the Jenkins CI serverIn a letter, he’s attempting to get other Open Source projects and developers on board with him to drop support for Java 5. While this change is rather trivial and marginal for most Open Source projects, it’s a major change for a continuous integration server such as Jenkins. With his permission, I’m citing his letter about why Java 5 should no longer be supported by Jenkins CI. If you’re an Open Source developer and you want to drop or have already dropped support for Java 5, then join this initiative:

What?

We are putting the stake on the ground: our releases after Sep 30th 2013 will start requiring Java 6 as the minimum runtime environment.

We are delivering this message to our users to give them a fair notice. To make this more effective, we are building a coalition of OSS projects. We’ll put up a simple website to advertise this, and encourage people to spread the news. Our collective project names and logos will help spread the message.

We are developers of an OSS project. To help our users use our software, we’ve been refraining from requiring Java 6 as the minimum runtime so far. But we think we did that long enough. It’s time to move on.

Why?

  • Most Java VM vendors no longer support Java 5. People shouldn’t be using it.
  • There’s no viable open-source Java 5 implementation.
  • We can’t use increasing number of libraries that require newer Java, translating into more development effort, less features and fixes.
  • It’s adding to the integration test cost. We run more tests for Java 5, when increasingly smaller number of developers actually have Java 5.
  • Newer Java runtime has more features. More collection APIs, NIO improvements, console access, XML support, compiler API, annotation processors, and scripting language interface.
  • 1.50 class file format comes with split verifier, resulting in faster classloading.
  • Putting our collective weight behind this will help us reach more users. Picking this fight individually is harder.
  • If this is successful, it’ll make it easier for us to move on to newer Java runtimes in the future versions.

Facts

  • Java5 was released in 2004, nearly a decade ago. Its public support has ended in 2009.
  • Even IBM is ending its support for Java 5 on the server side at Sep 30th, 2013.

Who is already onboard?

Being invited:

Considered contacting and discovered they have already moved on

Call for action

  • If you are a developer of an open-source project who wants to join, please let us know so that we can add you!
  • If you know some projects we should reach out, please let us know.

Contact

Kohsuke Kawaguchi: kk at kohsuke dot org / @kohsukekawa

See the original letter here:
https://docs.google.com/document/d/1pi8OsiG-hPDjqSge4xqmpZTshryUkMdF4QLBeCf0GXo

Published at DZone with permission of Lukas Eder, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)