Supported 'install' and 'configuration' types in Equinox

[HannesWell]

I'm currently working on modernizing and cleaning up the Equinox launcher Main which includes replacing all deprecated File/Path.toURL() conversions and calls to the deprecated URL constructors.
While doing this I wondered if the OSGi install location (i.e. osgi.install.area) and configuration location (i.e. osgi.configuration.area) can really anything different than a local file-system path respectively a file-URL?

Both locations seems to be designed for arbitrary URLs, but there a multiple places were it looks like only file-URLs are supported.
If we would assume that both locations are always local file-system paths respectively a file-URLs, it would allow to simplify the code a lot.

@tjwatson, @laeubi or @merks can you tell if anything else than file(-URLs) really works for both of them respectively is relevant?

[merks]

After having fixed yet another decoding problem

eclipse-pde/eclipse.pde#1709

While looking at various other places that do such conversion it’s very clear that far too many places make bad assumptions that the URL is not encoded. Fixing things will definitely break things.

Goodness knows why URL is used when file: is widely assumed and then the proper encoding and decoding is simply a chaotic disaster.

[HannesWell]

After having fixed yet another decoding problem

eclipse-pde/eclipse.pde#1709

While looking at various other places that do such conversion it’s very clear that far too many places make bad assumptions that the URL is not encoded. Fixing things will definitely break things.

Yes, when I saw your fix, it reminded me of that general problem and my existing PRs in Equinox so I tried to described a bigger picture in

• Widespread wrong handling of space in File->URI->File conversion?! eclipse-platform/eclipse.platform#35 (comment)

Goodness knows why URL is used when file: is widely assumed and then the proper encoding and decoding is simply a chaotic disaster.

My assumption is that it was intended to be generic, but the question to me is, if it can be really used in such a generic way or can we just eliminate one source of complication here?

[merks]

One would expect URL.openStream to be used to read the content if a general URL is to be supported. But no, let’s convert to a File and assume the URL is not encoded.

Somehow this needs to be stamped out. Thanks 🙏 for trying.

[laeubi]

While doing this I wondered if the OSGi install location (i.e. osgi.install.area) and configuration location (i.e. osgi.configuration.area) can really anything different than a local file-system path respectively a file-URL?

OSGi is specifically designed to run on devices that even don't have a file system at all (e.g. embedded device). Also of course things can reside on any (non local) file system, this can be seen best in the javadoc of getDataFile()

This method will return null if the platform does not have file system support or this bundle is a fragment bundle.

That's also the reason why all API to access a bundle content is URL based

It would generally be better if OSGi has more support for Path API as a first step I created:

• [core] Support Path for bundle data osgi/osgi#824

[tjwatson]

OSGi is specifically designed to run on devices that even don't have a file system at all (e.g. embedded device). Also of course things can reside on any (non local) file system, this can be seen best in the javadoc of getDataFile()

OSGi spec sure, but no implementation I know of runs with no file system. I don't see Equinox changing here. We always expect a file system for persistent install area and configuration area. I suggest we don't complicate things thinking that will change in any foreseeable future.

[HannesWell]

OSGi is specifically designed to run on devices that even don't have a file system at all (e.g. embedded device). Also of course things can reside on any (non local) file system, this can be seen best in the javadoc of getDataFile()

OSGi spec sure, but no implementation I know of runs with no file system. I don't see Equinox changing here. We always expect a file system for persistent install area and configuration area.

Yes and even if Equinox itself would support different kind of locations, the launcher itself could be more restrictive and just support regular file-systems respectively file-URL (or whatever can be directly converted into a nio-Path).

I suggest we don't complicate things thinking that will change in any foreseeable future.

I'm also in favor of making that assumption explicit. Sounds good. I'll create corresponding PRs in the next days.