Какие факторы следует учитывать при выборе среды выполнения / языка для настольных приложений Windows?

У всех моих пользователей Windows. Некоторые из них используют Linux или Mac, но если они это делают, они обычно могут использовать что-то вроде Mono, Wine, Parallels или двойной загрузки.

Моя команда разработчиков (включая меня) имеет большой опыт написания приложений Swing на Java, а также Windows Forms на C #. «Обширный» означает, что мы разработали и поставили более трех приложений в обе среды выполнения. Эти приложения являются приложениями технического анализа, поэтому они слабо взаимодействуют с базой данных, но сильно зависят от пользовательского интерфейса и размеров наборов данных.

Мы подошли к тому моменту, когда мы действительно хотим принять решение о том, на какой платформе сосредоточиться с этого момента, так как это становится бременем для поддержки обоих (если вы работаете в Swing в течение полугода, это слишком много хлопот снова привыкнуть к Windows Forms и наоборот) и мы хотим, чтобы все в нашей команде могли работать над всеми нашими приложениями.

• Windows Forms обычно требует меньше усилий для создания узнаваемых приложений Windows. Никакое количество скинов и пользовательских элементов управления в Java не решило это за эти годы. В то же время у нас никогда не было клиента, который не мог бы использовать приложения Swing.
• Раньше Java имела гораздо более богатую экосистему с точки зрения библиотек и инструментов автоматизированной сборки, но это быстро меняется (Java не падает, тем более что .NET догоняет).
• В редких случаях, когда мультиплатформенность предпочтительнее, Java опережает .NET. Mono - это замечательно, но это все же больше работы, чем Java.

Если мы выбираем .NET, мы можем сосредоточиться на WPF, но также начать использовать F #. Если мы выберем Java, мы можем сосредоточиться на RCP, но также начать использовать Scala.

Кто-нибудь должен был принять подобное решение? Если так, что это было и что повлияло на вас больше всего? Какие-то главные проблемы, которые я пропускаю?

(Обратите внимание: на Programmers.SE уже есть похожие вопросы, но они либо неконструктивны, либо под другим углом.)

Мы пошли на Java (Swing) плюс некоторые нативные части через JNI. В то время как коммерческий спрос на мультиплатформенность сегодня может быть незначительным, ситуация может измениться через 5 лет, и жизненный цикл приложения (приложения для научных измерений) будет более 10 лет (его предшественник C ++, все еще используемый сегодня, имеет исходные файлы от 1991 года). Как вы писали, Java опережает .NET в средах, отличных от Windows, и если нам когда-либо понадобится переключиться с Windows, это просто вопрос перекомпиляции некоторых нативных частей, возможно, тонкой настройки внешнего вида графического интерфейса и проверки того, что все работает.

Если вы уверены, что будете использовать только Windows, а ваше приложение будет работать всего несколько лет, тогда предпочтение может отдаться .NET - оно выглядит и ведет себя больше как собственное приложение, потому что оно есть. Но в качестве долгосрочной инвестиции я больше доверяю Java. Swing может выглядеть немного не идеально, время запуска может быть больше, все немного неоптимально из-за многоплатформенного уровня абстракции, но, по крайней мере, он «просто работает».

Вещь, которую вы можете рассмотреть, - это проект IKVM, позволяющий использовать код Java в мире .NET. Затем вы можете воспользоваться преимуществами Java-бэкенда, в то время как, насколько я понимаю, у вас может быть тонкий передний слой в Swing или WinForms.

http://www.ikvm.net/

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

На MSDN есть ресурс, который может быть вам полезен: http://msdn.microsoft.com/en-us/gg715299.aspx .

Если вы перейдете к нижней части страницы, вы найдете множество технических документов, которые концептуально сравнивают Java и .NET. Конечно, поскольку он находится на MSDN, он смещен в сторону .NET, но ресурсы все еще весьма полезны.

Я тоже немного обдумал это и обнаружил, что ответ зависит от типа проекта и того, что вы можете предвидеть.

Иногда хорошо создать One Codebase для обслуживания всех платформ - вы получаете некоторый уровень согласованности пользовательского интерфейса с меньшим общим кодом. Я думаю, что преимущества и недостатки очевидны, поэтому я пропущу это.

Есть моменты, когда лучше иметь 2 базовых кода. Если, например, написание вашего приложения в WPF элегантно для .NET, а написание, скажем, в Cocoa - элегантно для Mac OS, результирующий код может быть на самом деле меньше, чем, скажем, с использованием Java или Mono (который не имеет WPF). В этом случае вы можете получить лучшие результаты с меньшим количеством кода.

Последнее соображение, возможно, заключается в том, чтобы сделать ваше приложение приложением HTML5 или даже расширением Chrome, но это может быть слишком левое поле.

Вы рассматривали Silverlight ? Это может быть хорошим выбором для сборки приложений Windows Desktop (от SL4 +) и отлично работает на Mac.

Как постоянный Java-разработчик, я могу вам сказать, что, хотя кроссплатформенная совместимость удивительна, каждая нативная интеграция - это ад .

У меня всегда было много проблем, и иногда я терпел неудачу на этом основании. Возможно, вам это и не нужно, но иногда я сталкиваюсь с этим, и это обычно причиняет боль.

• Интеграция с COM - это боль, а COM + иногда невозможен (потраченные впустую недели на то, чтобы заставить его работать с Windows Tablet API).
• Аппаратное взаимодействие может повредить. Иногда API доступен только на одной платформе (например, интеграция камеры / сканера).
• Взаимодействие с локальными приложениями тоже может повредить. Я упоминал, что боль COM? Ну, другой способ (который мы фактически использовали) состоял в том, чтобы сгенерировать и выполнить сценарии VBS, которые запускают приложение Windows, такое как MapPoint, или какое-то проприетарное приложение отображения, и загружают его данными.
• Интеграция и интеграция с рабочим столом (ярлыки, деинсталлятор, меню «Пуск») также могут повредить. Веб-старт очень ненадежен. Альтернативы либо стоят дорого, либо отсутствуют некоторые функции (например, распространение обновлений).

Не пойми меня неправильно. Я Java-разработчик и не хочу его разжигать. Я только говорю, что если вы подозреваете, что вам понадобится что-то из вышеперечисленного, это может повредить, и вам может быть лучше с .net . По крайней мере, это аргумент, который вы должны принять во внимание.