[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[eclipse-dev] Eclipse on AMD64
|
If you develop plug-ins for Eclipse Platform 3.0 on AMD64 processors,
please read on.
In the 3.0 cycle we added early access support for 64-bit Linux GTK and
tested Eclipse using early access 64-bit J2SEs running on AMD64
processors. When we did this, we introduced a new processor architecture
constant, Platform.ARCH_AMD64, and used the string "amd64" (what the Sun
1.5 JVM returns) as the standard name for subdirectories that hold 64-bit
native libraries (e.g., for SWT).
It appears that the designation "x86_64" is taking hold in various
communities (e.g., http://www.x86-64.org/ ) as the preferred,
vendor-neutral designation of this processor architecture. Since
Eclipse.org is committed to vendor neutrality, we are revisiting this
issue for 3.1 (bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=81722).
For 3.1, we're planning to switch over to using the new designation
"x86_64" and constant Platform.ARCH_X86_64. The question is: What level of
backward compatibility support do we provide for "amd64"? In particular,
do we include binary compatibility support so that Eclipse 3.1 can load
Eclipse existing 3.0 plug-ins containing libraries in "amd64"
subdirectories?
We believe the segment of the Eclipse community currently vested in the
current choice of "amd64" is small, and that there would be almost no
impact to them from switching over in 3.1 to using the new designation
exclusively. Rather than building in extra backward compatibility
mechanisms that no one will ever use, we'd prefer to spend our resources
on other things.
Please speak up now you have reason to believe that our impact assessment
is off base, so that we can plan a bump-free migration path accordingly.
---jim
