Support OSGi Annotations from R8 about eclipse.pde

[laeubi]

R8 also defines the org.osgi:org.osgi.service.feature annotations:

• https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.feature.html#org.osgi.service.feature.annotation.RequireFeatureService
• https://blog.osgi.org/2019/07/new-osgi-work-features.html
• https://projects.eclipse.org/projects/technology.osgi/releases/1.0-feature-service

[iloveeclipse]

Note: PR #234 causes a huge regression for compiling workspaces with plugins,
I'm mostly unable to work now using I20220802-1800 build because compiler needs ages now compiling a single bundle.
Compilation of entire workspace with lot of SDK bundles takes ~10 minutes instead of 1-2.

To reproduce: import jdt.core bundle in the workspace and do a clean build. It takes ages.

[iloveeclipse]

Looking on stack traces I assume it is org.eclipse.pde.internal.ui.annotations.OSGiAnnotationsCompilationParticipant that causes trouble. Consider to either disable that until performance issues are identified or make optional via preference, or fix performance issue.

Since I'm using nightly SDK builds for my daily work ("eat my own dog food"), I can't continue to do this anymore since I20220802-1800, so if there will be no real fix soon, I plan to disable new compilation participant today (there are no tests for that one anyway).

[laeubi]

@iloveeclipse I'll take a look at this, as you are more familiar with JDT, is there anything "wrong" in the usage or anything that could be performed better here? I assume it is common for code to inspect the Java-Files so I'm a bit astonished that this is causing such slow down?

[iloveeclipse]

@laeubi : sorry, I have no time to work on this.

Briefly looking on the code I assume isActive() doesn't work, as it seem to slowdown compilation of ALL projects, independently if there is any annotation setup (I assumed there is no changes in JDT so far to use new annotations).

Beside this, I'm not expert in JDT model / AST parsing, but I assume creating AST for every single file is might be the problem here.

May be @cdietrich has some hints here how one could speed that up:

eclipse.pde/ui/org.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/annotations/OSGiAnnotationsCompilationParticipant.java

Line 51 in 883fe14

public void processAnnotations(BuildContext[] files) {

[laeubi]

No problem I think I found a way to fix this for now, just need to get my SDK working again as I crashed it yesterday by merging the repositories and now Eclipse don't start up anymore :-\

[laeubi]

Briefly looking on the code I assume isActive() doesn't work, as it seem to slowdown compilation of ALL projects, independently if there is any annotation setup (I assumed there is no changes in JDT so far to use new annotations).

Good point, this is maybe useless and incurred a higher performance penalty than simply assume if its a PDE project this should be applied, I have copied that from the DS Annotations processor but really wonder if it is good for anything:

• Lets assume the annotation could be found, then i still need to check if the annotation is present
• If not, then it can't be used, and processing will not do anything anyways ...

[iloveeclipse]

@laeubi : please also consider to add a preference to turn this feature off, at least as long as it is in experimental state.

BTW, it would be nice if there would be explanation what actually the future is (from the user point of view), because #234 doesn't say anything concrete.

[laeubi]

I'll try to explain this a bit more detail in the N&N entry, but first this must be usable by the user :-D

[laeubi]

The metatype annotations should be supported as well, this requires

• eclipse-platform/eclipse.platform.releng.aggregator#653

as a perquisite.

[AlBundy33]

is it already possible to disable this feature?
this still seems to impact the build time
-> in releases and not only i-builds

[laeubi]

is it already possible to disable this feature? this still seems to impact the build time

It is not possible to disable at the moment.

[AlBundy33]

what do you think about a temporary solution to disable this feature e.g. via system-property?
so we could test this on our machines