0

I would like to add some dynamic behavior to an application, preferably without resorting to reflection, so I am looking at object registration.

The approach I am thinking is simple: in a class (say Base) which gets to be loaded early enough, a registry (e.g., a HashMap) of plugin objects will be maintained, each of which will later on be used for invoking some of their methods.

The question is, how to register those plugins in Base without any prior knowledge of their existence (so that the application can be dynamically extended via more such plugins). Not knowing them beforehand means a ClassLoader or any reference to their classes cannot be used, thus even with static initialization, registration code cannot be added (since the plugin classes will not be loaded early enough, so the Base class will start executing without knowing them).

Is there any simple solution to the above scenario?

PNS
  • 19,295
  • 32
  • 96
  • 143

2 Answers2

1

There's several ways of implementing plugin mechanisms, ultimately you need to either scan for implementations of an interface or annotations. Is it important to you that you implement this yourself? There's already libraries that do this (jspf for example).

If you're not interested in reflection, then the code must either adhere to a known interface. Otherwise you'll need to use reflection somewhere to map between what the plugin class(es) provide, and what the "base" code knows how to call.

Dave Newton
  • 158,873
  • 26
  • 254
  • 302
  • Does this mean I should use an interface and, via reflection, retrieve all implementing classes? – PNS Dec 01 '11 at 16:16
  • @PNS That's one way, yes--there are others. Like I said, ultimately, you need to identify participating classes, and what they offer. There are various ways to do that. – Dave Newton Dec 01 '11 at 16:18
  • If there are several ways, could you name one? After 4 days of research (banging my head against the wall), it seems reflection cannot find classes or interfaces because you have to know the *"package name"* at compile time. Thus completely negating the entire purpose of trying to create a plug-in system. And Java doesn't have .NET's reflection system, nor does it have Delphi's *"unit initialization"*, or other languages *"static constructors"*. There seems to be no way to discover classes at runtime unless you know their names at compile time. – Ian Boyd Jul 22 '22 at 04:07
  • @IanBoyd I did; by scanning a jar file for classes (for example) etc. I also named a library that does it, although who knows if that decade-old reference still exists. There are multiple libraries that do it; clearly plug-in systems exist, so it must be possible. I’d suggest searching for things like “Java plugin system” or “Java plugin scanner” or something. While I’d no longer implement my own system, it’s a good exercise, and interesting. I’d use something already out there. – Dave Newton Jul 22 '22 at 12:57
  • All the plug-in systems seem to require that you add the name of the `package` to some configuration file somewhere. – Ian Boyd Jul 22 '22 at 14:11
  • @IanBoyd I haven’t found that to be the case, but YMMV. Again, if you search the web for Jar scanning you find multiple options, including libraries. The Baeldung article may prove insightful. – Dave Newton Jul 22 '22 at 14:52
  • My mileage certainly has varied. You can see my research effort [here](https://stackoverflow.com/q/73045692/12597) – Ian Boyd Jul 22 '22 at 15:09
0

could you use something like spring and dependency injection ? if you can, each plug in could be a initializing bean so its loaded on start up and in its init method call back to the base to register itself, if not through a direct dependency injection. that obviously uses reflection in background so not sure if that excludes this as your preferred solution...

on another note, typically, looking for classes is not fool proof esp if you could have multiple class loaders :-(

aishwarya
  • 1,970
  • 1
  • 14
  • 22