¿Qué factores a tener en cuenta al elegir el tiempo de ejecución / idioma para las aplicaciones de escritorio de Windows?

Todos mis usuarios tienen Windows. Algunos de ellos usan Linux o Mac, pero si lo hacen, generalmente son capaces de usar algo como Mono, Wine, Parallels o arranque dual.

Mi equipo de desarrollo (incluido yo mismo) tiene una amplia experiencia tanto en la escritura de aplicaciones Swing en Java como en Windows Forms en C #. "Extenso" significa que hemos desarrollado y enviado más de tres aplicaciones en ambos tiempos de ejecución. Las aplicaciones son aplicaciones de análisis técnico, tan leves en la interacción de la base de datos, pero pesadas en la IU personalizada y los tamaños de conjuntos de datos.

Estamos llegando al punto en el que realmente queremos tomar una decisión sobre en qué plataforma enfocarnos de ahora en adelante, ya que se está volviendo una carga apoyar a ambos (si está trabajando en Swing durante medio año, es demasiado complicado) acostumbrarnos nuevamente a Windows Forms y viceversa) y queremos que todos en nuestro equipo sean capaces de trabajar en todas nuestras aplicaciones.

• Windows Forms generalmente requiere menos trabajo para crear aplicaciones reconocibles de Windows. Ninguna cantidad de skinning y controles personalizados en Java lo ha resuelto a lo largo de los años. Al mismo tiempo, nunca hemos tenido un cliente que no pueda usar las aplicaciones Swing.
• Java solía tener un ecosistema mucho más rico en términos de bibliotecas y herramientas de compilación automatizadas, pero eso está cambiando rápidamente (Java no se está cayendo, es más que .NET se está poniendo al día).
• Para el raro caso de que se prefiera la multiplataforma, Java supera a .NET sin dudas. Mono es maravilloso, pero aún es más trabajo que Java.

Si elegimos .NET podemos comenzar a centrarnos en WPF, pero también comenzar a usar F #. Si elegimos Java, podemos comenzar a centrarnos en RCP, pero también comenzar a usar Scala.

¿Alguien ha tenido que tomar una decisión similar? Si es así, ¿qué fue y qué te influyó más? ¿Alguna de las principales preocupaciones que me estoy perdiendo?

(Tenga en cuenta: hay algunas preguntas similares sobre Programmers.SE ya, pero no son constructivas o desde un ángulo diferente).

Fuimos por Java (Swing) más algunas partes nativas a través de JNI. Si bien la demanda comercial de multiplataforma puede ser marginal hoy en día, la situación puede ser diferente en 5 años, y el ciclo de vida de la aplicación (una aplicación de medición científica) será más de 10 años (su predecesor C ++, que todavía se usa hoy en día, tiene archivos fuente con fecha de 1991). Como escribió, Java supera a .NET en entornos que no son de Windows, y si alguna vez necesitamos alejarnos de Windows, es solo una cuestión de volver a compilar algunas partes nativas, tal vez ajustar la apariencia de la GUI y verificar que Todo funciona.

Si está seguro de que solo será Windows, y su aplicación durará solo unos años, entonces .NET puede ser preferible: se ve y se comporta más como una aplicación nativa porque así es. Pero como inversión a largo plazo, confío más en Java. Swing puede parecer un poco menos que perfecto, el tiempo de inicio puede ser más largo, todo es un poco subóptimo debido a la capa de abstracción multiplataforma, pero al menos "simplemente funciona".

Algo que quizás desee considerar es el proyecto IKVM que le permite usar código Java en un mundo .NET. Luego puede obtener los beneficios de un backend de Java, mientras que, a mi entender, puede tener una capa frontal delgada en Swing o WinForms.

http://www.ikvm.net/

He oído que otros han usado esto para usar una biblioteca de conexión de código abierto escrita en Java desde .NET en lugar de tener que usar la engorrosa versión .NET.

Hay un recurso en MSDN que podría serle útil: http://msdn.microsoft.com/en-us/gg715299.aspx .

Si va al final de la página, encontrará un montón de documentos que comparan Java y .NET conceptualmente. Por supuesto, dado que está en MSDN, está sesgado hacia .NET, pero los recursos siguen siendo bastante útiles.

También he pensado un poco en esto, y he descubierto que la respuesta depende del tipo de proyecto y de lo que puede prever al respecto.

A veces, crear One Codebase para dar servicio a todas las plataformas es algo bueno: obtienes cierto nivel de coherencia de la interfaz de usuario con menos código general. Creo que las ventajas y desventajas son obvias, así que me saltearé eso.

Hay momentos en que tener 2 bases de código escritas de forma nativa es mejor. Si, por ejemplo, escribir su aplicación en WPF es elegante para .NET, y escribirlo en, digamos, Cocoa es elegante para Mac OS, el código resultante podría ser más pequeño que usar, por ejemplo, Java o Mono (que no tiene WPF). En ese caso, puede obtener mejores resultados con menos código.

Una consideración final es quizás hacer su aplicación como una aplicación HTML5, o incluso una extensión de Chrome, pero eso podría ser demasiado campo.

¿Has considerado Silverlight ? Puede ser una buena opción para compilar también la aplicación de escritorio de Windows (de SL4 +) y funcionar bien en Mac.

Como desarrollador de Java a tiempo completo, puedo decirle que si bien la compatibilidad multiplataforma es increíble, todas y cada una de las integraciones nativas son un infierno .

Siempre tuve muchos problemas, y algunas veces fallé, por este motivo. Puede que no lo necesite, pero a veces me tropiezo y generalmente duele.

• La integración con COM es difícil, y COM + es a veces imposible (semanas perdidas tratando de que funcione con la API de tableta de Windows).
• La interacción del hardware puede doler. A veces, la API solo está disponible en una plataforma (por ejemplo, integración de cámara / escáner).
• La interacción con aplicaciones locales también puede doler. ¿Mencioné ese dolor COM? Bueno, otra forma (que realmente usamos) fue generar y ejecutar scripts de VBS que inician una aplicación de Windows como MapPoint o alguna aplicación de mapeo patentada y la alimentan con datos.
• La instalación y la integración de escritorio (accesos directos, desinstalador, menú de inicio) también pueden dañar. Web Start es muy poco confiable. Las alternativas le cuestan mucho o le faltan algunas características (como la distribución de actualizaciones).

No me malinterpretes. Soy un desarrollador de Java y no quiero pretenderlo. Solo digo que si sospecha que necesitará algo de lo anterior, puede doler y podría estar mejor con .net . Al menos es un argumento que debes tener en cuenta.