Фрагменты архитектуры Eclipse для конкретной архитектуры - PullRequest
Новая
       10

Фрагменты архитектуры Eclipse для конкретной архитектуры

0 голосов
/ 07 июля 2010

Мне нужно ориентироваться как на win32.x86, так и на win32.x86_64 при создании подключаемого модуля RCP, использующего OS.getRegOpenKey (...).Типы аргументов для метода различны для двух архитектур.

Теперь я понимаю, что не существует простого способа заставить фрагмент x86 или x86_64 (в зависимости от сборки) переопределить метод в моем плагине хоста.

Однако из этого поста похоже, что фрагмент может, например, добавить класс, расширяющий класс в хосте.И плагин хоста может затем явно использовать ClassLoader для поиска и создания экземпляра правильного подкласса из фрагмента, включенного в сборку этой архитектуры.Как это будет выглядеть?

1 Ответ

0 голосов
/ 07 июля 2010

Основываясь на связанном посте, это то, что у меня есть (сборка без ошибок теперь для обеих архитектур, и мне просто нужно посмотреть, будет ли встроенное 64-битное приложение работать на 64-битной Windows!)

Используйте мастер подключаемых модулей Eclipse для создания фрагментов x86 и x86_64.В манифестах есть несколько дополнительных строк, добавленных вручную.Например, важные биты фрагмента x86_64 Manifest.mf: 

...
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/,.

Затем добавили подкласс к фрагменту (использовал то же имя пакета, что и суперкласс из подключаемого модуля хоста, но это, вероятно,необязательно): 

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) {
    ...

То же самое для класса OSUtilities32.

Добавлены фрагменты в файл feature.xml, содержащий плагин хоста: 

   <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"/>

Затем плагин хоста может статически загрузить соответствующий доступный класс: 

/**
 * 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;

Я должен использовать системное свойство архитектуры, чтобы выбрать, какой экземпляр создать - позже.

...