PF4J 4 roadmap

[decebals]

I think that is time to talk about PF4J 4.x roadmap.
PF4J is maintained under the Semantic Versioning guidelines, so in a new major version (4.0 in our case) we can make incompatible changes in our API.
Now is time to improve PF4J without to care about backward compatible.

I will try to add some proposes:

• Migrate to Java 11
• Async APIs (Async APIs #269)
• List all extension points and extensions for a plugin (List all extension points and extensions for a plugin #207)

The list with proposes will grow in time.

If you think that something is bad designed or you want to change something in the current API, please add a comment.

[rmrodrigues]

Hi @decebals ,
I think we have to create a more complex DEMO app.
Example: Create a web-app to export a list of data where each plugin represents export formats such as:

MS Office plugin:

• Excel
• CSV
• Word

Open Office plugin:

• ODT

Generic plugin:

• Text

This dame could provide a plugin manager web based with the following actions:

• Install/uninstall plugins
• Start/Stop plugins

[decebals]

Hi @rmrodrigues
Now, the PF4J ecosystem is big enough. I see a lot of applications that use PF4J with success together with Vert.x, Spring Boot or other frameworks. I think we don't lack projects that show how to use PF4J.
I want to focus on PF4J and not on how to integrate Excel, Word or something similar.

[rmrodrigues]

@decebals the idea is not to integrate with Excel and Word. It's just a more complex use case using the framework.

[fendo8888]

Looking forward to an example

[decebals]

@fendo8888 What is wrong with demo (https://pf4j.org/doc/demo.html)?

[fendo8888]

@decebals I have seen that demo, I mean an example of the integrity of a replication point

[fendo8888]

When will version 4.0 come out, big brother

[decebals]

@fendo8888 Nothing concrete until now, I cannot give you an estimation. It's a community driven project so the roadmap is entirely dictated my community. As I have not seen a high demand for the points proposed in this issue, so it is not a top priority :).
We will see.

[hank-cp]

@decebals I would like to have more fine-grained controll on PluginClassLoader. In my project sbp, I have to do some hack to achieve my purpose. For example, I need to control some resouces get loaded from application or plugin only. That's kind of painful everytime when I upgrade pf4j versions.

Another thought, for extension, could we have kind of exclusive extension, could only be extent by only one plugin, and application throw error when more than one plugin trying to extend this exclusive extension?

[decebals]

@decebals I would like to have more fine-grained controll on PluginClassLoader. In my project sbp, I have to do some hack to achieve my purpose. For example, I need to control some resouces get loaded from application or plugin only. That's kind of painful everytime when I upgrade pf4j versions.

I see some requests for plugin encapsulation (from security point of view). A plugin to be run in a kind of sandbox, to be able to access only specific resources (file system, ,,,). We need here a clear definition of the problem to be able to sketch a solution (API). PluginClassLoader was enhanced constantly (add support for different strategies for loading classes and resources) but of course is room for better. Did you tried to extends PluginClassLoader in your library and inject your custom version in pf4j via AbstractPluginManager#createPluginClassLoader?

Another thought, for extension, could we have kind of exclusive extension, could only be extent by only one plugin, and application throw error when more than one plugin trying to extend this exclusive extension?

I think here that this feature is a (very) particular use case. pf4j is very extensible (my opinion) and it's a chance to be able to implement this feature with some custom code. If you find that is not possible, we cand improve de API to allow this thing.

[wolframhaussig]

@decebals I would prefer to keep the Java 8 compatibility. A lot of users are still on the openJDK 8 which is still supported for a while (e.g. Azul supports their openJDK 8 until 2030). Migrating to Java 11 would prevent those users from benefitting from new features in pf4j.

[decebals]

@decebals I would prefer to keep the Java 8 compatibility. A lot of users are still on the openJDK 8 which is still supported for a while (e.g. Azul supports their openJDK 8 until 2030). Migrating to Java 11 would prevent those users from benefitting from new features in pf4j.

@wolframhaussig What you said makes sense. Thanks for your feedback and implications (I see some activity on your part on this project and I'm happy about that).

[decebals]

Avoid passing entirely PluginManager to PluginWrapper and use a new PluginContext component as bridge between plugin and the plugin manager. For more details #450 (comment).

[wolframhaussig]

maybe switch the DefaultVersionManager from jsemver to semver4j (see PR for semver4j #454)?

[decebals]

Avoid passing entirely PluginManager to PluginWrapper and use a new PluginContext component as bridge between plugin and the plugin manager. For more details #450 (comment).

The main problem here is related to backward compatibility (they are many applications that uses pf4j for modularity and I don't want to force a modifications off all these plugins because the API was modified).

[slovdahl]

Async APIs (#269)

More than 5 years has passed since the initial request for this, and the demand for async APIs in pf4j seems to be quite low overall. I recognize that there are and will be a lot of applications out there using async/reactive idioms for a long time to come, but given that the Java ecosystem is moving towards Virtual Threads (officially supported since JDK 21 and JEP 444) and doubling down on synchronous APIs, maybe it isn't worth the extra maintenance effort?

[slovdahl]

Migrate to Java 11

Are there many pf4j users still in need of Java 8-compatibility? The overall feeling is that OSS libraries have quite actively started dropping support for Java 8 lately.

As for example Spring 6 / Spring Boot 3 bumped the minimum required version to Java 17, I would almost vote for going straight to 17 for pf4j as well, if there's consensus for bumping the minimum requirement.

[decebals]

Are there many pf4j users still in need of Java 8-compatibility?

It's an interesting question. I'm curious to hear some opinions.

[wolframhaussig]

Although I would not be affected as I am already using Java 21, I would hesitate to require Java 17+:
Spring 5 is still supported and it works with Java 8, so users may be affected. If you really want to, I would at least wait for Spring 5 to be EOL.
On another note, I don't know how many enterprise users this library has, but Azul Java 8 is supported until 2030, so it may be possible to really affect users here when removing support 6 years earlier.

[slovdahl]

Although I would not be affected as I am already using Java 21, I would hesitate to require Java 17+: Spring 5 is still supported and it works with Java 8, so users may be affected. If you really want to, I would at least wait for Spring 5 to be EOL. On another note, I don't know how many enterprise users this library has, but Azul Java 8 is supported until 2030, so it may be possible to really affect users here when removing support 6 years earlier.

The Spring 5 OSS EOL date is not that far away (~5 months):

https://spring.io/projects/spring-framework#support

But yeah, it's true that Java 8 will still be freely available and supported for quite a few years. Unless it requires/starts requiring a big burden to maintain Java 8 support going forward, maybe it's fine to keep the support.