[jira] [Commented] (JCLOUDS-747) Determine level of android support and how to ensure we keep it.

["Andrew Gaul (JIRA)" <ji...@apache.org>]

    [ 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)