> >
> > Agreed. We will loosen the language in the javadoc to
> include at least those
> > two types, and I think in the end we should not even be
> that restrictive.
> > After this draft we will look at loosening the language and
> perhaps even
> > adjusting the API if necessary.
>
> Mike, as we've been discussing in our separate thread, the key is
> providing enough information in the spec that you can write a portable
> provider. Knowing that it can be any kind of URL at all isn't enough
> given what the provider has to be able to do. Requiring it
> to be either
> a file: URL or another URL from which you can get an InputStream that
> contains a jar file is sufficient, but let's just say it's not very
> object oriented. :-) Returning a new kind of object that abstracts
> the required operations, as Sahoo suggested, would be better, but I
> realize it's too late to fix that in this release.
Absolutely. I was suggesting that for this draft we should limit
the URL to be one of those two types, but that before we are final we
should loosen it further. As I mentioned, I am certainly not averse
to tweaking the API to accomodate an abstraction of that, just not
right now!