Use standard Java classes

[rupert-madden-abbott]

This library is excellent, thank you for creating it.

There are quite a few places where using standard Java classes may make it more usable.

1. RecurrenceRuleInterator -> This seems like it could implement Iterator which would then make it much easier to generate a Stream. Alternatively, RecurrenceRule could have a stream method which returned a stream.

2. Weekday -> There is already DayOfWeek. Could this be used instead?

3. DateTime -> This is similar to either LocalDate (all day floating), LocalDateTime (floating), ZonedDateTime (timezone). I can see it is convenient, internally, to have a single class that can represent any of these concepts but externally, RecurrenceRule could accept these more standard classes, and the recurrence rule could emit them, and the conversion to DateTime could happen internally.

These kinds of changes would allow the library to work more easily with other code which will already be using these classes.

I've wrapped the library but I'm wondering if you would find these changes useful in this library itself and if so, whether you would be open to some PRs?

[dmfs]

Thanks for your suggestions. I've indeed already considered and planned some of these changes. Please bear in mind that the library is also being used in Android Projects, which means we can't use Java 8 API unless we drop support for everything prior to Android 8. Our OpenTasks app supports Android 4.4+.

That being said, I do agree with your points and I'm not completely happy with the current design either. In particular I'd like to replace RecurrenceRuleInterator with an Iterable and provide decorators which convert the results to DateTime, Joda Time, Java Time, etc.
My goal is to split the larger classes into multiple smaller ones. In addition I want to make this lib more usable by supporting other Date & Time implementations. Also, I'm still looking for a good way of handling unsynchronized start dates.

I do have some very concrete ideas, but I'm happy to discuss your changes.

[jdvp]

@dmfs I'm not super familiar with maintaining java libraries (as opposed to android-specific libraries), but one option for using the Java8 classes could be for this library to update to use the Java 8 APIs and then advise consuming Android applications to use the new Java 8 desugaring support bundled with the Android Gradle Plugin 4.0.0 mentioned here:
https://developer.android.com/studio/write/java8-support#library-desugaring
The page mentions that desugaring in this way doesn't necessitate any specific minSdk version

Not 100% sure if there are any issues with that approach as I've only tried the deseugaring process with using Java 8 time directly rather than through another library, but it might be a viable option.

[dmfs]

@jdvp right, I guess with the advent of the new desugaring features, we no longer need to refrain from using Java 8 API. I'll give that a try.
My only concern now is backwards compatibility. It should be possible though, to provide a better API while still keeping the old one in place. I'll spend some time to think about this.