Específica de la arquitectura Eclipse Plug-in Fragments

Question

Me necesidad de dirigirse tanto win32.x86 y win32.x86_64 arquitecturas en la construcción de un plug-in de RCP que los usos OS.getRegOpenKey (...). Los tipos de los argumentos del método son diferentes para las dos arquitecturas.

Ahora entiendo que no hay manera fácil de tener un fragmento de x86 o x86_64 (dependiendo de la construcción) reemplazar un método en mi anfitrión plug-in.

Sin embargo, desde este post suena como una lata fragmento, por ejemplo, añadir una clase que se extiende una clase en el huésped. Y el plugin anfitrión puede entonces utilizar explícitamente el cargador de clases para encontrar y crear una instancia de la subclase correcta del fragmento incluido en la acumulación de esa arquitectura. ¿A qué se parecería?

Answer 1

Sobre la base de la ligada al puesto, esto es lo que tengo hasta ahora (construye sin error ahora para ambas arquitecturas, y yo sólo hay que ver si la aplicación integrada de 64 bits se ejecutará en Windows de 64 bits!):

fragmento de plug-in asistente de Uso Eclipse para crear los fragmentos x86 y x86_64. Los manifiestos tienen un par de líneas extra añadido manualmente. Por ejemplo, los bits importantes de MANIFEST.MF del fragmento x86_64:

...
Bundle-SymbolicName: com.company.product.win32.x86_64;singleton:=true
Fragment-Host: com.company.product.win32;bundle-version="1.0.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Eclipse-PlatformFilter: (& (osgi.os=win32) (osgi.arch=x86_64))
Bundle-ClassPath: src/,. 

A continuación, subclase añadido al fragmento (utilizado el mismo nombre de paquete como la super clase desde el host plug-in, pero que probablemente no es necesario):

package com.company.product.win32;

import org.eclipse.swt.internal.win32.OS;
import org.eclipse.swt.internal.win32.TCHAR;

/**
 * Subclass the host's abstract OSUtilities
 */
public class OSUtilities64 extends OSUtilities {

    public String getRegKeyValue (String path, String key) {
         long [] phkResult = new long [1];
         if (OS.RegOpenKeyEx ((long) OS.HKEY_LOCAL_MACHINE, new TCHAR(0, path, true), 
             0, OS.KEY_READ, phkResult) != 0) {
    ...

Lo mismo para la clase OSUtilities32.

Añadido los fragmentos a la feature.xml que contienen el anfitrión plug-in:

   <plugin
     id="com.company.product.win32"
     os="win32"
     download-size="0"
     install-size="0"
     version="0.0.0"
     unpack="false"/>
   <plugin
     id="com.company.product.win32.x86"
     os="win32"
     arch="x86"
     download-size="0"
     install-size="0"
     version="0.0.0"
     fragment="true"
     unpack="false"/>
   <plugin
     id="com.company.product.win32.x86_64"
     os="win32"
     arch="x86_64"
     download-size="0"
     install-size="0"
     version="0.0.0"
     fragment="true"
     unpack="false"/>

A continuación, el anfitrión plug-in puede cargar estáticamente el apropiado, clase disponibles:

/**
 * Get class from appropriate fragment
 */
public static OSUtilities getOSUtilities() {
    ClassLoader loader = OSUtilities.class.getClassLoader();
    try {
        Class<?> cls;
        try {
            cls = loader.loadClass("com.company.product.win32.OSUtilities32");
        } catch (ClassNotFoundException e) {
            cls = loader.loadClass("com.company.product.win32.OSUtilities64");
        }
        OSUtilities util = (OSUtilities) cls.newInstance();
        return util;

Debería utilizar la propiedad de la arquitectura del sistema para recoger los cuales instanciar -. Tarde