Note I would also highly recommend a global revert of MoreObjects back to Objects, again until we have a significant reason to deal with that maintenance burden.
Objects.toStringHelper is not scheduled to be removed until June 2016, and MoreObjects.X causes a mess for folks not following guava updates as fast as we do. I am *this* close to suggesting not using Objects.toStringHelper regardless of things like auto-value as it is disastrous for portability. We should favor compatibility way over staying 2 years ahead of guava deprecation policy. WRT android. Let's set the language level back to 1.6 and plop this into the parent pom in a way that projects inherit it. Animal sniffer also checks api usage. If that turns into pandora's box, we can table animal sniffer until we can fix around it. <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>animal-sniffer-maven-plugin</artifactId> <version>1.11</version> <executions> <execution> <phase>test</phase> <goals> <goal>check</goal> </goals> </execution> </executions> <configuration> <signature> <groupId>org.codehaus.mojo.signature</groupId> <artifactId>java16</artifactId> <version>1.1</version> </signature> </configuration> </plugin> On Fri, Oct 17, 2014 at 2:45 PM, Chris Custine <chris.cust...@gmail.com> wrote: > > I was waiting until after 1.8.1 was released, but since you ask... I think > this or something like it sounds like a good idea, however I don’t think we > need to revert very much if anything. My understanding from reading about > this issue over the weekend was that there are only very specific parts of > Java 7 usage that would prevent it from working on anything older than 4.4. > Specifically, try-with-resources seems the only real issue. From what I read > (and it is fairly well documented) that is the only part that is of concern. > If we adopt this route temporarily and try to evaluate what it would take to > have a usable jclouds on Android, we could simply have a wiki doc with the > guidelines I have seen on what language level features of Java 7 are suitable > for the best level of Android compatibility. > > I was also going to suggest a 1.9 release to include oauth and gce graduating > out of labs, and any other bits that we decided to leave out of 1.8.1 but > which we might not want to wait months for 2.0. Just a thought. > > Chris > -- > Chris Custine > > > > On October 17, 2014 at 8:41:02 AM, Andrew Phillips > (aphill...@qrmedia.com(mailto:aphill...@qrmedia.com)) wrote: > >> > I can’t argue with that. If we keep this opportunity open and >> > encourage the exploration, and still nobody steps up for it then I >> > think it is fair to reevaluate this again. >> >> Just in terms of concrete implications: would we want to consider a >> 1.9.x that still supports Java 6, reverting the Java 7-only on master >> for that? Or how else would you suggest going about this? >> >> ap >
