Windows 데스크톱 응용 프로그램의 런타임 / 언어를 선택할 때 고려해야 할 요소는 무엇입니까?

내 사용자는 모두 Windows를 가지고 있습니다. 그들 중 일부는 Linux 또는 Mac을 사용하지만 일반적으로 Mono, Wine, Parallels 또는 dual-boot와 같은 것을 사용할 수 있습니다.

저 자신을 포함한 저의 개발 팀은 Java로 Swing 응용 프로그램을 작성하고 C #으로 Windows Forms를 작성하는 데 광범위한 경험을 가지고 있습니다. "Extensive"는 두 런타임 모두에서 3 가지 이상의 응용 프로그램을 개발하여 제공했음을 의미합니다. 이 응용 프로그램은 기술 분석 응용 프로그램이므로 데이터베이스 상호 작용에는 약하지만 사용자 정의 UI 및 데이터 세트 크기에는 무겁습니다.

우리는 지금 어느 플랫폼에 초점을 둘 것인지에 대한 결정을 내리고 자하는 시점에 이르렀습니다. 두 플랫폼을 모두 지원해야하는 부담이 되었기 때문입니다. Windows Forms에 다시 익숙해지고 다른 방법으로 돌아갑니다) 팀의 모든 사람이 모든 응용 프로그램에서 작업 할 수 있기를 바랍니다.

• Windows Forms는 일반적으로 인식 가능한 Windows 응용 프로그램을 만드는 데 더 적은 노력을 기울입니다. Java에서 스키닝 및 사용자 정의 컨트롤의 양은 수년 동안 해결되지 않았습니다. 동시에 Swing 애플리케이션을 사용할 수없는 고객은 없었습니다.
• Java는 라이브러리 및 자동화 된 빌드 도구 측면에서 훨씬 더 풍부한 에코 시스템을 가지고 있었지만 빠르게 변화하고 있습니다 (Java는 다운되지 않고 .NET은 따라 잡습니다).
• 드문 경우이지만 다중 플랫폼이 선호되는 경우 Java가 .NET보다 우선합니다. 모노는 훌륭하지만 여전히 Java보다 더 많은 작업입니다.

.NET을 선택하면 WPF에 중점을 둘 수 있지만 F #을 사용할 수 있습니다. Java를 선택하면 RCP에 집중할 수 있지만 Scala도 사용할 수 있습니다.

누구도 비슷한 결정을 내려야 했습니까? 그렇다면 무엇이며 무엇이 가장 영향을 미쳤습니까? 내가 놓친 가장 큰 문제는 무엇입니까?

(참고 : Programmers.SE에는 이미 비슷한 질문이 있지만 구성이 틀리거나 다른 각도로되어 있습니다.)

우리는 JNI를 통해 Java (Swing)와 일부 네이티브 부분으로 갔다. 오늘날 멀티 플랫폼에 대한 상업적 수요는 미미할 수 있지만 상황은 5 년 내에 다를 수 있으며 앱의 (과학적 측정 앱) 수명주기는 10 년 이상이 될 것입니다. 1991 년 소스 파일). 작성한 것처럼 Java는 Windows 이외의 환경에서 .NET을 능가하며 Windows에서 전환 해야하는 경우 일부 기본 부분을 다시 컴파일하고 GUI 모양을 미세 조정하고 확인해야합니다. 모든 것이 작동합니다.

Windows 만 사용한다고 확신하고 몇 년 안에 앱을 사용할 예정이라면 .NET이 선호 될 수 있습니다. .NET은 기본 앱처럼 보이며 동작하기 때문입니다. 그러나 장기 투자로 Java를 더 신뢰합니다. 스윙은 완벽한 것보다 조금 덜 보일 수 있고, 시작 시간이 길어질 수 있으며, 멀티 플랫폼 추상화 계층으로 인해 모든 것이 약간 차선책이지만 최소한 "작동합니다".

