pico-args VS Mockito

That's because the maintainer does not consider it an issue but an implementation detail: https://github.com/RazrFalcon/pico-args/issues/15

Maybe pico-args then?

If I forget to get around to it, would you mind poking RazrFalcon/pico-args about adding it to the comparison chart? I really like using that thing as something I can link people to with just a quick explanation of that particular trade-off.

If fewer dependencies is better, you can't get much fewer than pico-args, which has zero dependencies.

You might also want to check out pico-args, Gumdrop, and lexopt to see if any of them meet your needs.

For example, The Rust compiler isn't slow; we are. and pico-args: Alternatives.

For example, I'd love to go from StructOpt to Gumdrop for parsing command-line arguments and cut my compile times and output size by an order of magnitude, but Gumdrop uses String internally, which means it'll panic if it encounters a Windows path with un-paired surrogates or a mojibake'd posix path... some of which I actually have.

Mockito 5 Released (1 min)🎉 https://github.com/mockito/mockito/releases/tag/v5.0.0

For those using a "release" testBuildType for integration tests, what does your mocking setup look like? My app is stuck on Mockito 2.23.4, because higher (> 1.8.12) versions of Byte Buddy required beyond that point [do not play nicely with non-debuggable APKs](https://github.com/mockito/mockito/issues/2302). Solutions I've considered so far:

Mockito

The code is pretty self explanatory but here's a quick run down. o.getClass().getDeclaredFields() gets us an array of all the fields. We then have a enhanced for loop that loops over the array. Check if the field is annotated field.isAnnotationPresent(Gucci.class). If it is then we set its modifier to true with field.setAccessible(true);. If we don't do this and the field is private we will get an error. Then we get the binary name of the field, field.getGenericType().getTypeName();, remember its just the package and the class name. Lastly we set the value of the field, field.set(o,dynamicInjection(classLoader,binaryName). With that we have now created a dependency injection annotation with the Junit 5 extension model. Now I am sure you can see the tower of exceptions, which is obviously not ideal. I'm not sure how I want to handle all the exceptions yet. However, I will be digging around the Mockito code base to see if I can find how they handle all their exceptions.

Mockito 3.11.* releases

Hi, I've been trying to write parquet files on android for the past couple of days, and have really been struggling to find a solution. My original hypothesis was to just use the java parquet implementation (https://github.com/apache/parquet-mr), but I've since realized that not all java libraries play well with Android. I've gone through essentially dependency hell trying to franken-fit the library into my project, and imported as much as i could before hitting walls such as this one (https://github.com/mockito/mockito/issues/841).