Register protocol handlers in a lazy fashion

[laeubi]

Currently the activator loads the extension class what might trigger activation of bundles immediatly.

This changes to a more lazy aproach where the extension class is only loaded at frist use of the protocol.

[scottslewis]

Hi Christian,

On pr #52 you said:

To make certain: This change is only about doing things more lazily, right? There isn't some bug or semantic change that this is meant to address?

Correct, at least from my testing :-)

The reason I ask is that since this code used in Eclipse (p2) I recall something long ago about the p2 startup sequence (which I'm not completely familiar with) potentially requiring (at one point in the past if not now) a greedy startup/setting of the url stream handler service (maybe because equinox sets it as well?).

The handler is still eagerly registered, it is just delaying the loading of the implementation class until the first request is made to the handler, this is similar to changes in

[Scott] Yes I understand that. I also understand your general desire to make more things lazy but truthfully I don't know if this will have much effect in the Eclipse use case, as I'm pretty sure that p2 usually uses the protocol handler almost immediately after this bundle being activated (on Eclipse startup). So I will do some more looking and testing, and then include this in ECF next release, I may not do a next release anytime soon...for this change alone.

[laeubi]

I don't know if this will have much effect in the Eclipse use case, as I'm pretty sure that p2 usually uses the protocol handler almost immediately after this bundle being activated (on Eclipse startup).

The handlers are collected by Equinox right now (but even this will be improved here https://github.com/eclipse-equinox/equinox/pull/290) but even then the class from the extension will only be loaded after a URL of that Type is actually called the first time, so the crucial part is the delaying of the configurationElement.createExecutableExtension until one really calls a method on the interface.

So I will do some more looking and testing, and then include this in ECF next release, I may not do a next release anytime soon...for this change alone.

No problem I think it can wait until the next regular release maybe we can even sort out the problem with JavaHttp11 as well :-)

[laeubi]

The build currently fails with:

[ERROR] org.eclipse.ant.core 3.7.0.v20230329-1001 requires Execution Environment that matches (&(osgi.ee=JavaSE)(version=17)) but the current resolution context uses [a.jre.javase 11.0.0]
[INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true, osgi.arch=x86_64}
[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: org.eclipse.ant.core 3.7.0.v20230329-1001
[ERROR]   Missing requirement: org.eclipse.ant.core 3.7.0.v20230329-1001 requires 'osgi.ee; (&(osgi.ee=JavaSE)(version=17))' but it could not be found

So it seems you need to update your build infrastructure to Java 17 now, I also noticed that you are still using Tycho 2.7.5 with pom.xml maybe you want to upgrade to a pomless build with a more recent Tycho: https://tycho.eclipseprojects.io/doc/4.0.0/StructuredBuild.html

this will also make version bumps a bit easier as one only need to edit the manifest file.

[scottslewis]

The build currently fails with:

So it seems you need to update your build infrastructure to Java 17 now,

I don't have time for this at the moment.

I also noticed that you are still using Tycho 2.7.5 with pom.xml maybe you want to upgrade to a pomless build with a more recent Tycho: https://tycho.eclipseprojects.io/doc/4.0.0/StructuredBuild.html

this will also make version bumps a bit easier as one only need to edit the manifest file.

I'm hesitant to use pomless builds for all of ECF, and I don't want to have a combination of pom/pomless. We struggled for literally years with meeting all the releng needs for all of ECF, dependents (Eclipse), build infrastructure/versions of maven/Tycho that weren't fully debugged/tested, and subsequent loss of releng resources (i.e. I've been doing most releng myself for a few years now...and it's not really 'my thing').

So, if you can marshal resources for using pomless builds then I'm generally fine with it...once in place and tested...but I won't be able to do it myself. Feel free to open new issues if you like.