В недавнем посте я описывал причины, побудившие меня приступить к написанию
библиотеки, целью которой было-бы обеспечение более тесной интеграции двух ЯП:
PowerBuilder и Java. Понятно, что в век dotnet-технологий и смутных перспектив первого,
для кого-то этот пост не вызвал никакого интереса. Тем не менее, для нас эта тема все еще
актуальна (пока). К тому же, такой подход, на мой взгляд, может оказаться полезным при
постепенной миграции имеющихся PB-приложений в сторону Java (при необходимости).

Здесь я хочу привести пример небольшого тестового приложения, которое в общих чертах
отображает архитектуру и способ взаимодействия двух языков на основе созданной
библиотеки (beta-версия).

Итак,
имеем следующее окно в PB



Предварительно создана и инициализирована глобальная переменная jvm,
выполнен коннект к базе данных DemoEAS и отобажен список покупателей
из таблицы customers . В окне создана instance-переменная inv_jobject ,
а ее инициализацию проводим в событии open рабочего окна:



Определение java-метода может показаться чем-то потусторонним. На самом
деле, все не так страшно. Первый параметр - это имя метода, второй - его
сигнатура на Java. Правила описания сигнатур методов достаточно просты и
выложены на официальном сайте Java, в разделе о JNI. Именно эта Java-
сигнатура методов и прячется в proxy-объектах PB, от которых я отказался в
принципе из-за их жесткой сцепкой с IDE. Кстати, в PB тоже есть сигнатуры
методов, только они имеют другие правила описания и их можно увидеть в
специальном окне Browser все той-же IDE.
Вообще, чтобы каждый вызов часто используемых методов не стал лишней
головоломкой, просто надо спрятать их в соответствующие методы-обертки и
пользоваться только последними.

Приведу исходник Java класса Controller.java



Как видно из текста, в Java мы будем работать с тем же самым PB-объектом
(экземпляром) класса DataWindow, переданном в качестве параметра методу
open . Только его тип, при доставке в среду Java, будет автоматичеси
преобразован в PBDatawindow - зеркальный класс, для работы с dw-объектами.
Вернемся к PB.

Событие окна close


Событие clicked по щелчку на кнопке NY'ers :


Событие clicked по щелчку на кнопке Top 20 :


Обычный MessageBox(), но вызванный из Java:



Событие clicked по щелчку на кнопке Get syntax :


Разработку и отладку кода на стороне Java можно проводить в любой IDE-среде,
умеющей работать с Java. Например, Eclipse (доступна и полностью бесплатна).

to Локшин Марк

Подход, связанный с REST и AppServer - это уровень, требующий пересмотра всей
архитектуры имеющегося client/server приложения. В данном случае делается попытка
предоставить конечному пользователю механизм расширения функционала системы на
стороне клиента, используя более известный и широко используемый язык программирования.
Многозвенное решение можно заложить на стороне скриптов-обработчиков Java, но это
будет следующим этапом.

Основную задачу, которая изначально ставилась, а именно дать возможность расширения функционала приложения легальным способом - я, в общем-то, выполнил. Сейчас идет отладка, зачистка и пр. си-кода и написания соответствующих классов на Java для работы с PB. Чуть позднее, планирую закинуть в продакшн.

По поводу идей использования. Не скажу, что я большой спец и практик по Java, но какие мне видятся преимущества такого подхода:
1) помимо написания скриптов-контроллеров, возможность модульного расширения имеющейся системы на основе подключаемых плагинов
2) более широкие возможности по работе с сетью и web-сервисами
3) подключение к JavaFX , а это не только полноценная 2D/3D графика. Это качественно новый интерфейс с возможностью работы как в вебе, так и на десктопе. И, соответственно, при необходимости более плавная миграция в новую среду имеющихся наработок.
4) это, пусть пока и небольшой, шаг к созданию кроссплатформенного решения

P.S.: Конкретные примеры, если будет интерес, выложу чуть позже.

Локшин МаркС тем же успехом можно было бы исполнять на VBScript что-нибудь например

На VBScript/JScript можно, но только с использованием COM-объектов, а такой подход имеет ряд существенных недостатков, как с точки зрения проектирования, так и дальнейшей реализации. К тому-же производительность такого решения будет существенно ниже, чем pure C++ и Java. Хотя, последний аспект для многих приложений, тесно связанных с обработкой данных и использованием БД не столь принципиален.

По поводу JavaFX - с моей стороны это скорее была фантазия, возможно, и не такая уж далекая от реальности. В мире Java, как я понял, вообще все очень быстро меняется - так что немудрено и ошибиться.