C, Динамическая библиотека, Конфигурация.

Глобальные переменные — вполне разумное решение. Следите за thread-safety и всё будет в порядке.

Только, конечно, инициализировать её нужно специальной функцией, а не из реестра.

Хотя возможно лучше передавать эти параметры первым аргументом, или что то подобное. JNI-методы могут вызываться в контекстве какого-нибудь объекта класса, эти параметры можно, например, сделать членами этого класса. Без специфики задачи трудно сказать больше.

Спасибо за ответ.

Да, параметрами класса было бы здорово их сделать.

Как вы думаете такой вариант подойдет:

Передаем параметры классу в конструкторе (или с помощью мутаторов). Далее пишем n нативных методов и к каждому добавляем эти параметры. Далее пишем пользовательские методы с теми же параметрами что и нативные за исключением дополнительных. Из пользовательских вызываем нативные, подставляя поля класса. Все. Для пользователя прозрачно. Не мучаемся с реестром, глобальными переменными и прочим, прочим.

Что лучше, то что я описал в первом посте или это, при условии, что мне не принципиально хранить параметры в реестре?

> Передаем параметры классу в конструкторе (или с помощью мутаторов). Далее пишем n нативных методов и к каждому добавляем эти параметры. Далее пишем пользовательские методы с теми же параметрами что и нативные за исключением дополнительных. Из пользовательских вызываем нативные, подставляя поля класса.

А зачем так сложно? Библиотека и сама может вытащить значения полей класса. Можно сразу нативные методы дать пользователю, без промежуточных значений.

> Что лучше, то что я описал в первом посте или это, при условии, что мне не принципиально хранить параметры в реестре?

В варианте с реестром практически невозможно использовать библиотеку для двух разных наборов параметров. Её тяжелее портировать на другие системы.

Что касается специфики задачи. Есть некое API, представленное в виде COM объекта. Мне нужно дергать методы этого объекта. Методы этого API хотят определенный URL. Для моей задачи этот URL не меняется, да и не должен, поэтому идея инкапсулировать его в Java класс, которые моделирует этот объект очень мне кажется логичным.

P.S. Я знаю, что есть Java библиотеки для работы с COM, но мне это не подходит. Довольно большой overhead получается.

> А зачем так сложно? Библиотека и сама может вытащить значения полей класса. Можно сразу нативные методы дать пользователю, без промежуточных значений.

Я с JNI никогда ранее не работал, не знал. Спасибо! Надо хорошенько почитать.

Я бы делал JNI-прослойку как можно более тонкой и просто передавал бы в ней параметры/возвращаемое значение/исключения (т.е. никакой логики, исключительно трансляция). А в Java уже бы объявил константу URL и её передавал бы (ну или фасад к этому классу сделать).

Да, так и сделаю. Никакой логики у меня в JNI нет. Она только, что бы дернуть COM, и отдать Java то что он получил. Вся основная логика в Java.

Спасибо за конструктивные ответы!