Only import errorprone.annotations with optional (if at all)

[laeubi]

Gson version

2.12.0

Java / Android version

any java version

Used tools

• Maven; version:
• Gradle; version:
• ProGuard (attach the configuration file please); version:
• ...

Description

Currently the gson release requires in its manifest:

com.google.errorprone.annotations;version="[2.36,3)"

this requires to pull in the error prone annotations to the OSGi runtime.

Expected behavior

The annotations should only be imported with optional

com.google.errorprone.annotations;version="[2.36,3)";resolution:=optional

because they are not interesting/required at runtime, see also

• Make annotations class retention only error-prone#4797

or not imported at all.

[eamonnmcmanus]

See this comment and the discussion it links to. Unless you have reason to think the situation has evolved, this doesn't seem like something we want to change.

[laeubi]

Unless you have reason to think the situation has evolved, this doesn't seem like something we want to change.

Maven optional (compile time) is something completely with OSGi optional (runtime), the jar is already compiled at this stage so it can't lead to any "cryptic compiler message", so I'd like to ask to reopen this please!

[chrisrueger]

@eamonnmcmanus I support @laeubi in this regard and would encourage to reopen.

This topic is similar to my work done in #2735 and is about runtime and resolving bundles in an OSGi context. Without resolution:=optional all OSGi applications now need to add error-prone as a runtime depedency to their OSGi applications.

[laeubi]

Especially the last version of the artifact don't seem to use that header at all

[eamonnmcmanus]

OK. To be honest, OSGi support is something of an annoyance to the project maintainers, since none of us has expertise in it or uses it in any way. As recently as yesterday I was forced to spend quite some time figuring out how to adjust the OSGi configuration, and I seriously contemplated just removing it from the project. However, apparently some people do need it, presumably because of Eclipse, and this change is probably harmless.

[iloveeclipse]

Is there a chance to release 2.12.1 ASAP with this fix?

[eamonnmcmanus]

Is there a chance to release 2.12.1 ASAP with this fix?

Has something changed to make this urgent? Was the situation not already the same with 2.11.0, released last May?

[iloveeclipse]

Has something changed to make this urgent? Was the situation not already the same with 2.11.0, released last May?

2.12.0 was released and people / projects will update to it like in eclipse-platform/eclipse.platform.releng.aggregator#2794

[HannesWell]

OK. To be honest, OSGi support is something of an annoyance to the project maintainers, since none of us has expertise in it or uses it in any way. As recently as yesterday I was forced to spend quite some time figuring out how to adjust the OSGi configuration, and I seriously contemplated just removing it from the project. However, apparently some people do need it, presumably because of Eclipse, and this change is probably harmless.

I think you can ping everybody involved in this issue (including myself) in case you need assistance with OSGi or the configuration of the bnd-maven-plugin in the future.

[eamonnmcmanus]

2.12.0 was released and people / projects will update to it like in eclipse-platform/eclipse.platform.releng.aggregator#2794

That doesn't really answer the question. You're asking me to do something ASAP and I'm asking you what has made it so suddenly urgent. Apparently people have been living with the current situation for a long time.

I'm a little reluctant to make another release a few days after the last one, if only because of the churn it may cause for client projects.

[iloveeclipse]

Apparently people have been living with the current situation for a long time.

Umm. The problem appears first with 2.12.0 version, so 3 days is not a long time :)

Especially because the problem just happened it would be beneficial for all OSGI consumers to get immediate hotfix.

[eamonnmcmanus]

I see. Can you or @HannesWell help me understand why the problem occurred with 2.12.0 and not 2.11.0?

[iloveeclipse]

I see. Can you or @HannesWell help me understand why the problem occurred with 2.12.0 and not 2.11.0?

The manifest of 2.12.0 says OSGI to require errorprone annotations bundle, 2.11.0 manifest doesn't have this dependency at all.

