Re: [jdt-dev] Changed behaviour of PackageFragmentRoot.getHandleIdentifi

[Andrey Loskutov <loskutov@xxxxxx>]

I assume the side effect was not eintended and we see that it causes troubles with Xtext, so I would recommend create a bug and discuss there what could be a fix / solution.
 

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov

 

 

Gesendet: Dienstag, 27. Oktober 2020 um 08:24 Uhr
Von: "Dietrich, Christian" <christian.dietrich@xxxxxxxxx>
An: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx>
Betreff: [jdt-dev] Changed behaviour of PackageFragmentRoot.getHandleIdentifier

 

Last year org.eclipse.jdt.internal.core.PackageFragmentRoot.getHandleMemento(StringBuffer)

was changed to include the extra classpath attributes into the handle identifier.

this requires org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath()

to be called (at least it is called for now)
although e.g. subclasses have org.eclipse.jdt.internal.core.JarPackageFragmentRoot.extraAttributes

this leads to the problem that getHandleIdentifier cannot be called if the caller does not have the workspace lock that is needed for resolveClasspath

 

is this side effect of the change intended?
can this be done in a better way?
should we mimic the behaviour of getHandleIdentifier to avoid the problem?