Add option to replace Joda-time with a different lib

[four01]

Joda-time is being used in a few places to format date variables, but in our project we use threetenbp (https://github.com/ThreeTen/threetenbp) instead. It seems silly to pull in the Joda dependency just for that small use case. We would like some way of replacing Joda with threetenbp either via a plugin or interface we can implement.

This is for our Android app, where method counts are important.

Thanks!

[damnhandy]

I think this something that could be targeted at a future release as it would likely bring along some breaking changes. I developed this library with Java SE/EE in mind and not Android, so some of this was unexpected 😄 But since we're on the topic of method count, I'm going to that the Jackson support also causes some issues as well with respect to method count? If these are indeed problematic for Android devs, I'm thinking that there should probably be even more modularization?

[damnhandy]

On a related note, I have been considering making a future version of this library Java 8 only given that Java 7 is no longer supported. I'm curious to know how this would affect Android devs?

[four01]

When we removed Joda we also ended up removing Jackson, only because we were already at it and removing Jackson was straightforward. (One of our apps was already using Jackson so it wasn't a big deal).

Android supports java 8 with jack compiler (tho it breaks other things like data binding). We use retrolambda for java 8 lambda support and going forward it looks like Android is moving to java 8, so it should be safe to increase the requirement.

[drdamour]

AFAIK java 8 only works on nougat (7.0) + so in practice there's still a restriction on java 8...namely many people need to get new phones. https://developer.android.com/about/dashboards/index.html says nougat is < .5%.
so going to 8 sounds great to me...but i'd keep open a way to hotfix/feautre add via PR the java 7 branch too for a bit.

I might also suggest adoption a pattern similar to discussed at http://jakewharton.com/java-interoperability-policy-for-major-version-updates/ where v2 can live side by side with v1 for a while. IE put new code in new package (put a 2 in there). I've put this lib in some shared components for our stuff and it'd be nice to let apps update but not force updating of shared components.

[four01]

@drdamour https://developer.android.com/guide/platform/j8-jack.html

[drdamour]

yup confirms what I said. only .4% of devices can use java8

…

On Dec 26, 2016 12:37 PM, "four01" ***@***.***> wrote: @drdamour <https://github.com/drdamour> https://developer.android.com/ guide/platform/j8-jack.html — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABccAMA_D03OSNIlqsgBmMx_txdKJ03lks5rMBeGgaJpZM4LUEXv> .

[four01]

Note: When developing apps for Android, using Java 8 language features is optional. You can keep your project's source and target compatibility values set to Java 7, but you still need to compile using JDK 8.

We're using JDK 8 and compile for Java 7. Support for Java 7 can be dropped, but you would need to be careful as to which Java 8 features are being used. Lambdas are okay, but some other features are not.

[drdamour]

not sure what you're saying there...i' focusing on this line:
"Android does not support all Java 8 language features. However, the following features are available when developing apps targeting Android 7.0 (API level 24):"

[four01]

I guess the issue is, if Java 7 support is dropped to require Java 8, will Java 8 specific features be used? If you just want to use lambdas then it's all good since Android supports that (via Jack), but if you want to use the new Java 8 JSR 310 date specs (for example) then you can't, because it won't support older versions of Android.

[drdamour]

yes exactly...so that's why 7 i still what you need to target with any lib used for droid for a while longer. maybe if all those samsung notes blow up...

…

On Mon, Dec 26, 2016 at 4:30 PM, four01 ***@***.***> wrote: I guess the issue is, if Java 7 support is dropped to require Java 8, will Java 8 specific features be used? If you just want to use lambdas then it's all good since Android supports that (via Jack), but if you want to use the new Java 8 JSR 310 date specs (for example) then you can't, because it won't support older versions of Android. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABccANEx-qnILZDRB4IhhssFvUuddOfAks5rME4OgaJpZM4LUEXv> .

[damnhandy]

I think going forward, we'll look at doing a module system similar to what Jackson does with it's modules. That way, uses can opt-in to what features they want. Additionally, TravisCI is now offering Android support and we should consider setting up a configuration for different Android SDKs as well.