Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] Changed behaviour of PackageFragmentRoot.getHandleIdentifier

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

Спасение утопающих - дело рук самих утопающих
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?

Back to the top