Backport to Java7/Android

For an Android app, I had a need to parse a Cron expression and determine the previous/next execution date based on this expression. I came across this library but then realized it relies on JSR310 which was introduced in Java 8 and does not work with Android.

I forked the library and was able to make it work on Android in 2 steps:

Step 1: Make it work with Java 7

1. Use threetenbp which is a backport of JSR310
2. Search-and-replace all occurrences of java.time with org.threeten.bp
3. Use retrolambda to be able to use java.util.function.Function and the lambdas in pre-Java 8

With this, I was able to successfully run all cron-util tests with a target of Java 7

Step 2: Make it work on Android

Here I started off with some tests for my own use case (parse a Cron expression and get the next/previous execution times), but I made them Android tests (i.e., run on an emulator). For this. I had to make some more changes in my app/tests

1. Add ThreeTenABP which is an Android extension to threetenbp.
2. Initialize ThreeTenABP in my test like this. If you use it in an app, you will still have to init it in your Application sub-class.
3. Add a dependency on an implementation of SL4J. I used this one but any which works for you will do.

compile 'eu.lp0.slf4j:slf4j-android:1.7.22-0'

With these changes, I was able to run my app-specific tests successfully on Android.

Next steps

I left it at that because I am not sure how the maintainers would like to proceed with this. There are open questions like

• Do you want to support Android in the first place?
• If so, would you like to use JSR310 for Java8 targets and use the backport for older targets? Basically generate multiple versions of the library from the same code-base with multiple targets
• Would you rather do some runtime shenanigans to detect if JSR310 is on the classpath and use that and fall back to the backport otherwise (don’t even know if this is possible!)
• How would you like to approach the tests? For the Android target, It makes sense to run all the existing (408, at the time of this writing) tests on an emulator to make sure everything is compatible.

[jmrozanec]

@curioustechizen version 6.0.0 was released with this changes!

[jmrozanec]

@curioustechizen sure. Just found out that we cannot setup a Java and Android language at the same time for Travis. I am thus deleting the Gradle project files at ‘master’ and will keep them at the ‘android’ branch, which will hold the Android Travis configuration as well. The deployed jar will still be a single one: the one from ‘master’, but the builds at ‘android’ should help us address issues early. Thank you for the help!