Я думаю, что это вполне возможно, но это означало бы другое восприятие серверной стороны.
Если вы выполняете разработку на основе интерфейса POJO серверных компонентов, с которыми пользовательский интерфейс взаимодействует для выполнения работы, вы оставляете за собой возможность реализации в памяти или в качестве прокси для удаленного компонента. , Пользовательский интерфейс рабочего стола Swing может использовать версию серверной части в памяти, а версия GWT взаимодействует с распределенной версией.
Если вы используете Spring, легко внедрить соответствующую реализацию для каждого пользовательского интерфейса. Оба знают только об интерфейсе и не обращают внимания на детали реализации.
Я представляю одну кодовую базу, которая может быть упакована разными способами. Настольное приложение Swing будет упаковано и доставлено в виде файла JAR. Он не будет включать классы контроллеров GWT или веб-уровня. База кода GWT будет включать веб-конфигурацию и контроллеры, потому что контроллеры действительно являются частью веб-уровня.
Интерфейс сервиса и все, что за ним стоит, останутся одинаковыми для обоих. Единственным отличием будет то, что конфигурация рабочего стола Swing будет внедрять реализации сервисного уровня в оперативной памяти интерфейса сервиса. Веб-конфигурация будет внедрять веб-реализации интерфейса службы.
Является ли моя попытка прочитать ваши мысли о требованиях правильной или нет, этот подход имеет ценность независимо от того, как вы решите реализовать уровни обслуживания и клиента.
Я фанат Spring, поэтому я бы рекомендовал использовать Spring.