Переделка Gdsfmt под java

Пусть у нас будет класс JGDS.
Все его методы статические.
Вот список его публичных методов- они практически дублируют методы, описанные в файлах gdsfmt-main.r и methods.r библиотеки Gdsfmt (но мы заменяем точки на нижнее подчеркивание).
Тут перечислены не все методы оттуда, потому что мы будем реализовать только чтение из этих файлов, а не чтение/запись.

openfn_gds
closefn_gds
cleanup_gds
showfile_gds
diagnosis_gds
cnt_gdsn
name_gdsn
ls_gdsn
index_gdsn
getfolder_gdsn
objdesp_gdsn
getfile_gdsn
get_attr_gdsn
compression_gdsn //?
readmode_gdsn //?
read_gdsn
readex_gdsn
apply_gdsn
clusterApply_gdsn //для нее надо будет реализовать класс Кластер или что-то вроде того
cache_gdsn
is_element_gdsn
summarize_gdsn
lasterr_gds
system_gds
print_gds_class
print_gdsn_class
_get
_view_dim2
_view_dim

У него есть также приватные методы, их список ниже. Эти методы нужны для написания кода публичных методов.
Они делятся на три класса:

Класс 1: Функции, которых нет в Java и их надо будет реализовать:

stopifnot(boolean array of variable size) // при невыполнении заданных условий можно просто выкидывать JGdsfmtException, где пишется, что n- ное условие не выполняется
as.data.frame
match.arg
Класс Cluster
parallel::splitIndices
parallel::clusterApply

Класс 2: Функции, которых нет в Java, но их можно не реализовывать:

Если какая-либо функция R не попала ни в один класс, то она принадлежит этому.

normalizePath // встречается в коде только раз.
setOldClass и setMethod, names и class, attr // судя по всему, какие-то R'овские костыли, должно в теории заменяться обычным java-ооп.
file(filename, "wb") из createfn.gds // как я понял, просто создает файл
inherits // http://stackoverflow.com/questions/3504870/how-to-test-if-one-java-class-extends-another-at-runtime
invisible //надо спросить у кого-нибудь, что значит invisible без аргументов, как например в closefn.gds
seq_along
print,paste // может быть, реализовывать все-таки придется
missing
sprintf
identical
rep
match.fun // вместо функции можно передавать обьект, хранящий эту функцию (это единственная его цель)
sapply
.Platform$OS.type
prod
intersect
unname
stop
getOption
requireNamespace
crayon просто выбрасываем
cat

Класс 3: Функции, которые мы обьявляем как native и не реализуем их:

Их реализации лежат в файле gdsfmt.cpp. Эти реализации надо будет изменить: в оригинале они написаны так, чтобы передавать данные в R, а нам надо передавать их в JNI.

Эти функции возвращают либо примитивные типы, либо строки, либо ничего (но они могут пытаться печатать в консоль), либо классы gds (файл формата gds), либо gdsn (нода файла формата gds, может содержать данные или другие ноды).

У классов gds и gdsn есть несколько полей(тут я их не описываю), но нет методов, они только передаются как аргументы в методы класса JGDS.

Над обработкой исключений из c++ еще предстоит подумать, вот тема на SO, дающая представление об этом вопросе: http://stackoverflow.com/questions/4138168/what-happens-when-i-throw-a-c-exception-from-a-native-java-method.

Аргументы указанных функций можно посмотреть в исходниках CoreArray, мы возьмем Java аналоги для JNI типов (т.е. для jint берем int и так далее)