Repackaging of batik causes huge lag on first use

[Kellindil]

Hello ed,

With 6e25ee9 you've added the "Eclipse-BuddyPolicy: dependent" header to batik.

Using that version of batik, I'm observing a very long freeze of eclipse on the first use of anything that tries to use SVG files.
When using a sirius (Capella) based product, the first creation of a SVG node in a diagram takes up to 30 seconds because batik now tries to look inside (seemingly) every single jar of the platform to find its services, due to the buddy policy.

Could we have more information on why you added that header? Was there a bug with batik without it?

[merks]

These bundles have service registrations that rely on class loader visibility:

org.apache.batik.codec_1.17.0.v20231009-1000.jar
        0  2023-08-21 11:37   META-INF/services/
     1503  2023-08-21 11:37   META-INF/services/org.apache.batik.ext.awt.image.spi.ImageWriter
     1290  2023-08-21 11:37   META-INF/services/org.apache.batik.ext.awt.image.spi.RegistryEntry
org.apache.xmlgraphics.source_2.9.0.v20230916-1600.jar
org.apache.xmlgraphics_2.9.0.v20230916-1600.jar
        0  2023-08-21 12:21   META-INF/services/
       48  2023-08-14 13:10   META-INF/services/javax.xml.transform.URIResolver
      273  2023-08-14 13:10   META-INF/services/org.apache.xmlgraphics.image.loader.spi.ImageConverter
      407  2023-08-14 13:10   META-INF/services/org.apache.xmlgraphics.image.loader.spi.ImageLoaderFactory
      448  2023-08-14 13:10   META-INF/services/org.apache.xmlgraphics.image.loader.spi.ImagePreloader
      321  2023-08-14 13:10   META-INF/services/org.apache.xmlgraphics.image.writer.ImageWriter

If I recall correctly, it's specifically ImageWriter registered by org.apache.batik.codec that's not found by org.apache.xmlgraphics.
I'm not sure if there were other Class.forName issues as well; it's been a few months...

In principle it's possible to split up the recipes and use https://wiki.eclipse.org/Context_Class_Loader_Enhancements#Eclipse-RegisterBuddy to be more selective, but there needs to be a faster feedback cycle so that I can test that it does not break existing things (BIRT) while improving performance for your use case. Of course I only expect it to look for services in jars that are downstream of batik, but given the platform is using it, that can be quite a lot of bundles... I'm not sure what would be special in Capella. Just bigger and more things downstream from batik?

[merks]

Thanks for the confirmation guys! Now I have peace of mind!! ☺️

[pcdavid]

on monday I'll rebuild a GMF Runtime using the (hopefully) final v20231215-1130 to check again.

It's at https://download.eclipse.org/modeling/gmp/gmf-runtime/updates/milestones/S202312180813/

[ldelaigue]

I'm rebuilding against this gmf-runtime milestone for a last check, will keep you posted :)

[ldelaigue]

I confirm that the performance degradation we had noticed is no longer there. Thanks guys!

[merks]

That's great! Yeah!!