[
https://issues.apache.org/jira/browse/JCLOUDS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165908#comment-14165908
]
Adrian Cole commented on JCLOUDS-747:
-------------------------------------
Also, the android site is pretty clear that java 7 is supported in
minSdkVersion 19, and prior versions wouldn't have try-with-resources.
```
Note that you can use minSdkVersion with a value earlier than 19, for all
language features except try with resources. If you want to use try with
resources, you will need to also use a minSdkVersion of 19.
```
http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Using-sourceCompatibility-1.7
Personally, I don't see try-with-resources as the killer feature with which
now.. all our internal code will be finally awesome. We aren't that often
internally doing resource management (probably 1% of our main classes). The
largest area where try-with-resources can make impact are tests. Tests don't
need to be concerned about android levels anyway. Hell, they could be run with
a different JDK!
Regardless, this issue can be a placeholder where folks who ask about android
support can land.
> 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)
