This is a GTK bug, and should have a priority considerably higher than the present "low". (I do not know who can change priority, or where/how GTK bugs should be tracked.)
The GTK folk released an iteration of a shared library. The iteration was advertised as backwards compatible, but contained a change that broke compatibility with the Eclipse platform. A minor release (2.18?) should have no or minor effect on compatibility.
The GTK folk blew it. No doubt the change was well intentioned, and meant to be minor (as the release notes indicate) - but it turned out to have a large impact. (If you maintain shared libraries for any length of time, odds are good this will happen to you too, eventually.) The proper response is to remove the problem, which may also mean deferring the troublesome change to a major release.
The Eclipse folk are being helpful, and changing their code - but this only helps slowly and in future. For all the applications out there based on the Eclipse platform, the development and distribution practices are going to vary quite a lot. Not all are going to be based on the current version of Eclipse, and the cost to update those applications is not small.
The fact that Ubuntu package maintainer(s) are proactive in applying the Eclipse fix is great! ... but largely irrelevant. Not all the software in the world is going to be part of the package archive. (In my own case I have three - or more? - Eclipse-platform applications installed, none from the package archive, and all effected.)
The cost to fix this in GTK is small and coherent. The cost to "fix" this on the Eclipse side is going to be many times larger in time and trouble. In usual practice, a minor release of a widely-used shared library should not cause this sort of grief.
The GTK folk made a perfectly human goof - and need to deal with it.
This is a GTK bug, and should have a priority considerably higher than the present "low". (I do not know who can change priority, or where/how GTK bugs should be tracked.)
The GTK folk released an iteration of a shared library. The iteration was advertised as backwards compatible, but contained a change that broke compatibility with the Eclipse platform. A minor release (2.18?) should have no or minor effect on compatibility.
The GTK folk blew it. No doubt the change was well intentioned, and meant to be minor (as the release notes indicate) - but it turned out to have a large impact. (If you maintain shared libraries for any length of time, odds are good this will happen to you too, eventually.) The proper response is to remove the problem, which may also mean deferring the troublesome change to a major release.
The Eclipse folk are being helpful, and changing their code - but this only helps slowly and in future. For all the applications out there based on the Eclipse platform, the development and distribution practices are going to vary quite a lot. Not all are going to be based on the current version of Eclipse, and the cost to update those applications is not small.
The fact that Ubuntu package maintainer(s) are proactive in applying the Eclipse fix is great! ... but largely irrelevant. Not all the software in the world is going to be part of the package archive. (In my own case I have three - or more? - Eclipse-platform applications installed, none from the package archive, and all effected.)
The cost to fix this in GTK is small and coherent. The cost to "fix" this on the Eclipse side is going to be many times larger in time and trouble. In usual practice, a minor release of a widely-used shared library should not cause this sort of grief.
The GTK folk made a perfectly human goof - and need to deal with it.