Future of mockito-android

[tvanderlippe]

Hey everyone,

I wanted to add Philip Moltmann into the discussion regarding the future of mockito-android.

The core issue is that we currently have a large amount of open issues regarding this artifact: https://github.com/mockito/mockito/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+mockito-android+ Most of them are related to limitations, bugs and other general issues such as method count.

Philip already elaborated in private about the (dis-)advantages compared to dexmaker-mockito, but I wanted to have this discussion in public.

For me personally, we should aim for a good experience for users, which means we should overcome the limitations. If we are unable to (for technical reasons or simply trade-offs we are forced to make), I do not see a concrete future for mockito-android. We can keep the compatibility layer for now until we make more sweeping breaking changes in Mockito 3, but we should then also think of a migration path.

Basically, we have to come up with a proper way for mocking on Android. I think no one on the core team has the time nor the experience to do so, thus I think a community effort would be great here.

Looking forward to your responses.

Cheers,

Tim

[Philip P. Moltmann]

Hi,

yeah, Android's JVM is in many places subtly different from the server side Java. I think the by far biggest advantage of mockito-android is that is as compatible as it can be. Of course it cannot overcome Android specific problems such as the issues mentioned by Tim. These are "minor" issues an many can probably be dealt with in the compatibility layer. If mockito ever requires inline-mocking, this compatibility layer will get much more complicated so that we should just go back to dexmaker-mockito which has a more heavy handed approach to compatibility and therefore handle bigger changes.

I understand that supporting Android and server side Java at the same time is frustrating as there are just so many Android specific issues. This leads to bugs being a lesser priority and build up. I fear that pushing it into a separate project is likely to make this even worse as nobody will feel responsible. On the other hand: If you find some group who is willing to spend a lot of time on this issue and wants to keep maintaining it, this could improve the situation as these people could make improvements following their own process.

Of course I am willing to help this group wherever I can, esp. I can help with access to the people who write the Android JVM and facilitate any questions. If new APIs are needed I can try to make this work. Still, I currently appear to not have time to consistently promise time to work on Mockito full time, so I can join this group, but not be a key member.

Thanks
Philip

[Rafael Winterhalter]

Hi,

for my part, this is the best way to go forward. mockito-android was added in a period where the dexmaker did not seem active and it suggested to be an easy addition which worked well in the begining. I have personally hoped that the Android VM would converge more towards OpenJDK over time but this does not seem to be the case. I am not working with Android in my professional life, it is therefore a bit too much for me to support the artifact as things in the Android space constantly change and break. If someone with a stake in Android did the work, I think this would be a better way to offer support for Mockito.

Best regards, Rafael

--
You received this message because you are subscribed to the Google Groups "mockito-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mockito-dev...@googlegroups.com.
To post to this group, send email to mocki...@googlegroups.com.
Visit this group at https://groups.google.com/group/mockito-dev.
For more options, visit https://groups.google.com/d/optout.