[
https://issues.apache.org/jira/browse/JCLOUDS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168806#comment-14168806
]
Ignasi Barrera commented on JCLOUDS-747:
----------------------------------------
I'm definitely not an Android expert, but I think we should do our best to
support it.
There was a discussion time ago about moving jclouds mater branch to Java 7. We
all agreed and have been announcing that for a while, but If I'm not wrong no
one took into account Android support. There weren't users/contributors
stepping into the discussion and requesting that, but the participation in our
dev@ list is often limited to the committers (I hope we improve this!). This
is, we made the call to move to Java 7 without taking into account an important
scenario.
The version of Java seems to be the conflicting part, and I think we should
reconsider the decision by answering the following questions:
* What is more important for our users? Being able to use Java 7 features or
being able to use jclouds on their Android devices?
* What will better help adoption? Will Java 7 make jclouds more attractive to
people, or will Android bring more users and help us gain traction?
* What will make jclouds better?
* Why not Android? Is there a really good reason to not supporting (and not
being able to support) Android?
These are the questions I ask myself when thinking about it, and I really think
we should reconsider the Java7 thing and try to be Android friendly. We've
already announced that we'll be supporting Java 7, but that shouldn't be a
problem. We can announce that we've reconsidered that in favor of providing
better support from Android.
> 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)
