Технически проблемы нет совершенно.

Но осмысленность сего действия не очень понятна. Т.к. "вместо корявых формсовских" Вы напладите еще большую корявость. Кроме того, Forms он для работы с базой данных. Нормально работать _в той же сессии_ умеет только Pro*C, но не Java JDBС*. Делать приложения в котором будет 100500 паралелльных и не связанных между собой сессий - COMMIT'ы придется в каждую строчку кода впихивать.

Под Web-Forms, поддерживаются визуальные Java Bean'ы - проблемы нет, все документировано. В OeBS индусы тоже любят свои корявые Java бины впихивать и потом баги бинов тоннами разгребать.

Последние патчи Forms 6i позволяли и обычные Java модули импортировать. Теоретически должно и в Client-Server работать. Игрался с этим __очень__ давно - подробностей уже не помню. Но Java импортировалась, вызывалась, все работало.

Другое дело, что Java лучше бы использовать (по крайне мере вначала) ту, которая идет вместе с Forms (т.е. старую).

На худой конец, Java завсегда можно через JNI вызвать (проблемs версии не будет, можно любую JVM запустить)

* - Можно, конечно, если делать нечего и за работу платят и свой JDBC драйвер под Forms написать (я бы попытался декомпилировать и "хакнуть" OCI JDBC, писать драйвер с нуля как-то совсем влом), что бы работал через PRO*C и использовал сессию Forms'ов. Насколько это юридически будет законно - не знаю

Как я понимаю, OC4J скорее мертв, чем жив. Т.ч. ADF == Oracle Weblogic

Для разработки приложений, последнии версии ADF вполне юзабильны. IMHO & AFAIK

https://www.oracle.com/assets/technology-price-list-070617.pdf
Oracle Global Price List

Касательно вопроса "Можно ли из FORMS 6.0 запустить явский код?"

Java Importer
https://docs.oracle.com/cd/A97335_02/apps.102/a86202/appc.htm#628076


НО, IMHO что-бы как-то красиво интегрировать новые модули в существующую систему, лично я бы хотел:

1. Визуально создавать окна внутри "родного" приложения.

2. Возможность коммуникации между приложениями.
2,1, В направлении Forms --> другое_средство
2.2. В направлении другое_средство --> Forms

3. Возможность работать в пределах той же сиссии, что и основное приложение.
Стандартно доступно только через PRO*C.

Насколько данные пункты важны и что именно вы хотите порисовать на Swing - я не знаю.

Но если не важны все ))), то формочки можно рисовать на чем угодно HOST build-in никто не отменял.

Если сильно напрячься - то можно

Например можно сделать кодогинератор (через Open Form/Forms API) и в кодогенераторе менять кол-во строк в блоке под конкретный монитор / компьютер.

Сам такое делал в 1999-2001 гг. для www.kamis.ru.

С растягивать по горизонтали - проблем нет. Это можно делать через PL/SQL код. через SET_ITEM_PROPERTY. Единственное, не нужно использовать графические элементы Frame / Line - но по большей части они даром не нужны.

С растягиванием по вертикале - да, все фигово. Нужно менять и компилировать саму форму. Можно делать програмно (кодогенератор) через Open API / Forms API. Сразу же совет - исходные формы хранить в не изменном виде. Кодогенератором править/добавлять элементы и соханять и компилировать в отдельный директорий. От частого изменения формы "замусориваются" и могут "накрыться медным тазом". Поэтому исходный шаблон лучше хранить отдельно и менять только копию.

IMHO & AFAIK

P.S. Когда 10 лет назад внедрял OeBS, то заинтересовался, как данную проблему решают серьезные вендоры. Например на Еврохиме OeBS внедряла IBM. Т.ч. напряг коллег и выяснил про "лучшие практике от IBM". ВСЕ ГЕНИАЛЬНОЕ ПРОСТО !

IBM выпускает ЖИДКОКРИСТАЛИЧЕСКИЙ монитор "спешиал под OeBS" с большой диагональю и НАТИВНЫМ разрешением матрицы 1024 x 768. Вот эти специальные мониторы они на Еврохим и продали вместе с OeBS. Т.ч. и мониторы и большие и современные, и OeBS выглядит красиво )))

А если покупать всякий китайский ширпотреб ))), где нативное разрешение 1920 x 1080 или даже большее - то что же удивляться, что формы от OeBS выглядят как плевок на экране.