고려해야 할 사항은 .NET 세계에서 Java 코드를 사용할 수있는 IKVM 프로젝트입니다. 그러면 Java 백엔드의 이점을 얻을 수 있지만 Swing 또는 WinForms에서 얇은 프론트 레이어를 가질 수 있습니다.

http://www.ikvm.net/

다른 사람들이 번거로운 .NET 버전을 사용하는 대신 .NET에서 Java로 작성된 오픈 소스 연결 라이브러리를 사용하기 위해 이것을 사용했다고 들었습니다.

당신에게 유용 할 수 있습니다 MSDN의 자원이있다 : http://msdn.microsoft.com/en-us/gg715299.aspx .

페이지 맨 아래로 이동하면 Java와 .NET을 개념적으로 비교하는 많은 백서가 있습니다. 물론 그것은 MSDN에 있기 때문에 .NET으로 편향되어 있지만 리소스는 여전히 유용합니다.

나는 이것에 대해서도 약간의 생각을했고, 그 대답은 프로젝트의 유형과 당신이 그것에 대해 예측할 수있는 것에 달려 있다는 것을 알았습니다.

때로는 모든 플랫폼에 서비스를 제공하기 위해 하나의 코드베이스를 작성하는 것이 좋습니다. 전체 코드를 줄이면 UI 일관성이 어느 정도 유지됩니다. 장점과 단점이 분명하다고 생각하므로 생략하겠습니다.

기본적으로 작성된 2 개의 코드 기반이 더 나은 경우가 있습니다. 예를 들어 WPF에서 앱을 작성하는 것이 .NET에서 우아하고 Cocoa가 Mac OS에서 우아하다고 작성하는 경우 결과 코드는 실제로 Java 또는 Mono를 사용하는 것보다 작을 수 있습니다 (예 : WPF). 이 경우 적은 코드로 더 나은 결과를 얻을 수 있습니다 .

마지막 고려 사항은 아마도 HTML5 응용 프로그램 또는 Chrome 확장 프로그램으로 앱을 수행하는 것이지만 너무 왼쪽에있을 수 있습니다.

Silverlight 을 고려 하셨습니까? SL4 이상에서 Windows 데스크톱 응용 프로그램을 빌드하고 Mac에서 잘 작동하는 경우에 적합합니다.

풀 타임 Java 개발자로서 크로스 플랫폼 호환성은 놀랍지 만 모든 기본 통합은 지옥 입니다.

나는 항상이 문제에 대해 많은 문제가 있었으며 때로는 실패했습니다. 당신은 그것을 필요로하지 않을 수도 있지만 때로는 그것을 넘어서서 보통 아파요.

• COM과의 통합은 어려우며 COM +가 불가능한 경우도 있습니다 (Windows Tablet API와 작동하도록 몇 주가 소요됨).
• 하드웨어 상호 작용이 손상 될 수 있습니다. 때때로 API는 하나의 플랫폼에서만 사용할 수 있습니다 (예 : 카메라 / 스캐너 통합).
• 로컬 응용 프로그램과의 상호 작용도 손상 될 수 있습니다. COM 고통에 대해 언급 했습니까? 글쎄, 우리가 실제로 사용한 또 다른 방법은 MapPoint 또는 일부 독점 매핑 응용 프로그램과 같은 Windows 응용 프로그램을 시작하고 데이터를 공급하는 VBS 스크립트를 생성하고 실행하는 것입니다.
• 설치 및 데스크탑 통합 (바로 가기, 제거 프로그램, 시작 메뉴)도 손상 될 수 있습니다. Web Start는 매우 신뢰할 수 없습니다. 대안은 비용이 많이 들거나 업데이트 배포와 같은 일부 기능이 누락되었습니다.

내가 틀리지 마 나는 자바 개발자이며 화를내는 것은 아닙니다. 난 단지 말인지 당신이 의심되는 경우 위의, 그것은 해칠 수해야합니다 그리고 당신은 더 나은 .NET을 해제 할 수 있습니다 . 적어도 당신이 고려해야 할 주장입니다.