I had local builds failing I forced pushed and passed CI. Which is why I was asking. What is odd is the amount of issues that came up as part of the PR that did not in my env. I was building it the standard way via maven, where I was getting the additional modifications. But I feel those are not necessary, more like a band aid that will cause problems later.
The changes really are not that big or require much modification. If you avoid guava 21. I do not see a path there. The community needs to discuss moving to guava 22+. Not supporting anything <= 22. There are API changes you cannot easily get around. Plus these odd issues I feel are specific to 21. I am not seeing any of this with guava 24 under Java 9, and I can test under 10. These are odd issues that come up with trying to use newer stuff in older JDKs. I can appreciate some legacy compatibility, but the Java world has changed. There will be 4 releases a year. Even 9 is about to be replaced by 10 next month, in a few weeks. Anyone still stuck on 1.6, or 1.7. I feel is not forward looking. IMHO this is where situations like the Equifax Struts2 hack comes from. No one should be running Struts2 period, its like a decade old. Replaced by jsf, spring, etc. Both many versions later, so not new. I feel like projects that keep catering to legacy users are not helping this situation. It gets even worse when you pull stuff from maven/gradle that has been built for 1.5. Which happened with trying to switch [byte-buddy from lombok to autovalue](https://github.com/raphw/byte-buddy/pull/400#issuecomment-361006248). Lombok has major issues under newer due to supporting older. Its creating a big mess for some things. There are only a handful of things that have such legacy requirements. Lombok, byte-buddy, and jclouds. Even gradle I was able to upgrade guava pretty trivially. Not sure why they are stuck on old versions. Intelliij was stuck on guava 18 for a while. I do not believe bugs are fixed in older versions. Not sure why someone would want to remain running older vs newer. Seems they are not trying to keep their codebase current, or something. I just do not see it practical to be able to continue supporting legacy while being forward moving at the same time. I do not see any way for Jclouds to support that many versions of guava, or even < guava 22. Likely have to bite the bullet, go to 1.8, and guava 22. Legacy users can remain with older versions of jclouds. Like they are already using older versions of Java and guava. Not to mention both 1.6 and 1.7 are long EOL. Anyone running that is either paying Oracle/IBM/RedHat for support, running openjdk/icedtea, to get around EOL from others. Basically running some what unsupported JDKs. I do not see how any of that should be encouraged. By now if people are not on 1.8. They have their own problems and should not be catered to. The java world has changed. IMHO need to make sure you work with newer vs older. That is the new world and I much prefer it. Way to much legacy stuff still in wide usage. Projects that have not been updated in a long time. Some no longer in active development. One example is [jsch-agent-proxy](https://github.com/ymnk/jsch-agent-proxy/releases), but its not as outdated as other stuff from early 2000s... Anyway I would say lets close this PR. I do not see any viable option for supporting Guava 21, nor would I bother. I recommend moving to 1.8, and guava 24. The gson problem is different preventing OSGi, so that is a blocker till code change. Guava is not. But there are changes in Guava 22, thus that version and anything newer should be fine. Older no go. I can submit a new PR that should work for Guava 22+ and Java 1.8+. I think that is the route to go. I do not see this route being viable. Thus I think we should close. I can submit a new one for Guava 22+. It will require considerable less changes. I have sed to make those changes quickly. I really feel that is a better long term direction. Please discuss that with community members. I can join ML or IRC if need be to help in discussion. I really do not see any options. There are simply to many changes required, and it will just cause issues later one. All for Guava 21, and I do not feel its worth while. Thus skipping that version. -- 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-366459193
