[
https://issues.apache.org/jira/browse/JCLOUDS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168845#comment-14168845
]
Andrew Gaul commented on JCLOUDS-747:
-------------------------------------
[~nacx] We circulated the the Java 7 proposal on the user mailing list, not the
development list, and we publicized it via Twitter as well.
[~adriancole] Android API level 19 supports many of the Java 7 features we
propose using, including try-with-resources and
{{HttpUrlConnection.setFixedLengthStreamingMode(long)}}, although not
filesystem extended attributes. Roughly 25% of devices support this today,
trending upward and presumably higher when jclouds 2.0 releases.
More generally, what use case do we envision for jclouds users on mobile
devices? Do owners of older phones overlap with this? Are we comfortable with
a small and hypothetical user base with no known projects determining the
requirements for the larger user base? I strongly believe someone creating a
mobile cloud application should explain their needs to us instead of guessing
at what they might be.
> 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)
