I found the plugin system difficult to use. I see from the source that the PluginLoader class is supposed to find the native library in the same directory as the jar, but it didn't seem to work. Worse, I didn't get any sort of error or message or anything on standard output or standard error about the failure. (I think I may have been using an older version, since the 1.1.0 source appears to have fixed that.)
Now that I've looked at the source and discovered what I need to do, I'm not too happy with the steps required to use it. I sure wouldn't expect users to set up such things.
I'd like to suggest making use of Java's own "SPI Jar" specification:
http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20ProviderPretty short read, isn't it? It does everything the Plugins class does, and it's a Sun standard that's already used by New I/O, XML parsing, sound, Image I/O, and input methods. I've used it in projects both at work and at home, and it works quite well.
The easiest way to use it is with the javax.imageio.spi.ServiceRegistry class, which despite its package works with any SPI jar. (There's also a sun.misc.Service class, but relying on an undocumented sun.* class is not wise.)
One thing the Plugins package does which SPI jar doesn't do, is provide a ClassLoader that can find a native library which is simply in the same directory as a jar file. While I understand the reason for that functionality, I can't help feeling like that's the job of the installation process: put jinput.jar and linux-jinput.jar (or whatever) in ${java.home}/lib/ext, put the native library in ${java.home}/lib/${os.arch}, and if we're using the SPI jar approach, there's no more setup to do. No system properties, no extra classpath. Developers would still use ControllerEnvironment.getDefaultEnvironment().