Миграция RPG на Java в IBM iSeries

моя компания также пытается перейти на Java из RPG.

1. мы не пытаемся использовать JRE на тонком клиенте, мы переходим к веб-приложениям, поставляемым через браузер. Это может повлечь за собой (в конечном итоге) замену наших старых POS-сканеров некоторыми из новых на базе ПК.
2. Я был проинформирован (архитекторами компании), что JVM на ISERIES OS тут есть некоторые проблемы с производительностью. Я лично не знаю, что эти ограничения. В нашем случае миграция включала выделение ресурса AIX, что должно быть намного лучше - поговорите с вашим представителем IBM о том, нужно ли вам просто купить лицензию на ОС (я просто программирую на эту вещь, я не участвую в аппаратном обеспечении).
3. см. ответ на вопрос 1. В более широком контексте, где вы пытаетесь обновить обозреватель (или любой другой ресурс), это обычно обрабатывается с помощью корпоративных лицензий-большинство из них будут иметь разрешить принудительные удаленные обновления.

некоторые другие Примечания:

• вы должны быть в состоянии перейти только с помощью .NET, хотя вам может понадобиться разные оборудование / разделы для запуска среды. По крайней мере, так можно разговаривать с DB2. Единственное преимущество Java заключается в том, что он будет работать на той же ОС/оборудовании, что и база данных.
• Я видел приложение screenscraper здесь (это было в VB.NET, но я уверен, что пример применяется.) Скребок экрана был выполнен путем получения / ввода символов в определенные позиции на экранах (эквивалент substring()). Это может быть просто API, который мы использовали - я думаю, я слышал о решениях, которые могли читать имена полей. Тем не менее, он также полагался на поток программы RPG для своей логики и в противном случае не был доступен.
• большинство программ RPG, которые я видел и писал, как правило, являются нарушением MVC, то есть вы не можете сделать ничего меньше, чем интеграционное тестирование-история и архитектура самого языка (и некоторых разработчиков) предпочитает, чтобы все (доступ к файлу на экран) было в одном файле. Это также сделает невозможной попытку обернуть RPG для удаленного эффективного вызова. если вы правильно разделили все на служебные программы, вы должны иметь возможность обернуть их (как эквивалент собственного вызова метода, почти) аккуратно - к сожалению, я ничего не видел здесь это не склонно полагаться на один или несколько трюков, которые не будут выполняться для обычного веб - использования (например, использование файла в QTEMP для управления выполнением программы-сеанс на iSeries эффективно исчезает каждый раз, когда запрашивается новая страница...).
• Java как язык, как правило, способствует лучшему разделению кода (обратите внимание, что его можно использовать так же плохо), поскольку он не имеет истории RPG. В общем, может быть полезно думать о Java как о языке, где все это служебная программа, где все параметры передаются с VALUE установлено, OPTIONS(*nopass : *omit) запрещено, CONST обычно рекомендуется, и большинство параметров имеют тип DS (datastructure - это отдельный тип в RPG) и передается указателем. Параметры уровня модуль с неодобрением, если пользу инкапсуляции все в прошло структур или сервисной процедуры сами. STATIC имеет несколько другое использование в Java, делая переменную глобальной и недоступно внутри процедур.
• RPG довольно немного проще, чем Java, как правило, и OO-программирование-это совсем другая парадигма. Вот некоторые вещи, которые, вероятно, заставят разработчиков перейти на Java:
  1. массивы в RPG начинаются с 1. Массивы в Java начинаются с 0.
  2. Java не имеет параметров "ouput", и все примитивные типы передаются по значению (копируются). Это означает, что редактирование целого числа не будет отображаться при вызове методы.
  3. Java не имеет упакованной / подписанной кодировки, и поэтому перевод в / из чисел / строк является более сложным. Тип даты в Java также имеет некоторые серьезные проблемы (он включает в себя время, вид), и гораздо сложнее осмысленно изменить/из символьного представления.
  4. труднее читать / писать файлы на Java, даже при использовании SQL (и забыть об использовании собственного ввода-вывода непосредственно с Java) - это можно несколько смягчить с помощью хорошей структуры, однако.
  5. нет ENDxx операторы в Java, все использует квадратные скобки ({}), чтобы указать начало/конец блоков.
  6. все в Java находится в freeformat, и нет никаких столбчатых спецификаций любого рода (хотя подписи процедур по-прежнему требуются). Там нет hardlimit на длине линии, хотя ~80 символов по-прежнему рекомендуется. Инструменты (свободный те, даже) лучше, период и вообще гораздо более полезны (хотя они могут занять некоторое привыкание для тех, кто подвергается SEU). Есть также огромные, бесплатные библиотеки, доступные для скачивания.
  7. на = знак не является контекстно-зависимым в Java, как это в RPG, это всегда используется для задания. Используйте double-equals,== оператор для сравнения значений в Java.
  8. объекты (datastructures) не могут быть осмысленно сравнены с == - вам часто нужно будет реализовать метод под названием equals() вместо.
  9. строки не изменяются, их нельзя изменить. Все операции, выполняемые над строками (либо над самим классом / структурой данных, либо из внешних библиотек), возвращают новые ссылки. И да, строки считаются datastructures, а не типы значений, поэтому вы не можете сравнить их с == либо.
  10. нет встроенных эквивалентов /copy предварительно директив компилятора. Попытка реализовать их использует Java неправильно. Поскольку они обычно используются для работы с "шаблонным" кодом (определения переменных или общий код), лучше иметь дело с этим в архитектуре. Переменная (все D-спецификации, на самом деле) definitons будет обрабатываться с import или import static операторы, в то время как варианты общего кода обычно обрабатываются платформой или определением нового класса.

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