On Mon, Jul 15, 2024 at 10:25:04AM -0600, John Calcote wrote: > I recently submitted a PR to support virtual private clouds (vpc) in aws-s3 > (https://github.com/apache/jclouds/pull/206). As I was doing this, I > noticed that all of the changes made since March 2024 have been about > upgrading (and requiring) Java 11 and Jakarta interfaces. I understand why > we need to move to Jakarta (thanks to Oracle). I'm a bit in the dark as to > why we cannot maintain backward compatibility with Java 8. > > Is there a branch that will continue to support Java 8? And will > community-provided patches moving forward always (for a while anyway) be > backported to this branch? Some of us don't have the option of upgrading > from Java 8 to 11 in the immediate future. We have millions of lines of > code on Java 8. I'm certain we're not the only ones in this boat, so a > mandatory move to Java 11 has a tendency to alienate a portion of the > jclouds community.
While I sympathize with your Java 8 situation, I am the only currently active jclouds maintainer and can only devote a few hours a month to this task. Anything that reduces the maintenance burden should merge and nothing that increases the burden makes sense, e.g., Java 8 compatibility. Specifically the Jakarta dependency upgrade addressed a widespread issue with newer versions of Guice, itself a problem due to other jclouds technical debt. I am trying to get the project into a state that maximizes its utility if the project cannot make new releases any more, i.e., moving to the Apache attic. jclouds 2.6.0 might be the final release but I hope to run 2.6.1/2.7.0 to include a few remaining fixes. But if jclouds is a key dependency for your project it would be prudent for your employer to invest in the project or evaluate alternatives. -- Andrew Gaul http://gaul.org/
