org.mockito:mockito-core - J2ObjC continuous build

[brunobowden]

Mocking framework for unit tests written in Java.

@szczepiq, @bric3 - FYI for you both. This is to support translation of your Java library to Objective-C such that it can be used on iOS. This bug is specifically for testing this as part of a continuous build using Google's J2ObjC conversion tool.

@advayDev1 FYI

[bric3]

I'm not sure how we can help on the matter. Looks a nice initiative though !

[brunobowden]

@bric3 - no action needed on your part for now. At some point we may ask for changes to Mockito but for lots of us the translated library library has been working well for some time.

[bric3]

ok great let us know your advances on the topic ;)

[advayDev1]

@bric3 - At the moment we are blocked on the issues mentioned here: https://github.com/google/j2objc/blob/master/testing/mockito/README

Those are all the modifications necessary to Mockito to have it work on iOS.

@brunobowden - I don't think we can do much here. j2objc's repo already has all the modifications needed to build Mockito in ObjC. And I assumed they won't be released to a jcenter jar.

[bric3]

Added a mock maker that works with iOS and Mac OS X.

That's indeed the appropriate way to support other mock makers.

Modified ClassPathLoader to load the iOS mock maker by default.

It shouldn't be necessary to modify this class, as the iOSMockMaker can be in another jar, just as long as our internal PluginLoader finds the mockito-extensions/org.mockito.plugins.MockMaker file in the classpath. (version 1.10.19, 2.0.x)

Stubbed out unused ASM and Cglib classes, removed use of Objenesis, since iOS doesn't support bytecode.

It shouldn't be necessary if the relevant mockmaker is used.

---

A side note, mockito 2.x is using bytebyddy instead of CGLIB.

[advayDev1]

Thanks @bric3; I'm cc-ing @tomball and @kstanger here who made those modifications to Mockito in the repo linked above. Tom and Keith - had you already considered what Brice mentions above (that fewer modifications to Mockito may be necessary) and found you still needed to make more changes?

[tomball]

What @bric3 says about other jars certainly works for Java jars and normal static libraries, but for testing on iOS we have a special weird case: to support successful loading of unreferenced classes, the test binary needs to be linked with every Objective C class. iOS runs apps in a sandbox that prohibits the loading of code from anywhere other than the main executable, so it all has to be included. I guess you can include all the bytecode support classes, but that adds a lot of useless code to each test binary (and of course, any requests to support bytecode on iOS will be cheerfully ignored :-).

The ClassPathLoader and other modifications may no longer be necessary, as j2objc's JRE support has grown quite a bit since we first supported Mockito. I felt an obligation then to get it done early, since that team was gracious enough to accept Jesse Wilson's and my MockMaker proposal so quickly.

[brunobowden]

@tomball, depending on what comes out of this, we'd be happy to host modifications to mockito on https://github.com/j2objc-contrib/, then we can build it continuously. That'll be a future activity, while we focus for now on libraries that are easier to support.

[bric3]

iOS runs apps in a sandbox that prohibits the loading of code from anywhere other than the main executable, so it all has to be included.

OK. I don't know much about iOS constraints, but maybe packaging all together and still using the PluginLoader mechanism could still work.

[advayDev1]

@brunobowden - we can actually submodule out to google/j2objc/testing/mockito. to do it in this repo would require translating their existing make magic to gradle (pretty simple). but it would then no longer build like j2objc's other modified libraries (which do not rely on gradle at all).

[brunobowden]

cc @kstanger

I expect we'll have a number of cases where we build an existing library with a small number of modifications, e.g. replacing certain files, disabling certain functionality and so forth. It sounds like Mockito will be one of those cases.

The question is where should those changes go?

As far as possible, it would be best to integrate them upstream in to the public Mockito repo, as has already happened with Guava 19.0-rc1. @tomball, are there any changes like that appropriate for Mockito?

If there aren't any remaining changes which are J2ObjC specific, that's the ideal and simplest case. If changes do remain, where should they go? The possible places Google, j2objc-contrib or the original repository. For many reasons, a library maintainer may be unwilling or unable to have "alien" J2ObjC specific files in their repo. I think the best answer is that changes should be in j2objc-contrib. This means that third-party developers can freely iterate and contribute, likely for many libraries that Google has no interest in.

For something like Mockito though, it's more sensitive for Google about accepting third-party code (if the changes were in j2objc-contrib). If the changes are modest enough in scope and likely stable over time, then it may be best to just maintain a duplicate copy of the code. That'd allow us to avoid the complexity of pulling in both j2objc-contrib and Google code. Normally I'd be against this as a bad code smell ("Number one in the stink parade is duplicated code" according to https://sourcemaking.com/refactoring/duplicated-code). In this case, I want to play devil's advocate.

@tomball, @kstanger - your thoughts on this?

[tomball]

I recommend lowering the priority on this library, or dropping it completely. Mockito is a weird and wonderful library that creates classes out of thin air, and so will need special handling on any platform. I should be able to reduce the size of its fork as Brice suggests, but investing the time to make it perfectly portable (if that's even possible) doesn't seem worth the small benefit, IMO.

On Mon, Sep 28, 2015 at 6:42 PM Bruno Bowden notifications@github.com wrote:

cc @kstanger https://github.com/kstanger

I expect we'll have a number of cases where we build an existing library with a small number of modifications, e.g. replacing certain files, disabling certain functionality and so forth. It sounds like Mockito will be one of those cases.

The question is where should those changes go?

As far as possible, it would be best to integrate them upstream in to the public Mockito repo, as has already happened with Guava 19.0-rc1. @tomball https://github.com/tomball, are there any changes like that appropriate for Mockito?

If there aren't any remaining changes which are J2ObjC specific, that's the ideal and simplest case. If changes do remain, where should they go? The possible places Google, j2objc-contrib or the original repository. For many reasons, a library maintainer may be unwilling or unable to have "alien" J2ObjC specific files in their repo. I think the best answer is that changes should be in j2objc-contrib. This means that third-party developers can freely iterate and contribute, likely for many libraries that Google has no interest in.

For something like Mockito though, it's more sensitive for Google about accepting third-party code (if the changes were in j2objc-contrib). If the changes are modest enough in scope and likely stable over time, then it may be best to just maintain a duplicate copy of the code. That'd allow us to avoid the complexity of pulling in both j2objc-contrib and Google code. Normally I'd be against this as a bad code smell ("Number one in the stink parade is duplicated code" according to https://sourcemaking.com/refactoring/duplicated-code). In this case, I want to play devil's advocate.

@tomball https://github.com/tomball, @kstanger https://github.com/kstanger - your thoughts on this?

— Reply to this email directly or view it on GitHub https://github.com/j2objc-contrib/j2objc-common-libs-e2e-test/issues/17#issuecomment-143920233 .

[brunobowden]

Thanks for your input @tomball. I'm closing this bug and so the J2ObjC Gradle Plugin will continue using the J2ObjC distributed version of Mockito. As and when you make upstream changes or have any other comments, please update this issue. We'll likely only open it again when and if you think it's advisable.