Nullable cause issues with OSGi #31
Comments
|
Mickael: no. We removed import-package directive from guava's manifest to workaround the issue locally. |
|
You can use the often-overlooked It's nearly equivalent to specifying |
|
You could use |
|
We could also consider introducing our own annotation, since we're using it only for (a) documentation of what elements may be null and (b) run-time checking of incoming and outgoing messages. In both cases we don't need the annotation to be from the "standard" javax.annotation package. The standard package could just be useful for interoperability with other findbugs-style tools. |
|
A possible hack would be that you include a copy of javax.annotation.Nullable in the bundle that requires it. |
|
Another workaround would be that the code lookup for Nullable via reflection and skip checks if not found Class<?> nullableClass = null;
try {
nullableClass = getClass().getClassLoader().loadClass("javax.annotation.Nullable")
} catch (NoClassDefFound e) {
// log Null check disabled
return;
}and make the import-package optional. |
|
The To clarify: the annotations are build-time artifacts, and not run-time artifacts. In Maven terms, you'd have a compile-time dependency on |
|
@briandealwis In this case, these annotations are used at runtime here to automate some checks in the marshaller/unmarshaller: https://github.com/TypeFox/ls-api/blob/master/io.typefox.lsapi.services/src/main/java/io/typefox/lsapi/services/validation/ReflectiveMessageValidator.xtend#L39 |
And instead of 2 different sources of the javax.annotation.Null annotations, we'll now have 3 :-) It's an ugly situation and with JSR-305 dormant, it doesn't look like it will get any better. I think I'd go with @spoenemann's suggestion to define your own annotations. At least you have control over them and you can add new annotations should you see the need instead of feeling shoehorned into an existing set. |
|
If we were introducing our own annotation we wouldn't leverage any nullable checkers. |
That's not true. See jgit/egit projects. JDT can be configured to use custom style annotations, and FindBugs accepts different package names for NP annotation types. |
|
It seems there are two separate issues:
|
|
We're going for a solution with catching NoClassDefFoundError where we read the annotations at runtime, and adding |
|
The only bundle I found so far is the |
|
It looks like |
|
I added a comment to the commit: the code there will work for a flat classpath. But when verifying a class under a managed classpath, you want to use the |
|
Thanks, the patch does its job so the ls-api works in OSGi world without complex classloading tweaks now. Should we close this report? |
|
thanks for trying. |
Intoduction of the dependency on Nullable make it complex to integrate ls-api in OSGI:
Import-Package: javax.annotationresolves to some other bundle that do not contain Nullable, driving to NoClassDefFound at runtimeorg.apache.servicemix.bundles.jsr305fromio.typefox.lsapivia a fragment leads to conflcts with guava resolving thejavax.annotationpackage from the JVM directlyBasically, the issue is that that the javax.annotation package is split across several sources: JVM, javax.annotation bundle, org.apache.servicemix.bundles.jsr305... OSGi cannot create a classpath merging all those splits.
@briandealwis @iloveeclipse: are you aware of any good way to simultaneously depend on guava and some jsr305 bundle?
The text was updated successfully, but these errors were encountered: