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

10

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).

Deckard
fuente
2
Desde el principio de la lectura, creo que el título de la pregunta debería ser "¿En qué factores debo pensar al elegir el tiempo de ejecución / idioma para una aplicación de escritorio de Windows?" , centrándose más en el aspecto de toma de decisiones de su pregunta. Eso es mucho más fácil de responder y menos infeccioso que "¿Qué debo usar?", Una pregunta que parece implicar el título.
Spoike
@Spoike Gran punto, actualicé el título (lo hice un poco más corto).
Deckard
1
Puede ser este enlace tiene algo sobre el futuro de Windows, que es muy importante para ustedes IMHO- zdnet.com/blog/microsoft/...
Gulshan
Obligar a los usuarios de Mac a instalar Wine y ejecutar una aplicación de Windows es lo mismo que torturarlos.
derecha el

Respuestas:

7

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".

Joonas Pulakka
fuente
2
¿De qué manera es una aplicación .NET más una aplicación nativa de Windows que Java?
Rei Miyasaka
@Rei: en el sentido de que .NET Framework solo está disponible para Windows. Claro, hay mono, pero siempre está rezagado, y actualmente su futuro es, bueno, incierto.
Tamás Szelei
1
@ Tamás Esa es una cuestión completamente diferente e incidental. Aparte de los primeros varios bytes de código en los .exes que imprimen "Este programa no se puede ejecutar en modo DOS", el programa sigue siendo completamente código de bytes. Una biblioteca Java es tan nativa de Windows como una .NET, incluso si lo contrario puede ser falso debido a la falta de implementación.
Rei Miyasaka
4

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.


fuente
3

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.

David Salamon
fuente
1

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.

Kevin Hsu
fuente
1

¿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.

ADIMO
fuente
SL está casi muerto ..
klm_
Microsoft no lo cree así. Personalmente, creo que html5 es la primera opción para la aplicación web, pero el SL del lado del cliente puede ser una buena tecnología.
ADIMO
También optaría por HTML5, porque es compatible con W3O. Silverlight compite con HTML5 y creo que si no hace un nicho, morirá.
klm_
1

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.

Konrad Garus
fuente