Java 8

[mishako]

Pros

• Java 8 features → easier development
• Java 8 types (Date/Time, Optional) → better interoperability with modern code

Cons

• Some developers are constrained to Java 6/7

Guava requires Java 8 since 21.0, but since 22.0 also provides an "android flavor" for Android and Java 7 environments.

Should we do what Guava does? What are the constrains for Java version in current Android environment?

[imk]

About "general" java development, we could simply add a note in the docs about the last Rome version supporting java 6 and 7. This version won't be supported anymore but ist still useable, won't get new features but if there should be any major bugs, pull requests for fixes could be accepted and releases build (for some time).

About Android, I haven't found a good source about support for the different java versions in different API levels yet. I'll ask some devs I know but haven't met them yet.

[imk]

After some more research, you can use some parts of Java 8 for Android when building your app with Android Studio 3.0 Preview 1 or later, see https://developer.android.com/studio/write/java8-support.html about the other requirements. So we could use lambdas without API level restrictions, but when using streams API (amongst others), min level 24 ist required (Android Nougat, 7.0).

So when using Java 8 and trying to get better Android support, we should make sure, no APIs are used that would require an Android minimum API Level 24.

[PatrickGotthard]

So when using Java 8 and trying to get better Android support, we should make sure, no APIs are used that would require an Android minimum API Level 24.

+1

[mishako]

What about DateTime (jsr 310) and Optional?

[imk]

I'm afraid, Android is really annoying: Optional had been added to Android API level 24, java.time will be added in API level 26. But I haven't found any notes about these, some newer stuff is catched by the compiler and converted to some special bytecode that can be executed even on older systems. I don't know, if there is some magic for this stuff too. I think, I'll have to create some tests for this. Especially to find out if there are some differences between using newer APIs and language features in your Android application code itself or in a third party lib.

[mishako]

In the android version of guava they seem to simply remove anything related to Java 8 from the code: Comparators.java vs android-compatible Comparators.java (no Optional and no Collector). Not sure if they somehow automate the removal.

[imk]

It seems to me like guava kept the last versions of Java 7 sources and copied them to the android module, at least I can't find any trace of some automation.

Of course we could take a comparable approach, keeping Rome 1 alive (with some minor optimizations) for Android and dropping the attempt to support as many android versions as possible and restricting Rome 2 to minimum API level 24. But I'm not convinced that's a good idea.

[eknoes]

As 90% of android devices run in Android versions with a lower API-Level then 24, we would not reach a big audience if rome2 would require that. I would prefer Android support instead of newest Java 8 Features.

[mishako]

I suggest to conclude the discussion with the following decision.

We will do it the guava way: for each version of Rome 2 we will provide an additional android version. How exactly we build these versions is something to figure out when we develop the prototype.

The decision can of course be rethought based on learnings from prototyping.

[mishako]

An interesting issue they have with this approach: https://github.com/google/guava/issues/2914 It's probably less relevant to us, because Rome is unlikely to be used in a way where you would end up depending on two different versions of it.