So whoever had dependency to gson but never had errorprone annotations can't update now without additionally install errorprone dependency as in eclipse-platform/eclipse.platform.releng.aggregator#2794

[eamonnmcmanus]

Do you know what changed to cause that addition to the manifest?

[iloveeclipse]

Not a slightest idea. @laeubi and @HannesWell are much more familliar with the build tooling around maven.

[chrisrueger]

help me understand why the problem occurred with 2.12.0 and not 2.11.0?

@eamonnmcmanus

Let me try, because I had a look at bnd today:

I believe it happened because

• gson 2.11.0 was released on May 20th before PR Add @CheckReturnValue to our packages. #2693 was merged ([2.11.0] error_prone_annotations dependency #2676) which introduced the @CheckReturnValue annotation.

• @CheckReturnValue has @Retention(RUNTIME)

• because of @Retention(RUNTIME) bnd recognizes it as a runtime dependency and adds it to Import-Package

• I found also Make annotations class retention only error-prone#4797 related to this. I believe (not 100% sure) if @CheckReturnValue annotation would be @Retention(CLASS) instead, com.google.errorprone.annotations would not have appeared in the manifest.

Thus in order to opt-out and say "No we do not use it at RUNTIME, and it is fine to be optional", the OSGi Manifest needs to be manually adjust via resolution:=optional, which is what @laeubi did.

[eamonnmcmanus]

OK. I will make another release, but I have to say that you OSGi guys are making a lot of work for other people. Perhaps there is some way to avoid that?

[chrisrueger]

I will make another release, but I have to say that you OSGi guys are making a lot of work for other people. Perhaps there is some way to avoid that?

Thanks a lot.
I will try to bring up this question to the next OSGi working group meeting, to discuss options.

[eamonnmcmanus]

Thanks a lot. I will try to bring up this question to the next OSGi working group meeting, to discuss options.

Much appreciated!

[laeubi]

@eamonnmcmanus First thanks for working on this I can understand it is annoying. But on the other hand it is also annoying for consumer of such a (widely used) library if things "suddenly" go in the wrong direction.

It is a bit hard to help/improve if we not know what are the problems you have had here:

As recently as yesterday I was forced to spend quite some time figuring out how to adjust the OSGi configuration

so if there is any problem/question you can of maybe just ping anyone recently adjusted that configuration (like @chrisrueger ) and I'm sure they will help. I think for general OSGi question one can even ask here.

Beside that I have opened this ticket, I really don't see any value (beside confusing people and tools) that these error prone annotation are available at RUNTIME:

• Make annotations class retention only error-prone#4797

I don't use error prone at all so its hard to tell, but from the description:

Error Prone is a static analysis tool for Java that catches common programming mistakes at compile-time.

the CLASS or even SOURCE retention policy should be enough and would make this annotation much less intrusive (and probably even let the strange compile errors go away).

[laeubi]

I also created:

• If a package imported is only containing annotation, make the import optional by default bndtools/bnd#6454

[HannesWell]

• @CheckReturnValue has @Retention(RUNTIME)

This sounds very plausible for me. If one wants to be very sure. One could revert the commit that adds these annotations locally and re-build GSON without the change that makes the errorprone-annotations optional explicitly.

[eamonnmcmanus]

It is a bit hard to help/improve if we not know what are the problems you have had here:

As recently as yesterday I was forced to spend quite some time figuring out how to adjust the OSGi configuration

so if there is any problem/question you can of maybe just ping anyone recently adjusted that configuration (like @chrisrueger ) and I'm sure they will help. I think for general OSGi question one can even ask here.

For the record, this was in the context of #2793. OSGiManifestIT detected a new dependency on com.google.common.collect, because of a Class.forName call I think. I had to figure out why the test was failing and what I needed to do to address that. I also took a while to figure out what the correct syntax of the Import-Package header was. Nothing really hard, but also nothing I felt it was productive for me to spend time on.

As it turns out, I am dropping that PR anyway.