Permissionsdispatcher: SupportV13MissingException when jack is enabled

[livotov]

After enabling the Jack, Im getting permissions.dispatcher.processor.exception.SupportV13MissingException: PermissionsDispatcher for annotated class 'MyFragment' can't be generated, because the support-v13 dependency is missing on your project



The v13 dependency is in place, it works fine if I switch back to apt plugin.

[mannodermaus]

Thanks for your report! I can reproduce the issue here.

We'd have to look deeper into what classpath Jack is provided with when invoking its annotation processors, because it doesn't seem to pick up on the support-v13 library. There's a simple Class.forName check here to determine if that library is available (more specifically, FragmentCompat), so that's really the only explanation I can come up with right now, as to why this lookup fails, even though the class is available to the application. It might also be that our "success-catch" isn't properly triggered from Jack, since it repurposes ClassNotFoundException for this.

[shiraji]

@aurae Could you provide a sample project and steps to repoduce this issue?

[mannodermaus]

Sure thing, I'll prepare that shortly.

[hotchemi]

Thx contributors! I'm still not sure this is our side bug since I dunno Jack will assure the classpath around behavior compatibility...I'll wait @aurae 's work:D

[livotov]

Thanks guys and great it's reproducible!

btw, @hotchemi , didn't you think to just make 2 extra modules, so one can include either one or another dependency, depending on support fragments usage, like

compile 'com.github.hotchemi:permissionsdispatcher:${latest.version}'
apt 'com.github.hotchemi:permissionsdispatcher-processor-support:${latest.version}'

or

compile 'com.github.hotchemi:permissionsdispatcher:${latest.version}'
apt 'com.github.hotchemi:permissionsdispatcher-processor:${latest.version}'

I suppose this could help with such weird autodetection issues

[hotchemi]

@livotov Thx! What's the difference between you suggested? Do you mean like exporting support native Fragment feature as another module dependency?

[livotov]

yeah, exactly, so one can simply add on or another "compile/apt" statement depending on the project. This could reduce some boilerplate if/else code in the library as well as make the library free from such classpath errors when jack or sms else will change again. Just a thought.

[mannodermaus]

Personally, I find the auto-detection route that we've been going down so far to be more elegant, since it doesn't really add any unnecessary boilerplate to the logic of our annotation processor. Therefore, I'm confident that we can make this work with Jack without having to introduce yet another artifact. Fingers crossed!

[hotchemi]

@aurae Can you take a look? 😃

[mannodermaus]

I'm out of the country at the moment, but it's on my backlog, yes!

[mannodermaus]

I've created a jack-based sample project in a dedicated branch within my fork to show off the issue. Running the sample:assemble task completes without error, running sample-jack:assemble fails with the error mentioned in the OP.
Please excuse the delay. 🙇

[hotchemi]

@livotov Can you check? https://github.com/hotchemi/PermissionsDispatcher/issues/220#issuecomment-266255116

[mannodermaus]

I meant that I only created a project that exposes the issue, I haven't done any work to actually fix it yet. :) I may have a time slot on the weekend open for this, however feel free to join in before that, guys!

[hotchemi]

Ah sorry! Take your time @aurae 🙇

[E3V3A]

Not sure if this helps, but I found this from here:

Known issues

Instant Run does not currently work with Jack and will be disabled while using the new toolchain.

Because Jack does not generate intermediate class files when compiling an app, tools that depend on these files do not currently work with Jack. Some examples of these tools are:

• Lint detectors that operate on class files
• Tools and libraries that require the app’s class files (such as instrumentation tests with JaCoCo)

If you find other issues while using Jack, please file a bug.

[mannodermaus]

I suppose the second bullet point is what applies to our issue at hand, yes. If Jack is unaware of the compile classpath during its runtime, there's little we can do to add this detection to it.

I mean, we could try to add an override flag to the annotation processor, for users that are certain of support-v13's presence inside their apps - kind of like a "manual mode", which would then take precedence over the dynamic Class.forName lookup we have right now. @hotchemi-san, @shiraji-san, what do you think?

[ankitbatra11]

Hi, is there an update on this? This is the only blocking step in upgrading my app to Jack compiler.

[shiraji]

I was thinking Jack is responsible for fixing this issue. However, since they don't handle this problem yet, we could provide a temporary solution like an override flag to skip the check which is what @aurae wrote. If Jack resolve this issue, I would like to remove the feature.

[hotchemi]

I think the most simple solution is using v4 Fragment(Ive never used normal fragment actually).
Why do you guys use normal Fragment?

[ankitbatra11]

I use PreferenceFragment that derives from android.app.Fragment in my
project.

On Tue 21 Feb, 2017, 07:13 Shintaro Katafuchi, [e-mail]
wrote:

I think the most simple solution is using v4 Fragment(Ive never used
normal fragment actually).
Why do you guys use normal Fragment?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/hotchemi/PermissionsDispatcher/issues/220#issuecomment-281221868,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGsjJ3l14w5d2lZ6R7kwhrn65_3VhFDNks5rekFbgaJpZM4K3_9E
.

[shiraji]

How about PreferenceFragmentCompat?

[ankitbatra11]

It's a lot of work in my project to convert to fragment compat as I have a
lot of settings screen. I would rather have this issue fixed or stay at
java 1.7.

On Tue 21 Feb, 2017, 11:53 Yoshinori Isogai, [e-mail]
wrote:

How about PreferenceFragmentCompat?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/hotchemi/PermissionsDispatcher/issues/220#issuecomment-281255993,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGsjJzNCgwMGalWiyMIMMcIE4kbochMIks5reoLqgaJpZM4K3_9E
.

[shiraji]

Can we close this?

https://android-developers.googleblog.com/2017/03/future-of-java-8-language-feature.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+blogspot/hsDu+(Android+Developers+Blog)

[hotchemi]

@livotov Unfortunately(or fortunately) Jack became obsoleted so we decided not to support it actively. On the other hand about implicit switching to not-v4 Fragment support I have some thoughts and will be discussing on https://github.com/hotchemi/PermissionsDispatcher/issues/254.
Thx for your report!