Действительно ли возможно вызвать собственную функцию CPP использование JNI, который берет универсальные аргументы? Что-то как следующее:
public static native <T, U, V> T foo(U u, V v);
И затем назовите его как:
//class Foo, class Bar, class Baz are already defined;
Foo f = foo(new Bar(), new Baz());
Кто-либо может предоставить мне образец, который на самом деле делает это или некоторое учебное руководство в сети, которая делает это? Я спрашиваю, потому что в моей функции JNI CPP (названный JVM), я получаю неудовлетворенную ошибку ссылки.
Код CPP следует:
JNIEXPORT jobject JNICALL Java_Processor_process (JNIEnv *env, jclass processor_class, jobject obj1, jobject obj2)
{
jclass bar_class = env->FindClass("Bar");
jmethodID getFooMethod = env->GetMethodID(bar_class, "getFoo", "()Ljava/lang/Object;");
//getFoo() is defined as `public Foo getFoo();` in Bar.java
return env->CallObjectMethod(obj1, getFooMethod);
}
Править:
Я попробовал путем изменения кода, но теперь я получаю NoSuchMethodError:
Код Java:
public static native <U, V> String foo(U u, V v);
//...
String str = foo(new Bar(), new Baz());
Код CPP:
JNIEXPORT jstring JNICALL Java_Processor_process (JNIEnv *env, jclass processor_class, jobject obj1, jobject obj2)
{
jclass bar_class = env->FindClass("Bar");
jmethodID getFooMethod = env->GetMethodID(bar_class, "getFoo", "()Ljava/lang/String;");
//getFoo() is now defined as `public String getFoo();` in Bar.java
return env->CallObjectMethod(obj1, getFooMethod);
}
Это означает, что JNI не имеет никакой поддержки дженериков, или я пропускаю что-то?
Думали ли вы о повторной привязке «C-x k» к буферу захоронения вместо буфера убоя? (При необходимости можно периодически очищать список буферов, например, «midnight.el».)
-121--2688336-Если я не хочу получить взрыв методов (OpenFormViewingScenario1, OpenFormViewingScenario2 и т.д.).
Нельзя удалить присущую сложность требований. Тем или иным пути необходимо обнаружить сценарий использования и действовать соответствующим образом.
Вы можете перечислить все возможные комбинации или попытаться выделить обработку интеллектуально - если это возможно. Например, если из-за самого характера требования существуют возможности N * M = X
, то исчерпывающий перечень методов X
действительно не является хорошим. Следует учитывать необходимость создания возможных форм X
из состава вариантов N
и M
.
Не зная точного требования, трудно сказать. Кроме того, существует множество возможных способов факторизации такой композиции, например Decorator , ChainOfResponsability , Filter и т.д. Это все способы составления сложной логики.
А именно, UI, который жил в невежественном блаженстве о детали реализации OpenFormForViewing, должен обладать знание и создание экземпляра IFormViewCreator.
Презентации должна быть выдана форма, созданная где-то еще, чтобы оставаться агностической от создания формы. Однако форма должна быть собрана/создана где-либо.
В MVC такая логика переходит в контроллер, который обновляет модель/форму и отправляет в правильное представление/визуализацию. То же самое можно сделать с ASP.NET
-121--2417740- Существует множество вопросов относительно стирания типа при переполнении стека (например, Получите универсальный тип java.util.List ), что вы хотите сделать, так это невозможно ни с JNI, ни с самой Java. Сигнатурой типа выполнения foo является (в обоих мирах, или на самом деле, существует только один мир) Object foo (Object u, Object v)
, который будет выполнять неявное приведение класса к возвращаемому значению к тому типу, с которым вы его называете.
Как вы можете заметить (и как указано в комментарии к вашему вопросу), вам нет пути знать, что такое тип T
.
EDIT :
Кстати, метод getFoo должен возвращать 'Foo', так что не стоит ли вам делать
jmethodID getFooMethod = env->GetMethodID(bar_class, "getFoo", "()LFoo;");
Подумайте об этом, вся ваша последовательность вызовов кажется неуместной... у вас есть foo
, который является родным, возвращающимся последовательностям. Теперь foo
ищет getFoo
в строке
, которая возвращает «Foo», и возвращает результат этого вызова напрямую, эффективно пытаясь вернуть Foo
( Foo getFoo ()
согласно комментарию), где ожидается последовательность.
В общем, вы всегда должны использовать javap -s для получения сигнатур методов, которые вы собираетесь искать в JNI. Не угадай.