@demobox Sure I can see about joining the lists. One route is also to keep a legacy version of jclouds. Like a 2.0.x branch, and then 2.1.x can be jdk 1.8 or newer. Seems odd that they would want a new jclouds, but other stuff old. Given other stuff likely has bugs fixed in newer updates.
Not sure if you all want to maintain 2 code bases and backport important stuff. That is another way to go. Many projects do have different releases for older versions and newer. Definitely other ways to go about all this. I think trying to do it all in one codebase is asking for trouble. Though some of the changes could be made on the fly for newer guava. That is [how I am doing it via sed](https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/jclouds-core/jclouds-core-9999.ebuild#L55). Which I can use some of that for more than just core, and submit new PR for guava 22+. There does not seem to be to many changes required for even guava 24 which I am building against, with java 9, etc. I should be moving onto 10 around the end of the month or before. I think 2 code bases/branches maybe best for legacy support and moving forward. Rather than changing code based on guava versions etc. You maybe right on Java usage, per various vendors life cycles. http://www.oracle.com/technetwork/java/eol-135779.html https://developer.ibm.com/javasdk/support/lifecycle/ https://access.redhat.com/articles/1299013 I feel like oracle is speeding things up to kill of legacy Java, and reduce competition Seems others tend to support older versions longer than Oracle. Which can explain continued usage of 1.7. Likely means the same for 1.8, even when like Java 12+ comes out... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1180#issuecomment-366483335
