jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William L Thomson Jr <notificati...@github.com>
Subject Re: [jclouds/jclouds] core: Fix compile issue under Java 8+ (#1180)
Date Sat, 17 Feb 2018 17:57:41 GMT
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:
View raw message