Question regarding extensibility

[Alan Bateman]

Marcel Ammerlaan wrote:
> The use case I'm working on is a container-like environment that hosts 
> a plugins (it's comparable to OSGi). The only stable entrypoint in the 
> JDK that the plugins can expect is the core java.nio.file.* classes: 
> they dont know which filesystems have been loaded. So the most likely 
> way to get a Path object is to use the Paths utility class to convert 
> a URI to a Path. In this case the custom Filesystem will not be found. 
> The workaround here would be to provide an alternative Paths-like 
> implementation that does
> keep a dynamic registry.
>
> The downside to this is that the plugin starts depending on this 
> container-like environment and cannot be reused independant of the 
> container (ie. standalone) without additional work.
>
> The other use-case is to provide an alternative provider. The provider 
> I'm currently working on is an HTTP provider. A basic one might be 
> readonly (ie. based on java.net.URL functionality) whereas a more 
> advanced provider might be loaded dynamically (quite possibly via the 
> naive HTTP filesystem) adds write-support (something like WebDav for 
> example). This provider can actually replace the old provider 
> completely for newly constructed Paths.
>
> Hopefully this gives some insight in how I will use the 
> java.nio.file.* stuff. The most likely workaround will indeed be a 
> custom registry that should be used by the plugins.
We don't have any plans at this point for a registry of providers. What 
we have now is a solution based on the service-provider loading facility 
that is used through-out the JDK. If your HTTP provider is on the class 
path and has the provider configuration file, then it will be located 
and loaded. Once jdk7 is further along then I would expect the service 
provider loading facility to be module-aware, in which case providers 
that are installed as modules should be available. For the environment 
that you describe then it would require a bit of thought as if its the 
container or the platform should keep the list of providers. It's not 
too different to maintaining a list of URL protocol handlers and other 
service providers for others APIs in the platform. Maybe when you are 
further along with this you could back to discuss this further?

-Alan.