Озверин1) Считаете ли вы, что разработка сложных gui на java - достаточно трудоемкая операция(по времени, возможно по прикладным усилиям)?

Да. Считаю.

Озверин2) Если считаете, то как выходите из положения?

Из какого положения? Swing - наше всё. Мучаемся, грызем кактус.

Озверин3) Когда либо использовали связку из каких нить WinForms(gui)+Java(Back End) ?

Нет, не использовали.

ОзверинУ меня сложилось устойчивое отвращение к swing библиотеке

Нормальная либа. Просто нужно разобратся во всех нюансах.

Озверин, возможно именно потому мне кажется разработка чуть более, чем сложно интерфейса немного трудоемкой операцией.

Сейчас как раз педалируем сложный интерфейс. Грабли все типичные. В следующий раз просто сделаем сразу правильно.

ОзверинЕсть цель - перевод старого проекта с access на java.

JavaFX

ОзверинЕсть идея - написание back end`а(сервис шина), написание по одному сервиса для шины, но интерфейс пока-что оставить в access(условно, это возможно при сохранении требуемого быстродействия). Зачем? Чтобы можно было уже "сейчас" предоставить бизнесу по одному работающему сервису, а не ждать перевода всей "программы" несколько лет.
Ну, нормальный подход в бизнесе делать что-то поэтапно если возможно. Первый этап позволит вскрыть большую часть потенциальных граблей и обойти их в будущем.

ОзверинКто что думает?
Не очень понял про Access. Оставить его в качестве UI?

ОзверинJava выигрыывает при интеграции сервисов

К GUI не относится.

ОзверинJava выигрывает при высоконагруженных сервисах

К GUI не относится.

ОзверинJava выигрывает по качеству сообщества и решений

К GUI относится частично. Опытных GUI разработчиков на Java минимум. Решения есть интересные, это правда.

ОзверинА если бы на вас давил бизнес, допустим, что надо делать быстрее - кровь из носу.

Так а нельзя, разве, Access оставить в качестве GUI и через какой-нибудь протокол завязать его на Java сервер?

ОзверинПри условии, что ресурсов не хватает (как качественных, так и количественных), могли бы писать gui на "другом" языке?

Не понял вопроса. Я мог бы на чем угодно писать. Но если есть команда VB формошлеперов, глупо пытаться с ними наваять что-то на Java в разумные сроки.

ОзверинВопрос скорее не конкретного выбора(если конечно куда то упадет, я только за), сколько за рассуждения о плюсах , минусах (Для примера, взять jpython который вроде как компилицо стандартным jvm и на нем за 2 секунды чтонибудь набросать)
Быстро клепать можно и на WindowBuilder Pro + MigLayout. Проблема только в том как всё это подружить с сервером и логикой толстого клиента. И эта проблема никуда не уйдёт независимо от платформы реализации. Логика вообще будет на толстом клиенте, или максимально серверная?

GregTkНезнаю как другим, а мне нравиться писать на SWING
+1

GregTkи не вижу проблем со скоростью написания.
Не сталкивались значит. Есть геморой со стилизацией. Есть геморой с отдельными контролами. Есть геморой с нестандартными контролами. Для многопоточности только SwingWorker. Синхронизировать поведение будь добр сам.
Много всего достаточно стандартного приходиться кодить самостоятельно.

GregTkКонечно с наскоку нормально не получиться, нужно обрастить свой код удобным каркасом, но это не проблема.

Во-во. Это как раз проблема. Swing Application Framework-а очень не хватает. Каждый ваяет его теперь сам.

GregTkНо с JavaFX не всё так празрачно как со свинг.

Что там не прозрачно? Биндинг, например, более прозрачный.

GregTkСталкивался и с многопоточностью, но видимо не с теми задачами что у вас

Ну, в целом, нет никаких инструментов для этого. Запустили фоновую задачу (запрос на сервер). Юзер что-то делает. А потом нужно как-то "мержить" действия юзера и результат фоновой задачи.
Или например, некоторые действия нужно "запрещать". А некоторые можно просто "откладывать", пока фоновая задача не выполнется.

GregTk, а со стилизацией проблем не было правда юзал XUI Framework для этих целей.

Мало готовых фич. Много нужно руками делать. Причем шаг влево/шаг вправо - расстрел (отрисовка на глаз начинает тормозить).
Новые LAF слишком перемудрены. Делать Painter-ы для Nimbus тоже никакой радости нет.

GregTk Суть не в этом, суть в том что больше раздувают проблемы. Как будто в других фреймворках нет проблем.

Везде есть. Везде разные. Поэтому лучше брать то что хорошо знаешь.

GregTk А вот binding в JavaFX мне показался немного перегруженым так как для обычного POJO, который описывает данные придётся делать DTO
DTO решает задачу комуникации сервера и клиента. JavaFX проперти добавить в POJO, по-моему не проблема.
Тут, кстати, вопрос архитектуры. На самом деле биндить прямиком на сущности плохая затея. Потому что часто возникают задачи отделить пользовательский ввод, от изменений сделаных кодом. Или просто перехватывать ввод через биндиг для каких-то целей.
Т.е. от доплнительных слоёв никуда не деться.


GregTkи этот шлак нельзя вынести в xml или куда-нибудь ещё.
XML зло. О каком ещё шлаке речь?

MasterZiv1) Считаете ли вы, что разработка сложных gui на java - достаточно трудоемкая операция(по времени, возможно по прикладным усилиям)?
Да. И главное -- бесполезная.

Аргументацию хотелось бы послушать.