[
https://issues.apache.org/jira/browse/JCLOUDS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168833#comment-14168833
]
Adrian Cole commented on JCLOUDS-747:
-------------------------------------
So, I don't do android fulltime, but I have worked on an android app this year
at my dayjob, specifically a component that synchronized a local model to an
http endpoint. I also contribute to android libraries that end up in AOSP.
I would say that the java7 question this isn't a slam dunk, it is more about
being able to play at all.
Android in real life can't depend on the latest api version, as it just isn't
deployed. Android in real life may encounter other problems, including the
heaviness of jclouds with regards to initialization, reflection, allocation,
scheduling etc.
However, those issues are easier to solve than making the world deploy the
latest android release.
This in mind, if we continue to run master on java 7, we are basically formally
closing the android door. People who have interest in android would probably
look at maybe adapting other frameworks to read jclouds interfaces, or just
recreate them in a different codebase.
I'd consider that a shame, as basically we would be trading these contributors
for being able to use try-with-resources internally. Moreover, if an alternate
framework rises out of this, and it ends up better, we'd have lost over
try-with-resources.
> 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)
