XtextResourceSet.getResource keeps creating resources, because they are never placed in the resource map.

[JoeryDev]

XtextResourceSet.getResource(URI uri, boolean loadOnDemand) overrides ResourceSet.getResource(URI, boolean), presumably because of the 'URI normalization' which I think was added because of https://bugs.eclipse.org/bugs/show_bug.cgi?id=399771.
Contrary to ResourceSet.getResource though, XtextResourceSet.getResource never places the result of demandLoadHelper in the map obtained from getURIResourceMap(). As a consequence, the Resource can never be obtained from the map, so demandLoadHelper keeps getting called.

[cdietrich]

Can you please give more details on the scenario you are observing this

[JoeryDev]

I'm simply editing a file. Every edit leads to a new Resource instance.

[JoeryDev]

For completeness, resourceLocator = null, so the call to super.getResource(uri, loadOnDemand) is bypassed.

[cdietrich]

Can you provide stacktraces ? Eg in validation job I think it’s expected . For the others I guess we release anyway

[JoeryDev]

I'm sorry, that's going to be difficult, because this is on a secure network. I think it's quite easy to see that the result of demandLoadHelper is not placed in the map though. If you aim to reproduce this, I would write something that calls getResource twice in a row with the same URI. Also, if this is indeed a bug, it's been in there for years, so no hurry ;)

[cdietrich]

The question is if it is a feature cc @szarnekow

[JoeryDev]

Ah yes, not sure if this is related, but I was wondering how edited resources are distinguished from unedited ones, which seems of importance when resolving cross-references. That is to say, I would expect a cross-references to point at the unedited, saved version of a resource, whereas when validating the resource itself, it may be the edited version.

[JoeryDev]

I notice that the org.eclipse.xtext.build.IncrementalBuilder always unloads all changed resources anyway, which surprised me, but which suggests that the fact that the resource is not placed in the map may indeed not really be a problem. It does beg the question why the map is there in the first place. Note that reloading changed changed resources also means that their isModified flags are always false, which also surprised me.

[JoeryDev]

OK, apologies, this is not a bug. There were two red herrings here. Firstly, although at first glance the Resource seemed not to be registered in the map, it turned out that is was, only by way of a different route, namely by way of XtextResourceSet.ResourceList.inverseAdd(), which is called from demandCreateResource. The reason the resource wasn't found in the map was that my IncrementalBuilder (which I copied from a collegue) chose to unload all changed resources, which I think is the actual bug. The second red herring was that there was an additional call to unloadResources from installSourceLevelURIs, but this is a conditional one, and has no effect.