[
https://issues.apache.org/jira/browse/JCLOUDS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165826#comment-14165826
]
Andrew Gaul commented on JCLOUDS-747:
-------------------------------------
If an experienced Android developer steps forward and investigates the current
level of compatibility and how we can improve it, I am in favor of including
small changes to accommodate this compatibility. However, the exact level of
Java compatibility in Android is unclear and different versions support newer
features like try-with-resources in 4.4. I do not believe that we should try
to guess how someone might use jclouds on Android and artificially restrict
ourselves to older Java on master. We have previously discussed making 1.8.x a
long-lived branch if Java 6 users cannot move forward.
For what it's worth, Java 6 is increasingly losing support in some of jclouds
dependencies and future versions of assertj and checkstyle will only support
Java 7:
http://joel-costigliola.github.io/assertj/assertj-news.html
https://groups.google.com/forum/#!topic/checkstyle-devel/CvYiVq5lsNY
> Determine level of android support and how to ensure we keep it.
> ----------------------------------------------------------------
>
> Key: JCLOUDS-747
> URL: https://issues.apache.org/jira/browse/JCLOUDS-747
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-core
> Reporter: Adrian Cole
>
> One of the knock-on effects of moving on is tracking how we deal with
> android. One way is to establish a floor android level we aim to support
> (even if it is best efforts). That's due to the fact that android != java and
> only a subset of features are present, on each version. Here's a handy link
> that begins to discuss this complexity.
> http://stackoverflow.com/questions/20480090/does-android-support-jdk-6-or-7
> Modern android libraries typically use a combination of plugins and
> integration tests to ensure android isn't accidentally broken. Some projects
> just rely on folks to remember the rules.
> Here's an example of a signature-checking plugin
> {code}
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>animal-sniffer-maven-plugin</artifactId>
> <version>${animal.sniffer.version}</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>
> {code}
> In short, I think we should be careful and consciously decide whether certain
> features that break some level of android support are worthwhile. We should
> also note that entrypoints that aren't used by android callers will not
> affect compatibility. In other words, we are most concerned with the common
> paths.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
