Add option to replace Joda-time with a different lib
four01 opened this issue · comments
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!
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?
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?
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.
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.
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.
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):"
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.
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.
Just follow up on this old open issue. Given that it's now 2 years later, is moving to Java 8 still a problem with Android devs?
our android devs say yes, targeting java8 has become the norm.
ok wait...just got more info. it would not be a good idea to use java8 if you want to keep droid compatibility. the lesson is be careful what level8 feaures you use. see the table at https://developer.android.com/studio/write/java8-support minSDK is 24 for a lot of stuff...and minSDK 24 would exclude a LOT of devices out there... that list includes stream and function.
then you go looking for a package...in this case you want to use java.time well the docs at https://developer.android.com/reference/java/time/package-summary say that was added in api level 26 following that you get to https://developer.android.com/guide/topics/manifest/uses-sdk-element#ApiLevels which means android 8 and above..which is very incompatible.
so sorry about the misdirect previously...i would suggest you NOT use java.time if you want to be android happy.
I might consider keeping the 2.1.x series on Java 6 and branch off a 2.2 series on Java 8. This way, bug fixes and tweaks could still be made to to 2.1.x as needed but all new work would continue on 2.2.x
per semver dropping java6 support should be a full major ver bump (IMO), so i'd suggest 3.x
Given the year and EOL of Java versions, I think it would be ok to switch to Java 8 time api with a new 3.0 release. Android folks can still use the current 2.x releases. Not being able to use the new api objects and having to include/map to joda time is also an impediment.
An alternative would be to refactor into a core and two extension libraries (joda, java8) and use the ServiceLoader mechanism to load an appropriate VarExploder from the extension.
@leonard84 one of reason for not moving to the Java Time is API is older versions of Android. But, your suggestion of leveraging the VarExploder with 1 ServiceLoader` is a good one and something I'll look at when I get around to v3. Thanks for the suggestion.